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:
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
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.
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 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
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 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.
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