Ars Technica : A Chrome feature is creating enormous load on global root DNS servers
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-enormou... 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
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@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-enormou...
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@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.
Good question Carlton, I asked myself the same questions ... *Sergio Salinas Porto **Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>**Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>**FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>**facebook: salinasporto <http://www.facebook.com/salinasporto> **twitter: sergiosalinas <http://twitter.com/sergiosalinas>**Mobi:+54 9 223 5 215819**"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra * * conciencia o violan nuestro sentido común" Eduardo Galeano* El mar., 25 ago. 2020 a las 19:35, Carlton Samuels (< carlton.samuels@gmail.com>) escribió:
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@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-enormou...
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@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@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.
Matts APNIC blog describes exactly what they are for… And no these are not any kind of attack on the root, the Ars article blows it out of all proportion, OCTO presented on this at some stage earlier in the year and its also mentioned as a non issue in OCTO-008 https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf From: ttf <ttf-bounces@atlarge-lists.icann.org> on behalf of Sergio Salinas Porto <presidencia@internauta.org.ar> Date: Wednesday, 26 August 2020 at 07:59 To: Carlton Samuels <carlton.samuels@gmail.com> Cc: Technical issues <technical-issues@atlarge-lists.icann.org>, At-Large Worldwide <at-large@atlarge-lists.icann.org>, Technology Taskforce WG <ttf@atlarge-lists.icann.org> Subject: Re: [technology taskforce] [At-Large] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers Good question Carlton, I asked myself the same questions ... Sergio Salinas Porto Presidente Internauta Argentina - LACRALO/ICANN<https://atlarge.icann.org/ralos/lacralo> Asociación Argentina de Usuarios de Internet<http://www.internauta.org.ar/>/FeTIA<http://www.fetia.org.ar/> FUILAC- Federación de Usuarios de Internet de LAC<https://fuilac.org> facebook: salinasporto<http://www.facebook.com/salinasporto> twitter: sergiosalinas<http://twitter.com/sergiosalinas> Mobi:+54 9 223 5 215819 "Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra conciencia o violan nuestro sentido común" Eduardo Galeano El mar., 25 ago. 2020 a las 19:35, Carlton Samuels (<carlton.samuels@gmail.com<mailto:carlton.samuels@gmail.com>>) escribió: 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@gmail.com<mailto:devtee@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-enormou... 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@atlarge-lists.icann.org<mailto:ttf@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@atlarge-lists.icann.org<mailto:At-Large@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.
Thanks for the link to the OCTO-008 (at https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf) file. However, it doesn't say its a non-issue. Under 3.1 "The Chromium queries are the largest single cause of queries to root servers. Other IMRS instances often see over 50% of all incoming queries from Chromium. The purpose of these queries is to check if Chromium is behind a captive portal. Provisioning for root servers is often a function of the overall load on root servers to satisfy the scaling needs. While these queries are free for Chromium to make, the cost of provisioning for root-server instances is not. Google has been notified of this issue, but it remains outstanding." The two related Bug issues : https://bugs.chromium.org/p/chromium/issues/detail?id=946450&q=intranet%20re... https://bugs.chromium.org/p/chromium/issues/detail?id=1090985 Dev Anand On Wed, Aug 26, 2020 at 3:08 AM James Gannon <james@cyberinvasion.net> wrote:
Matts APNIC blog describes exactly what they are for…
And no these are not any kind of attack on the root, the Ars article blows it out of all proportion, OCTO presented on this at some stage earlier in the year and its also mentioned as a non issue in OCTO-008 https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf
*From: *ttf <ttf-bounces@atlarge-lists.icann.org> on behalf of Sergio Salinas Porto <presidencia@internauta.org.ar> *Date: *Wednesday, 26 August 2020 at 07:59 *To: *Carlton Samuels <carlton.samuels@gmail.com> *Cc: *Technical issues <technical-issues@atlarge-lists.icann.org>, At-Large Worldwide <at-large@atlarge-lists.icann.org>, Technology Taskforce WG <ttf@atlarge-lists.icann.org> *Subject: *Re: [technology taskforce] [At-Large] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers
Good question Carlton, I asked myself the same questions ...
*Sergio Salinas Porto *
*Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>*
*Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>*
*FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>*
*facebook: salinasporto <http://www.facebook.com/salinasporto> *
*twitter: sergiosalinas <http://twitter.com/sergiosalinas>*
*Mobi:+54 9 223 5 215819*
*"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra *
* conciencia o violan nuestro sentido común" Eduardo Galeano*
El mar., 25 ago. 2020 a las 19:35, Carlton Samuels (< carlton.samuels@gmail.com>) escribió:
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@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-enormou...
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@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@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.
_______________________________________________ ttf mailing list ttf@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.
Sorry my use on non issue may not have been descriptive, it poses no risk to the security or stability of the DNS was the core of my message, in reply to the DoS characterisation. On 8/27/2020 7:35:18 PM, Dev Anand Teelucksingh <devtee@gmail.com> wrote: Thanks for the link to the OCTO-008 (at https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf [https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf]) file. However, it doesn't say its a non-issue. Under 3.1 "The Chromium queries are the largest single cause of queries to root servers. Other IMRS instances often see over 50% of all incoming queries from Chromium. The purpose of these queries is to check if Chromium is behind a captive portal. Provisioning for root servers is often a function of the overall load on root servers to satisfy the scaling needs. While these queries are free for Chromium to make, the cost of provisioning for root-server instances is not. Google has been notified of this issue, but it remains outstanding." The two related Bug issues : https://bugs.chromium.org/p/chromium/issues/detail?id=946450&q=intranet%20re... [https://bugs.chromium.org/p/chromium/issues/detail?id=946450&q=intranet%20redirect&can=2] https://bugs.chromium.org/p/chromium/issues/detail?id=1090985 [https://bugs.chromium.org/p/chromium/issues/detail?id=1090985] Dev Anand On Wed, Aug 26, 2020 at 3:08 AM James Gannon <james@cyberinvasion.net [mailto:james@cyberinvasion.net]> wrote: Matts APNIC blog describes exactly what they are for… And no these are not any kind of attack on the root, the Ars article blows it out of all proportion, OCTO presented on this at some stage earlier in the year and its also mentioned as a non issue in OCTO-008 https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf [https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf] From: ttf <ttf-bounces@atlarge-lists.icann.org [mailto:ttf-bounces@atlarge-lists.icann.org]> on behalf of Sergio Salinas Porto <presidencia@internauta.org.ar [mailto:presidencia@internauta.org.ar]> Date: Wednesday, 26 August 2020 at 07:59 To: Carlton Samuels <carlton.samuels@gmail.com [mailto:carlton.samuels@gmail.com]> Cc: Technical issues <technical-issues@atlarge-lists.icann.org [mailto:technical-issues@atlarge-lists.icann.org]>, At-Large Worldwide <at-large@atlarge-lists.icann.org [mailto:at-large@atlarge-lists.icann.org]>, Technology Taskforce WG <ttf@atlarge-lists.icann.org [mailto:ttf@atlarge-lists.icann.org]> Subject: Re: [technology taskforce] [At-Large] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers Good question Carlton, I asked myself the same questions ... Sergio Salinas Porto Presidente Internauta Argentina - LACRALO/ICANN [https://atlarge.icann.org/ralos/lacralo] Asociación Argentina de Usuarios de Internet [http://www.internauta.org.ar/]/FeTIA [http://www.fetia.org.ar/] FUILAC- Federación de Usuarios de Internet de LAC [https://fuilac.org] facebook: salinasporto [http://www.facebook.com/salinasporto] twitter: sergiosalinas [http://twitter.com/sergiosalinas] Mobi:+54 9 223 5 215819 "Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra conciencia o violan nuestro sentido común" Eduardo Galeano El mar., 25 ago. 2020 a las 19:35, Carlton Samuels (<carlton.samuels@gmail.com [mailto:carlton.samuels@gmail.com]>) escribió: 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@gmail.com [mailto:devtee@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-enormou... [https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormou...] The APNIC blog post : https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/ [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@atlarge-lists.icann.org [mailto:ttf@atlarge-lists.icann.org] https://mm.icann.org/mailman/listinfo/ttf [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 [https://www.icann.org/privacy/policy]) and the website Terms of Service (https://www.icann.org/privacy/tos [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@atlarge-lists.icann.org [mailto:At-Large@atlarge-lists.icann.org] https://atlarge-lists.icann.org/mailman/listinfo/at-large [https://atlarge-lists.icann.org/mailman/listinfo/at-large] At-Large Official Site: http://atlarge.icann.org [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 [https://www.icann.org/privacy/policy]) and the website Terms of Service (https://www.icann.org/privacy/tos [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. _______________________________________________ ttf mailing list ttf@atlarge-lists.icann.org [mailto:ttf@atlarge-lists.icann.org] https://mm.icann.org/mailman/listinfo/ttf [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 [https://www.icann.org/privacy/policy]) and the website Terms of Service (https://www.icann.org/privacy/tos [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. _______________________________________________ ttf mailing list ttf@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.
IMO, there is a future risk - Microsoft Edge is now a Chromium derivative for Windows and Microsoft will migrate/upgrade all Windows installations to use this new Edge browser. The number of non-existent TLD queries by Edge to the root servers will only increase. This will increase the cost for provisioning root-server instances to answer non-existent tld queries which (shrug) seems wasteful. Dev Anand On Fri, Aug 28, 2020 at 8:29 AM James Gannon <james@cyberinvasion.net> wrote:
Sorry my use on non issue may not have been descriptive, it poses no risk to the security or stability of the DNS was the core of my message, in reply to the DoS characterisation.
On 8/27/2020 7:35:18 PM, Dev Anand Teelucksingh <devtee@gmail.com> wrote: Thanks for the link to the OCTO-008 (at https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf) file. However, it doesn't say its a non-issue. Under 3.1
"The Chromium queries are the largest single cause of queries to root servers. Other IMRS instances often see over 50% of all incoming queries from Chromium. The purpose of these queries is to check if Chromium is behind a captive portal. Provisioning for root servers is often a function of the overall load on root servers to satisfy the scaling needs. While these queries are free for Chromium to make, the cost of provisioning for root-server instances is not. Google has been notified of this issue, but it remains outstanding."
The two related Bug issues :
https://bugs.chromium.org/p/chromium/issues/detail?id=946450&q=intranet%20re... https://bugs.chromium.org/p/chromium/issues/detail?id=1090985
Dev Anand
On Wed, Aug 26, 2020 at 3:08 AM James Gannon <james@cyberinvasion.net> wrote:
Matts APNIC blog describes exactly what they are for…
And no these are not any kind of attack on the root, the Ars article blows it out of all proportion, OCTO presented on this at some stage earlier in the year and its also mentioned as a non issue in OCTO-008 https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf
*From: *ttf <ttf-bounces@atlarge-lists.icann.org> on behalf of Sergio Salinas Porto <presidencia@internauta.org.ar> *Date: *Wednesday, 26 August 2020 at 07:59 *To: *Carlton Samuels <carlton.samuels@gmail.com> *Cc: *Technical issues <technical-issues@atlarge-lists.icann.org>, At-Large Worldwide <at-large@atlarge-lists.icann.org>, Technology Taskforce WG <ttf@atlarge-lists.icann.org> *Subject: *Re: [technology taskforce] [At-Large] Ars Technica : A Chrome feature is creating enormous load on global root DNS servers
Good question Carlton, I asked myself the same questions ...
*Sergio Salinas Porto *
*Presidente Internauta Argentina - LACRALO/ICANN <https://atlarge.icann.org/ralos/lacralo>*
*Asociación Argentina de Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA <http://www.fetia.org.ar/>*
*FUILAC- Federación de Usuarios de Internet de LAC <https://fuilac.org>*
*facebook: salinasporto <http://www.facebook.com/salinasporto> *
*twitter: sergiosalinas <http://twitter.com/sergiosalinas>*
*Mobi:+54 9 223 5 215819*
*"Ojalá podamos ser desobedientes, cada vez que recibimos órdenes que humillan nuestra *
* conciencia o violan nuestro sentido común" Eduardo Galeano*
El mar., 25 ago. 2020 a las 19:35, Carlton Samuels (< carlton.samuels@gmail.com>) escribió:
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@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-enormou...
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@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@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.
_______________________________________________ ttf mailing list ttf@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.
_______________________________________________ ttf mailing list ttf@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.
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@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@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-enormou...
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@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.
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@atlarge-lists.icann.org> Im Auftrag von Dev Anand Teelucksingh Gesendet: Mittwoch, 26. August 2020 03:25 An: At-Large Worldwide <at-large@atlarge-lists.icann.org> Cc: Technical issues <technical-issues@atlarge-lists.icann.org>; Technology Taskforce WG <ttf@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@gmail.com <mailto:carlton.samuels@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@gmail.com <mailto:devtee@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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1090985> Intranet Redirect Detector, 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 <https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/> post outlining the problem and defining its scope. Read rest of Ars Technica article : https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormou... 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@atlarge-lists.icann.org <mailto:ttf@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.
…a recommended setup, we should promote it
Thankyou, Lutz +1 CW
El 2 de septiembre de 2020 a las 16:13 Lutz Donnerhacke <lutz@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@atlarge-lists.icann.org> Im Auftrag von Dev Anand Teelucksingh Gesendet: Mittwoch, 26. August 2020 03:25 An: At-Large Worldwide <at-large@atlarge-lists.icann.org> Cc: Technical issues <technical-issues@atlarge-lists.icann.org>; Technology Taskforce WG <ttf@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@gmail.com mailto:carlton.samuels@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@gmail.com mailto:devtee@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-enormou...
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@atlarge-lists.icann.org mailto:ttf@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@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.
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@christopherwilkinson.eu CW < mail@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@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@atlarge-lists.icann.org> *Im Auftrag von *Dev Anand Teelucksingh *Gesendet:* Mittwoch, 26. August 2020 03:25 *An:* At-Large Worldwide <at-large@atlarge-lists.icann.org> *Cc:* Technical issues <technical-issues@atlarge-lists.icann.org>; Technology Taskforce WG <ttf@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@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@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-enormou...
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@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@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@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@gmail.com
An update from Versign's blog Jan 7 2021 https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traff... " 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@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@christopherwilkinson.eu CW < mail@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@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@atlarge-lists.icann.org> *Im Auftrag von *Dev Anand Teelucksingh *Gesendet:* Mittwoch, 26. August 2020 03:25 *An:* At-Large Worldwide <at-large@atlarge-lists.icann.org> *Cc:* Technical issues <technical-issues@atlarge-lists.icann.org>; Technology Taskforce WG <ttf@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@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@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-enormou...
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@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@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@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@gmail.com
_______________________________________________ ttf mailing list ttf@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.
On August 25, 2020 at 17:35 carlton.samuels@gmail.com (Carlton Samuels) wrote:
I'm still left with little understanding of why this is important?
It's basically inevitable. Lacking effective internet governance structures we have multi-billion dollar corporations acting unilaterally as vigilantes or, perhaps put better, warlords with code as their armed militias in the spirit of Lessig's "Code is Law". But hey keep debating travel reimbursements oh right no one travels anymore but whatever. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
participants (8)
-
bzs＠theworld.com -
Carlton Samuels -
Dev Anand Teelucksingh -
James Gannon -
Lutz Donnerhacke -
mail＠christopherwilkinson.eu CW -
Sergio Salinas Porto -
Sivasubramanian M