Bug 61391

Summary:	telnet delay connecting to site not in DNS
Product:	[Retired] Red Hat Linux	Reporter:	Walt Weber <wweber>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	furcats, fweimer, redhat-mail
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-04-24 04:20:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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: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??

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/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-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.
See:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6

for details.

Comment 5 Landon Curt Noll 2003-02-25 19:26:09 UTC

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.

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.