Clients get DNS timeouts because ipv6 means more queries for each lookup

[Phil Mayers]

On 07/11/2011 07:11 PM, Jonathan Kamens wrote:
>   The number of DNS queries required for each address lookup requested
> by a client has gone up considerably because of IPV6. The problem is
> being exacerbated by the fact that many DNS servers on the net don't yet
> support IPV6 queries. The result is that address lookups are frequently
> taking so long that the client gives up before getting the result.

Can you be more specific here? Do you mean "many DNS servers don't 
support queries with qtype=AAAA" or "many DNS servers don't support 
queries over IPv6/UDP or IPv6/TCP"?

>
> This is fine when the wikipedia.org nameservers are working, but let's
> postulate for the moment that two of them are down, unreachable, or
> responding slowly, which apparently happens pretty often. Then we end up
> doing:
>
>     wikipedia.org DNS
>     en.wikipedia.org AAAA /times out
>     /en.wikipedia.org AAAA /times out
>     /en.wikipedia.org AAAA
>     en.wikipedia.org A /times out/
>     en.wikipedia.org A /times out
>     /en.wikipedia.org A

I don't quite see how you're getting this behaviour.

Every operating system that I know of recommends getaddrinfo or some 
similar variant for doing multiprotocol IPv4/IPv6 lookups, and as far as 
I'm aware, they all do something very similar - namely, send the A and 
AAAA lookups in parallel. When I try this against a bind server, I see 
this makes bind perform the A/AAAA lookups in parallel too. So, at worst 
you should have something like:

0.0001 A query
0.0002 AAAA query
...
1.0000 A query timeout
1.0001 AAAA query timeout

...repeated X+1 times for X non-responding NS records.

That is, the lookups should happen in parallel, so the time taken should 
not double.

If your app is doing its own DNS requests and it's doing them in series, 
then it's broken, for exactly this reason, and should use the system 
resolver.

>
> By now the end of that sequence, the typical 30-second DNS request
> timeout has been exceeded, and the client gives up.
>
> I said above that the problem is exacerbated by the fact that many DNS
> servers don't yet support IPV6 queries. This is because the AAAA queries
> don't get NXDOMAIN responses, which would be cached, but rather FORMERR

Not in my observations. As Tony has said, you seem to have a broken 
upstream resolver.

> I'm interested to hear if other people are encountering this problem and

No, we are not seeing this problem, and we have thousands of 
IPv6-enabled clients making A/AAAA DNS requests constantly. It just 
works (tm).

This is not to say -ve caching of FORMERR is a bad idea; it may well be 
a good idea. But I think there is more going on here than simply a 
failure of -ve caching.