7 ms·

"after much deliberation the <bold>Chrome team is now experimenting with building its own DNS resolver</bold>" With all due respect, I think you have missed th

by CUR10US 14y ago

"after much deliberation the <bold>Chrome team is now experimenting with building its own DNS resolver</bold>" With all due respect, I think you have missed the point.

stock_toaster 14y ago
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.
- 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 ago
    I 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 ago
    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.
  - afimrishi 14y ago
    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.
    - CUR10US 14y ago
      I remember reading that thread some time ago. Are you the engineer who was rude to the journalist?
      - afimrishi 14y ago
        I think you have someone else in mind. Perhaps one of the commenters on her article?
- igrigorik 14y ago
  Just tested it in Canary builds and the async DNS resolver does parse and respect /etc/hosts.
  - stock_toaster 14y ago
    Great news! Thanks for testing igrigorik.
- afimrishi 14y ago
  The Chromium experimental DNS resolver should respect that. If it does not, it's a bug and please file it at new.crbug.com.
james4k 14y ago
Interestingly, but off topic, Go has its own DNS resolver that it uses when the getaddrinfo C API isn't available.
- CUR10US 14y ago
  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.
  - james4k 14y ago
    Go's net package has its own resolver. See http://golang.org/src/pkg/net/dnsclient.go http://golang.org/src/pkg/net/dnsclient.go http://golang.org/src/pkg/net/dnsclient_unix.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.
    - CUR10US 14y ago
      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.

by CUR10US 14y ago

"after much deliberation the <bold>Chrome team is now experimenting with building its own DNS resolver</bold>" With all due respect, I think you have missed the point.

stock_toaster 14y ago

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.

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 ago
  I 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 ago
  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.
- afimrishi 14y ago
  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.
  - CUR10US 14y ago
    I remember reading that thread some time ago. Are you the engineer who was rude to the journalist?
    - afimrishi 14y ago
      I think you have someone else in mind. Perhaps one of the commenters on her article?
igrigorik 14y ago
Just tested it in Canary builds and the async DNS resolver does parse and respect /etc/hosts.
- stock_toaster 14y ago
  Great news! Thanks for testing igrigorik.
afimrishi 14y ago
The Chromium experimental DNS resolver should respect that. If it does not, it's a bug and please file it at new.crbug.com.

james4k 14y ago

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

CUR10US 14y ago
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.
- james4k 14y ago
  Go's net package has its own resolver. See http://golang.org/src/pkg/net/dnsclient.go http://golang.org/src/pkg/net/dnsclient.go http://golang.org/src/pkg/net/dnsclient_unix.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.
  - CUR10US 14y ago
    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.