SANS ISC InfoSec Forums

Couple of days ago one of our readers, Thomas, wrote about weird DNS requests that he is seeing coming from his machine. After spending some time he found out that Chrome is sending those requests that he could not explain every time it is started.
Since I spent some time on this (long) time ago, I decided to pay more attention to Chrome’s DNS request (besides that, this diary might help someone who stumbles upon the same thing in the future).

So, in order to speed up browsing Google Chrome does a lot of DNS requests in advance (DNS prefetching – this can be even turned on and off in Chrome’s options). When Chrome is started it will lookup domain names for previously opened web pages early in the startup process so if the user clicks on one of those links Chrome can connect to the target site immediately.

Among those requests 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, for every DNS extension configured. For example, for my system you can see a Wireshark capture below:

In a normal setup this results in a “No such name” response from your DNS server, as you can see in the screenshot above. If the owner of the DNS server you use has a wildcard setup, each of these requests will result in a response (which is normally even the same) so Chrome knows that there is someone potentially modifying DNS responses. This can happen for example also on wireless networks where you have to authenticate through a browser in order to get access to the Internet.

However, this is not all. Chrome actually does quite a bit of extra DNS lookups that some people might not be happy with. When a user is typing in a URL in Chrome’s address bar, Chrome automatically tries to determine if the user typed in a domain and tries to resolve it in the background.

For example, if you type isc.sans.org in Chrome’s address bar (as you should, at least once a day :), while typing Chrome will see that isc.sa is a possible domain (.sa = Saudi Arabia) and Chrome will happily send a request for that domain. Since isc.sa doesn’t exist, .sa’s root server will send back an NXDOMAIN response. Good thing is that these negative responses can be cached by your local DNS too so the request does not have to go out every
single time. You can see Wireshark’s output for this request below:

What other popular cases are there?

www.cnn.com ends up at www.cn (China)www.facebook.com ends up at www.fa (doesn’t exist)www.twitter.com ends up at www.tw (Taiwan)

How bad is this? Well, it’s not too bad but it is certainly causing some extra traffic, especially since it depends on caching of (mostly) negative answers. A bad guy could, for example, possibly buy the www.cn domain, set up TTL to 0 (means do not cache) and watch in real time how this domain gets resolved every single time a Chrome user types in www.cnn.com in the address bar (clicking on a bookmark will not cause this).

This is not a new behavior in Chrome, has been around for a while and has implications for certain specific gTLDs when the browser autocompletes to www.cnn.com to www.cnn.co or www.foo.net to www.foo.ne. But thats just the tip of the iceberg.
There was a study presented by us a year ago at LEET referenced here: http://www.usenix.org/event/leet10/tech/full_papers/Krishnan.pdf