Hacker News Reader

Comment by donor20 | Hacker News Reader

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?

View on HN

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.

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.

The budget for operating the root servers is unlikely to be shared with the budget for operating Sitefinder.

The GTLD / top level domain servers are different from root servers. Also, root servers are a shared, distributed responsibility. Verisign doesn't run most of them: https://en.wikipedia.org/wiki/Root_name_server

"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."

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?

I thought it was already the default for chrome?

A billion requests-per-day is not much actually. 1B / (24h * 60m * 60s) = 11.5K qps

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.

You can get over 9 million queries per second from an AMD Epyc box https://en.blog.nic.cz/2019/12/10/epic-dns-benchmarking/ and over a million qps on more modest hardware https://www.knot-dns.cz/benchmark/ but a lot of the root DNS servers are running BIND so aren’t able to reach such lofty heights

Thanks for confirming my intuition. I haven't paid attention to bind performance for well over a decade. So now I am even more flabbergasted that Verisign are even talking about the load.

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.

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.

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.

We are talking 15k qps. A single AMD machine should be able to much higher rates - millions. Yes, there is overhead, but my point was, if verisign or whoever is in charge can't run these root servers to handle 15k qps for the entire global internet then let google do it.

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.

I think the root resolvers can handle it (at least so far). It's just that these probably unnecessary DNS request to test for a somewhat rare situation are causing just about as much traffic to root resolvers as the rest of the internet combined.

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.

If Chrome used DoH then it wouldn't need to send these types of queries

That's not the proper way though.

Reply on news.ycombinator.com