Bug#658171: libc6: dns resolving failing after point release update
On Wed, Feb 01, 2012 at 01:32:15PM +0100, Aurelien Jarno wrote:
> tag 658171 + confirmed
> thanks
>
> Le 31/01/2012 21:17, Bernhard R. Link a écrit :
> > * Bernhard R. Link <brlink@debian.org> [120131 20:57]:
> >> It guess it gets confused if the dns server (in this case a local pdnsd
> >> as the ISP supplied server does not answer to AAAA at all thus causing
> >> long timeouts all the time) replies to AAAA queries with "not implemented".
> >
> > Here is some tcpdump log of wget www.gmx.net:
> >
> > This is with the old version libc6:
> >
> > 21:05:57.420550 IP (tos 0x0, ttl 64, id 42980, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.47733 > 127.0.0.1.53: [bad udp cksum 3540!] 46166+ A? www.gmx.de. (28)
> > 21:05:57.423897 IP (tos 0x0, ttl 64, id 42981, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.47733 > 127.0.0.1.53: [bad udp cksum c6d5!] 7850+ AAAA? www.gmx.de. (28)
> > 21:05:57.423973 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.53 > 127.0.0.1.47733: [bad udp cksum 4255!] 7850 NotImp q: AAAA? www.gmx.de. 0/0/0 (28)
> > 21:05:57.424093 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
> > 127.0.0.1.53 > 127.0.0.1.47733: [bad udp cksum e4e6!] 46166 q: A? www.gmx.de. 1/0/0 www.gmx.de. [11m8s] A 213.165.64.74 (44)
> > 21:05:57.546142 IP (tos 0x0, ttl 64, id 43012, offset 0, flags [DF], proto UDP (17), length 57)
> > 127.0.0.1.54485 > 127.0.0.1.53: [bad udp cksum 61e6!] 61514+ A? www.gmx.net. (29)
> > 21:05:57.546159 IP (tos 0x0, ttl 64, id 43013, offset 0, flags [DF], proto UDP (17), length 57)
> > 127.0.0.1.54485 > 127.0.0.1.53: [bad udp cksum b187!] 13307+ AAAA? www.gmx.net. (29)
> > 21:05:57.546259 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 57)
> > 127.0.0.1.53 > 127.0.0.1.54485: [bad udp cksum 2d07!] 13307 NotImp q: AAAA? www.gmx.net. 0/0/0 (29)
> > 21:05:57.546371 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 73)
> > 127.0.0.1.53 > 127.0.0.1.54485: [bad udp cksum d780!] 61514 q: A? www.gmx.net. 1/0/0 www.gmx.net. [12m21s] A 213.165.64.71 (45)
> >
> > Note that it gets a NotImp for the AAAA and an address for the A and
> > then proceeds (as it gets a HTTP redirect then asking for the redirected
> > address).
> >
> > This is with the newer bad version:
> >
> > 21:06:07.348727 IP (tos 0x0, ttl 64, id 45462, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.34608 > 127.0.0.1.53: [bad udp cksum 377f!] 43161+ A? www.gmx.de. (28)
> > 21:06:07.351912 IP (tos 0x0, ttl 64, id 45463, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.34608 > 127.0.0.1.53: [bad udp cksum 8a57!] 53291+ AAAA? www.gmx.de. (28)
> > 21:06:07.351986 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 56)
> > 127.0.0.1.53 > 127.0.0.1.34608: [bad udp cksum 5d7!] 53291 NotImp q: AAAA? www.gmx.de. 0/0/0 (28)
> > 21:06:07.352099 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
> > 127.0.0.1.53 > 127.0.0.1.34608: [bad udp cksum f125!] 43161 q: A? www.gmx.de. 1/0/0 www.gmx.de. [10m58s] A 213.165.64.74 (44)
> > 21:06:07.352164 IP (tos 0x0, ttl 64, id 45463, offset 0, flags [DF], proto UDP (17), length 79)
> > 127.0.0.1.50438 > 127.0.0.1.53: [bad udp cksum a99e!] 20724+ A? www.gmx.de.Speedport_W_502V_Typ_A. (51)
> > 21:06:07.352220 IP (tos 0x0, ttl 64, id 45464, offset 0, flags [DF], proto UDP (17), length 79)
> > 127.0.0.1.50438 > 127.0.0.1.53: [bad udp cksum da40!] 37827+ AAAA? www.gmx.de.Speedport_W_502V_Typ_A. (51)
> > 21:06:07.352294 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 79)
> > 127.0.0.1.53 > 127.0.0.1.50438: [bad udp cksum 261e!] 20724 NXDomain q: A? www.gmx.de.Speedport_W_502V_Typ_A. 0/0/0 (51)
> > 21:06:07.352341 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 79)
> > 127.0.0.1.53 > 127.0.0.1.50438: [bad udp cksum 55c0!] 37827 NotImp q: AAAA? www.gmx.de.Speedport_W_502V_Typ_A. 0/0/0 (51)
> >
> > Here it gives up after it gets the address and instead continues using
> > the domain search path from resolv.conf. (Finally giving up and wget
> > getting an error).
> >
> > I've also done this test on a system with the old working libc6 and only
> > giving one wget the newer libc6 version using LD_LIBRAR_PATH and it
> > shows the same problem (so it cannot be anything else depending on libc6
> > but must be the resolver itself).
> >
>
> Thanks a lot for the detailed analysis, it helped me to understand the
> problem. I have written a patch for bind9 that returns NOTIMP for AAAA
> queries, and with it I have been able to reproduce the issue. That
> clearly help for debugging and tests.
>
> For the record, it usually fails only for the first query, as in that
> case the result of the AAAA query arrives before the result from the A
> one. For the others, given the entry is in cache, they are returned most
> of the time in the order of the queries, that is A and than AAAA.
>
> It means that a workaround until the bug is fixed is to add the
> following line to /etc/resolv.conf:
>
> options single-request
>
> I am going to continue debugging in the next days, and I'll upload a
> package when I have a patch.
>
I have been able to write patch, that I have submitted upstream. The
patch is present in sid version 2.13-26, and is already committed to our
stable branch SVN. It is likely to be uploaded to
squeeze-proposed-updates if the feedback from sid is good.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: