Live data from Hacker News

Chromium's Impact on Root DNS Traffic

blog.apnic.net

11–20 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#11
post #2

I think I've understood the most of the article but I missed the initial part. Why is there a probe in Chrome that uses DNS to query random 7-15 character long hostnames, only to get NXDOMAIN and burden the root nameservers? What does this probe achieve?

Some DNS providers (like ISPs) will hijack NXDOMAINs and redirect you to ads or stuff like that. Chrome wants to detect that.

There was a point where, at least in the US, this was standard behaviour for virtually every single major ISP and mobile provider. Several used to hijack all port 53 traffic to disallow you from using anything but their resolver.

Re: Chromium's Impact on Root DNS Traffic

#12

For me, the kicker: if I'm reading it correctly, over 40% of DNS traffic to the root server they examined is just diagnostic probes from Google Chrome being used to spot malicious DNS servers.

Just thinking for a few seconds, I can think of a number of ways to not repeatedly spam DNS servers while still accomplishing the objective. If you were to send 3 random queries to Google every time you opened your browser, you would quickly get hellbanned behind a recaptcha. Not saying that we should embark on some quest for retribution against Google. It's just sad.

I bet they just made this as a throwaway and it worked fine when it was 1% of traffic and maybe they just haven't looked at it again. I bet if the APNIC people harassed them they would change it.

Re: Chromium's Impact on Root DNS Traffic

#14
post #6

For me, the kicker: if I'm reading it correctly, over 40% of DNS traffic to the root server they examined is just diagnostic probes from Google Chrome being used to spot malicious DNS servers.

We got hit by this issue in March when our remotr users increased 5+ times and the DNS traffic going through our VPNs was causing a headache to our DNS servers. We pinpointed this to tis Chrome functionality, which includes also other chromium based browers like new Edge, and we had to deploy a relevant GPO to disable this functionality. Some background, I'm talking about ~200+k remote users. Also while in the office…

Fairly certain this feature is more then ten years old.

Re: Chromium's Impact on Root DNS Traffic

#15
post #6

Earlier quoted context omitted.

We got hit by this issue in March when our remotr users increased 5+ times and the DNS traffic going through our VPNs was causing a headache to our DNS servers. We pinpointed this to tis Chrome functionality, which includes also other chromium based browers like new Edge, and we had to deploy a relevant GPO to disable this functionality. Some background, I'm talking about ~200+k remote users. Also while in the office…

The last time I saw DNS throughput or performance issues was around 2003 on a network with 200K desktops and servers. That was 17 years ago, and they don't have a problem any more, despite growing in footprint to nearly half a million client machines. I struggle to understand how DNS can possibly be a performance issue in 2020. In most corporate environments, the "working set" of a typical DNS servers will fit in the…

[deleted]

Re: Chromium's Impact on Root DNS Traffic

#16

I'm curious to know how much data the root namespace servers put out in terms of gbps, but this doesn't seem to be public information.

https://root-servers.org/

Select a root server at the bottom. Some, but not all, have a "statistics" link. Seems to be stated in qps and message size distribution, but you should be able to derive traffic volume from that.

Re: Chromium's Impact on Root DNS Traffic

#18
post #11

Earlier quoted context omitted.

Some DNS providers (like ISPs) will hijack NXDOMAINs and redirect you to ads or stuff like that. Chrome wants to detect that.

There was a point where, at least in the US, this was standard behaviour for virtually every single major ISP and mobile provider. Several used to hijack all port 53 traffic to disallow you from using anything but their resolver.

And for those who don't understand why this is a bad thing, I will present my own use case. I run pi-hole at home and frequently work from there for another company. That company has provided me with a laptop that uses Cisco's DNS "Umbrella", which is some sort of security feature: https://docs.umbrella.com/deployment-umbrella/docs/point-you... Because my company laptop doesn't pay attention to the DNS servers recommended by DHCP, and ignores the local domain search TLD, if I try to ssh into a machine on my local network (without a FQDN) from the company laptop, it replaces the local search domain with the corporate domain, then does the lookup, and gets an A record from Umbrella that is not on my local network. It makes the ssh connection and (surprisingly) reaches an ssh server, which asks me for my password. The login fails, and my password (in plain text) could very well have been harvested by the ssh server on the catchall host. Now you are going to tell me that I shouldn't use ssh passwords, and should instead be using RSA keys for ssh. Regardless of what the NSA tells you, THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.

Sorry for the rant, but wildcard catchall DNS is a REALLY BAD THING.

Re: Chromium's Impact on Root DNS Traffic

#19
post #11

Earlier quoted context omitted.

There was a point where, at least in the US, this was standard behaviour for virtually every single major ISP and mobile provider. Several used to hijack all port 53 traffic to disallow you from using anything but their resolver.

And for those who don't understand why this is a bad thing, I will present my own use case. I run pi-hole at home and frequently work from there for another company. That company has provided me with a laptop that uses Cisco's DNS "Umbrella", which is some sort of security feature: https://docs.umbrella.com/deployment-umbrella/docs/point-you... Because my company laptop doesn't pay attention to the DNS servers recomm…

In that case you should get a host key differing message (or not present) at least.

Re: Chromium's Impact on Root DNS Traffic

#20
post #14
post #6

Earlier quoted context omitted.

We got hit by this issue in March when our remotr users increased 5+ times and the DNS traffic going through our VPNs was causing a headache to our DNS servers. We pinpointed this to tis Chrome functionality, which includes also other chromium based browers like new Edge, and we had to deploy a relevant GPO to disable this functionality. Some background, I'm talking about ~200+k remote users. Also while in the office…

Fairly certain this feature is more then ten years old.

https://cloud.google.com/docs/chrome-enterprise/policies/?po...

        Google Chrome (Linux, Mac, Windows) since version 80
        Google Chrome OS (Google Chrome OS) since version 80
Chrome 80: February 4, 2020

and as a clarification

When you connect via VPN to the corporate network the DNS queries are not distributes as when you are in the office. You have a X amount of entry points for the VPN which are served by Y DNS servers which is less than the total amount of DNS servers available in the corporate network. Plus the amount of remote users increased vastly, plus the VPN technology used plus the DNS servers used. Not that simple I'm afraid

Post reply on HN