Red Hat Bugzilla – Bug 173276
hostname resolution on strictly local Ethernet
Last modified: 2007-11-30 17:11:17 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Machines are on a strictly local Ethernet, all hostnames in the /etc/hosts file, /etc/nsswitch.conf specifies for hosts: files dns lftp <hostname> sits for a long time [Resolving host address...] before it times out and finds the address in /etc/hosts. Other commands e.g. ftp <hostname> connect immediately. If there is a gateway from the local Ethernet to the Internet then lftp resolves the host address immediately, even though the host address is not findable through the Internet DNS. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Have a local network with no connection to the outside world 2.lftp <hostname> where <hostname> is listed in /etc/hosts 3. Actual Results: [Resolving host address...] (long wait) (finds the address and connects to the host) Expected Results: Should have obeyed the directive in /etc/nsswitch.conf and looked in the host table first. Additional info:
Sorry for the delay in responding to this bug report. This problem is now fixed with lftp-3.2.1-8_FC4, and lftp-3.3.5-1 (FC-5/Rawhide). Part of this problem is due to a misconfiguration issue - you have 'hosts: files dns' in /etc/nsswitch.conf, even though you say you have no DNS servers configured and do not wish to use DNS. When the 'dns' method is in the nsswitch.conf 'hosts:' database line, glibc will always attempt to contact DNS servers - if no DNS servers are in resolv.conf, glibc will try to contact a DNS server on the local host . Thus, when a host is not found, glibc returns a 'TRY_AGAIN' error instead of a 'HOST_NOT_FOUND' error - this is because it was unable to contact DNS servers and thus the non-existence of records for a host name is non-authoritative . lftp, while it receives the glibc 'TRY_AGAIN' error code, will continue to reissue the request, until a timeout occurs ( the default is no timeout - see 'dns:fatal-timeout' setting in the lftp man-page ). By default, lftp looks up IPv6 addresses for host names, and then IPv4 addresses - see the 'dns:order' setting in the lftp man-page . So if nsswitch.conf contains 'hosts: files dns', and lftp looks up IPv6 addresses first, and no IPv6 addresses are defined in /etc/hosts, and no nameservers can be reached, lftp will hang forever trying to look up the IPv6 address for a host name. So the fix for this is to remove 'dns' from the /etc/nsswitch.conf hosts line . But there were some issues with lftp behavior when 'dns' is in the nsswitch hosts line and no nameservers can be contacted: o While no address of a given family in 'dns:order' is found, with the TRY_AGAIN error, no other address families for a name will be looked up - so even if /etc/hosts contains an IPv4 address for a name, it will never be found, while the IPv6 address lookups return TRY_AGAIN o Even if 'dns:order' is 'inet inet6', any IPv4 address in /etc/hosts would never be used, because lftp would never stop trying to lookup the IPv6 address while the lookups return TRY_AGAIN . o Even if you specify a 'dns:fatal-timeout' > 0, when the timeout is reached, and an IPv4 address WAS found but no IPv6 address was found, the IPv4 address would not be used and the whole lookup would fail. These issues are now fixed with lftp-3.2.1-8_FC4, and lftp-3.3.5-1 (FC-5/Rawhide): o There is now a 'dns:use-first-address' setting, which defaults to true, that will make lftp use the first address returned for a lookup, even if lookups for other families return TRY_AGAIN . o If dns:fatal-timeout is > 0, when the timeout expires, and an address of one family in dns:order was found, it will be used, and the lookup will not be designated a failure. o There is now a 'dns:n-attempts' setting, which defaults to 0, and if >0, specifies the maximum number of times to retry the lookup after TRY_AGAIN is returned. o There is now a 'dns:try-again' settting, defaulting to true, which if false, will disable retrying lookups that fail with TRY_AGAIN. These new settings are also documented in the lftp man-page. I'm releasing lftp-3.2.1-8.FC4 into FC-4 Updates/Testing today - please try it out and let me know of any issues - thanks.
Thanks. The reason I have hosts: file dns in there is (1) that's the way it comes by default, and (2) when I need to I can bring up a gateway machine on the local net to get to the Internet. And I took it to be a bug because the plain old ftp program seems to do the right thing regardless of whether the gateway is up or down.
From User-Agent: XML-RPC lftp-3.2.1-8_FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Thanks. Now it connects immediately given a hostname in /etc/hosts, which is what I expected it to do.
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists in a current Fedora release (such as Fedora Core 5 or later), please reopen and set the version appropriately.