<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Nov 26, 2019, at 11:33 AM, Jim Reid <<a href="mailto:jim@rfc1035.com" class="">jim@rfc1035.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">On 26 Nov 2019, at 09:16, Florian Weimer <<a href="mailto:fw@deneb.enyo.de" class="">fw@deneb.enyo.de</a>> wrote:<br class=""><br class="">Up until recently, well-behaved recursive resolvers had to forward<br class="">queries to the root if they were not already covered by a delegation.<br class="">RFC 7816 and in particular RFC 8198 changed that, but before that, it<br class="">was just how the protocol was expected to work.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">So what? These RFCs make very little difference to the volume of queries a resolving server will send to the root. QNAME minimisation has no impact at all: the root just sees a query for .com instead of<span class="Apple-converted-space"> </span></span><a href="http://foobar.com/" style="font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">foobar.com</a><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">. A recursive resolver should already be supporting negative caching and will have a reasonably complete picture of what's in (or not in) the root. RFC8198 will of course help that but not by much IMO.</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote></div><br class=""><style class="">ul[class*='mb-extra__public-links'], ul[class*='mb-note__public-links'], ul[class*='mb-task__public-links'] { display: none !important; }</style><div class="">It would appear a rather large percentage of queries to the root (like 50% in some samples) are random strings, between 7 to 15 characters long, sometimes longer.  I believe this is Chrome-style probing to determine if there is NXDOMAIN redirection. A good example of the tragedy of the commons, like water pollution and climate change.</div><div class=""><br class=""></div><div class="">If resolvers would enable DNSSEC validation, there would, in theory, be a reduction in these queries due to aggressive NSEC caching.  Of course, practice may not match theory (<a href="https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf" class="">https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf</a>). </div><div class=""><br class=""></div><div class="">Of course, steady state query load is largely irrelevant since root service has to be provisioned with massive DDoS in mind. In my personal view, the deployment of additional anycast instances by the root server operators is a useful stopgap, but ultimately, given the rate of growth of DoS attack capacity (and assuming that growth will continue due to the stunning security practices of IoT device manufacturers), stuff like what is discussed in that paper is the right long term strategy.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">-drc</div><div class="">(Speaking for myself)</div><div class=""><br class=""></div></body></html>