6 ms·

Google Chrome and (weird) DNS requests

62 points by there 16y ago

jacquesm 16y ago
Interesting side effect of the helpful features in browsers are apparently sending DNS requests to unsuspecting parties. The owner of www.go can't be all that happy with the flood of requests!
- dchest 16y ago
  There's no .go domain :-)
  - jacquesm 16y ago
    You're right, the application was (apparently) refused. I remember seeing it go by and thinking 'wow, that's a really neat TLD', but never heard from it afterwards. Now I know why :) http://www.icann.org/en/tlds/report/dubai1.html http://www.icann.org/en/tlds/report/dubai1.html
aj700 16y ago
I'm not sure that, as this article states "Chrome automatically tries to determine if the user typed in a domain and tries to resolve it in the background." When I first switched my windows ipv4 dns settings to use opennic i noticed: chrome knows that a string typed into the address bar (one that isn't already eventually found in history or typed before) that ends with any normal suffix .com .uk etc. is a url, instead of just a query to be sent to the default search engine. but it doesn't know what to do with strings that have opennic only suffixes like .free on them. unless i make it clear that i am typing a url and not a query, by putting http:// http:// on the front, it doesn't know that it is a url, because it has the non-standard .free or something on the end. typing example.free or www.example.free for the first time just sends it to the search engine. so it seems chrome only knows/validates the official dns suffixes.
- soult 16y ago
  I am only guessing here, but maybe Chrome uses the Public Suffix list behind this feature, which includes only "official" registries. http://publicsuffix.org/ http://publicsuffix.org/
- hk9565 16y ago
  Sounds like something we'd like to fix. Please file a bug at <http://new.crbug.com/> http://new.crbug.com/>. If you'd like to dig through the code and post a patch too, that will likely speed things up: <http://dev.chromium.org/developers/contributing-code> http://dev.chromium.org/developers/contributing-code>.
  - aj700 16y ago
    i rechecked this with dns prefetching off and with it on. in either case, anything with a standard tld puts the url as the top/selected result on the pulldown, with "send as a query to search" as the second possibility. but if I have prefetching ON (which I didn't when I first encountered the issue) the prefetching finds non-standard domains (eg register.fur, register.ing) and their servers and homepage titles but the option to treat them as a url and just go to the page appears below the default option to treat them as a search in the pulldown, so just typing them in and pressing enter still sends them to search. whether that is a big deal is up to you. it seems silly that something.suffix is not treated as a url when the prefetcher has already found it.
uxp 16y ago
I noticed the random DNS requests the other day when I had to tunnel my traffic over ssh from the local library, but didn't think to figure out what the requests were. Interesting that this article shows up now. If anyone is interested, my auth.log shows: https://gist.github.com/797184 https://gist.github.com/797184
Luyt 16y ago
"Chrome also tries to find out if someone is messing up with the DNS (i.e. “nasty” ISPs that have wildcard DNS servers to catch all domains). Chrome does this by issuing 3 DNS requests to randomly generated domain names," I have a question. Why would wilcard domains be 'nasty'? It's not that unusual, is it? Would Google discourage this? I can imagine that a site uses wildcard domains to differentiate in the content it should serve, for example a blog provider: john.bloggo.com, luyt.bloggo.com, johndoe.bloggo.com etc... You wouldn't want to put a few thousand customer names in your DNS tables, instead use *.bloggo.com and let the webapp interpret the subdomain name. Or in the case of some development server, ftp.domain.com, svn.domain.com, git.domain.com and www.domain.com maybe all should resolve to the same IP and find the corresponding service on that machine. If the admin were to add another service, say SMTP, he could just install a mailer on port 25 and he wouldn't have to adjust the DNS.
- SpikeGronim 16y ago
  It's nasty when the ISP returns an A record for an advertising filled spam page instead of NXDOMAIN.
- cryptoz 16y ago
  > Would Google discourage this? Yes, I think so. When ISPs wildcard all domains, I think the typical reason is so that when you've typed an invalid name, they return a page with search results guessing at your intent. If I'm right (I might not be), then Google has plenty of incentive to stop that from happening, or at least know that it is happening. First, those pages with search results are often ugly, full of ads, poorly formatted, etc. Google would like you to have a nice experience in Chrome so that you're a happy user. If you see an ugly, messy ad-ridden page (especially if the ads aren't Google ads) every time you make a typing mistake, Google loses out. There are probably other more subtle and nuanced reasons that Google would dislike that practice, but I'm not really sure of specifics. (In fact, I'm not entirely sure that DNS wildcarding is even related to those ISP search pages...but I think it is.)
  - dmethvin 16y ago
    Also, if the ISP is answering every DNS query with "yes this is a valid domain" it breaks Chrome's domain discovery feature, described a bit further down the SANS article.
