482971 - network.dns.disableIPv6=false causes dns timeouts with newer libc6 when behind netfilter firewall

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Stefan Schmidt]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

When i enable IPv6 networking in firefox it asks the recursive Nameservers for both IN A and IN AAAA records and sends the packets immediately after each other, _but_ from the same source port.
This causes trouble with the current Linux netfilter firewalling code and most 
likely with several other CPE routers like fritzbox that cannot cope with this kind of thing.
Two packets get sent out but only one is answered. [1]


ns.disableIPv6=true:
15:44:27.255090 IP 194.97.7.90.38067 > 194.97.173.116.53: 14231+ A? www.ripe.net. (30)
15:44:27.268586 IP 194.97.173.116.53 > 194.97.7.90.38067: 14231 2/0/0 CNAME[|domain]


ns.disableIPv6=false:
15:44:40.296316 IP 194.97.7.90.42979 > 194.97.173.116.53: 59197+ A? www.gaga.de. (29)
15:44:40.296353 IP 194.97.7.90.42979 > 194.97.173.116.53: 57748+ AAAA? www.gaga.de. (29)
15:44:40.305694 IP 194.97.173.116.53 > 194.97.7.90.42979: 59197 1/0/0 A 82.165.87.9 (45)
(no answer for the 'second' packet is ever received)


I had that problem with ping and such too after upgrading from libc6 2.7 to 2.9 but was able to revert libc to the old behaviour with this [2] ld-preload hotfix, as apparently the Debian package maintainers are too lame [3] to hotfix the issue like gentoo did [4].


Is this DNS packet behaviour of firefox in any way linked to my new libc6 version?
What can else i do other than downgrading the libc to achieve a 'nicer' behaviour of firefox i.e. sending dns query packets with each their own source ports? i.e. what is the name of the libc6 function i need to ld-preload? ;)

It would be good to just use a different source port for each query. [5]


[1] http://www.spinics.net/lists/linux-net/msg16712.html
[2] http://bugs.gentoo.org/attachment.cgi?id=182205&action=view
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516218
[4] http://bugs.gentoo.org/250468
       http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/glibc/2.9/0080_all_glibc-2.10-dns-no-gethostbyname4.patch?rev=1.1
[5] http://tools.ietf.org/html/rfc5452

Reproducible: Sometimes

Steps to Reproduce:
1. get IPv4/IPv6 dual-homed Linux machine w/ libc6 2.9
2. network.dns.disableIPv6=false
3. get behind a multi processor linux/netfilter firewall
Actual Results:  
DNS lookup stalls for ~2s because we're still waiting for the 2nd dns answer which will never come then connecting.
Depending on what went through netfilter first, IN AAAA or IN A we eventually will be seeing an dns resolution error.

Expected Results:  
instant DNS lookups as i am the hostmaster and i rock ;)

hotfixes:
http://bugs.gentoo.org/attachment.cgi?id=182205&action=view
http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/glibc/2.9/0080_all_glibc-2.10-dns-no-gethostbyname4.patch?rev=1.1
http://pasky.or.cz/~pasky/dev/glibc/glibc-2.10-dns-no-gethostbyname4.diff

bugreports:
http://sourceware.org/bugzilla/show_bug.cgi?id=7060
http://bugs.gentoo.org/250468
http://www.spinics.net/lists/linux-net/msg16712.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516218

Comment 1

[Stefan Schmidt]

With libc6 version 2.9-6 Debian introduced a temporary patch to mitigate this issue:
  * any/local-disable-gethostbyname4.diff: disable unified lookup for
    getaddrinfo(). While unified lookup fix the problem of DNS servers simply
    dropping AAAA requests, it breaks lookup with even more broken DNS servers
    only returning a broken AAAA answer. As it seems the second type of broken
    DNS concerns more users, let's revert to the old behaviour.  Closes:
    #516218.

With the abovementioned Version of Firefox this has the effect that different DNS query ports are used for the near simultaneous IN A and IN AAAA queries.

10:27:22.770899 IP 194.97.7.90.48485 > 194.97.173.116.53: 61066+ AAAA? ipv6.google.com. (33)
10:27:22.784703 IP 194.97.173.116.53 > 194.97.7.90.48485: 61066 2/0/0 CNAME[|domain]
10:27:22.784840 IP 194.97.7.90.57373 > 194.97.173.116.53: 13946+ A? ipv6.google.com. (33)
10:27:22.801187 IP 194.97.173.116.53 > 194.97.7.90.57373: 13946 1/1/0 CNAME[|domain]

Thus case solved for me, for now and on that platform. I'm pretty sure however that we will see it again somewhere and somewhen. ;)