Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients)

[Jeroen Massar]

Tore Anderson wrote:
> Hi,
> 
> * Jeroen Massar
> 
>> In short: host has IPv6 enabled, application does a getaddrinfo(), which
>> means it will ask for AAAA and then A from the resolvers. The DNS
>> resolver though sees a DNS query for an AAAA record and does "eeehmm
>> dunno, go away" and then just drops the request. The DNS client thus has
>> to time out, as that is the only option it has. The client then send a
>> request for an A record and gets a direct response.
> 
> Well, this is a different problem than the one I've been describing.

Guess why I changed the subject ;)

> I'm sure this issue is causing its share of the client loss I see on the
> dualstack site too, but I believe it is smaller in scope than the
> problem I've been asking about.  From what I can tell "my" problem is
> responsible for more than half of the client loss on the dualstack site.

try googling for "ubuntu ipv6 disable", you'll get an idea :)
or for that matter "disable ipv6" which also gives you the results for
Windows.

Googling here returns about 173.000 results along with:

Searches related to: disable ipv6
disable ipv6 linux	disable ipv6 ubuntu	disable ipv6 xp
disable ipv6 centos	disable ipv6 fedora	disable ipv6 debian	disable ipv6
windows xp	disable ipv6 redhat

I guess that tells enough on how wide-spread this issue is.

> "Your" problem is incredibly hard to do anything about short of copying
> Google's approach, as the problem is probably in the users' SOHO routers

Nope, that won't help. It does not matter if there are AAAA records in
DNS, it is all about having the client query for them and the resolver
(the one in the CPE) which drops the requests.

> most of the time and it would be impossible to contact them all and get
> them to do anything about it.  Unless of course it is a common problem
> with a certain type of CPE device distributed by a certain ISP, of
> course, but that does not appear to be the case here.

The problem there is that even older versions of dnsmasq had this issue
and that is used in in a lot of CPEs.

> "My" problem is confined to two specific eyeball networks here in Norway
> which I think it is more likely to do be able to do something about
> somehow.

In that case not returning AAAA records for those would work and should
not be too much overhead. Best solution in this case though is to
convince the networks to fix their filtering issue, that is that they
don't filter.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/bb3f4312/attachment.bin