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):
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
Hmm, it works for me.
for example, I added 172.16.2.154 www.hihihi.org in /etc/hosts.
And it works as expected.
It only works for me when using Mozilla and Galeon. Konqueror times out.
My /etc/hosts file:
127.0.0.1 localhost.localdomain localhost noname
192.168.1.5 eric.thewunders.org eric upstairs
192.168.1.2 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?
OK. I did your test this time, I added
to my /etc/hosts file, and it resolved fine, my local home page displayed. I
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.
i confirm this problem
I can also confirm that Konqueror does not work well
I have in my /etc/hosts:
10.25.150.2 www.isthe.com www.dmz.isthe.com www
The host www.isthe.com, via DNS, resolves to 18.104.22.168. My RH8.0
system is behind a firewall where 22.214.171.124 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 10.25.150.2.
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 126.96.36.199
instead of 10.20.150.2.
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.
p.s. In my previous comment when I said:
instead of 10.20.150.2.
I should have said:
instead of 10.25.150.2.
Sorry for the typo.
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.
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.
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.
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.
Changing priority to High because of additional information posted that may
prove beneficial in resolving the bug.
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
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:
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
FWIW, if you have multiple hosts resolving to a single IP, you can enter thusly:
192.168.0.1 foo.bar.com foo1.bar1.com foo2.bar2.com
192.168.0.1 foo.bar.com. foo1.bar1.com. foo2.bar2.com.
Many, many thanks to email@example.com for the workaround.
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!
It appears that this ignoring /etc/hosts problem has been resolved in
ok, upgrade glibc-2.3.1-54 or later fix this problem
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.