[davidu]

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 trifecta that the consumer will probably be best served avoiding. I’m sure we’ll find out soon enough."

[simoncion]

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

[davidu]

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.

[simoncion]

Firstly I'm not making a point, I'm giving you information that your vague hand-wavy rant seems to indicate that you don't have. Secondly, I point to the RFCs to indicate that my description of stub resolvers isn't just my opinion, but is somewhat in line with the community definition.

I never said that one could not have multiple stub resolvers installed on a single system. I also never intended to imply this. There's no reason to believe that the Chromium stub resolver will do anything but intelligent caching and fetching. Certainly, there's nothing in the linked Google Plus post to make me believe otherwise. Mr. Chan mentions that writing a browser-specific stub resolver is really the wrong thing to do, but it's something that they really need to do to get their target DNS query performance and to detect and work around certain kinds of really shitty breakage.

Why did you get downvoted? Perhaps because you said

I like how they mask very crystal-clear strategy...

when the strategy is anything but clear to anyone but you. By way of explanation, you point to a multi-page article about you and OpenDNS in which -among many other things- you say "[Google has] a separate privacy policy for Google DNS, and I’m sure they are hypersensitive about privacy concerns, so I wouldn’t be too paranoid [about the possibility of DNS query logging and data mining].". I'm not sure what strategy it is that you're worked up about, but it would be really nice if you'd come out and say it, rather than being all oblique and mysterious.

Additionally, it would seem that you're the CEO or President or something of OpenDNS? It's exceedingly poor form to say vague FUDdy smelling things about companies that compete with your core business. If you're going to say something, man up and say it; don't make others feel around to maybe discover a hint of what your point was.

[kiloaper]

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.

[krakensden]

Isn't all that paranoia stressful to maintain?

[davidu]

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

[rictic]

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

[davidu]

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.

[saurik]

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

[simoncion]

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