Bug#159781: marked as done (libc6: getaddrinfo doesn't do nsswitch.conf ordering correctly)
Your message dated Thu, 5 Sep 2002 21:01:41 -0400
with message-id <20020906010141.GA14796@phunnypharm.org>
and subject line Bug#159781: libc6: getaddrinfo doesn't do nsswitch.conf ordering correctly
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 5 Sep 2002 21:45:56 +0000
>From apenwarr@nit.ca Thu Sep 05 16:45:56 2002
Return-path: <apenwarr@nit.ca>
Received: from (mars.net-itech.com) [64.119.101.42]
by master.debian.org with smtp (Exim 3.12 1 (Debian))
id 17n4Rn-0007Uj-00; Thu, 05 Sep 2002 16:45:55 -0500
Received: (qmail 20115 invoked from network); 5 Sep 2002 21:45:54 -0000
Received: from mai.net-itech.com (HELO mai.internal.nit.ca) (192.168.12.1)
by mars.net-itech.com with SMTP; 5 Sep 2002 21:45:52 -0000
Received: (qmail 12431 invoked from network); 5 Sep 2002 21:45:51 -0000
Received: from insight.internal.nit.ca (192.168.12.100)
by mai.internal.nit.ca with SMTP; 5 Sep 2002 21:45:51 -0000
Received: from apenwarr by insight.internal.nit.ca with local (Exim 3.34 #1 (Debian))
id 17n4Ri-0004CO-00; Thu, 05 Sep 2002 17:45:50 -0400
From: apenwarr@nit.ca
Subject: libc6: getaddrinfo doesn't do nsswitch.conf ordering correctly
To: submit@bugs.debian.org
X-Mailer: bug 3.3.10
Message-Id: <[🔎] E17n4Ri-0004CO-00@insight.internal.nit.ca>
Date: Thu, 05 Sep 2002 17:45:50 -0400
Delivered-To: submit@bugs.debian.org
Package: libc6
Version: 2.2.5-14
Severity: normal
If I have this line in /etc/hosts:
192.168.43.128 cproxy
and I type this:
telnet cproxy
I show the following DNS activity in tcpdump:
# tcpdump -vni eth0 port 53
tcpdump: listening on eth0
17:09:16.272347 192.168.12.100.34212 > 192.168.12.1.53:
[udp sum ok] 61379+ AAAA? cproxy.internal.nit.ca.
[|domain] (DF) (ttl 64, id 48677, len 68)
17:09:16.272740 192.168.12.1.53 > 192.168.12.100.34212:
[udp sum ok] 61379 NXDomain* 0/0/0 (40) (DF) (ttl 64, id 0, len 68)
17:09:16.272875 192.168.12.100.34212 > 192.168.12.1.53:
[udp sum ok] 61380+ AAAA? cproxy.
[|domain] (DF) (ttl 64, id 48677, len 52)
17:09:16.292883 192.168.12.1.53 > 192.168.12.100.34212:
[udp sum ok] 61380 NXDomain* 0/0/0 (24) (DF) (ttl 64, id 0, len 52)
My nsswitch.conf contains the following line:
hosts: files dns
Therefore, I believe that hosts listed in /etc/hosts should, under no
circumstances, elicit a DNS lookup.
It appears to be no problem in the situation above - and indeed, it doesn't
really affect my life much in this case - BUT, when the Internet connection
is down, the DNS server takes 60-120 seconds to answer, and telnet sits
waiting all that time, even though it already knows the answer from
/etc/hosts!
When I add the following line to /etc/hosts, the DNS lookups go away,
although telnet tries first to connect to an IPv6 address (which fails
instantly and harmlessly, since I don't have IPv6 enabled):
::1 cproxy
Although I haven't looked at the libc source, I expect the reason for this
misbehaviour is an implementation of getaddrinfo that goes something like
this:
getaddrinfo:
gethostbyname2(name, AF_INET6)
nss_files_gethostbyname2(name, AF_INET6) = FAIL
nss_dns_gethostbyname2(name, AF_INET6) = FAIL
... FAIL
gethostbyname2(name, AF_INET)
nss_files_gethostbyname2(name, AF_INET) = OK
... OK
... OK
It should be more like this:
getaddrinfo:
nss_files_gethostbyname2(name, AF_INET6) = FAIL
nss_files_gethostbyname2(name, AF_INET) = OK
... OK
Or, for reference, if the name weren't in /etc/hosts, it should be like this:
getaddrinfo:
nss_files_gethostbyname2(name, AF_INET6) = FAIL
nss_files_gethostbyname2(name, AF_INET) = FAIL
nss_dns_gethostbyname2(name, AF_INET6) = FAIL
nss_dns_gethostbyname2(name, AF_INET) = OK
... OK
Unfortunately, this requires getaddrinfo to know about the nss rather than
just calling the nss-independent libc gethostbyname2() function, but it
looks like there's no better way to solve the problem.
Have fun,
Avery
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux insight 2.4.19 #1 mer sep 4 10:52:04 EDT 2002 i686 unknown
---------------------------------------
Received: (at 159781-done) by bugs.debian.org; 6 Sep 2002 01:01:52 +0000
>From bmc@phunnypharm.org Thu Sep 05 20:01:52 2002
Return-path: <bmc@phunnypharm.org>
Received: from blowme.phunnypharm.org [65.207.35.140]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 17n7VP-0006nK-00; Thu, 05 Sep 2002 20:01:52 -0500
Received: from hopper.phunnypharm.org ([192.168.0.13] ident=mail)
by blowme.phunnypharm.org with esmtp (Exim 3.35 #1 (Debian))
id 17n7VM-0006GN-00; Thu, 05 Sep 2002 21:01:48 -0400
Received: from bmc by hopper.phunnypharm.org with local (Exim 3.35 #1 (Debian))
id 17n7VF-0003yk-00; Thu, 05 Sep 2002 21:01:41 -0400
Date: Thu, 5 Sep 2002 21:01:41 -0400
From: Ben Collins <bcollins@debian.org>
To: apenwarr@nit.ca, 159781-done@bugs.debian.org
Subject: Re: Bug#159781: libc6: getaddrinfo doesn't do nsswitch.conf ordering correctly
Message-ID: <20020906010141.GA14796@phunnypharm.org>
References: <[🔎] E17n4Ri-0004CO-00@insight.internal.nit.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[🔎] E17n4Ri-0004CO-00@insight.internal.nit.ca>
User-Agent: Mutt/1.4i
Sender: Ben Collins <bmc@phunnypharm.org>
Delivered-To: 159781-done@bugs.debian.org
On Thu, Sep 05, 2002 at 05:45:50PM -0400, apenwarr@nit.ca wrote:
> Package: libc6
> Version: 2.2.5-14
> Severity: normal
>
> If I have this line in /etc/hosts:
>
> 192.168.43.128 cproxy
>
Read the glibc FAQ/Bugs (upstream). This is not a bug, but is just how
getaddrinfo works, so that it can fulfill it's specifications.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Reply to: