From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
Telnet connections to hosts not in DNS but listed in /etc/hosts shows 2-5 second
delay on connect-by-name , even though /etc/host.conf is listed as "order
host,bind" and /etc/nsswitch.conf shows "hosts: files,dns". Problem observed
when passing hostname on command line, and also when passing name to telnet
command-loop as "open hostname".
Behavior is avoided by entering the dotted-quad IP address instead of hostname.
Recompiling telnet and running under gdb, the problem is in the call to glibc
It appears from other Bugzilla reports (58568, 61121, 61123, etc.) that
glibc::getaddrinfo() is always performing a DNS lookup, and is then checking the
local host file.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Configure /etc/host.conf and /etc/nsswitch.conf to use /etc/hosts before DNS
2.Add an entry in /etc/hosts for machine without entry in DNS.
3.enter command "telnet your-host" and observe delay before seeing message
Actual Results: Delay in connecting to host while DNS is queried, rather than
immediately using the entry from /etc/hosts file.
Expected Results: Observe the rules entered in /etc/nsswitch.conf and
/etc/host.conf , rather than hard-coding a DNS search.
This bug appears to have existed in a variety of forms, reported against glibc
as far back as Bugzilla #9871. After 2 years, perhaps a fix is in order??
this bug appears to be present in rh7.3 as well. any nsswitch-aware program,
telnet, ftp, ssh,
causes (apparently) the etc/hosts query to fail. even using the cmd, "telnet
localhost", i can see
(via strace) all the usual suspects being open'd and read:
/etc/resolv.conf,/etc/nsswitch.conf, /lib/libnss_files.so.2, /etc/host.conf,
and finally, /etc/hosts. but then (after checking etc/services
and a brief check for nis -/lib/libnss_nisplus.so.2 - it does a connect with the
dns host. its like the
query of etc/hosts didn't completely satisfy.
the delay noticed by the original submitter seems due to waiting for the dns
host to give up. not sure
why his result isn't "Connection closed by foreign host." or "host unreachable"
It seems this bug has been around for a long time, and reported multiple times.
Look at bugs 9871 (> 2 yrs. old), 57998, 59320, and 61391. As explained in
bug 57998, things that use glibc get it wrong, and things that use
libresolve do it right.
This bug can make minor network problems much worse. I've seen problems
from it on several occasions.
Is there some issue that makes this bug hard to fix?
See also bug 84105
It appears that this telnet delay has been mostly resolved in rawhide.
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.
This shouldn't be a problem anymore in any recent release. If the entr yis
found locally it's used. I'm closing the bug now.