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 function getaddrinfo(). 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): How reproducible: Always 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 "Trying your-ip-addr-for-host..." 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. Additional info: 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. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6 for details.
A clarification on: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6 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.