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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
