7 ms·

ISPs Improve Their DNS Hijacking And How To Stop It

68 points by SnowLprd 14y ago

Rudism 14y ago
I don't quite understand how the new method of hijacking gets around using 3rd party DNS servers. If I ping nonexistentdomain.tld, doesn't that lookup occur at the 3rd party server? How does my ISP inject its own IP address for that domain if the IP address is coming from (for example) Google? Are they intercepting the entire DNS query?
- gwillen 14y ago
  The claim appears to be that they are intercepting queries to 3rd-party DNS servers, yes.
  - sp332 14y ago
    It might not replace all DNS traffic. Maybe it just replaces NXDOMAIN records with its own responses.
  - ewillbefull 14y ago
    If so, they're breaking so much functionality, protocol and ethics in the process. I don't think it's adequate just to bypass it, ISPs need to be confronted when they are sniffing/modifying traffic.
  - jpdoctor 14y ago
    > The claim appears to be that they are intercepting queries to 3rd-party DNS servers, yes. [my head explodes] This is just begging to be hacked: bankofamerica can be mispelled a number of ways, and I doubt BoA has covered them all.
    - snarkinatree 14y ago
      Yup. This is why it's amusing to watch trademark registrants going after domain names based on confusing variations of their registered mark. Meanwhile their trademarks are being hijacked by DNS services and ISP's, in order to show ads, probably far more often (since these services and ISP's have huge user bases). And for the trademark registrants, ISP's are much easier to locate and take action against than evasive domain name miscreants. Pass the popcorn.
  - dsl 14y ago
    Never trust the DNS related claims of someone who uses 'ping' to perform a DNS lookup.
mhurron 14y ago
Run your own nameserver(s)?
- lhnn 14y ago
  Still wouldn't help, I don't think. Your DNS server is likely just a caching server, which means it forwards requests to another, third party server.
  - mhurron 14y ago
    Mine isn't. I would assume that if you wanted to set up a nameserver you'd be able to handle the slight change of adding a root.hints.
  - pwaring 14y ago
    You can set up your own resolver - I've done this in the past when I've been with an ISP with dreadfully slow nameservers (they weren't doing any interception, just the service was bad).
  - y0ghur7_xxx 14y ago
    You can install PowerDNS recursor[1] or BIND on you own server and use that instead of your ISP/google DNS. [1]http://doc.powerdns.com/built-in-recursor.html http://doc.powerdns.com/built-in-recursor.html
- kogir 14y ago
  Won't help. If the ISP is intercepting all outbound DNS queries, it will also intercept those made by your server. In case it's not clear, even non-forwarding DNS servers have to make DNS queries to the authoritative servers of each domain. It may stop invalid results for top level domains (queries to the root servers might not be intercepted), but would likely still serve ads for invalidsubdomain.validdomain.com. This is one of many reasons why we need broad DNSSEC adoption.
  - SnowLprd 14y ago
    Broad DNSSEC adoption would have to include NSEC, which is needed to authenticate that the resource does indeed not exist. More on NSEC here: "All records are signed offline. When a nameserver receives a query it looks up the answer plus the signature and returns the two (RRSIG + RRset) to the resolver. The signature is thus not created in real time. How can a secure-aware nameserver then respond to a query for something it does not know (that is, give an NXDOMAIN answer)? The only way to have offline signing and NXDOMAIN answers work together is to somehow sign the data you do not have. In DNSSEC this is accomplished by the Next SECure (NSEC) record. This NSEC record holds information about the next record; it spans the nonexistence gaps in a zone, so to say." Source: https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html https://www.cisco.com/web/about/ac123/ac147/archived_issues/...
snarkinatree 14y ago
This is also how OpenDNS makes money. Neustar does the same. And probably others too. They call this "DNS service". Anyone can run a resolver, including your next door neighbor. Unless you live next to a datacenter, your neighbour's "DNS service" will likely be faster than Google's or any commercial vendor. It's been suggested the optimum number of users for a decent cache is probably around 10 [source: IPJ]. Can you trust 10 people not to poison the cache? How many users do you think the "DNS service" providers have? Can you trust each and every one of those users? As for DNSSEC, most people running authoritative nameservers for websites do not support it, let alone most domain name registries. Interesting to note: no rDNS for either of those IP's.
sounds 14y ago
I want to know whether the false NXDOMAIN (saying the domain is actually present at the address of your isp) is dnssec-signed. If it isn't, oh well. If it is, this is an exploit and is big news.
JumpCrisscross 14y ago
What is so insidious about ISPs serving ads on un-occupied domains? I can't see who it hurts and seems like a rather clever way to monetize dead space.
- harshreality 14y ago
  Wanting to access a website is not the only reason to resolve a domain.
- angersock 14y ago
  If I have a script that is listening for a response to ping or trying to confirm an HTTP request or something, I damn well want to know when the host is unreachable. I don't want to successfully reach your bullshit ad host. I don't want to get successfully served an ad instead of timing out. I just want to fail. Any other behavior is wrong. I assume you ask this honestly. The problem isn't something like "Oh, hey, well, there's some empty space so let's setup a lemonade stand until someone buys up the property." The address is supposed to be valid, or fail fast. It is of much greater utility to everyone (except the ad farmers) to fail fast.
  - pbhjpbhj 14y ago
    >It is of much greater utility to everyone (except the ad farmers) to fail fast. // No it isn't yours in an extreme minority edge case compared to most internet users. Users don't want a blank page with just a weird code on it. They want links to click to get to the page that they meant to type in, or failing that a similar page link supplied by their ISP ...
    - mikeash 14y ago
      If users want that, it can and should be solved in the client instead. One of the really nasty things about ISPs doing this is that it actively prevents clients from doing it, since they can no longer easily identify a nonexistent domain.
    - netdog 14y ago
pjscott 14y ago
This is one of the many problems that DNSCurve solves, by setting up encrypted and authenticated connections between you and any DNS servers you decide to trust. http://dnscurve.org/ http://dnscurve.org/ OpenDNS already supports it: http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://blog.opendns.com/2010/02/23/opendns-dnscurve/
- snarkinatree 14y ago
  It's great they support it, but how many people have DNSCurve enabled authoritative nameservers? And how many OpenDNS cache users are routing their queries through a DNSCurve forwarder? It's the same as with DNSSEC. To get the full benefit, every point in the chain needs to be on board, from the source to the sink. If any link in the chain doesn't support it, you're SOL. If you read Dempsky's announcement carefully, you notice the words "whenever possible". That could be almost never depending on DNSCurve uptake among DNS admins and users. An easier solution is to just run your own instance of dnscache. That's what OpenDNS uses.
- kijin 14y ago
  Meanwhile, OpenDNS hijacked NXDOMAIN results and tried to show me ads the last time I used them. Have they stopped doing that?
  - pbhjpbhj 14y ago
    I imagine typo domain suggestion/resolution is one of their key selling points for people who don't know what NXDOMAIN is (ie most of their customers), removing it seems unlikely.
    - kijin 14y ago
      Fair point, but I think it's the browser's job to decide what to do when the user types a domain that doesn't exist. Chrome gives you a search page if you enter a nonexistent domain.
      - 14y ago
pdubs 14y ago
Don't bloggers have to disclose affiliate links now?
- SnowLprd 14y ago
  No subterfuge intended. Changed the post to make it clearer.
TazeTSchnitzel 14y ago
Won't DNSSEC stop this, hopefully?
DHowett 14y ago
I believe Comcast stopped this as of their network-wide DNSSEC deployment. Either way, the article provides a pretty interesting way around it, but I can't expect ISPs hell-bent on false lookup spoofing to sit on their hands for long enough to make this a practical long-term solution.
- hextraorinary 14y ago
  That's one benefit of DNSSEC. If an ISP adopts it, including NSEC, they can't also do NXDOMAIN spoofing with their DNS servers. Mutually exclusive. But for ISP's that insist on doing this, there are various workarounds besides the one mentioned in the blog post. It's quite easy. Tunneling inside HTTP is a last resort. At some point it's not worth the trouble for the ISP, e.g., to peek into every packet trying to stop users from getting a proper NXDOMAIN response.
rblatz 14y ago
I'm on Time Warner and just tested this. Could not reproduce.
- SnowLprd 14y ago
  Could be region-specific. I get the impression that Time Warner Cable's management isn't highly centralized. These tests were performed on Time Warner Cable's SoCal network; I just ran them again with the exact same results, despite the fact that I have my DNS servers set to 8.8.8.8 and 8.8.4.4 (Google's DNS servers).
  - Travis 14y ago
    Time Warner must not have their acts together. Just ran a test using their default DNS (not google), was able to reproduce. Ran a test on Google DNS, could not reproduce (receive an unknown host error). Also in SoCal (TW San Diego). Not doubting you, just wanted to add another data point.
hextraorinary 14y ago
There's a solution to all this, where you will always get the right response, and it even obviates the need for DNSSEC or DNSCurve. And that is, write your own resolver that only sends nonrecursive queries to authoritative nameservers. If the DNS admin has configured DNS simply and sensibly, it will only take you 2 queries to get a name resolved. It's very fast. If they are using Akamai or some other CDN, or they have a love for CNAMES and indirection, it can take many more queries. Sometimes up to 7.
- X-Istence 14y ago
  Only 2? Wouldn't you have to hit the root, then the tld server, then the name server for the domain, and if it isn't the root domain (example.net), but if it is a sub-domain (www.example.net) which could potentially return more NS records ... and the process would have to happen all over again. net. => root (return tld) example.net. => tld (return ns) www.example.net. => ns (returns ns2) www.example.net. => ns2
  - hextraorinary 14y ago
    Someone is paying attention. ;) The tld server ip's are "hardcoded" into the resolver application and revised as needed from the root.zone.gz file periodically- these servers do not change very often. The application is just a simple lexer that can be easily edited and recompiled. Writing this thing was a learning experience: the vast majority of cases, DNS lookups follow some very predictable patterns. So, to answer your question: that first lookup is unnecessary. There's no need to keep hitting the root to get a relatively small number of tld server ip's that rarely change or go inactive. It's easier just to download the root zone regularly to check for changes. As for subdomains, such as www, that's the CNAME indirection to which I alluded. Everytime someone adds indirection, whatever their reasons (e.g. load balancing, CDN, etc.), it slows down the lookup process by necessitating more lookups. It's a small tradeoff that probably few people pay attention to. From the resolver's perspective, it is more work and it does slow things down compared to the typical 2 query resolution. Note I still say 2 queries because even with recursive resolvers like the ones we all use, the tld server ip's for the popular tld's are almost always already in the cache. You only need to lookup a single domain.com and the com tld server ip's will be there for all future queries.
