5 ms·

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 serve

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 6y ago
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 6y ago
  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.
  - donor20 6y ago
    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.
- thayne 6y ago
  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.
suprfsat 6y ago
If Chrome switched to Google DNS for everything they wouldn't need to check for ISP interception.
eat_veggies 6y ago
If Chrome used DoH then it wouldn't need to send these types of queries
- gsich 6y ago
  That's not the proper way though.

donor20 6y ago

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 6y ago
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.
- donor20 6y ago
  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.
thayne 6y ago
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.

suprfsat 6y ago

If Chrome switched to Google DNS for everything they wouldn't need to check for ISP interception.

eat_veggies 6y ago

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

gsich 6y ago
That's not the proper way though.