[At-Large] [technology taskforce] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers

mail@christopherwilkinson.eu CW mail at christopherwilkinson.eu
Wed Sep 2 18:03:33 UTC 2020


 > …a recommended setup, we should promote it

Thankyou, Lutz +1

CW

> El 2 de septiembre de 2020 a las 16:13 Lutz Donnerhacke <lutz at donnerhacke.de> escribió:
> 
> 
>     Most ISPs can mirror the root zone into their own resolvers. So the queries are terminated early and the load is distributed.
> 
>     Several instances of the root servers allow AXFR/IXFR without any problems.
> 
>     It’s a recommended setup, we should promote it more.
> 
>      
> 
>     Von: ttf <ttf-bounces at atlarge-lists.icann.org> Im Auftrag von Dev Anand Teelucksingh
>     Gesendet: Mittwoch, 26. August 2020 03:25
>     An: At-Large Worldwide <at-large at atlarge-lists.icann.org>
>     Cc: Technical issues <technical-issues at atlarge-lists.icann.org>; Technology Taskforce WG <ttf at atlarge-lists.icann.org>
>     Betreff: Re: [technology taskforce] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers
> 
>      
> 
>     It’s to test whether the network  is using NX domain modification (or NX domain hijacking )
> 
>      
> 
>     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 
> 
>      
> 
>     Otherwise, it would have to bug the user “did you mean to search for “word” or https://word” for every single word query 
> 
>      
> 
>     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 
> 
>      
> 
>     The apnic blog post says “ 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.” 
> 
>      
> 
>     Dev Anand 
> 
>      
> 
>      
> 
>     On Tue, 25 Aug 2020 at 6:35 PM, Carlton Samuels <carlton.samuels at gmail.com mailto:carlton.samuels at gmail.com > wrote:
> 
>         > > 
> >         I'm still left with little understanding of why this is important?
> > 
> >          
> > 
> >         What is the use of these lookups for the browser? A previously undisclosed security feature? 
> > 
> >          
> > 
> >         And what is being alleged from the name service side? A unintentional DOS-type attack on the root server system itself? 
> > 
> >          
> > 
> >         CAS.
> > 
> >          
> > 
> >         On Tue, 25 Aug 2020, 3:39 pm Dev Anand Teelucksingh, <devtee at gmail.com mailto:devtee at gmail.com > wrote:
> > 
> >             > > > 
> > >             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.
> > > 
> > >             The Intranet Redirect Detector https://bugs.chromium.org/p/chromium/issues/detail?id=1090985 , 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 post https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/  outlining the problem and defining its scope.
> > > 
> > >             Read rest of Ars Technica article : 
> > > 
> > >             https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/
> > > 
> > >              
> > > 
> > >             The APNIC blog post : 
> > > 
> > >             https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/
> > > 
> > >              
> > > 
> > >             Not aware if this is  mentioned before  in ICANN circles 
> > > 
> > >              
> > > 
> > >             Dev Anand 
> > > 
> > >              
> > > 
> > >         > > 
> >             > > > 
> > > 
> > > 
> > >             _______________________________________________
> > > 
> > > 
> > >             ttf mailing list
> > > 
> > > 
> > >             ttf at atlarge-lists.icann.org mailto:ttf at atlarge-lists.icann.org
> > > 
> > > 
> > >             https://mm.icann.org/mailman/listinfo/ttf
> > > 
> > > 
> > > 
> > > 
> > > 
> > >             _______________________________________________
> > > 
> > > 
> > >             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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
> > > 
> > >         > > 
> >          
> > 
> >     > 
>      
> 


 

> _______________________________________________
>     At-Large mailing list
>     At-Large at atlarge-lists.icann.org
>     https://atlarge-lists.icann.org/mailman/listinfo/at-large
> 
>     At-Large Official Site: http://atlarge.icann.org
>     _______________________________________________
>     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 (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). 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.
> 


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20200902/66353cf1/attachment-0001.html>


More information about the At-Large mailing list