Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 61391 - telnet delay connecting to site not in DNS
Summary: telnet delay connecting to site not in DNS
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2002-03-18 23:20 UTC by Walt Weber
Modified: 2016-11-24 15:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-24 04:20:07 UTC

Attachments (Terms of Use)

Description Walt Weber 2002-03-18 23:20:25 UTC
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 17:10:42 UTC
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/,  /etc/host.conf,
and finally, /etc/hosts.  but then (after checking etc/services 
and a brief check for nis -/lib/ - 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-04 03:22:40 UTC
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 07:55:13 UTC
See also bug 84105 

Comment 4 Landon Curt Noll 2003-02-22 15:19:12 UTC
It appears that this telnet delay has been mostly resolved in rawhide.

for details.

Comment 5 Landon Curt Noll 2003-02-25 19:26:09 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. 

Comment 6 Ulrich Drepper 2003-04-24 04:20:07 UTC
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.