<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 26, 2013 at 1:03 PM, Jim Reid <span dir="ltr"><<a href="mailto:jim@rfc1035.com" target="_blank">jim@rfc1035.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">On 26 Nov 2013, at 20:22, Vernon Schryver <<a href="mailto:vjs@rhyolite.com">vjs@rhyolite.com</a>> wrote:<br>
<br>
> If those diagnoses are correct that the probes are for subdomains of<br>
> the local hosts's domain<br>
<br>
</div>I'll be charitable. If these diagnoses are correct they fail to tell the full story.<br>
<br>
It's not possible to predict what the code does unless someone knows what how the local stub resolver is configured or how the stub resolver behaves, assuming Chrome uses the one that ships with the OS rather than its own stub resolver.</blockquote>

<div><br></div><div>Apparently that's not a valid assumption: Chrome has its own stub resolver, and I think it's enabled by default.  Look for "Internal DNS client enabled: true" in chrome://net-internals/#dns</div>

<div><br></div><div>Back to solving the problem of traffic at the roots, I've always been curious why recursive resolvers don't just AXFR the root zone file and cache the list of TLDs.  Yes, a new TLD might go unnoticed for the duration of your cache, but it's not like we're adding new TLDs every day (yet!).  If recursors did this, it would be trivial to avoid sending any of these queries to the roots.</div>

<div><br></div><div>Damian</div></div></div></div>