On 7/11/2011 2: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.
The example I am seeing this with most frequently is my RSS feed
reader, rss2email, trying to read a feed from en.wikipedia.org in a
cron job that runs every 15 minutes. I am regularly seeing this in the
output of the cron job:
W: Name or service not known [8]
http://en.wikipedia.org/w/index.php?title=/[elided]/&feed=atom&action=history
The wikipedia.org domain has three DNS servers. Let's assume that the
root and org. nameservers are cached already when rss2email does its
query. If so, then it has to do the following queries:
wikipedia.org DNS
en.wikipedia.org AAAA
en.wikipedia.org A
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
By now the end of that sequence, the typical 30-second DNS request
timeout has been exceeded, and the client gives up.
The math isn't working. I just ran a quick test and named (9.7.x) failed
over from a non-working delegated NS to a working delegated NS in less
than 30 milliseconds. How are you reaching a 30-*second* timeout
threshold in only 6 queries?
In practice, it would also be quite unlikely that named would pick
"dead" nameservers before live ones for *both* the AAAA and the A query.
At the very least, once the timeouts were encountered for the AAAA
query, those NSes would be penalized in terms of NS selection, so they
are unlikely to be chosen *again*, ahead of the working NS, for the A
query. Any en.wikipedia.org NSes which were found to be *persistently*
broken, would gravitate to the bottom of the selection list, and be
tried approximately never.
I think maybe you need to probe deeper and find out what _else_ is going on.
- Kevin
_______________________________________________
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
