Chromium's DNS-Hijacking Tests Accused of Causing Half of All Root Queries (zdnet.com) 84
ZDNet reports:
In an effort to detect whether a network will hijack DNS queries, Google's Chrome browser and its Chromium-based brethren randomly conjures up three domain names between 7 and 15 characters to test, and if the response of two domains returns the same IP, the browser believes the network is capturing and redirecting nonexistent domain requests. This test is completed on startup, and whenever a device's IP or DNS settings change.
Due to the way DNS servers will pass locally unknown domain queries up to more authoritative name servers, the random domains used by Chrome find their way up to the root DNS servers, and according to Verisign principal engineer at CSO applied research division Matthew Thomas, those queries make up half of all queries to the root servers. Data presented by Thomas showed that as Chrome's market share increased after the feature was introduced in 2010, queries matching the pattern used by Chrome similarly increased.
"In the 10-plus 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," Thomas said in an APNIC blog post. "That equates to about 60 billion queries to the root server system on a typical day."
Thomas added that half the DNS traffic of the root servers is being used to support a single browser function, and with DNS interception being "certainly the exception rather than the norm", the traffic would be a distributed denial of service attack in any other scenario.
Due to the way DNS servers will pass locally unknown domain queries up to more authoritative name servers, the random domains used by Chrome find their way up to the root DNS servers, and according to Verisign principal engineer at CSO applied research division Matthew Thomas, those queries make up half of all queries to the root servers. Data presented by Thomas showed that as Chrome's market share increased after the feature was introduced in 2010, queries matching the pattern used by Chrome similarly increased.
"In the 10-plus 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," Thomas said in an APNIC blog post. "That equates to about 60 billion queries to the root server system on a typical day."
Thomas added that half the DNS traffic of the root servers is being used to support a single browser function, and with DNS interception being "certainly the exception rather than the norm", the traffic would be a distributed denial of service attack in any other scenario.
Give us more money to do nothing more... (Score:4, Funny)
Verisign bought Network Solutions 10 years ago. https://money.cnn.com/2000/03/... [cnn.com]
Two years later they sold some of the services, leaving the root server business to themselves. https://www.networkworld.com/a... [networkworld.com]
To finish off the trifecta they signed an agreement with the US Department of Commerce and ICANN to charge for remaining services, and to increase that anually. https://www.icann.org/news/ann... [icann.org]
And... now... 7 months later, they're complaining people are making use of their "free to all in the world to use" DNS servers is somehow like a DoS.
Is "Speedtest" a DoS? It's not usable bandwidth... it's just "send lots of bytes... receive lots of bytes.... time it all, and drop them all on the floor." Other than providing the latency and bandwidth, it's a DoS, right? Just like looking up false domain names to see when they resolve [in]correctly and then they NXDOMAIN.
Sounds to me like someone wants to "alter deal; pray I don't alter it further".
DNS queries to public DNS servers when used for a purpose that is to the befit of the user and as a result of the user's action is no different than a Speedtest or any other metric used to ensure the underlying structure of the Internet has not been compromised.
It's hard to see a DoS here... but then I'm not Verisign sucking on the US government's funds.
E
Re:Give us more money to do nothing more... (Score:4, Interesting)
Also, it's Chromium usage tracking data. Seriously, why are they *not* doing this already?
Re:Give us more money to do nothing more... (Score:5, Insightful)
I don't think so. A malicious party which is manipulating DNS responses can easily special-case *.google.com in order to avoid detection.
Re: (Score:2)
Re: (Score:2)
Most (all?) of the RIRs operate them
So I was curious if this was accurate, and it doesn't look like it [securitytrails.com] but maybe I'm just misinterpreting? It does look like RIPE runs one of the roots (the k root) but AFRINIC, APNIC, LACNIC, etc, all absent.
Re:Give us more money to do nothing more... (Score:5, Insightful)
While I don't know the specific ins and outs of this or any other $evilcorp's actions against another, I do sort of see their point.
A speed test is typically run from a server that local to your location to test edge performance. It is a service specifically set up and provided to do whats written on the box, with an expectation of fair use but no expectation of return. Critically, not every browser on the plant is using speed test to look up goat porn. If MS Word started running speed tests against my service every time it was run or a document was saved (so clippy could tell you how long it would take your spreadsheet to upload to the cloud for example) I'd be pretty pissy as well. I didn't provide the service so MS could add an upsellable feature to their application, and hell yes I'd want a slice of that pie.
Likewise, the DNS system is provided as a service, free (regardless of what is happening under the bonnet, none of us are paying a subscription for DNS resolution) for all and sundry to use, serves a singular purpose and again, has a expectation that you won't build an application that winds up being half of all the DNS traffic to operate. There is an entire rabbit hole of ongoing ethical red flags we could cite when considering Google's actions around the commodification of personal data and it's attitude to the public internet, but the TL;DR is that it's just another example of them riding hard and deep over what is basically public infrastructure. These fuckers have enough iron in their sheds and flesh in their shops, there is absolutely no reason for them not to roll their own solution that does not require half the global root capacity to operate.
Re: (Score:3)
So far I think you have done the best job of articulating why Verisign may be pissed off with how Google goes about it. Furthermore since Chrome is now enforcing its own DoH and bypassing the system DNS settings does it need to still do this?
Re: (Score:2)
Furthermore since Chrome is now enforcing its own DoH and bypassing the system DNS settings does it need to still do this?
Yes, because no one has had the sense to make tampering with transit illegal. DoH in Chrome is not enabled by default yet, and so the most insidious and obnoxious DNS meddling done by US ISPs redirecting bad hostnames to their own advertising pages will still work. Google implemented this feature specifically to deal with that bullshit, and it works well enough that ISPs largely abandoned it. But the moment that behavior goes away, you can be sure Comcast and Spectrum and friends will return to that bad
Re: (Score:2)
DoH simply means they pass the initial request to an encrypted DNS server (eg Cloudflares) which will then make requests to the hierarchy of other DNS servers anyway.
So the exceptional load is still there, and impacting all the servers as requesting a doman that does not exist means the caches will not be hit and the request must be passed on in the expectation that this is just a new domain name.
Re: (Score:2)
I think you missed my point there. Google's justification for all the extra traffic was to check if networks were hijacking DNS traffic. With DoH the request is encrypted until it gets to the trusted DNS server so it completely bypasses traditional DNS hijacking which relied on plaintext requests. So it makes their justification completely pointless and redundant.
Re: Give us more money to do nothing more... (Score:2)
Re: Give us more money to do nothing more... (Score:2)
Potentially Microsoft is also doing it, as Edge is now based on Chromium
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yup, that's what I based my comments on. When D-Link engaged in NTP vandalism some years ago, they apologised and stopped doing it once it was drawn to their attention. When Netgear did the same thing they went to some lengths to try and fix the problem once they were informed about it.
In contrast, what have Google done? According to the Chromium bug tracker [chromium.org], nothing.
Re: (Score:2)
I actually wrote a blog post about this [1] for apnic earlier this year, after giving a talk about it at DNS-OARC last year. The problem is a pain, as it does generate a bunch of garbage queries that are otherwise useless. Yes, our infrastructure can (and must) handle them, but there is a cost in terms of time, energy, etc.
[1]: https://blog.apnic.net/2020/04... [apnic.net]
[2]: https://youtu.be/sh9Bbk_1bMQ?t... [youtu.be]
Re: (Score:2)
Oh, follow on: the root servers operate at a loss. They currently receive no money for the service they run. [Yes, Verisign receives (a lot of) money for other services they run, but most have no way to fund their production root-server operations and offer the service for the public good]
Re: Give us more money to do nothing more... (Score:1)
Do any root server operators sell their data?
DNS interception is an exception? Hardly... (Score:5, Informative)
Pretty much every "free" WiFi service in hotels, coffee shops and bars does this, in order to force you to a sign-in page.
Further, I just typed "kjhsdjfhkjhazdkjfjhkjhnasdjkhad.com" into my browser's address bar and got a search page from Level3.
DNS interception happens all the time, ever since someone realised it could make money...
Re: (Score:2)
The hotels, coffee shops etc. are a different beast. They intercept ALL traffic if you're not signed in and direct you to the login page and it is expected behavior when you're there. The issue being discussed here is testing what happens when you try to go somewhere that doesn't exist.
Re: DNS interception is an exception? Hardly... (Score:5, Informative)
It's called a captive portal and they don't intercept all traffic. DNS in particular they're supposed to leave alone, because returning the captive portal IP would result in poisoning the DNS resolver cache, and for 5 minutes after signing in the user would swear there's no connectivity because their browsers home page doesn't load.
They do however intercept port 80 and 443, so no matter what IP address your browser goes to, it gets a 303 redirect to the captive portal web page. Everything else is usually actively blocked (TCP port closed or UDP black hole) until the sign in occurs.
Re: DNS interception is an exception? Hardly... (Score:4, Informative)
Not all of them, though. A hotel I stayed at in Shanghai (near Century Park) only blocked TCP when not signed in. UDP went through just fine. I could make SIP calls with an Australian SIP provider without signing in to the hotel WiFi.
Re: DNS interception is an exception? Hardly... (Score:2)
So what you're saying is that it registers on the sip server using udp? Strange...
Re: DNS interception is an exception? Hardly... (Score:4, Informative)
Yes, SIP is entirely UDP-based. It doesnâ(TM)t need TCP at all.
Re: (Score:2)
Only if they botch the TTL. DNS record TTL is measured by seconds. You can put a 1-second expiry on a result. However, that does nothing to already-cached records, so you still have to grab the ports.
Re: (Score:2)
Ummm no.
Most captive portals *DO INDEED* "intercept" DNS. They return responses with a short TTL so as to not corrupt the cache. "Intercept" is a loose word here because they aren't actually intercepting anything, as they are the primary resolver returned by DHCP.
Back in the bygone days, many captive portals did not intercept DNS - but folks soon figured out that you could trivially use DNS Tunneling to get free internet anywhere that DNS was allowed out. The widespread use of easy DNS Tunneling caused capt
Re: (Score:2)
Incompetent captive portals intercept DNS. They'll continue breaking as more security is added be it by DNSSec or DNS/TLS. Modern captive portals intercept HTTP traffic to specific hosts causing the OS or the browser to pull up a captive portal agent or webpage.
Not that that's a great solution because each OS/browser does this in their own peculiar way and worse, present a moving target to captive portal developers. Especially Apple which has a special browser just for this and it's behavior is always ch
Re: (Score:2)
That doesn't sound like a very good idea. Why on earth would you screw with TTL and risk running into problems when there are much easier ways of effectively blocking tunnels? For example, blocking text records prior to signing in, or even setting limits on subdomain lengths. DNS poisoning is bad mojo and stands to break a lot of things, even if you make a very short TTL.
Re: (Score:2, Funny)
kjhsdjfhkjhazdkjfjhkjhnasdjkhad.com" into my browser's address bar and got a search page from Level3.
Kjhsdjfhkjhazdkjfjhkjhnasdjkhad is popular tourist spot in glorious nation of Kazhakstan.
Re: (Score:2)
Re: (Score:2)
The primary "force" is by forcing all outbound HTTP and HTTPS through a managed web proxy. There are powerful reasons to do this, managing the load and providing accountability for services in their shop.
Re: (Score:2)
There's a difference between DNS interception, and proxying at the gateway to direct to a captive portal. Once you sign in a typical hotel / WiFi hotspot does not intercept any traffic. Specifically even when not signed in the HTTP / HTTPS redirect is *NOT* accomplished by DNS interception.
This is also why captive portals fail when attempting to access sites with HSTS.
Re: (Score:2)
Pretty much every "free" WiFi service in hotels, coffee shops and bars does this, in order to force you to a sign-in page.
No they don't. Redirects are done at the network level. If you use naming services for redirects you will win a never ending stream of support calls post sign-in.
Further, I just typed "kjhsdjfhkjhazdkjfjhkjhnasdjkhad.com" into my browser's address bar and got a search page from Level3.
Don't use level3's DNS servers and you won't have that problem.
one question (Score:3)
is there something in chrome://flags/ that can be disabled?
Re: one question (Score:3)
https://cloud.google.com/docs/... [google.com]
Re:one question (Score:5, Insightful)
> how do i disable this awful feature?
https://www.mozilla.org/en-US/... [mozilla.org]
Re:one question (Score:5, Insightful)
Well thats the catch isn't it. From a user perspective, its far from "awful", its protection against DNS poisoning.
The problem is , it dumped a huge workload onto the root DNS servers which they where not designed to cope with (Your really supposed to be interogating something upstream, assuming of course that your browser isn't trying to defend against hijacks.).
Re: (Score:3)
it is awful and unnecessary, stop supporting stupid design decisions.
Re: (Score:2)
Re: one question (Score:2)
I don't blame Chrome for addressing the DNS abuse of captive portals. The extra DNS queries are obviously the fault of those portals.
Re: (Score:2, Interesting)
Re: (Score:3)
You are only shilling for stupid design. Think harder.
Re: (Score:2)
You are only shilling for stupid design. Think harder.
It's stupid design to memorise a mistyped URL because a nefarious (nearly always) 3rd party is doing DNS interception? How the hell did you get an up mod for that comment while providing absolutely nothing of value to the discussion while baselessly accusing the OP of shilling? Stop being a toxic shit.
Re: (Score:2)
Let it break (Score:2)
Re: (Score:2)
Re: Let it break (Score:5, Interesting)
DNSSEC is rarely implemented by ISPs, probably because most of them like to hijack NXDOMAIN, which would break, and AFAIK most OSs don't implement it client side.
You can, if you choose, implement it at your router. I personally use a commination of DNSSEC and DNS over TLS with 1.1.1.1 and 1.1.0.0, which supports both, and then I configure my firewall to transparently redirect all DNS traffic to the routers DNS server, thus preventing individual devices from using their own DNS server. Especially Google devices, which like to always use 8.8.8.8 and 8.8.4.4.
You can do all of this with OpenWRT.
Terrible implementation (Score:4, Interesting)
Re: (Score:2)
Re:Terrible implementation (Score:5, Interesting)
Re: (Score:2)
I never noticed Chrome doing anything about it
Chrome doesn't do anything about it other than reporting to Google that it's happening on your network. Although another user has said that Chrome doesn't remember URLs in your history even if your ISP serves a legit landing page when it detects it's on this network. Take that comment for what you will. ... Actually maybe you could verify that behavior for us since you have a shitty ISP. I can't test this here.
Re: (Score:2)
Just as a suggestion I'd suggest using Quad9 (9.9.9.9) over Google's DNS. Quad9 is a 501c3, has no logging policy, and also does malware-domain filtering. Cloudflare has a similar filtering system but apparently Quad9 is the best one out there. Quad9 supports DNSCrypt, DoH, and DoT.
simple fix (Score:2)
Google change the Chrome algorithm slightly so that the 3 domains looked up are all like random-domain.google.com -- that will greatly reduce the load on the root DNS servers.
Re: (Score:3)
Someone else suggested the same thing almost two hours before you. It's not a solution, because it's much easier for the malicious actor to see that they're being tested and so avoid detection.
Re: (Score:2)
They specifically don't want to do this since then the ISPs that are doing NXDOMAIN rewriting will detect that domain too easily and change their tools to recognize that domain and special case it.
If DNS was a real secure protocol... (Score:1)
They should (Score:3)
Re: (Score:2)
And what's the basis for suspicion? Being online at all? There's no other way to tell.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Did you even read the summary?
Google's Chrome browser and its Chromium-based brethren randomly conjures up three domain names between 7 and 15 characters to test,
You are making up a completely different and unrelated scenario. If your domain doesn't have a TLD, then it doesn't go to the root servers (and if it did, whose root would it go to?). A keyword can do a local DNS lookup if there's only one word - but you pretty much just have to trust local DNS for that. They don't exist outside the LAN anyway.
Re: (Score:2)
Re: (Score:2)
That's a great way of not knowing how many people in your country have Coronavirus. Especially since how do you form suspicion? Like coronavirus few networks will show any detectable symptoms that redirects are happening.
Unless you want Google doing *even more* analysis of the URLs you're typing in. How do they tell the difference between two mistyped URLs and two sites that hit a common CDN?
DNSSEC (Score:3)
if they correctly used DNSSEC then they would be able to see if the domain was being intercepted...
Re: (Score:2)
It's not up to Chrome to use DNSSEC. The best Google could do is implement DoH and bypass the OS's settings altogether, something which is about as popular as shit on a blanket here.
Re: (Score:3)
And yet, that's exactly what Google has done. So why do they still do this when they don't use your resolver anyway?
Distributed Service of Drama (Score:1)
A factor of two is denial of service? It's pretty bad, but I usually think of DDOS as a factor of ten or a hundred, not two.
your system is broken (Score:2, Troll)
Does this even still work? (Score:5, Interesting)
Re: Does this even still work? (Score:2)
The algos for this stuff are constantly changing. It's an arms race. I see my regular captive portal change behavior ever few months. Then I find new ways to address the issue. Then they change how it works. Then I ...
Re: (Score:2)
Re: (Score:2)
Can't a malicious actor simply wait until the fourth request in a group to start its action?
Well they can NOW! Tomorrow's article: Google Chrome accounts for 3/4 of all DNS root queries.
Greenland (Score:1)
The traffic is already offset (Score:2)
I'm sure that the extra root server traffic has been more than offset by Google's own popular caching DNS servers. Even server administrators who would normally pass up to root DNS servers instead of their ISP caching DNS are likely to choose Google instead for speed.
how do i protect myself without this feature? (Score:1)
what are my options for protecting myself from DNS hijack?
is this method employed by any other software, outside of Chrome?
is there a better method of detecting hijacks?
is there any other method of detecting hijacks?
Re: (Score:2)
The most common entity doing a DNS hijack these days is the browser. Both Chrome and Firefox hijack DNS requests and send them to their own choice of server instead of the one programmed in your OS or supplied by your router/ISP.
Re: (Score:1)
thank you, could you cite your refs please?
i need to know about this, i think.
Re: (Score:2)
thank you very much, i get what this is about now.
Not your business Chrome! (Score:2)
default chrome to 8.8.8.8 and 8.8.4.4.. (Score:1)
The obvious chromium fix... (Score:2)
...would be to grab three random DNS entries already in cache to see if they return the same IP address. Only do the three random names if they can't find three good addresses. The DNS names in cache would presumably not have to go up to the root servers as much.