<!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>