This has some interesting ramifications- some network security appliances (I work for a company that makes one) look for suspicious sets of DNS requests that match the Domain Generation Algorithms that malware like Conficker use to find a command and control server.
These "random" requests look almost exactly the DGA for Murofet- a Zeus variant. This has caused some problems for us (and other vendors, I would assume) in the form of massive numbers of false positives. In short, it's been kind of a PITA.
I wish they wouldn't do this, but it is definitely a tough problem to solve and I can't think of a better approach off of the top of my head. The ultimate culprit is the ISPs that return an A record for a DNS request that really should return NXDOMAIN. These ISPs are essentially breaking the Internet, and we're all just scrambling to put band-aids in place to get it to work again.
i suspect that you're using their dns server because it's what is given to you via dhcp, but you can probably configure your own (well, you can certainly configure you own; the problem is it's possible that they are blocking dns requests). for example, set things to use 8.8.8.8 as the dns server (which is google's).
comment 5 (in that thread, from the developer involved) says that it is working and testing it myself (google-chrome --dns-server=8.8.8.8) with wireshark shows that it does query that server.
(thanks for pointing this out; it wasn't what i was suggesting - i had assume the laptop was the op's own).
This is a good reason not to stick to the DNS-resolver the ISP gives you with DHCP, but to explicitly set it to a DNS resolver you trust.
Wondering why Chrome is not simply using the Google resolver on 8.8.8.8. Of course this would yet be another band aid that breaks the internet even further, when applications start implementing their own network stack.
So instead of having these machines in our serverroom inside our office, we'd have to pay for using them in a data center and register URL's, only because some ISP's use an insane way to handle NXDOMAIN? There are many valid reasons to "go into the cloud", but this is not one of them.
You can assign real ip addresses to machines in your server room, give them dns, and firewall them externally. Just ask your isp for some addresses. There is no reason why this is any different from using nat in security, but you can use real dns. You can use ipv6 if you can't get ipv4 addresses.
Non-publicly-routable addresses are a hack that will cause you nothing but trouble, and are going away with IPv6, so you might as well move away from them now.
(Not that having chrome use 8.8.8.8 is a good idea either. As is often the case with hacks, either on its own works fine but the two interact poorly.)
Not sure I agree that non-publicly-routable addresses are a hack. The ability to run your own DNS server and having a firewall are pretty elegant components of most networks.
That being said, it very well maybe time to find a better alternative :).
Firewalls have their place but should not be conflated with routing; the two are separate, and treating them as the same can lead to confusion and broken security.
As for DNS, it has a very elegant hierarchical delegation system, such that organizations can control their own while also ensuring that all the world's DNS servers give consistent answers (and if you need short names for your internal systems on your own network, that's what search paths are for).
Not all networks allow using an external DNS. For example I regularly travel with the train in the Netherlands, and some trains provide wifi. The network intercepts all HTTP requests and forwards the user to a Terms Of Usage page; interception stops after the user has checked the 'I agree' checkbox. For a time I was wondering why even the Terms Of Usage page never shows up; turns out it was because I was using the Google DNS. Removing the custom DNS settings made it work again.
It seems like there should be at least some manual override (assuming there isn't one already - I didn't check the details much beyond the article provided) to set your 'my DNS is NX-LYING' flag manually. For machines that are permanently emplaced in a broken DNS network, it can just be turned on and left.
Roaming devices might make it a bit more tricky, but some integration with OS connectivity-detection and location-awareness might help there, as well as an improved UI for actually setting it.
A really short-term bandage would be to use some less identifiable DGA, but that opens the possibility of future malware using the Chrome DGA to pretend to be legit.
Is there a technical reason why 'foo.invalid' and 'bar.invalid' (and any of the other restricted dns names) couldn't be used instead?
I suppose that the ISPs could serve those correctly to make the tests pass, but what would they gain from it except even more user irritation?
It seems like there should be at least some manual override (assuming there isn't one already - I didn't check the details much beyond the article provided) to set your 'my DNS is NX-LYING' flag manually. For machines that are permanently emplaced in a broken DNS network, it can just be turned on and left.
A flag wouldn't be enough, because Chrome also learns what records it returns when it lies, so it can recognize other lies.
I noticed this two years ago, and eventually had to stop using Chrome (and Chromium browsers) as it would result in my ISP blocking all DNS requests from my IP (for a seemingly random amount of time). Even requests to public DNS would fail. It took awhile to identify Chrome as the culprit, and I wasn't convinced after seing the bogus DNS requests in TCP traps. So I started a cycle of using/not using Chrome, and it became obvious.
The easy solution was to stop using Chrome. The hard solution was to move. I've done both, but have yet to start using Chrome again.
I don't understand. Why would your ISP block your IP for bogus DNS requests? And why are they monitoring your traffic to public DNS servers? I presume this means they have to look at all traffic that goes over port 53. Is there a security concern?
This is common practice if the queries appear to be originating from worms like Conficker, etc. Others have reported that this behavior of Chrome's can set off false IDS alarms for the same reason.
I have no idea why they would want to block it, unless they considered it an attack vector for some reason. It was automatic - after a few of the bogus DNS requests, all DNS/port 53 traffic was dropped. Everything else worked, only DNS failed.
It was originally SBC DSL (resold Yahoo!, resold etc...). The Chrome-induced resolution failures weren't the only issue - their primary DNS server never worked, always went to the failover.
By default, the free service that anyone can use, they redirect nonexistent domains to a search page they control. If you pay (and register your IP address), you can turn that off. But the main reason for paying is to control which domains are blocked. You can choose categories, and/or maintain your own white or black list. http://www.opendns.com/web-filtering/ and http://www.opendns.com/internet-security/
if you go to chrome://chrome-urls/ and then down to net-internals, you can get a pretty transparent view of exactly what chrome is doing. plus there's a bunch of other stuff there too.
It appears that Chrome aggressively prefetches DNS results for most of the links in pages you visit too. It's quite strange to watch as DNS requested for hundreds of domains you haven't even intended to visit start flowing past. The first time I saw it I had to check that nothing unscrupulous was running on my computer...
Interesting, yesterday I moved to a local caching DNS server (much faster and more reliable than what isp provided), however I forgot to set it to run at start up, first thing I do today is try to get to my gmail account, everything is working ok then I try to enter another site, dns lookup error, then I remembered I had named turned off, which means that chrome may have hardcoded google sites ip addresses or is caching them (which is less probable the other site didn't work).
> "Your ISP (network administrator, ..) is intercepting and manipulating DNS requests. Do you want to use Google DNS instead?"
I would prefer
"Your ISP (network administrator, ..) is intercepting and manipulating DNS requests. Do you want to install a local caching DNS server and use it instead?"
Unbound [1] is a local DNS server that I have installed on all my machines. Small, fast, security-oriented, IPv6, BSD, made by NLnet Labs.
The grandparent said "use Google DNS" not "chrome doing its own DNS lookup".
If you use Google's DNS (or anybody's DNS) you are basically telling them which sites your are visiting. If you have a local DNS resolver you will not leak all that information to a single third party.
I don't understand. Your local DNS resolver still needs an upstream; either that is your existing broken DNS server, or it's google's DNS server; in either case we're back where we were. Sure, your local DNS resolver could do some caching, but so could chrome; and a local resolver doesn't combine your lookups with those of your neighbours, so you don't get any privacy advantage that way either.
> I don't understand. Your local DNS resolver still needs an upstream
No, not a single upstream.
When my browser asks my server on 127.0.0.1 to lookup news.ycombinator.com it will first contact the root DNS server, then `com` DNS server, then then `ycombinator.com` DNS server. Who knows about the fact that I was looking for `news.ycombinator.com`? only the `ycombinator.com` DNS server. Who knows about the fact that I was looking for `ycombinator.com`? only the `com` DNS server. Now I go to slashdot.org. Who will know about that? Only the `org` DNS server. If you use the Google DNS, Google will know that you requested both `news.ycombinator.com` and `slashdot.org`. Do you want them or any single company to have all these information?
Obviously you need an upstream, an authoritative server somewhere. But why do you need to concentrate all these requests on a single DNS server? ISP are actively tracking users and, probably, selling their DNS histories to advertiser. Nominum (makers of a widespread DNS server) is quite explicit about it: «Data gathering and measurement are a vital part of network operations and DNS data represents a rich vein to be mined that has been underutilized in the past». [1]
So you'd contact the root server directly? If that's really desirable behavior (and I suspect it isn't), why not just make chrome query the root servers and walk the hierarchy, not using a DNS server at all?
These "random" requests look almost exactly the DGA for Murofet- a Zeus variant. This has caused some problems for us (and other vendors, I would assume) in the form of massive numbers of false positives. In short, it's been kind of a PITA.
I wish they wouldn't do this, but it is definitely a tough problem to solve and I can't think of a better approach off of the top of my head. The ultimate culprit is the ISPs that return an A record for a DNS request that really should return NXDOMAIN. These ISPs are essentially breaking the Internet, and we're all just scrambling to put band-aids in place to get it to work again.