5 ms·
"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 resol
by CUR10US 14y ago
"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.
- igrigorik 14y agoI linked to Will's post in the article, definitely worth a read: https://plus.google.com/103382935642834907366/posts/FKot8mghkok 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.
- stock_toaster 14y agoI 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.
- afimrishi 14y agoThe 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.