That would not be a welcome change for me.

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.

Just tested it in Canary builds and the async DNS resolver does parse and respect /etc/hosts.

Great news! Thanks for testing igrigorik.

The Chromium experimental DNS resolver should respect that. If it does not, it's a bug and please file it at new.crbug.com.

"after much deliberation".

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.

The original comment in this thread seems to have been deleted, so I can't tell what was said. The primary reasons for implementing our own DNS resolver include: * Being able to fully instrument it. As the article mentions, we have internal debugging pages like about:net-internals, which rely on this instrumentation. * Being able to run experiments. Google Chrome releases often run A/B experiments to play around with different configurations to see which has better performance and what not. This is harder to do with a 3rd party library.

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.

I think you have someone else in mind. Perhaps one of the commenters on her article?

I linked to Will's post in the article, definitely worth a read: https://plus.google.com/103382935642834907366/posts/FKot8mgh...

Check the comments, there are some very good discussions in there with Daniel Stenberg about c-ares and other resolvers.

I hypothesize their reason would be because they want to turn chrome more into a full os (chrome os/chromebook), and bring more things in house. I also recall something about some resolvers having through when ipv6 is enabled but not actually functional. Possibly they are trying to make such things a bit more seamless.

I, currently at least, would still prefer that the os handle name resolution.

Interestingly, but off topic, Go has its own DNS resolver that it uses when the getaddrinfo C API isn't available.

You mean the Go tools have their own resolver?

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.

Go's net package has its own resolver. See http://golang.org/src/pkg/net/dnsclient.go http://golang.org/src/pkg/net/dnsclient_unix.go

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.

Interesting to read the comments. They should just rewrite the C resolver library for UNIX. Let's face it, the Plan 9^W^WGo team would probably produce a more elegant result than what we're using now, which has had its share of bugs over the years.