Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
Please note that this bug is now fixed in glibc 2.9, with the implementation of unified lookup. Both A and address are looked-up at the same time (starting with the A query), and the resolver does not choke anymore on a missing answer. However the behavior of the resolver will be restored to the one in glibc 2.7, as some even more broken DNS servers are getting confused and only answer to the request with a broken answer. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
On Thu, Aug 02, 2007 at 10:19:50PM +1200, Andrew McMillan wrote: Package: libc6 Version: 2.6-5 Severity: important Tags: patch Hi, Tolleff fog Heen has written a patch for the resolver, so that it does not start performing (or waiting for) lookups unless a globally scoped IPv6 address is present on some interface. Since Debian enables IPv6 by default, most users will have a system with an IPv6 address on the loopback interface (as well as a link-local address on each other interface) which will cause the current code to commence lookups for records, only falling back to requesting A records when these fail or timeout. The patch here: http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff seems to take a reasonable approach, since it will not be possible to connect to IPv6 addresses without a globally scoped address (plus routing :-) in any case. This is an important issue because some users are so inconvenienced as to be behind broken DNS infrastructure which ignores requests, resulting in frequent timeouts with much confusion and frustration. This patch is causing breakage (see bug#441857) and thus will be disabled in the next upload of the glibc. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
Hi, I've been runing libc6 with Andrew M's patch on a IPv6 enabled AMD64 box for the past week just fine. IPv6 is still runing just great. I'll try removing the global IPv6 address soon and see how it runs without. Cheers! -- Andrew Ruthven, Wellington, New Zealand At work: [EMAIL PROTECTED] At home: [EMAIL PROTECTED] GPG fpr: 34CA 12A3 C6F8 B156 72C2 D0D7 D286 CE0C 0C62 B791 signature.asc Description: This is a digitally signed message part
Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
Package: libc6 Version: 2.6-5 Severity: important Tags: patch Hi, Tolleff fog Heen has written a patch for the resolver, so that it does not start performing (or waiting for) lookups unless a globally scoped IPv6 address is present on some interface. Since Debian enables IPv6 by default, most users will have a system with an IPv6 address on the loopback interface (as well as a link-local address on each other interface) which will cause the current code to commence lookups for records, only falling back to requesting A records when these fail or timeout. The patch here: http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff seems to take a reasonable approach, since it will not be possible to connect to IPv6 addresses without a globally scoped address (plus routing :-) in any case. This is an important issue because some users are so inconvenienced as to be behind broken DNS infrastructure which ignores requests, resulting in frequent timeouts with much confusion and frustration. Thanks, Andrew McMillan. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (690, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.1-hippy (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.2-20070712-1 GCC support library libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
Andrew McMillan a écrit : Package: libc6 Version: 2.6-5 Severity: important Tags: patch Hi, Tolleff fog Heen has written a patch for the resolver, so that it does not start performing (or waiting for) lookups unless a globally scoped IPv6 address is present on some interface. Since Debian enables IPv6 by default, most users will have a system with an IPv6 address on the loopback interface (as well as a link-local address on each other interface) which will cause the current code to commence lookups for records, only falling back to requesting A records when these fail or timeout. The patch here: http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff seems to take a reasonable approach, since it will not be possible to connect to IPv6 addresses without a globally scoped address (plus routing :-) in any case. This is an important issue because some users are so inconvenienced as to be behind broken DNS infrastructure which ignores requests, resulting in frequent timeouts with much confusion and frustration. I have already been given the link to this patch. It sounds reasonable, but first I would like to know if it is in use on more than one machine, for both IPv4 and IPv4 + IPv6 setups? I don't really want to apply a patch that can cause regressions. Cheers, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435646: libc6: resolver considers IPv6 enabled when any IPv6 address is configured
On Thu, 2007-08-02 at 12:30 +0200, Aurelien Jarno wrote:
I have already been given the link to this patch. It sounds reasonable,
but first I would like to know if it is in use on more than one machine,
for both IPv4 and IPv4 + IPv6 setups?
I don't really want to apply a patch that can cause regressions.
Indeed not!
I have built current libc6 from source, and applied the patch. It
didn't apply cleanly, and I looked at the bit that didn't apply and
decided that not applying that particular part was correct...
I attach an updated patch, which *does* apply cleanly to the current
libc6 packages :-)
I have tested this on my laptop, as follows:
With IPv6 Fully Working
===
Enable query logging on my DNS
Start iceweasel
Browse to www.kame.net
Observe that there is an query for www.kame.net before any A query
and the turtle moves.
Browse to ipv4.generic.website
Observe that there is an query, with negative response, followed by
an A query, which gets a v4 address.
With IPv6 Presnt, but only localhost and link local addresses
=
Enable query logging on my DNS
Start iceweasel
Browse to www.kame.net
Observe that there is only an A query, and that the turtle does not
move.
Browse to ipv4.generic.website
Observe that there is only an A query, which gets a v4 address.
Browse to ipv6.geek.nz (there is no A record for this domain).
Observe that there is only an A query, and we get the host not found
page in Iceweasel.
I don't have access to any IPv4 boxes at present, but if I disable all
IPv6 addresses (including the loopback and link-local addresses) I see
the same behaviour as when only loopback and link-local addresses are
present above.
I've got someone else who will test this in a couple more environments,
but I guess it would be nice to find some more volunteers :-)
Regards,
Andrew McMillan.
-
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Day of inquiry. You will be subpoenaed.
-
diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c
index adb3c4f..d12835c 100644
--- a/sysdeps/posix/getaddrinfo.c
+++ b/sysdeps/posix/getaddrinfo.c
@@ -263,7 +263,7 @@ extern service_user *__nss_hosts_database attribute_hidden;
static int
gaih_inet (const char *name, const struct gaih_service *service,
const struct addrinfo *req, struct addrinfo **pai,
- unsigned int *naddrs)
+ unsigned int *naddrs, bool usable_ipv6)
{
const struct gaih_typeproto *tp = gaih_inet_typeproto;
struct gaih_servtuple *st = (struct gaih_servtuple *) nullserv;
@@ -706,7 +706,7 @@ gaih_inet (const char *name, const struct gaih_service *service,
if (fct != NULL)
{
if (req-ai_family == AF_INET6
- || req-ai_family == AF_UNSPEC)
+ || (req-ai_family == AF_UNSPEC usable_ipv6))
{
gethosts (AF_INET6, struct in6_addr);
no_inet6_data = no_data;
@@ -1903,7 +1903,7 @@ getaddrinfo (const char *name, const char *service,
if (hints-ai_family == AF_UNSPEC || hints-ai_family == AF_INET
|| hints-ai_family == AF_INET6)
{
- last_i = gaih_inet (name, pservice, hints, end, naddrs);
+ last_i = gaih_inet (name, pservice, hints, end, naddrs, seen_ipv6);
if (last_i != 0)
{
freeaddrinfo (p);
diff --git a/sysdeps/unix/sysv/linux/check_pf.c b/sysdeps/unix/sysv/linux/check_pf.c
index 46161a8..5287ed0 100644
--- a/sysdeps/unix/sysv/linux/check_pf.c
+++ b/sysdeps/unix/sysv/linux/check_pf.c
@@ -146,7 +146,10 @@ make_request (int fd, pid_t pid, bool *seen_ipv4, bool *seen_ipv6,
*seen_ipv4 = true;
break;
case AF_INET6:
- *seen_ipv6 = true;
+ if (ifam-ifa_scope RT_SCOPE_LINK)
+ {
+ *seen_ipv6 = true;
+ }
if (ifam-ifa_flags (IFA_F_DEPRECATED
| IFA_F_TEMPORARY
signature.asc
Description: This is a digitally signed message part
