
Google Chrome and (weird) DNS requests - there
http://isc.sans.edu/diary.html?storyid=10312&rss
======
Luyt
_"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.

~~~
cryptoz
> 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
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.

------
aj700
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://> 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.

~~~
hk9565
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
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
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>

------
jacquesm
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
There's no .go domain :-)

~~~
jacquesm
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>

------
requinot59
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.

~~~
comex
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
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.

