A Chrome feature is creating load on global root DNS servers
arstechnica.com
arstechnica.com
THANK you google for stopping this total abuse of internet standards (very annoying for some cases where no UI as well).
The irony of Verisign complaining about this is incredible actually - they were the no 1 abusers of this in the past! They go on about interception being the exception these days. That's actually because chrome put a stake right through the heart of Verisgns efforts to intercept.
It feels like folks complain - you are sending too much traffic. If google said - we can handle it directly (they obviously can - the bandwidth youtube alone uses has got to be magnitudes larger) people would complain - no no - send us the traffic.
Google already runs 8.8.8.8 and encourages adoption of it I think - maybe it can handle the billion requests per day? Or maybe they can help verisign scale their infra?
Not to rain on the sob story, but netflix, amazon and google probably pump out orders of magniture more bytes then these requests.
It's axiomatic. If my session makes 3 512 byte requests when I start browsing, and then I watch 10 youtube videos at 2K, then a netflix movie at 4K, how in the WORLD is the bandwidth from the 3 512 byte requests crushing infrastructure?
And if it is, let google or amazon or someone with a clue run the infra. Seriously - this makes no sense that THIS is the bandwidth killer out there. Apple updates - sure, those are monsters and a ton of people get them. DNS packets are pretty small by contrast.
It's certainly possible to design DNS to scale, it's just that they may be overwhelmed by QPS right now because they made different trade-offs.
These are ridiculously low numbers, and dns is EASIER not harder than video. Google is doing full live streaming, multi res / format delivery with chat across a ton of platforms.
And no - root DNS does not change at a high rate of speed. It's a 2MB file you can download yourself. .com stays .com for a LONG time and the TTLs are going to be in hours and days.
Note that this will actually be disproportionately higher than DNS traffic to recursive resolvers, because, since these domain names are randomly generated, they won't be cached very well.
I think the complaint is not "we can't handle this" so much as "we don't want to pay for this."
Now, if you are saying that google should run root resolvers so they can absorb some cost of doing this, that might be fair. Although, I suspect it would be cheaper for them to find a different way to accomplish this in the browser.
The ISPs now will have a series of PR articles about how Google wants to own the internet, track all your web DNS, monopolize the access, and evil blah blah.
We should read these articles with the mindset that they are PR pieces, not a solution request.
Opinions are my own.
Something doesn't make sense here.
They'd be right, but that's neither here nor there in this contrived strawman.
And yes, a lot of people would have a serious problem if Google baked in their own DNS. That would break a lot of stuff. And it would make the notion of checking invalid DNS entries rather unnecessary, wouldn't it?
Let's say 2:1 between daily peak and trough, and call that 23K qps peak.
10 years ago a single server could do 30Kqps of DNS:
https://www.dell.com/downloads/global/shared/DNS_performance...
So ~40 boxes 10 years ago would have been able to handle 60 billion queries per day.
I'd expect a single modern server of reasonable size to easily do 100K qps, and probably more like 200-300K qps, if not exceeding a million qps (though a single box may hit the packet/s bottleneck).
So Verisign is complaining about a single digit to low double digit server box worth of traffic. I have a hard time imagining this being more than a rounding error for them.
EDIT: Updated to directly reflect 60B queries per day figure.
> The root server system is, out of necessity, designed to handle very large amounts of traffic. As we have shown here, under normal operating conditions, half of the traffic originates with a single library function, on a single browser platform, whose sole purpose is to detect DNS interception. Such interception is certainly the exception rather than the norm. In almost any other scenario, this traffic would be indistinguishable from a distributed denial of service (DDoS) attack.
> Could Chromium achieve its goal while only sending one or two queries instead of three? Are other approaches feasible? For example, Firefox’s captive portal test uses delegated namespace probe queries, directing them away from the root servers towards the browser’s infrastructure.
It would be good to switch to a less expensive solution, and I hope the Chromium team does so, but at the end of the day we don't want ISPs to hijack DNS queries.
I'm not convinced that I should care more about the extra load on root DNS servers than I should care about the hijacking. And frankly, I don't trust the people who are complaining about this.
https://en.wikipedia.org/wiki/Site_Finder
Google had nothing to do with solving that problem.
Google's search engine is not an "internet standard". Being the default on Chrome, that is in effect what this DNS querying behaviour is protecting. Protecting Google "search via the address bar" is also the raison d'etre for Google Public DNS. Back in 2008/2009, this type of "search" was being hijacked by OpenDNS.
The solution to not having DNS "hijacked" is to have more user control of DNS. Letting users select a third party DNS provider is better than no choice at all, but that is not really control. The third party still has control. Unfortunately, full user control -- the best solution to stop hijacking and other DNS tricks -- is not what Google and others are promoting.
By design, I have no entries for certain Google domains in the zone files I use on the LAN. I have seen how much involuntary DNS traffic there is from Chrome and other Google software 24/7 (including queries for these random strings). It is significant, even for just one user. Why don't they provide an option to turn this off.
And can't you select your DNS provider in Chrome by going to Settings > Security > Advanced > DNS Stuff
Sending all browser DNS queries back to google by default seems abusive in a different way.
Changing one abuse for another is barely an improvement.
Regulations is what will force ISP to behave correctly and stop hijacking DNS queries.
For me, as European, it is worst to be spied by Google and my data given to the United States of America intelligence, than to depend on my ISP that is bounded to European laws and will know where I connect regardless.
Google is abusing its position and most users are not technical savvy enough to understand the implications.
The context of the discussion is whether Google should be sending those DNS queries. The premises involved technical details about how heavy those DNS queries are. The DNS queries don't make things worse for the end-users privacy wise. Nobody is arguing that we should give Google more "abuse". There is an actual net negative of "abuse" in this case, by removing the abuse from the ISPs, with a solution that doesn't change your data privacy from Google.
Notice that all of the breathless articles going on about how evil Google is are using percentages, not absolute numbers?
This is because journalists don't do journalism any more, they just put their name on corporate PR that is intended as a weapon in a war for control.
The ISP just took it as a great idea. Now we have to make countermeasures for it.
Are the root servers 90% idle or are they overloaded? That changes everything. Also servers are fast, bandwidth is cheap, and DNS is lightweight. How is this really a major resource issue?
Anything else?
https://blog.mozilla.org/blog/2020/02/25/firefox-continues-p...
As the article itself says:
> Are other approaches feasible? For example, Firefox’s captive portal test uses delegated namespace probe queries, directing them away from the root servers towards the browser’s infrastructure.
This is about malicious DNS resolvers that don't return NXDOMAIN for non-existent domains but instead send you to an ISP advertisement page. This messes with the omnibox. For all other domains, they resolve just fine. These resolvers are inclined to evade detection, e.g. if browsers checked a static list of domains, they would just return NXDOMAIN for only those.
This is not always true; several systems try to get you out of the iOS/macOS captive portal detection because it boxes the user into a restrictive frame, and either always impersonate captive.apple.com or begin to impersonate it when they want the user to believe they're "online".
* https://github.com/jdebp/nosh/blob/9a113ec2c2e58679bab8d8b34...
I bet there's a decent amount of cash in DNS hijacking for big players, so you should probably think of it like the hypothetical cryptography attacker. You should assume they will know everything about your method but still can't beat it. If you can tell them what you're doing and they can beat it, they will. They wouldn't have done it in the first place without motivation.
Send a second request of the same domain via the system DNS. If it's not NXDOMAIN, it's hijacking unknown DNS requests.
One request that might hit the root instead of 3.
You can very easily just make 'qwajuixk.' or 'qwajuixk' + dhcp assigned search domain return one of your spam IPs.
(Hell, it's open source, ISP could just integrate the algorithm into their DNS hijacking logic).
If there was, ISPs would already detect 3 quick requests from a client that fits this pattern and disable the domain hijacking for the second and third request (or even for all 3 if they’re confident enough that the first request is part of this pattern).
It's unacceptable, it's unhelpful, and I see it as a vector for getting untrustworthy software on less savy users hardware.
Its a good thing DoH is now in the stable version of RouterOS, I've just switched it on.
Here is the difference between using Virgin Media's resolving proxy DNS servers and using your own:
% # http://jdebp.uk./Softwares/djbwares/guide/commands/dnsqrx.xml
%
% dnsqrx a z398nvfsd0098u3qwtltnk. 194.168.4.100
1 z398nvfsd0098u3qwtltnk:
56 bytes, 1+1+0+0 records, response, noerror
query: 1 z398nvfsd0098u3qwtltnk
answer: z398nvfsd0098u3qwtltnk 0 A 92.242.132.24
%
%
% dnsqr a z398nvfsd0098u3qwtltnk.
1 z398nvfsd0098u3qwtltnk:
40 bytes, 1+0+0+0 records, response, authoritative, nxdomain
query: 1 z398nvfsd0098u3qwtltnk
%
% tail -n 1 /var/log/sv/tinydns/current | tai64nlocal
2020-08-26 09:37:44.305619726 7f000001:cfd9:f163 + 0001 z398nvfsd0098u3qwtltnk
%
I did have my router setup to cache DNS requests to google and updated the DHCP config so everything would use my router for resolution, but virgin's DNS servers were still being pulled through as a "dynamic server" according to the RouterOS panel.
I thought Virgin was fiddling with my DNS requests even though I was sending them to a different provider.
Requiring HTTPS would absolutely protect against hijacking of top-level domains that aren't registered, as no SSL/TLS issuer that's trusted by browsers will issue certificates covering those domains.
A first step towards that eventual outcome would be to default to https:// for anything typed by a user that doesn't start explicitly with http:// so that they are protected from NXDOMAINs in that regard.
I hope that the various browsers implement at least that first step.
Amazon and Azure are still lagging behind, but those aren't going to ignore DNSSEC forever.
DoH solves nothing in this context unless we centralise DNS resolution to Google or Cloudflare. The Windows method submits the DNS requests to the same server as your regular DNS server by default, so the protocol doesn't give you any advantage there. Chrome does the same thing; if it detects that your name server does DoH, it'll switch to that, but it won't switch DNS servers.
Perhaps this does solve the problem for the few people with custom DNS servers getting their queries intercepted, but the vast majority of people (everyone not using Firefox inside the US) won't notice any difference.
DNSSEC will solve this problem by making the certification chain break for domains that haven't been signed by their TLD, but only if we start enforcing it (like we are enforcing HTTPS for certain features already). DNS over HTTPS will just encrypt the bad NXDOMAIN DNS query when it comes from the same malicious server, only protecting against traffic interception when using different DNS servers; the two protocols serve different purposes.
DoH breaks ISP DNS interception immediately, and for all zones, not just the rare DNSSEC-signed ones, by moving DNS resolution off-net to a more trusted provider.
The irony is, breaking NXDOMAIN interception is in fact a core use case of DNSSEC, and the protocol simply won't work for it, because the ocean needs to boil before every vector of the attack is closed. DoH went from the whiteboard to deployment in a tiny fraction of the time, and actually closes this hole decisively.
(That the firefox solution works is due to the root servers themselves being deemed trustworthy, and the ISP ones being tentatively not, but the DNSSEC solution is strictly better as now nothing needs to be trusted.)