requinot59 16y ago
Chrome should stick to its true nature, do one thing well, and leave the DNS stuff (refetch after..., the weird anti-nasty system explained in the post) to a DNS cache daemon. Google could include one in Chrome OS, and don't turn Chrome (the browser) into a big pile of bloat.
- kjksf 16y ago
  So instead of shipping one executable with code X + Y they should ship two executables: one with code X + one with Y + Z, increasing the overall complexity of what they ship and adding the inevitable "bloat" which would come from extracting DNS code into a deamon and additional code to communicate between Chrome and that deamon (the Z part). That doesn't sound like a sound engineering practice.
  - requinot59 16y ago
    No. They give them a competitive advantage over other OSes by offering a faster Internet experience on ChromeOS. They stick with classic DNS resolving on Chrome the browser, no matter the plateform. The complexity and bloat is having Chrome, Firefox, Opera copying DNS cache features and not gathering their knowledge together in this area.
- comex 16y ago
  Anti-nasty system, maybe. The prefetching thing can't possibly be implemented by the DNS cache daemon because it doesn't know what the user is currently typing.
  - requinot59 16y ago
    I was speaking about the fact that Chrome also re-fetch some of the (most used) DNS entries in the background when they are about to expire (like they do for the DNS "8.8.8.8" servers). I agree that prefetching however can't be done by a DNS cache program.

62 points by there 16y ago

Interesting side effect of the helpful features in browsers are apparently sending DNS requests to unsuspecting parties. The owner of www.go can't be all that happy with the flood of requests!

dchest 16y ago
There's no .go domain :-)
- jacquesm 16y ago
  You're right, the application was (apparently) refused. I remember seeing it go by and thinking 'wow, that's a really neat TLD', but never heard from it afterwards. Now I know why :) http://www.icann.org/en/tlds/report/dubai1.html http://www.icann.org/en/tlds/report/dubai1.html

aj700 16y ago

I'm not sure that, as this article states "Chrome automatically tries to determine if the user typed in a domain and tries to resolve it in the background." When I first switched my windows ipv4 dns settings to use opennic i noticed: chrome knows that a string typed into the address bar (one that isn't already eventually found in history or typed before) that ends with any normal suffix .com .uk etc. is a url, instead of just a query to be sent to the default search engine. but it doesn't know what to do with strings that have opennic only suffixes like .free on them. unless i make it clear that i am typing a url and not a query, by putting http:// http:// on the front, it doesn't know that it is a url, because it has the non-standard .free or something on the end. typing example.free or www.example.free for the first time just sends it to the search engine. so it seems chrome only knows/validates the official dns suffixes.

