[dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[Damian Menscher]

On Tue, Nov 26, 2013 at 1:03 PM, Jim Reid <jim at rfc1035.com> wrote:

> On 26 Nov 2013, at 20:22, Vernon Schryver <vjs at rhyolite.com> wrote:
>
> > If those diagnoses are correct that the probes are for subdomains of
> > the local hosts's domain
>
> I'll be charitable. If these diagnoses are correct they fail to tell the
> full story.
>
> 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.


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

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.

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131126/e67708aa/attachment.html>