search

ekr / draft-rescorla-doh-cdisco

Other
1 stars 2 forks source link

doh.test is incompatible with caching DNS proxies and other middleware per RFC6761 #8

Open nhnt11 opened 3 years ago

nhnt11 commented 3 years ago

When we (DoH team at Mozilla) measured the accuracy of our implementation of CNAME based discovery for DoH steering, we found that around 2% of clients appear to be doing lookups through Comcast resolvers as seen in nameserver logs, but do NOT see the CNAME response expected from those resolvers on the client side. This suggests the presence of middleboxes, e.g. simple caching proxies, that are not forwarding the doh.test request.

Investigation of this issue unearthed RFC6761, which dictates how .test. and other "special-use" names should be treated across the recursive resolution chain. Specifically, this text, under 6.2. Domain Name Reservation Considerations for "test.":

   4.  Caching DNS servers SHOULD recognize test names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve test names.  Instead, caching DNS servers SHOULD, by
       default, generate immediate negative responses for all such
       queries.  This is to avoid unnecessary load on the root name
       servers and other name servers.  Caching DNS servers SHOULD offer
       a configuration option (disabled by default) to enable upstream
       resolving of test names, for use in networks where test names are
       known to be handled by an authoritative DNS server in said
       private network.

suggests that we should actively expect such middleware to respond negatively to a request for doh.test if they obey the spec, giving Comcast resolvers no chance to be discovered using this mechanism.

We have yet to make measurements to confirm that this is indeed the source of the 2% of unsteered clients mentioned at the beginning of this issue description, but it's probable. In any case, worth noting the issue here.

martinthomson commented 3 years ago

Those rates aren't too much of a concern for me. As we are essentially running an experiment here, we have learned something interesting, which is that the implementation of that provision is at around 2%.

It also suggests that this SUDN isn't the right one, but I think that we knew that already. I would expect the IETF to define something under .arpa., as is currently being discussed in the ADD working group.