Bug#658171: libc6: dns resolving failing after point release update
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.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: