<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 7/11/2011 2:11 PM, Jonathan Kamens wrote:
<blockquote cite="mid:4E1B3CED.2040508@kamens.us" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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.<br>
<br>
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:<br>
<blockquote>W: Name or service not known [8] <span
class="moz-txt-link-freetext"><a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://en.wikipedia.org/w/index.php?title=">http://en.wikipedia.org/w/index.php?title=</a><i>[elided]</i>&feed=atom&action=history</span><br>
</blockquote>
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:<br>
<blockquote>wikipedia.org DNS<br>
en.wikipedia.org AAAA<br>
en.wikipedia.org A<br>
</blockquote>
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:<br>
<blockquote>wikipedia.org DNS<br>
en.wikipedia.org AAAA <i>times out<br>
</i>en.wikipedia.org AAAA <i>times out<br>
</i>en.wikipedia.org AAAA<br>
en.wikipedia.org A <i>times out</i><br>
en.wikipedia.org A <i>times out<br>
</i>en.wikipedia.org A<br>
</blockquote>
By now the end of that sequence, the typical 30-second DNS request
timeout has been exceeded, and the client gives up.<br>
</blockquote>
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?<br>
<br>
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.<br>
<br>
I think maybe you need to probe deeper and find out what _else_ is
going on.<br>
<br>
- Kevin<br>
<br>
<br>
<br>
</body>
</html>