Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 61391 - telnet delay connecting to site not in DNS
telnet delay connecting to site not in DNS
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-03-18 18:20 EST by Walt Weber
Modified: 2016-11-24 10:15 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-24 00:20:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Walt Weber 2002-03-18 18:20:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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:

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??
Comment 1 w miller 2002-06-04 13:10:42 EDT
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"
Comment 2 Joe Krahn 2002-07-03 23:22:40 EDT
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?
Comment 3 Landon Curt Noll 2003-02-12 02:55:13 EST
See also bug 84105 
Comment 4 Landon Curt Noll 2003-02-22 10:19:12 EST
It appears that this telnet delay has been mostly resolved in rawhide.


for details.
Comment 5 Landon Curt Noll 2003-02-25 14:26:09 EST
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 6 Ulrich Drepper 2003-04-24 00:20:07 EDT
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.

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