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 <[email protected]> [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 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
