Bug 77538 - Konqueror will not resolve domain names enterred in /etc/hosts file
Summary: Konqueror will not resolve domain names enterred in /etc/hosts file
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kdebase
Version: 8.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Ben Levenson
URL: Local URL resolved via /etc/hosts
Depends On:
TreeView+ depends on / blocked
Reported: 2002-11-08 19:07 UTC by Tim Wunder
Modified: 2007-03-27 03:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-22 20:19:06 UTC

Attachments (Terms of Use)

Description Tim Wunder 2002-11-08 19:07:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021107

Description of problem:
Due to firewall reissues, I use my /etc/hosts file to locally resolve the Domain
Name of my webserver. This works fine for Mozilla and Galeon, but Konqueror
always times out.

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

How reproducible:

Steps to Reproduce:
1. Make an entry in /etc/hosts like:
<local IP> www.MyDomainName.org
2. Open Konqueror and type in the URL box, www.MyDomainName.org


Actual Results:  Konqueror times out

Expected Results:  Home page of local webserver should be displayed

Additional info:

Comment 1 Ngo Than 2002-11-12 11:03:27 UTC
Hmm, it works for me.

for example, I added    www.hihihi.org in /etc/hosts.
And it works as expected.

Comment 2 Tim Wunder 2002-11-12 12:26:42 UTC
It only works for me when using Mozilla and Galeon. Konqueror times out.    
My /etc/hosts file:       localhost.localdomain   localhost noname     eric.thewunders.org     eric    upstairs     www.thewunders.org thewunders.org downstairs.thewunders.org downstairs    
www.thewunders.org, thewunders.org, www.sufathersclub.org all time out with konqueror. They all    
work in Mozilla. downstairs.thewunders.org works in konqueror, as does localhost.   
Potential problems I see with your test:    
If the Domain name you used doesn't resolve, the fall back could be the /etc/hosts file, so you get   
a name resolution failure via DNS and konqueror then sources /etc/hosts. My domain    
names, www.thewunders.org and sufathersclub.org are resolvable via DNS, but are not loadable    
because of my firewall (a Freesco router).    
Did you disconnect from the Internet before testing? 

Comment 3 Tim Wunder 2002-11-20 22:08:01 UTC
OK. I did your test this time, I added www.hihihi.org
to my /etc/hosts file, and it resolved fine, my local home page displayed. I
then added www.excite.com
and the *real* excite page loaded. So you *must* test this with a *resolvable*,
*real* domain name.

Mozilla behaves properly.

I will be updating KDE to 3.0.5 shortly, using the RPMs found at kde.org and
will post an update.

Comment 4 Ngo Than 2002-12-16 23:35:20 UTC
i confirm this problem

Comment 5 Landon Curt Noll 2002-12-24 04:48:04 UTC
I can also confirm that Konqueror does not work well 
with /etc/hosts. 
I have in my /etc/hosts:	www.isthe.com www.dmz.isthe.com www 
The host www.isthe.com, via DNS, resolves to  My RH8.0 
system is behind a firewall where is not accessible. 
The host www.dmz.isthe.com is a private name for the web server 
and is NOT resolvable via DNS.  It only exists in my /etc/hosts 
as a private-10 IP address. 
In /etc/nsswitch.conf I have: 
	hosts:      files dns 
So resolving should first check /etc/hosts and then with DNS. 
Now I am able to access with Konqueror: 
Both of those URLs resolve to port 80 on 
However when I try to access: 
Konqueror fails to find the web server.  A tcpdump of eth0 shows 
that Konqueror is attempting to use the DNS IP address of 
instead of 
NOTE: Both Mozilla and Netscape correctly resolve www.isthe.com 
via the /etc/hosts file.  Prior to my upgrade to RH8.0, I was using 
RH7.3.   Konqueror correctly used /etc/hosts prior to the RH8.0 
This is really a problem for me as I depend on such private hostnames 
resolving via /etc/hosts. 

Comment 6 Landon Curt Noll 2002-12-24 04:56:08 UTC
p.s. In my previous comment when I said: 
	instead of 
I should have said: 
	instead of 
Sorry for the typo. 

Comment 7 brandon 2003-01-01 21:03:02 UTC
This is the same as bug 76543.  Seems pretty serious to me and is actually 
keeping me from deploying 8.0 on lots of machines.  From my experience the only 
thing that isn't affected by this is ping.  Telnet, ssh, ftp, etc. all break.

Comment 8 Landon Curt Noll 2003-01-01 23:31:35 UTC
I can confirm that many apps such as telnet, ssh, ftp, etc. all break.   
(Perhaps there is a bug in the resolver library that is ignoring or   
not correctly processing hosts entry in nsswitch.conf?)   
For what it is worth, we have halted testing on RH8.0 because we   
cannot move forward on RH7.3 upgrades on production systems because   
of this general problem.  I hope a general fix (that covers the many  
other apps) is in the works! 
Please re-prioritize this bug from Normal to High. 

Comment 9 Thiago Macieira 2003-01-17 14:14:02 UTC
Just adding some additional information that might help solving the problem. I have 
talked a lot with Tim Wunder (the original reporter) and he's done quite a bit of testing. 
First of all, all the programs that have been mentioned here as not working use 
getaddrinfo(3) as its resolution function. The other ones that are working use the 
conventional gethostbyname(3) calls, even those IPv6-enabled such as Mozilla (uses 
A small test test program using getaddrinfo(3) shows the very same problem. I can 
provide this test program. 
I wrote another test program. I made it call directly the _nss_files_gethostbyname2_r 
function inside /lib/libnss_files.so.2, which is the actual function that reads /etc/hosts 
and returns an address. It did succeed in finding the proper address. 
If you call gethostbyname2_r(3), which is what getaddrinfo(3) uses (see 
sysdeps/posix/getaddrinfo.c, macro gethosts), the correct addresses are found as 
My current conclusion is that somewhere, somehow, getaddrinfo(3) chose to use 
another address than the one gethostbyname2_r returned. That might be connected 
to the fact that gethostbyname2_r is called twice: once for IPv6 and once for IPv4. 
In time, I should note that I'm using glibc 2.3.1 on a Conectiva system and it does not 
appear to be affected. 
Bug# 76543 is certainly related. 

Comment 10 Thiago Macieira 2003-01-17 14:19:22 UTC
Oh, I've just remembered. 
An strace of the getaddrinfo(3) test program showed that all the NSS libraries were 
called twice (files, nis, nisplus, dns). The first must be the IPv6 query, which has 
probably failed on all domains. The second one, the IPv4 query, should have stopped 
in the files NSS, as it does in my system, but it doesn't. The other NSS libraries are 
searched until the dns one returns a success. 

Comment 11 Tim Wunder 2003-01-17 14:56:00 UTC
Changing priority to High because of additional information posted that may
prove beneficial in resolving the bug.

Comment 12 Stephen Walton 2003-01-24 05:40:09 UTC
Just today I tried installing glibc-, glibc-common-, and glibc-devel-2.3.1-38
from rawhide on a machine with a mainly-fresh RH 8.0 install.  I was amazed it
worked with a simple 'rpm -U'.  However, it doesn't seem to have fixed the
problem reported here;  my nsswitch.conf like others' searches NIS first, then
files, then DNS, but 'nslookup' failed to find an entry in NIS.  An HP-UX system
in the same NIS domain and with the same policy in its nsswitch.conf found the
NIS entry.

Comment 13 brandon 2003-01-31 20:11:16 UTC
This also happens in a recent install of Debian (3.0) here on my laptop.  From 
what I am seeing, this is a glibc bug.  I also read that a workaround (sort of) 
for it, is whatever you want to put into /etc/hosts, do it like this:

# /etc/hosts    foo.bar.com    foo.bar.com.

The first line takes care of things like ping, and the second takes care of 
telnet/ssh/etc.  Is this something to do with gethostbyname vs. getaddrinfo ?

So I guess any/ALL distributions that use one of these versions of glibc is 

Again, it looks like this only started in RH 8.0.  <= 7.3 seems to work fine 
for me.

Comment 14 Tim Wunder 2003-01-31 21:01:59 UTC
FWIW, if you have multiple hosts resolving to a single IP, you can enter thusly:
# /etc/hosts    foo.bar.com foo1.bar1.com foo2.bar2.com    foo.bar.com. foo1.bar1.com. foo2.bar2.com.

Many, many thanks to brandon@one.net for the workaround.

Comment 15 Landon Curt Noll 2003-02-12 08:02:02 UTC
See also bug 84105: 
	excessive IPv6 lookups done even when /etc/hosts resolves to IPv4 
The excess . hack-a-round is another symptom of the more general 
glibc resolver problem.  As noted in the bug 84105, the ignoring 
of /etc/resolv.conf and the excessive IPv6 lookups can cause 
serious delays.  In one case a full minute is wasted as 12 DNS 
lookups (between 2 DNS servers that are unreachable) takes place. 
I hope people don't think that this excess . hack-a-round is a fix! 

Comment 16 Landon Curt Noll 2003-02-22 15:24:01 UTC
It appears that this ignoring /etc/hosts problem has been resolved in
rawhide. See:


for details.

Comment 17 Than Ngo 2003-02-22 20:19:06 UTC
ok, upgrade glibc-2.3.1-54 or later fix this problem

Comment 18 Landon Curt Noll 2003-02-25 19:28:35 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. 

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