Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 157950 - nslookup doesn't handle arguments correctly
Summary: nslookup doesn't handle arguments correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-17 12:38 UTC by Radek Vokál
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 9.3.1-6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-05 00:03:26 UTC
Type: ---

Attachments (Terms of Use)
tcpdump output (3.44 KB, text/plain)
2005-05-18 07:44 UTC, Radek Vokál
no flags Details

Description Radek Vokál 2005-05-17 12:38:44 UTC
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):

How reproducible:

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

Name:   garfield.redhat.usu
-- correct

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

Additional info:

Comment 1 Jason Vas Dias 2005-05-17 16:29:09 UTC
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 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:

       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 Vokál 2005-05-18 07:44:15 UTC
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

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 16:12:58 UTC
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 ( 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 Vokál 2005-05-19 06:36:29 UTC
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

# cat hosts       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

Comment 5 Jason Vas Dias 2005-05-19 14:00:25 UTC
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-21 00:35:25 UTC
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 19:04:09 UTC
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 19:56:37 UTC
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.