drucken 14y ago
Doesn't this mean ISPs themselves couldn't use their own DNS servers for a reliable DNS service? Talk about not drinking your own Kool-Aid...

68 points by SnowLprd 14y ago

I don't quite understand how the new method of hijacking gets around using 3rd party DNS servers. If I ping nonexistentdomain.tld, doesn't that lookup occur at the 3rd party server? How does my ISP inject its own IP address for that domain if the IP address is coming from (for example) Google? Are they intercepting the entire DNS query?

gwillen 14y ago
The claim appears to be that they are intercepting queries to 3rd-party DNS servers, yes.
- sp332 14y ago
  It might not replace all DNS traffic. Maybe it just replaces NXDOMAIN records with its own responses.
- ewillbefull 14y ago
  If so, they're breaking so much functionality, protocol and ethics in the process. I don't think it's adequate just to bypass it, ISPs need to be confronted when they are sniffing/modifying traffic.
- jpdoctor 14y ago
  > The claim appears to be that they are intercepting queries to 3rd-party DNS servers, yes. [my head explodes] This is just begging to be hacked: bankofamerica can be mispelled a number of ways, and I doubt BoA has covered them all.
  - snarkinatree 14y ago
    Yup. This is why it's amusing to watch trademark registrants going after domain names based on confusing variations of their registered mark. Meanwhile their trademarks are being hijacked by DNS services and ISP's, in order to show ads, probably far more often (since these services and ISP's have huge user bases). And for the trademark registrants, ISP's are much easier to locate and take action against than evasive domain name miscreants. Pass the popcorn.
- dsl 14y ago
  Never trust the DNS related claims of someone who uses 'ping' to perform a DNS lookup.

mhurron 14y ago

Run your own nameserver(s)?

lhnn 14y ago
Still wouldn't help, I don't think. Your DNS server is likely just a caching server, which means it forwards requests to another, third party server.
- mhurron 14y ago
  Mine isn't. I would assume that if you wanted to set up a nameserver you'd be able to handle the slight change of adding a root.hints.
- pwaring 14y ago
  You can set up your own resolver - I've done this in the past when I've been with an ISP with dreadfully slow nameservers (they weren't doing any interception, just the service was bad).
- y0ghur7_xxx 14y ago
  You can install PowerDNS recursor[1] or BIND on you own server and use that instead of your ISP/google DNS. [1]http://doc.powerdns.com/built-in-recursor.html http://doc.powerdns.com/built-in-recursor.html
kogir 14y ago
Won't help. If the ISP is intercepting all outbound DNS queries, it will also intercept those made by your server. In case it's not clear, even non-forwarding DNS servers have to make DNS queries to the authoritative servers of each domain. It may stop invalid results for top level domains (queries to the root servers might not be intercepted), but would likely still serve ads for invalidsubdomain.validdomain.com. This is one of many reasons why we need broad DNSSEC adoption.
- SnowLprd 14y ago
  Broad DNSSEC adoption would have to include NSEC, which is needed to authenticate that the resource does indeed not exist. More on NSEC here: "All records are signed offline. When a nameserver receives a query it looks up the answer plus the signature and returns the two (RRSIG + RRset) to the resolver. The signature is thus not created in real time. How can a secure-aware nameserver then respond to a query for something it does not know (that is, give an NXDOMAIN answer)? The only way to have offline signing and NXDOMAIN answers work together is to somehow sign the data you do not have. In DNSSEC this is accomplished by the Next SECure (NSEC) record. This NSEC record holds information about the next record; it spans the nonexistence gaps in a zone, so to say." Source: https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html https://www.cisco.com/web/about/ac123/ac147/archived_issues/...

snarkinatree 14y ago

This is also how OpenDNS makes money. Neustar does the same. And probably others too. They call this "DNS service". Anyone can run a resolver, including your next door neighbor. Unless you live next to a datacenter, your neighbour's "DNS service" will likely be faster than Google's or any commercial vendor. It's been suggested the optimum number of users for a decent cache is probably around 10 [source: IPJ]. Can you trust 10 people not to poison the cache? How many users do you think the "DNS service" providers have? Can you trust each and every one of those users? As for DNSSEC, most people running authoritative nameservers for websites do not support it, let alone most domain name registries. Interesting to note: no rDNS for either of those IP's.

sounds 14y ago

I want to know whether the false NXDOMAIN (saying the domain is actually present at the address of your isp) is dnssec-signed. If it isn't, oh well. If it is, this is an exploit and is big news.

JumpCrisscross 14y ago

What is so insidious about ISPs serving ads on un-occupied domains? I can't see who it hurts and seems like a rather clever way to monetize dead space.

harshreality 14y ago
Wanting to access a website is not the only reason to resolve a domain.
angersock 14y ago
If I have a script that is listening for a response to ping or trying to confirm an HTTP request or something, I damn well want to know when the host is unreachable. I don't want to successfully reach your bullshit ad host. I don't want to get successfully served an ad instead of timing out. I just want to fail. Any other behavior is wrong. I assume you ask this honestly. The problem isn't something like "Oh, hey, well, there's some empty space so let's setup a lemonade stand until someone buys up the property." The address is supposed to be valid, or fail fast. It is of much greater utility to everyone (except the ad farmers) to fail fast.
- pbhjpbhj 14y ago
  >It is of much greater utility to everyone (except the ad farmers) to fail fast. // No it isn't yours in an extreme minority edge case compared to most internet users. Users don't want a blank page with just a weird code on it. They want links to click to get to the page that they meant to type in, or failing that a similar page link supplied by their ISP ...
  - mikeash 14y ago
    If users want that, it can and should be solved in the client instead. One of the really nasty things about ISPs doing this is that it actively prevents clients from doing it, since they can no longer easily identify a nonexistent domain.
  - netdog 14y ago

pjscott 14y ago

This is one of the many problems that DNSCurve solves, by setting up encrypted and authenticated connections between you and any DNS servers you decide to trust. http://dnscurve.org/ http://dnscurve.org/ OpenDNS already supports it: http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://blog.opendns.com/2010/02/23/opendns-dnscurve/

snarkinatree 14y ago
It's great they support it, but how many people have DNSCurve enabled authoritative nameservers? And how many OpenDNS cache users are routing their queries through a DNSCurve forwarder? It's the same as with DNSSEC. To get the full benefit, every point in the chain needs to be on board, from the source to the sink. If any link in the chain doesn't support it, you're SOL. If you read Dempsky's announcement carefully, you notice the words "whenever possible". That could be almost never depending on DNSCurve uptake among DNS admins and users. An easier solution is to just run your own instance of dnscache. That's what OpenDNS uses.
kijin 14y ago
Meanwhile, OpenDNS hijacked NXDOMAIN results and tried to show me ads the last time I used them. Have they stopped doing that?
- pbhjpbhj 14y ago
  I imagine typo domain suggestion/resolution is one of their key selling points for people who don't know what NXDOMAIN is (ie most of their customers), removing it seems unlikely.
  - kijin 14y ago
    Fair point, but I think it's the browser's job to decide what to do when the user types a domain that doesn't exist. Chrome gives you a search page if you enter a nonexistent domain.
    - 14y ago

pdubs 14y ago

Don't bloggers have to disclose affiliate links now?

SnowLprd 14y ago
No subterfuge intended. Changed the post to make it clearer.

TazeTSchnitzel 14y ago

Won't DNSSEC stop this, hopefully?

DHowett 14y ago

I believe Comcast stopped this as of their network-wide DNSSEC deployment. Either way, the article provides a pretty interesting way around it, but I can't expect ISPs hell-bent on false lookup spoofing to sit on their hands for long enough to make this a practical long-term solution.

hextraorinary 14y ago
That's one benefit of DNSSEC. If an ISP adopts it, including NSEC, they can't also do NXDOMAIN spoofing with their DNS servers. Mutually exclusive. But for ISP's that insist on doing this, there are various workarounds besides the one mentioned in the blog post. It's quite easy. Tunneling inside HTTP is a last resort. At some point it's not worth the trouble for the ISP, e.g., to peek into every packet trying to stop users from getting a proper NXDOMAIN response.

rblatz 14y ago

I'm on Time Warner and just tested this. Could not reproduce.

SnowLprd 14y ago
Could be region-specific. I get the impression that Time Warner Cable's management isn't highly centralized. These tests were performed on Time Warner Cable's SoCal network; I just ran them again with the exact same results, despite the fact that I have my DNS servers set to 8.8.8.8 and 8.8.4.4 (Google's DNS servers).
- Travis 14y ago
  Time Warner must not have their acts together. Just ran a test using their default DNS (not google), was able to reproduce. Ran a test on Google DNS, could not reproduce (receive an unknown host error). Also in SoCal (TW San Diego). Not doubting you, just wanted to add another data point.

hextraorinary 14y ago

There's a solution to all this, where you will always get the right response, and it even obviates the need for DNSSEC or DNSCurve. And that is, write your own resolver that only sends nonrecursive queries to authoritative nameservers. If the DNS admin has configured DNS simply and sensibly, it will only take you 2 queries to get a name resolved. It's very fast. If they are using Akamai or some other CDN, or they have a love for CNAMES and indirection, it can take many more queries. Sometimes up to 7.

X-Istence 14y ago
Only 2? Wouldn't you have to hit the root, then the tld server, then the name server for the domain, and if it isn't the root domain (example.net), but if it is a sub-domain (www.example.net) which could potentially return more NS records ... and the process would have to happen all over again. net. => root (return tld) example.net. => tld (return ns) www.example.net. => ns (returns ns2) www.example.net. => ns2
- hextraorinary 14y ago
  Someone is paying attention. ;) The tld server ip's are "hardcoded" into the resolver application and revised as needed from the root.zone.gz file periodically- these servers do not change very often. The application is just a simple lexer that can be easily edited and recompiled. Writing this thing was a learning experience: the vast majority of cases, DNS lookups follow some very predictable patterns. So, to answer your question: that first lookup is unnecessary. There's no need to keep hitting the root to get a relatively small number of tld server ip's that rarely change or go inactive. It's easier just to download the root zone regularly to check for changes. As for subdomains, such as www, that's the CNAME indirection to which I alluded. Everytime someone adds indirection, whatever their reasons (e.g. load balancing, CDN, etc.), it slows down the lookup process by necessitating more lookups. It's a small tradeoff that probably few people pay attention to. From the resolver's perspective, it is more work and it does slow things down compared to the typical 2 query resolution. Note I still say 2 queries because even with recursive resolvers like the ones we all use, the tld server ip's for the popular tld's are almost always already in the cache. You only need to lookup a single domain.com and the com tld server ip's will be there for all future queries.

drucken 14y ago

Doesn't this mean ISPs themselves couldn't use their own DNS servers for a reliable DNS service? Talk about not drinking your own Kool-Aid...