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

Wed Sep 2 21:04:51 UTC 2020

>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?

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 NXDOMAIN errors it should be receiving—so
> it just treats all single-word entries as search attempts until further
> notice...[some of] those three lookups tend to propagate all the way up
> to the root nameservers: the local server doesn't know how to resolve
> qwajuixk, so it bounces that query up to its forwarder, which returns the
> favor, until eventually a.root-servers.net or one of its siblings has to
> say "Sorry, that's not a domain."

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?

On Thu, Sep 3, 2020 at 12:53 AM mail at christopherwilkinson.eu CW <
mail at christopherwilkinson.eu> wrote:

>  > …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>
> 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>
> 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
>
>
> 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.
>
>
>
> _______________________________________________
> 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.

-- 
Sivasubramanian M
Please send all replies to 6.Internet at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20200903/dc90ffc1/attachment.html>