With all due respect, I think you have missed the point.
With all due respect, I think you have missed the point.
I use some hosts file overrides for two reasons:
1) testing at $dayjob
2) to block some spammy things, and if their in-browser resolver did not take those into consideration
If either of those were impacted, it would be bye-bye chrome.
Why did the team deliberate so much?
I will let the readers ponder this.
There are already some very good stub resolvers and resolver libraries available to users (e.g. dnsqr and the djbdns library). I have a hard time believing Google is going to do better than djb.
Of course I have no problem with them or anyone else writing another one. Have at it. The more attention brought to name resolution the better -- because it can be so easily abused for questionable purposes, it is something that deserves user oversight.
But why does Google need to place theirs _inside the browser_? That is a very curious design decision.
Check the comments, there are some very good discussions in there with Daniel Stenberg about c-ares and other resolvers.
I, currently at least, would still prefer that the os handle name resolution.
As Ilya notes, a fuller discussion can be found at the G+ post's comments section.
Note: I'm a Chromium developer on our network stack. I'm also the author of the G+ post linked to in the article.
The blog at miek.nl says that Go had a DNS library written in Go in the provided samples for a while, then they removed it. It would be interesting to know why.
But yes, it does not appear to be used anywhere now, as all of the dns lookups for each platform seem to end up at cgo calls.