Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 76543 - name to IP resolution issues
Summary: name to IP resolution issues
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
: 81737 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-23 03:45 UTC by Need Real Name
Modified: 2016-11-24 15:15 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-24 05:31:41 UTC

Attachments (Terms of Use)

Description Need Real Name 2002-10-23 03:45:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
Resolver.  General problem with name to IP resolution.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See Additional information section for configuration information

Actual Results:  See Additional information section for configuration information

Expected Results:  names should be resolved to IP via files when files specified
first.  BIND should resolve locally first when local host names are used.

Additional info:

There appears to be a general issue with name to IP resolution in RedHat Linux
8.0.  This is present in a number of different situations.

Senerio 1.  Initially I was working with a simple files based network setup. 
That is my system names were listed in /etc/hosts both as fqd names (dot 3) and
short (just server name) name alias.  Both /etc/host.conf and /etc/nsswitch.conf
were set for files first and then dns.  My IP's nameservers where set in
/etc/resolv.conf.  The first thing I noticed is that when trying to connect to
systems on my local network with this setup ssh and telnet attempt to resolve
via DNS first.  Only after the attempt times out or otherwise fails will it fall
back to files.  This is true both with short and fqd system names.  Oddly enough
ping is not effected.  With ping the hostnames appeared to immediately resolve
directly from /etc/hosts without an internet DNS lookup attempt.  I am throughly
convinced the behavior under this senerio is a bug.

Senerio 2.  Decided to setup a DNS (BIND) server for my local network.  Slightly
different resolution pattern observed.   All fqd (dot 3) local network system
names resolved without issue for ssh, telent, and ping.  However, short names
did not appear to resolve properly.  Encountered delays before they would
resolve via local DNS (I had commented out entries in /etc/hosts and had
internet DNS disabled to ensure I was resolving only through my DNS).  At first
I thought this was a setup problem with my DNS server but I found that when I
tried ping the system names resolved immediately without delay even with just
short (host) names.  It seems almost as if the domain name is not being
appropriately taken into account when using ssh and telnet during the hostname
resolution.  I tried entering the domain into /etc/resolve.conf but there was no
change.  Either way ssh and telnet attempted to contact outside DNS servers
(this could be evidenced in firewall logs after setting the fw to drop outbound
DNS at the gateway) before using the local zone information, however, ping
immediately resolved using the local zone information without attempting to
contact internet servers.

Sernerio 3.  The final thing to report is that I have just observed that mail
(sent from anacron to root on the local system in this case) appears to be
subject to external DNS resolution attempts when using the files based network
setup described in senerio 1.

Comment 1 Need Real Name 2002-10-23 03:48:02 UTC
Not component is not properly classified but I could not determine proper
library.  Please reclassify.

Comment 2 brandon 2003-01-01 21:05:03 UTC
This bug also appears as bug 77538  

RedHat: (can we get || is there) a master bug for this issue ?

Comment 3 Landon Curt Noll 2003-01-02 00:20:59 UTC
I can confirm this bug.  In fact this bug has become a show 
stopper for our RH7.3 to RH8.0 upgrades.  This problem does 
not show up in RH7.3, FYI. 
Please consider changing the Priority of this bug from normal 
to high. 

Comment 4 Landon Curt Noll 2003-01-02 00:38:14 UTC
FYI: I think this bug is better worded and addresses the    
more general problem than bug 77538.   
This general bug is related to /etc/nsswitch.conf.  The command:   
	rpm -q -f /etc/nsswitch.conf   
shows that /etc/nsswitch.conf is part of the glibc component.   
And the client/user-side name resolver is found in libc/glibc.   
In addition to changing the Priority to high, I recommend that  
the Component be changed to 'glibc'.  I believe that normally 
the Bug author ( is able to make these 
changes.  So, please make those changes 
in the 'Edit Bug Information' section and click submit below. 

Comment 5 Tim Mitchell 2003-01-02 00:45:59 UTC
NIS/ypbind is suspected to not work correctly as a client in RH 8.0. I have
received reports from co-workers and will provide additional information during
week of  6-January-2003. Having read Bug# 77539, and this bug I believe there is
a serious defect in a name resolution library.

Comment 6 Tim Mitchell 2003-01-02 00:47:31 UTC
correction to my previous comment: it should have referened but# 77538

Comment 7 Need Real Name 2003-01-02 01:49:49 UTC
Updating component and severity information.

Comment 8 Tim Wunder 2003-01-17 19:18:56 UTC
I think bug 77538#c9 and bug 77538#c10 may help in diagnosing the problem.

Comment 9 Landon Curt Noll 2003-01-31 23:01:18 UTC
There is an ugly hack-a-round for this bug: 
Duplicating each ip-host entry in /etc/hosts with an 2nd 
trailing dot entry allows one to hack-a-round this problem. 
This is a gross hack.  This glibc bug really does need to 
be fixed.  But while we wait for this bug to be fixed, 
you can try this hack. 

Comment 10 Landon Curt Noll 2003-02-12 07:56:51 UTC
See also bug 84105: 
	excessive IPv6 lookups done even when /etc/hosts resolves to IPv4 

Comment 11 Landon Curt Noll 2003-02-22 15:23:26 UTC
I appears that this name to IP resolution problem has been resolved in
rawhide. See:

for details.

Comment 12 Landon Curt Noll 2003-02-25 19:27:57 UTC
A clarification on: 
You should NOT install those RPMs on a production system.  Rawhide 
is raw bits.  Those RPMs were only in relationship to various DNS 
issues.  Those rpms have a number of non-DNS related problems. 
For example, they cause the rpm command to dump core.  They did, 
however,  resolve the DNS issues, with the possible exception of 
excessive IPv6 lookups. 

Comment 13 Ulrich Drepper 2003-04-24 05:31:41 UTC
There are a few misconceptions in the original report.  The order specification
in /etc/host.conf is pointless nowadays, this is what we have NSS for. The file
is read but order is not used.

Regarding the stall and DNS lookups, no recent release should have any problems
with this.

Comment 14 Steve Dickson 2004-06-16 00:38:40 UTC
*** Bug 81737 has been marked as a duplicate of this bug. ***

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