Red Hat Bugzilla – Bug 157950
nslookup doesn't handle arguments correctly
Last modified: 2007-11-30 17:11:06 EST
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):
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
Expected Results: An error message, invalid number of params...
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 :
look up name using servers in resolv.conf
nslookup - server
enter interactive mode with server
nslookup name server
query server for name
Created attachment 114497 [details]
Dammed, there's sth wrong about my configuration. I've got similar output with
$ 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
# 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.
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 .
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
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
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 .
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
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.
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.
bind-9.3.1-6 now in rawhide with the fix