Live data from Hacker News

Chromium's Impact on Root DNS Traffic

blog.apnic.net

21–30 of 221 posts

Re: Chromium's Impact on Root DNS Traffic

#21
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…

My personal thought is that you shouldn't be connecting to anything personal or local from a work provided, likely heavily keylogged, device.

Re: Chromium's Impact on Root DNS Traffic

#22
post #20
post #14

Earlier quoted context omitted.

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…

The article mentions relevant code changes in 2014. It seems like the enterprise policy may be recent, but the feature is much older.

Re: Chromium's Impact on Root DNS Traffic

#23
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…

User managed passwords aren’t ideal. If you’re looking for more security and you’re concerned about compromise of local keys, you could purchase a couple of yubikeys (or similar), or you could use an SSH CA (Hashicorp vault and Step come to mind). However, if you’re very concerned about storing creds on a company laptop, or compromising your passwords by logging into a honeypot server (which known_hosts should be protecting you from), you ought to be much more scared of your company keylogging you...

Re: Chromium's Impact on Root DNS Traffic

#24
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…

> THIS IS ALWAYS A BAD IDEA because once any account is compromised, ALL OTHER ACCOUNTS with locally stored keys ARE ALSO COMPROMISED.

This is not universally true. If you generate separate private keys for each server-client pair, compromising one private key will limit the damage to just the one server.

Re: Chromium's Impact on Root DNS Traffic

#25

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.

Google could, you know, use their own DNS servers for this...

Re: Chromium's Impact on Root DNS Traffic

#26
I don't get this feature. And I really hate that it's present in pretty much every browser these days. If I want to type an URL, I'll use the address bar. If I want to search, I'll use the search bar. Different bars with different keyboard shortcuts and different purposes. Why do so many browsers merge these two? Screens are insanely wide these days, so screen real estate can't be the reason. Are we trying to trick users into thinking that URLs aren't a thing anymore?

Maybe this "omnibox" doesn't know whether I want to enter a hostname or a search term, but I do.

Re: Chromium's Impact on Root DNS Traffic

#27
post #20
post #14

Earlier quoted context omitted.

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…

The article has a nice graph that shows when the feature was introduced - 2010.

Re: Chromium's Impact on Root DNS Traffic

#28

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.

I havent looked in a good 5 years, but “not much.” There were roots running off of 1gbs links back then. A quick loot at the sibling comment root stats and Im swagging a few hundred thousand tps at about 256 bytes per response. The problem is/was mostly in distributing and sinking inbound garbage packets.

Re: Chromium's Impact on Root DNS Traffic

#29
post #25

Earlier quoted context omitted.

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.

Google could, you know, use their own DNS servers for this...

No, they couldn't. The whole purpose of these probe requests is to assess whether the DNS server used by a particular client is acting normally (responding with NXDOMAIN if a domain does not exist), so these must bde sent to the DNS server of the client, which effectively means that unless this DNS server performs the hijacking that is to be detected, they will inevitably end up on a root DNS server, because no server in the hierarchy will know those domains.

Forcing these probe requests onto Google's DNS would completely defy their purpose in the first place.

Re: Chromium's Impact on Root DNS Traffic

#30

I'm sure anyone here who has set up a PiHole ad-blocking DNS server at home has run into these random domain requests and wondered what was going on. At first I thought one of my devices had a virus on it or something until I did a few searches and discovered it was Chrome being ludicrous. (Next topic: Getting Chrome to actually use the DNS provider that you specify and nothing else...)

Would these have occurred on a sever that has unbound as its upstream?
Post reply on HN