Bug 157950 - nslookup doesn't handle arguments correctly
nslookup doesn't handle arguments correctly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-17 08:38 EDT by Radek Vokal
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 9.3.1-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-04 20:03:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
tcpdump output (3.44 KB, text/plain)
2005-05-18 03:44 EDT, Radek Vokal
no flags Details

  None (edit)
Description Radek Vokal 2005-05-17 08:38:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Fedora/1.0.4-2 Firefox/1.0.4

Description of problem:
nslookup in noninteractive mode should accept only two parameters. 

Version-Release number of selected component (if applicable):
bind-9.3.1-2_FC4

How reproducible:
Always

Steps to Reproduce:
root@echo ~# nslookup gafield
nslookup: couldn't get address for '\uffff\uffff\uffff\uffff`\uffff\uffff\uffff\uffffp': not found
-- this is wrong and should be stamped out

root@echo ~# nslookup garfield bunny
Server:         bunny
Address:        192.168.1.2#53

Name:   garfield.redhat.usu
Address: 192.168.1.13
-- correct

Expected Results:  An error message, invalid number of params... 

Additional info:
Comment 1 Jason Vas Dias 2005-05-17 12:29:09 EDT
tsk, tsk! You're meant to be using "dig" or "host", not nslookup,
which is "deprecated" :)

nslookup may even be withdrawn completely soon in forthcoming 
ISC BIND releases.

About Issue 1:
# nslookup gafield
nslookup: couldn't get address for
'\uffff\uffff\uffff\uffff`\uffff\uffff\uffff\uffffp': not found

How did you manage to get nslookup to do that ?
I can't reproduce this problem. 

When I do an nslookup for a host for which the nameservers configured
in resolv.conf, or any root nameservers reachable through recursion,
do not have authoritative data, I get:

$ nslookup gafield
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find gafield: NXDOMAIN

Please append some further information to this bug report:
 - your /etc/resolv.conf
 - your "hosts" entry in /etc/nsswitch.conf
 - a tcpdump from when the problem was reproduced:
   # tcpdump -i any -nl -vvv -s 2048 port domain >/tmp/domain.log 2>&1 &
   # nslookup gafield
   ...
   # pkill tcpdump
   and append the /tmp/domain.log file to this bug.

 
About Issue 2:
   
   Actually, nslookup is meant to accept up to 2 command line
   arguments - see man nslookup(1), which states:

SYNOPSIS
       nslookup [ -option ]  [ name | - ]  [ server ]

   ie. these are all valid :

       nslookup name
           look up name using servers in resolv.conf
     
       nslookup - server
           enter interactive mode with server

       nslookup name server
           query server for name

Comment 2 Radek Vokal 2005-05-18 03:44:15 EDT
Created attachment 114497 [details]
tcpdump output

Dammed, there's sth wrong about my configuration. I've got similar output with
dig ...

$ dig bunny
dig: couldn't get address for '\uffffL\uffff\uffff\uffffL\uffff\uffffY"': not
found

I've got nameserver configured locally, so these are my settings

$ cat /etc/resolv.conf
search redhat.usu devel.redhat.com
nameserver localhost

# cat /etc/nsswitch.conf | grep hosts
hosts:	    files dns

The output from tcpdump looks quite strange (the output is with dig command).
Why is it searching for such a strange hosts? 

Would you like to see /etc/named.conf as well? I don't see anything special
there, it's just configured for redhat intranet and for my DNS.
Comment 3 Jason Vas Dias 2005-05-18 12:12:58 EDT
Yes, please attach your named.conf file.
Do you put any named options in /etc/sysconfig/named $OPTIONS ?

It's possible this could be a locale support issue - all the domain
names in the tcpdump and in dig output look garbled.

What locale are you using ( cat /etc/sysconfig/i18n ) ?
Is the problem fixed if you switch to the "en_US" locale and reboot ?
What architecture is your machine (could be a wide char issue) ?

Note that "dig" does not use the "search" path in /etc/resolv.conf -
"host" does. So the DNS servers were trying to return NXDOMAIN for
the lookup of "bunny.", but somehow the names are getting garbled.

Note: it's best to have the IP address (127.0.0.1) in your resolv.conf
      rather than the dns name (localhost). The resolver first has
      to lookup localhost for every DNS lookup, and hopefully finds it
      in /etc/hosts .
Comment 4 Radek Vokal 2005-05-19 02:36:29 EDT
Hey! That was it, I've changed the dns name for loopback IP and it works now.
Changing it back to 'localhost' and it's broken again. 

Anyway, the domain search should work while my hosts seems to be configured
correctly. 

# cat hosts
127.0.0.1       localhost.localdomain   localhost

In adition, this is  2.6.11-1.1287_FC4smp kernel, i686, locale is en_US.UTF-8

The `host` has exactly same behaviour, 
nameserver set to localhost:
# host garfield
host: couldn't get address for \uffffw      
\uffff\uffff\uffff\uffff\ufffft\uffff': not found

changing it to loopback IP
# host garfield
garfield.redhat.usu has address 192.168.1.13
Comment 5 Jason Vas Dias 2005-05-19 10:00:25 EDT
The resolver(5) man-page does say:
'  nameserver   IP address of a DNS server to use.'
                ^^^^^^^^^^

Nowhere does it say you are allowed to use DNS names for nameservers
in resolv.conf - indeed, you should not be allowed to use DNS names
for nameservers, as this could lead to infinite recursion if you have
'hosts dns...' in nsswitch.conf .

But glibc's resolver should not accept an incorrectly specified 
resolv.conf, nor should the BIND resolver .

I'll investigate making BIND detect and complain about resolv.conf mistakes .
I suggest glibc should do the same .

  
Comment 6 Ulrich Drepper 2005-05-20 20:35:25 EDT
This certainly won't change in glibc and IMO shouldn't change in bind.

Even before NSS there was the option to specify which services to use for name
lookups and in which order.  It always was possible to use names if the names
can be resolved by services used before DNS.  There are definitely people out
there depending on this and it makes no sense to break those uses without any
real reason.

Yes, the man page says IP address.  And I in most situations agree that this
should be used.  But using a name is not necessarily invalid.  There never has
been such wording.  It's just unspecified what happens and the assumption for
the last 20 years has been that names can be used in certain situations if the
sysadmin knows what s/he does.
Comment 7 Jason Vas Dias 2005-05-31 15:04:09 EDT
This issue will be fixed in bind-9.3.1-6 : if no "nameserver" 
entry in resolv.conf parses as an IPv4 or IPv6 address, then
dig, host and nslookup will return an error - they were 
actually detecting but ignoring resolv.conf parse errors.

dig, host and nslookup are tools for DNS lookups only, and should
not fall back to the glibc behaviour of trying /etc/hosts or NIS
lookups as configured by nsswitch.conf if a resolv.conf nameserver
entry does not parse into an address.
Comment 8 Jason Vas Dias 2005-05-31 15:56:37 EDT
bind-9.3.1-6 now in rawhide with the fix

Note You need to log in before you can comment on or make changes to this bug.