Bug 173276 - hostname resolution on strictly local Ethernet
hostname resolution on strictly local Ethernet
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lftp (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Maros Barabas
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-15 16:09 EST by Jim Haynes
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-21 22:16:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jim Haynes 2005-11-15 16:09:14 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:
Comment 1 Jason Vas Dias 2005-12-19 12:18:48 EST
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.
 
 
Comment 2 Jim Haynes 2005-12-19 12:46:32 EST
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.
Comment 3 Fedora Update System 2005-12-19 20:21:38 EST
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.
Comment 4 Jim Haynes 2005-12-19 21:55:04 EST
Thanks.  Now it connects immediately given a hostname in /etc/hosts, which is
what I expected it to do.
Comment 5 Bill Nottingham 2006-09-21 22:16:30 EDT
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.

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