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

Sat Feb 6 02:15:35 UTC 2021

An update from Versign's blog Jan 7 2021
https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/

" In a previous blog post
<https://blog.verisign.com/domain-names/chromiums-impact-on-root-dns-traffic/>,
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 redesigned its code
<https://bugs.chromium.org/p/chromium/issues/detail?id=1090985> 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...."

.... 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."

So some significant reductions...and more when the Chromium desktop client
gets the update.

Dev Anand

On Wed, Sep 2, 2020 at 5:06 PM Sivasubramanian M <6.Internet at gmail.com>
wrote:

> 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
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20210205/ec4b754e/attachment-0001.html>