Live data from Hacker News

Chromium DNS performance

plus.google.com

11–20 of 22 posts

Re: Chromium DNS performance

#11
post #10

So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening. My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close... "I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trife…

A lot depends on how you define 'control' in that context. People still have choices. No one is forced to use their services. I find Google's ambitions and scope amazing as well as a little frightening I'll admit. They now have a significant role in millions of peoples OS (Android, ChromeOS), their communications (GMail, Android), social circles (Google+), documents (Google Docs), browser they use (Chrome, Android, Google DNS), ads they see, applications/music/books they purchase (Play), videos they see (Youtube) and can now consolidate all they have gleamed about you into one solid product.

Re: Chromium DNS performance

#12
post #10

So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening. My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close... "I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trife…

Isn't all that paranoia stressful to maintain?

Re: Chromium DNS performance

#13
post #10

So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening. My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close... "I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trife…

Isn't all that paranoia stressful to maintain?

Don't troll on HN. My comment is the exact opposite of paranoia. Wesley's post papers over their strategic goals with technical jargon. That's not paranoia. That's the standard operating procedure for Google. They are an ad company. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-...

Re: Chromium DNS performance

#14
post #13

Earlier quoted context omitted.

Isn't all that paranoia stressful to maintain?

Don't troll on HN. My comment is the exact opposite of paranoia. Wesley's post papers over their strategic goals with technical jargon. That's not paranoia. That's the standard operating procedure for Google. They are an ad company. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-...

I don't think that you have any objection with the Chrome team writing their own (presumably open source) DNS client (or at least if you do I'm unable to see why).

To try and guess your objection (please correct me if I'm misreading), this worries you because it would make it simpler for Chrome to default to using Google's DNS rather than the OS setting?

That's an interesting objection, and one I'd like to see discussed here. If that was your point I kinda wish you'd just said it rather than hinting darkly and linking to a couple page long article.

(disclaimer: I work at Google and care a lot about its soul/ethics. I do not speak for Google. Also, I'm a low-level engineer on stuff completely unrelated to Chrome/ DNS/etc.)

Re: Chromium DNS performance

#15
post #14
post #13

Earlier quoted context omitted.

Don't troll on HN. My comment is the exact opposite of paranoia. Wesley's post papers over their strategic goals with technical jargon. That's not paranoia. That's the standard operating procedure for Google. They are an ad company. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-...

I don't think that you have any objection with the Chrome team writing their own (presumably open source) DNS client (or at least if you do I'm unable to see why). To try and guess your objection (please correct me if I'm misreading), this worries you because it would make it simpler for Chrome to default to using Google's DNS rather than the OS setting? That's an interesting objection, and one I'd like to see discus…

Of course this is what is going to happen. They will make it an "option," naturally. Like picking your default search provider when you start Chrome for the first time.

Re: Chromium DNS performance

#16
post #15
post #14

Earlier quoted context omitted.

I don't think that you have any objection with the Chrome team writing their own (presumably open source) DNS client (or at least if you do I'm unable to see why). To try and guess your objection (please correct me if I'm misreading), this worries you because it would make it simpler for Chrome to default to using Google's DNS rather than the OS setting? That's an interesting objection, and one I'd like to see discus…

Of course this is what is going to happen. They will make it an "option," naturally. Like picking your default search provider when you start Chrome for the first time.

FWIW, that would require a drastic rearchitecture of the existing Internet, and thereby seems quite unlikely: most performance-oriented infrastructure is based on being able to approximate the latency to and location of a user based on the origin of their DNS queries, allowing you to direct people to highly localized servers for the actual content; this is how all the major CDNs, such as Akamai, work. When you start using Google's DNS servers the Internet gets a lot slower (and it isn't just a couple hundred milliseconds of latency-to-start: it can mean minutes or hours of time-to-completion when you end up streaming large files and videos from the wrong places... the bandwidth difference can be massive).

Re: Chromium DNS performance

#17
post #16
post #15

Earlier quoted context omitted.

Of course this is what is going to happen. They will make it an "option," naturally. Like picking your default search provider when you start Chrome for the first time.

FWIW, that would require a drastic rearchitecture of the existing Internet, and thereby seems quite unlikely: most performance-oriented infrastructure is based on being able to approximate the latency to and location of a user based on the origin of their DNS queries, allowing you to direct people to highly localized servers for the actual content; this is how all the major CDNs, such as Akamai, work. When you start…

I'm neither a Google employee, nor can I speak for the team that runs Google's public DNS servers, but I'd be surprised if that team didn't consider "using Google's DNS servers [causes] the Internet [to get] a lot slower" to be a major bug. 8.8.8.8 and 8.8.4.4 are supposed to be anycast addresses which route to the closest server to your location. [0]

[0] https://code.google.com/speed/public-dns/faq.html#anycast

Re: Chromium DNS performance

#18
post #10

So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening. My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close... "I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trife…

It seems that you don't know what a stub resolver is.

A stub resolver is a piece of software which uses the DNS (and other) servers listed in the system configuration to resolve names to addresses. The stub resolver may use a variety of strategies when deciding which of the configured servers to use, how to time the queries, and what to cache; but stub resolvers respect the system admin's wishes WRT what name resolution servers to talk to.

See: https://tools.ietf.org/html/rfc1123#page-74 and: https://tools.ietf.org/html/rfc4033#section-7

Re: Chromium DNS performance

#19
post #10

So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening. My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close... "I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trife…

It seems that you don't know what a stub resolver is. A stub resolver is a piece of software which uses the DNS (and other) servers listed in the system configuration to resolve names to addresses. The stub resolver may use a variety of strategies when deciding which of the configured servers to use, how to time the queries, and what to cache; but stub resolvers respect the system admin's wishes WRT what name resolut…

There is no connection between a stub resolver as Chrome is implementing it, and the system-indicated DNS server.

This, as an aside, is what's wrong with HN. People cite RFCs or other datapoint as if it validates their point, when in fact, it does no such thing. You can run 10 stub resolvers on your system, each talking to a different DNS server. A stub simply indicates that it lacks the fortitude for full-blown root-down DNS resolution and validation. It might even still have a cache of sorts. That's it.

Why my post got marked down, I'll never know.

Re: Chromium DNS performance

#20
post #16

Earlier quoted context omitted.

FWIW, that would require a drastic rearchitecture of the existing Internet, and thereby seems quite unlikely: most performance-oriented infrastructure is based on being able to approximate the latency to and location of a user based on the origin of their DNS queries, allowing you to direct people to highly localized servers for the actual content; this is how all the major CDNs, such as Akamai, work. When you start…

I'm neither a Google employee, nor can I speak for the team that runs Google's public DNS servers, but I'd be surprised if that team didn't consider "using Google's DNS servers [causes] the Internet [to get] a lot slower" to be a major bug. 8.8.8.8 and 8.8.4.4 are supposed to be anycast addresses which route to the closest server to your location. [0] [0] https://code.google.com/speed/public-dns/faq.html#anycast

That same FAQ directly addresses this problem. They are supposedly working with the IETF on a specification solution to the problem (which will likely take forever to get good deployment of, if it even happens).

With existing infrastructure, however, the core issue is not going to be addressed unless Google has some Nyquist limit dominating ratio of DNS servers to the number of servers Akamai has (which is a very large number ;P).

As an example: I am pretty certain Akamai has nodes at the local university campus. Unless Google has a DNS server in my neighborhood (unlikely), I'm going to get streaming data from LA instead of a couple miles away.

http://code.google.com/speed/public-dns/faq.html#cdn

Post reply on HN