7 ms·

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 ma

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.

teach 15y ago
The behavior also causes problems in my workplace, too. I work in a public school, and we use an Internet filter as required by law. One part of the filter is attached to our default DNS server, and it looks up novel domains to see if they ought to be blocked. This lookup is slow. Launching Chrome first thing in the morning takes quite a while, because our DNS server/filter blocks until those 3 random domains fail to resolve. I really wish that I could turn it off, although admittedly our "network" is barely compliant with protocols in the name of filtering.
- andrewcooke 15y ago
  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).
  - teach 15y ago
    No, we can't configure our own. The network settings config is locked out using policy controls.
    - rdtsc 15y ago
      Supposedly there is a command line option in Chrome to specify a custom dns server. --dns-server=8.8.8.8 But it also looks like it doesn't always work (never worked, or is a special development mode only feature). Here is the bug report on it: http://code.google.com/p/chromium/issues/detail?id=85875 http://code.google.com/p/chromium/issues/detail?id=85875
      - andrewcooke 15y ago
        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).
shabble 15y ago
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? Anything I'm missing?
- icebraining 15y ago
  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.
jsilence 15y ago
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.
- FooBarWidget 15y ago
  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.
- st0p 15y ago
  We use chrome for internal apps. Forcing you to use 8.8.8.8 means our users have to remember ip addresses instead of http://nameofapplication/ http://nameofapplication/ Not a problem for me, but I'm sure a lot of people would complain.
  - justincormack 15y ago
    Put your internal apps on real IP addresses with real DNS and just firewall them?
    - st0p 15y ago
      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.
      - justincormack 15y ago
mrb 15y ago
There is a big difference between Chrome's requests and Murofet's requests. Chrome uses no TLD ("xxxxx") but Murofet does ("xxxxxx.com").

teach 15y ago

The behavior also causes problems in my workplace, too. I work in a public school, and we use an Internet filter as required by law. One part of the filter is attached to our default DNS server, and it looks up novel domains to see if they ought to be blocked. This lookup is slow. Launching Chrome first thing in the morning takes quite a while, because our DNS server/filter blocks until those 3 random domains fail to resolve. I really wish that I could turn it off, although admittedly our "network" is barely compliant with protocols in the name of filtering.

andrewcooke 15y ago
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).
- teach 15y ago
  No, we can't configure our own. The network settings config is locked out using policy controls.
  - rdtsc 15y ago
    Supposedly there is a command line option in Chrome to specify a custom dns server. --dns-server=8.8.8.8 But it also looks like it doesn't always work (never worked, or is a special development mode only feature). Here is the bug report on it: http://code.google.com/p/chromium/issues/detail?id=85875 http://code.google.com/p/chromium/issues/detail?id=85875
    - andrewcooke 15y ago
      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).

shabble 15y ago

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? Anything I'm missing?

icebraining 15y ago
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.

jsilence 15y ago

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.

FooBarWidget 15y ago
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.
st0p 15y ago
We use chrome for internal apps. Forcing you to use 8.8.8.8 means our users have to remember ip addresses instead of http://nameofapplication/ http://nameofapplication/ Not a problem for me, but I'm sure a lot of people would complain.
- justincormack 15y ago
  Put your internal apps on real IP addresses with real DNS and just firewall them?
  - st0p 15y ago
    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.
    - justincormack 15y ago

mrb 15y ago

There is a big difference between Chrome's requests and Murofet's requests. Chrome uses no TLD ("xxxxx") but Murofet does ("xxxxxx.com").