[HN Gopher] A Chrome feature is creating enormous load on global...
___________________________________________________________________
A Chrome feature is creating enormous load on global root DNS
servers
Author : BerislavLopac
Score : 83 points
Date : 2020-08-25 11:48 UTC (11 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| donor20 wrote:
| This issue only exists because without chrome's work here
| virtually every ISP / Wifi provider etc started hijacking DNS
| inquiries to pump trash ads down your throat.
|
| 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.
| mlindner wrote:
| Except there's other ways of doing this. For example Firefox
| does the same thing and doesn't do this.
| https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-d...
|
| > 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.
| donor20 wrote:
| Separate question - if google did what mozilla did and wrapped
| DNS in HTTPS and ran it to 8.8.8.8 (allowing user to pick other
| resolvers) - would that be better?
|
| 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?
| thanhhaimai wrote:
| The real "complaint" is that Google broke the ISPs ability to
| highjack your DNS. With that real goal in mind, they will
| still "complain" if Google wrap DNS on https and send to
| 8.8.8.8
|
| 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.
| donor20 wrote:
| Verisign, the folks complaining did a wildcard DNS entry
| for ALL .com and .net domains called sitefinder! How can
| they handle the bandwidth for that (serving full web pages
| with lots of "partner" offers etc) but not 3 DNS packets?
|
| Something doesn't make sense here.
| floatingatoll wrote:
| The budget for operating the root servers is unlikely to
| be shared with the budget for operating Sitefinder.
| firloop wrote:
| Google running the DNS resolver wouldn't fix this problem;
| due to the nature of the requests that Chrome is making, the
| lookups would have to hit the root server because they
| wouldn't be cached anywhere else.
| donor20 wrote:
| I'm suggesting let google run some root resolvers.
|
| 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.
| sterlind wrote:
| Bandwidth isn't the issue, it's the dynamic nature of the
| content and the global consistency needed between DNS
| servers. Videos are static content; they don't get
| updated so you don't need any schemes to check for
| updates.
|
| 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.
| suprfsat wrote:
| If Chrome switched to Google DNS for everything they
| wouldn't need to check for ISP interception.
| petee wrote:
| The irony is actually Google ignores/bends standards all the
| time because they can get away with it.
| Animats wrote:
| The root servers may have to delay NXDOMAIN replies. Those are
| rare for legit requests.
| tobyhinloopen wrote:
| Interesting problem
| jiggawatts wrote:
| In a previous YCNews discussion of this topic, I worked out based
| on public Root DNS statistics that this traffic amounts to at
| most a few gigabits spread across _hundreds_ of DNS servers, each
| of which has at least a gigabit connection.
|
| 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.
| adrr wrote:
| Just require HTTPS already.
| godman_8 wrote:
| HTTPS doesn't protect against DNS or SNI interception
| adrr wrote:
| If there's no valid cert for the domain, you can't 301/302
| redirect over https connection. SNI just lets the middleman
| peak at the host name, it doesn't allow you to redirect. DNS
| interception allows the attackers to change IP but https
| still needs a valid cert for the host.
| kenniskrag wrote:
| With HSTS and preload it should mitigate the vulnerability.
| adrr wrote:
| Issues with HSTS is that it is opt in. It should be an
| opt out with a list of legacy sites that ships with the
| browsers similar to how hsts preloading works.
| stordoff wrote:
| Incidentally, this affects how my ISP implements its domain
| blocks. Non-HTTPS sites are 307 redirected to
| https://assets.virginmedia.com/site-blocked.html, whereas
| connections to HTTPS sites are just halted (IIRC, it sends
| a TCP reset, but it's a while since I looked into it).
| floatingatoll wrote:
| Incorrect.
|
| 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.
| [deleted]
| lilSebastian wrote:
| This topic has been posted several times in the last few days
| jwilk wrote:
| https://news.ycombinator.com/item?id=24231857 (4 days ago, 207
| comments)
|
| Anything else?
| floatingatoll wrote:
| You can email the mods using the footer Contact link and ask
| them to dupe them all together, if you provide them the HN
| story links for the dupes.
| creeble wrote:
| What does Firefox do to prevent the problem chromium is trying to
| solve?
| stefan_ wrote:
| They turned on DNS over HTTPs by default and send your queries
| to Cloudflare:
|
| https://blog.mozilla.org/blog/2020/02/25/firefox-continues-p...
| stuartd wrote:
| You're seemingly pushing you own agenda here?
|
| 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.
| stefan_ wrote:
| In your agenda to expose my agenda in linking a Firefox
| blog post, you have missed that this isn't even about
| captive portal detection. Captive portals are easily
| detected by trying to load a known response page; captive
| portals don't fake that because they want to be detected so
| that the browser redirects you to their portal.
|
| 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.
| stuartd wrote:
| Ok sorry, please forgive my misunderstanding, it sounds
| like you're saying Cloudflare is a 'malicious DNS
| resolver', but I guess I'm wrong there as well? I opted
| into DoH when it became available in Nightly (though not
| in the US), am I being a mug here?
| carlhjerpe wrote:
| I can't even remember last i got an advertisement page.
| Must've been about 10 years ago, though the last 5 I've
| been using third party DNS. I don't know any Swedish ISP
| that does this. I'm using ISP DNS on my phone.
| floatingatoll wrote:
| Sounds like your country isn't as commonly affected.
| Lucky you :)
| stefan_ wrote:
| I assume at some point the calculus flipped for ISPs to
| not annoy you with low-quality ads and make customers cut
| them out, but instead operate a real DNS resolver so you
| can still sell their real-time browsing history to
| advertisers. Part of that is the Google and Cloudflare
| marketing campaigns for their public resolvers, so people
| had a ready alternative.
| iancarroll wrote:
| > captive portals don't fake that because they want to be
| detected so that the browser redirects you to their
| portal
|
| 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".
___________________________________________________________________
(page generated 2020-08-25 23:00 UTC)