<div dir="ltr"><div>An update from Versign's blog Jan 7 2021 <a href="https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/">https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/</a><br><br></div><div><br></div><div>"
In a <a href="https://blog.verisign.com/domain-names/chromiums-impact-on-root-dns-traffic/">previous blog post</a>,
 we quantified that upwards of 45.80% of total DNS traffic to the root 
servers was, at the time, the result of Chromium intranet redirection 
detection tests. Since then, the Chromium team has <a rel="noreferrer noopener" href="https://bugs.chromium.org/p/chromium/issues/detail?id=1090985" target="_blank">redesigned its code</a>
 to disable the redirection test on Android systems and introduced a 
multi-state DNS interception policy that supports disabling the 
redirection test for desktop browsers. This functionality was released 
mid-November of 2020 for Android systems in Chromium 87 and, quickly 
thereafter, the root servers experienced a rapid decline of DNS queries...."</div><div><br></div><div></div><div>....
Prior to the software release, the root server system saw peaks of ~143 
billion queries per day. Traffic volumes have since decreased to ~84 
billion queries a day. This represents more than a 41% reduction of 
total query volume."</div><div><br></div><div>So some significant reductions...and more when the Chromium desktop client gets the update.<br></div><div><br></div><div>Dev Anand<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 2, 2020 at 5:06 PM Sivasubramanian M <<a href="mailto:6.Internet@gmail.com">6.Internet@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">From what I understand of the arstechnica blog post,  there is a (bug) request to Google that the Intranet Redirect Detector be disabled by default. Why? If it is a well meant feature, should the issue be resolved by disabling the feature?</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="color:rgb(0,0,0);font-family:opensans;font-size:15px;background-color:rgb(240,241,242)">on startup or change of network, Chromium issues DNS lookups for three randomly generated seven-to-15-character top-level "domains." If any two of those requests come back with the same IP address, Chromium assumes the local network is hijacking the </span><code style="box-sizing:inherit;font-family:monospace,monospace;font-size:15px;color:rgb(0,0,0);background-color:rgb(240,241,242)">NXDOMAIN</code><span style="color:rgb(0,0,0);font-family:opensans;font-size:15px;background-color:rgb(240,241,242)"> errors it should be receiving—so it just treats all single-word entries as search attempts until further notice.<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">..[some of] </span></span><span style="color:rgb(0,0,0);font-family:opensans;font-size:15px;background-color:rgb(240,241,242)">those three lookups tend to propagate all the way up to the root nameservers: the local server doesn't know how to resolve </span><code style="box-sizing:inherit;font-family:monospace,monospace;font-size:15px;color:rgb(0,0,0);background-color:rgb(240,241,242)">qwajuixk</code><span style="color:rgb(0,0,0);font-family:opensans;font-size:15px;background-color:rgb(240,241,242)">, so it bounces that query up to its forwarder, which returns the favor, until eventually </span><code style="box-sizing:inherit;font-family:monospace,monospace;font-size:15px;color:rgb(0,0,0);background-color:rgb(240,241,242)"><a href="http://a.root-servers.net" target="_blank">a.root-servers.net</a></code><span style="color:rgb(0,0,0);font-family:opensans;font-size:15px;background-color:rgb(240,241,242)"> or one of its siblings has to say "Sorry, that's not a domain."</span><span style="color:rgb(51,51,51);font-family:verdana,sans-serif;background-color:rgb(240,241,242)"></span></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(51,51,51)">If Chromium can issue instructions(?) for the browser to randomly generate "domains",  couldn't it also instruct the browser how to handle a bounce? Is there someway by which the browser could instruct the DNS lookup to bounce it to forwarders and if not resolved, follow the path to one or more (new) task-specific root server mirrors and NOT to the root-server?  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 12:53 AM <a href="mailto:mail@christopherwilkinson.eu" target="_blank">mail@christopherwilkinson.eu</a> CW <<a href="mailto:mail@christopherwilkinson.eu" target="_blank">mail@christopherwilkinson.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

    
<div><p> > …a recommended setup, we should promote it</p><p>Thankyou, Lutz +1</p><p>CW</p><blockquote type="cite">El 2 de septiembre de 2020 a las 16:13 Lutz Donnerhacke <<a href="mailto:lutz@donnerhacke.de" target="_blank">lutz@donnerhacke.de</a>> escribió: <br> <br><div><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Most ISPs can mirror the root zone into their own resolvers. So the queries are terminated early and the load is distributed. </span></p><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Several instances of the root servers allow AXFR/IXFR without any problems. </span></p><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It’s a recommended setup, we should promote it more. </span></p><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">   </span></p><div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt"><div><div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm"><p><strong><span style="font-size:11pt;font-family:Calibri,sans-serif">Von:</span></strong><span style="font-size:11pt;font-family:Calibri,sans-serif"> ttf <<a href="mailto:ttf-bounces@atlarge-lists.icann.org" target="_blank">ttf-bounces@atlarge-lists.icann.org</a>> <strong>Im Auftrag von </strong>Dev Anand Teelucksingh<br><strong>Gesendet:</strong> Mittwoch, 26. August 2020 03:25<br><strong>An:</strong> At-Large Worldwide <<a href="mailto:at-large@atlarge-lists.icann.org" target="_blank">at-large@atlarge-lists.icann.org</a>><br><strong>Cc:</strong> Technical issues <<a href="mailto:technical-issues@atlarge-lists.icann.org" target="_blank">technical-issues@atlarge-lists.icann.org</a>>; Technology Taskforce WG <<a href="mailto:ttf@atlarge-lists.icann.org" target="_blank">ttf@atlarge-lists.icann.org</a>><br><strong>Betreff:</strong> Re: [technology taskforce] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers </span></p></div></div><p> </p><div><div><p>It’s to test whether the network  is using NX domain modification (or NX domain hijacking )</p></div><div><p> </p></div><div><p>The browser generates three Tld domains on startup or when the network changes (when switching WiFi providers for eg) - if the browser gets the same IP address from two of those domains , it knows the network is modifying the NX errors it should receive and therefore treats any single word as a search query </p></div><div><p> </p></div><div><p>Otherwise, it would have to bug the user “did you mean to search for “word” or <a href="https://word" target="_blank">https://word</a>” for every single word query </p></div><div><p> </p></div><div><p>The issue is that for networks reporting NX errors properly the root servers have to ultimately answer the query if the google generated tld exists </p></div><div><p> </p></div><div><p>The apnic blog post says “<span style="font-family:"Whitney SSm B",serif;color:black"> but in the 10+ years since the feature was added, we now find that half of the DNS root server traffic is very likely due to Chromium’s probes. That equates to about 60 billion queries to the root server system on a typical day.” </span></p></div><div><p> </p></div><div><p>Dev Anand </p></div><div><p> </p></div><div><p> </p></div><div><div><div><p>On Tue, 25 Aug 2020 at 6:35 PM, Carlton Samuels <<a href="mailto:carlton.samuels@gmail.com" rel="noopener" target="_blank">carlton.samuels@gmail.com</a>> wrote:</p></div><blockquote><div><p>I'm still left with little understanding of why this is important?</p><div><p> </p></div><div><p>What is the use of these lookups for the browser? A previously undisclosed security feature? </p></div><div><p> </p></div><div><p>And what is being alleged from the name service side? A unintentional DOS-type attack on the root server system itself? </p></div><div><p> </p></div><div><p>CAS.</p></div></div><p> </p><div><div><p>On Tue, 25 Aug 2020, 3:39 pm Dev Anand Teelucksingh, <<a href="mailto:devtee@gmail.com" rel="noopener" target="_blank">devtee@gmail.com</a>> wrote:</p></div></div><div><blockquote><p style="max-width:100%"><span style="font-size:14.5pt;font-family:-apple-system-font,serif;color:rgb(27,27,27)">The Chromium browser—open source, upstream parent to both Google Chrome and the new Microsoft Edge—is getting some serious negative attention for a well-intentioned feature that checks to see if a user's ISP is "hijacking" non-existent domain results. </span></p><p style="max-width:100%"><span style="font-size:14.5pt;font-family:-apple-system-font,serif;color:rgb(27,27,27)">The <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1090985" rel="noopener" target="_blank"><span style="color:rgb(65,110,210);text-decoration:none">Intranet Redirect Detector</span></a>, which makes spurious queries for random "domains" statistically unlikely to exist, is responsible for roughly half of the total traffic the world's root DNS servers receive. Verisign engineer Matt Thomas wrote a lengthy APNIC blog <a href="https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/" rel="noopener" target="_blank"><span style="color:rgb(65,110,210);text-decoration:none">post</span></a> outlining the problem and defining its scope. </span></p><div><p style="max-width:100%"><span style="font-family:-apple-system-font,serif">Read rest of Ars Technica article :  </span></p></div><div><div><p><span style="font-family:-apple-system-font,serif"><a href="https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/" rel="noopener" target="_blank">https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/</a> </span></p></div><p><span style="font-family:-apple-system-font,serif">   </span></p></div><div><p><span style="font-family:-apple-system-font,serif">The APNIC blog post :  </span></p></div><div><div><p><span style="font-family:-apple-system-font,serif"><a href="https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/" rel="noopener" target="_blank">https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/</a> </span></p></div><div><p><span style="font-family:-apple-system-font,serif">   </span></p></div><div><p><span style="font-family:-apple-system-font,serif">Not aware if this is  mentioned before  in ICANN circles  </span></p></div><div><p><span style="font-family:-apple-system-font,serif">   </span></p></div><div><p><span style="font-family:-apple-system-font,serif">Dev Anand  </span></p></div><p><span style="font-family:-apple-system-font,serif">   </span></p></div></blockquote></div><div><blockquote><p><br><br>_______________________________________________<br><br><br>ttf mailing list<br><br><br><a href="mailto:ttf@atlarge-lists.icann.org" rel="noopener" target="_blank">ttf@atlarge-lists.icann.org</a><br><br><br><a href="https://mm.icann.org/mailman/listinfo/ttf" rel="noopener" target="_blank">https://mm.icann.org/mailman/listinfo/ttf</a><br><br><br><br><br><br>_______________________________________________<br><br><br>By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noopener" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noopener" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</p></blockquote></div><p style="margin-bottom:12pt"> </p></blockquote></div></div><p style="margin-bottom:12pt"> </p></div></div></div></blockquote><p><br> </p><blockquote type="cite">_______________________________________________ <br>At-Large mailing list <br><a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a> <br><a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a> <br> <br>At-Large Official Site: <a href="http://atlarge.icann.org" target="_blank">http://atlarge.icann.org</a> <br>_______________________________________________ <br>By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote><p><br> </p></div>
 _______________________________________________<br>
At-Large mailing list<br>
<a href="mailto:At-Large@atlarge-lists.icann.org" target="_blank">At-Large@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/at-large" rel="noreferrer" target="_blank">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br>
<br>
At-Large Official Site: <a href="http://atlarge.icann.org" rel="noreferrer" target="_blank">http://atlarge.icann.org</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Sivasubramanian M</div>Please send all replies to <a href="mailto:6.Internet@gmail.com" target="_blank">6.Internet@gmail.com</a><div><br></div></div></div>
_______________________________________________<br>
ttf mailing list<br>
<a href="mailto:ttf@atlarge-lists.icann.org" target="_blank">ttf@atlarge-lists.icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ttf" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ttf</a><br>
<br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div>