soult 16y ago
I am only guessing here, but maybe Chrome uses the Public Suffix list behind this feature, which includes only "official" registries. http://publicsuffix.org/ http://publicsuffix.org/
hk9565 16y ago
Sounds like something we'd like to fix. Please file a bug at <http://new.crbug.com/> http://new.crbug.com/>. If you'd like to dig through the code and post a patch too, that will likely speed things up: <http://dev.chromium.org/developers/contributing-code> http://dev.chromium.org/developers/contributing-code>.
- aj700 16y ago
  i rechecked this with dns prefetching off and with it on. in either case, anything with a standard tld puts the url as the top/selected result on the pulldown, with "send as a query to search" as the second possibility. but if I have prefetching ON (which I didn't when I first encountered the issue) the prefetching finds non-standard domains (eg register.fur, register.ing) and their servers and homepage titles but the option to treat them as a url and just go to the page appears below the default option to treat them as a search in the pulldown, so just typing them in and pressing enter still sends them to search. whether that is a big deal is up to you. it seems silly that something.suffix is not treated as a url when the prefetcher has already found it.

uxp 16y ago

I noticed the random DNS requests the other day when I had to tunnel my traffic over ssh from the local library, but didn't think to figure out what the requests were. Interesting that this article shows up now. If anyone is interested, my auth.log shows: https://gist.github.com/797184 https://gist.github.com/797184

Luyt 16y ago

"Chrome also tries to find out if someone is messing up with the DNS (i.e. “nasty” ISPs that have wildcard DNS servers to catch all domains). Chrome does this by issuing 3 DNS requests to randomly generated domain names," I have a question. Why would wilcard domains be 'nasty'? It's not that unusual, is it? Would Google discourage this? I can imagine that a site uses wildcard domains to differentiate in the content it should serve, for example a blog provider: john.bloggo.com, luyt.bloggo.com, johndoe.bloggo.com etc... You wouldn't want to put a few thousand customer names in your DNS tables, instead use *.bloggo.com and let the webapp interpret the subdomain name. Or in the case of some development server, ftp.domain.com, svn.domain.com, git.domain.com and www.domain.com maybe all should resolve to the same IP and find the corresponding service on that machine. If the admin were to add another service, say SMTP, he could just install a mailer on port 25 and he wouldn't have to adjust the DNS.

SpikeGronim 16y ago
It's nasty when the ISP returns an A record for an advertising filled spam page instead of NXDOMAIN.
cryptoz 16y ago
> Would Google discourage this? Yes, I think so. When ISPs wildcard all domains, I think the typical reason is so that when you've typed an invalid name, they return a page with search results guessing at your intent. If I'm right (I might not be), then Google has plenty of incentive to stop that from happening, or at least know that it is happening. First, those pages with search results are often ugly, full of ads, poorly formatted, etc. Google would like you to have a nice experience in Chrome so that you're a happy user. If you see an ugly, messy ad-ridden page (especially if the ads aren't Google ads) every time you make a typing mistake, Google loses out. There are probably other more subtle and nuanced reasons that Google would dislike that practice, but I'm not really sure of specifics. (In fact, I'm not entirely sure that DNS wildcarding is even related to those ISP search pages...but I think it is.)
- dmethvin 16y ago
  Also, if the ISP is answering every DNS query with "yes this is a valid domain" it breaks Chrome's domain discovery feature, described a bit further down the SANS article.

requinot59 16y ago

Chrome should stick to its true nature, do one thing well, and leave the DNS stuff (refetch after..., the weird anti-nasty system explained in the post) to a DNS cache daemon. Google could include one in Chrome OS, and don't turn Chrome (the browser) into a big pile of bloat.

kjksf 16y ago
So instead of shipping one executable with code X + Y they should ship two executables: one with code X + one with Y + Z, increasing the overall complexity of what they ship and adding the inevitable "bloat" which would come from extracting DNS code into a deamon and additional code to communicate between Chrome and that deamon (the Z part). That doesn't sound like a sound engineering practice.
- requinot59 16y ago
  No. They give them a competitive advantage over other OSes by offering a faster Internet experience on ChromeOS. They stick with classic DNS resolving on Chrome the browser, no matter the plateform. The complexity and bloat is having Chrome, Firefox, Opera copying DNS cache features and not gathering their knowledge together in this area.
comex 16y ago
Anti-nasty system, maybe. The prefetching thing can't possibly be implemented by the DNS cache daemon because it doesn't know what the user is currently typing.
- requinot59 16y ago
  I was speaking about the fact that Chrome also re-fetch some of the (most used) DNS entries in the background when they are about to expire (like they do for the DNS "8.8.8.8" servers). I agree that prefetching however can't be done by a DNS cache program.