You are here: Home > Publications > RIPE Labs > Babak Farrokhi > Is Your ISP Hijacking Your DNS Traffic?

Is Your ISP Hijacking Your DNS Traffic?

Babak Farrokhi — 06 Jul 2016
You might not have noticed, but there are chances that your ISP is playing nasty tricks with your DNS traffic.

 

The answer to the above question used to be difficult. You had to be an expert to find out the answer. In fact, most people don’t even notice, nor care.

Playing with the dnstraceroute tool (see on GitHub ), I noticed that it is a common practice for service providers to hijack and redirect DNS traffic to their local DNS servers. So if you thought you were using Google’s Public DNS Server or Verisign's , you may want to think twice.

Following is a couple of examples, going through my favourite VPN Tunnel service provider:

    % ./dnstraceroute.py -q -s 8.8.8.8 yahoo.com
    
1 google-public-dns-a.google.com (8.8.8.8) 159 ms
    % ./dnstraceroute.py -q -s 4.2.2.1 yahoo.com

    1   a.resolvers.level3.net (4.2.2.1) 127 ms   

I am obviously not one-hop away from all DNS servers in the world.

So I thought maybe they have a list of well-known public DNS servers and doing a routing trick based on destination IP addresses.

Then I tried tracing to various random IP addresses (not DNS servers) but the results were the same, which is really interesting. The next idea was that they were basically redirecting all UDP/53 traffic. So I changed the port number to test this hypothesis:

    % ./dnstraceroute.py -q -p 55 -s 4.2.2.1 yahoo.com

    1   a.resolvers.level3.net (4.2.2.1) 133 ms 

Wow! The trick is even more sophisticated than a simple IP address or port-based policy. In fact, every DNS request aside from the destination IP address or port number is redirected. So there should be a layer 7 inspection or DPI in place, which is a clever (and scary) idea.

This is perhaps done to filter out suspicious DNS requests.


You can’t blame your service provider for hijacking your DNS traffic or running DPI on their network these days. In fact most of them use DPI to some extent for various reasons. But if they are inspecting my DNS traffic up to layer 7, they can also see everything else , unless it is encrypted.

If you are really concerned about your DNS traffic being intercepted (and you should be) or if you want to decouple your DNS traffic from web traffic, it is highly recommend to use DNSCrypt with your trusted DNS resolver. The IETF has also been working to standardize DNS encryption, but it takes time to adopt this new extension. (see: RFC 7858 )

Perhaps you already have a virtual machine idling somewhere on the Internet. Maybe it's time to install and configure an  Unbound  DNS resolver and secure it with DNSCrypt. Tempted to use Public DNSCrypt servers instead of your own setup? That’s another mistake you better not make. If you insist on using a public DNS server, you may want to use the  DNSDiag  tools to see how much you can trust your ISP.

 

5 Comments

Stéphane Bortzmeyer says:
06 Jul, 2016 02:06 PM
Besides the hardcore solution (accepting DNS-over-TLS, per RFC 7858, whose utility makes no doubt when we see such violations of network neutrality), the managers of big public DNS resolvers should allow simple mechanisms like NSID (RFC 5011). It's not real authentication but it is useful to detect/investigate most hijackings.
Babak Farrokhi says:
06 Jul, 2016 05:30 PM
This is very unfortunate that operators as well as users have minimum attention to DNS subject (at least in my local community). Operators simply set up DNS resolvers/forwarders with minimum configuration and leave it as it works. I personally know operators that have a simple BIND resolver with stock configuration or even unbound forwarders to public DNS servers like Google. While DNS is very important from both privacy and performance point of view, I believe there should be serious efforts to improve operator and user level awareness to the subject. NSID (RFC 5001) would come in very handy from a user vantage point to verify the DNS server and avoid using rogue DNS servers.
Stéphane Bortzmeyer says:
06 Jul, 2016 08:48 PM
On a RIPE mailing list, Pier Carlo Chiodi explains a interesting experience: "It seems [1] that 10 probes out of 972, when asked for whoami.akamai.net via 8.8.8.8, receive an IP address not mentioned in Google Public DNS FAQ [2]."

[1] rough edges analysis of RIPE Atlas measurement 4454125, please take it with a grain of salt! https://atlas.ripe.net/measurements/4454125/

[2] https://developers.google.com/speed/public-dns/faq#support
Babak Farrokhi says:
09 Jul, 2016 10:52 AM
The more you test, the nastier it gets. Here is a quick analysis of those IPs you mentioned:

213.120.234.114 BT-UK-AS British Telecommunications PLC, GB (AS 2856)
146.112.129.12 None (AS None)
213.120.234.114 BT-UK-AS British Telecommunications PLC, GB (AS 2856)
213.120.234.114 BT-UK-AS British Telecommunications PLC, GB (AS 2856)
203.171.221.181 INTERLINK-TECH-AS-ID INTERLINK TECHNOLOGY, PT, ID (AS 45298)
146.112.129.14 None (AS None)
67.215.80.21 OPENDNS - OpenDNS, LLC, US (AS 36692)
213.192.34.234 LGI-UPC Liberty Global Operations B.V., AT (AS 6830)
188.39.37.91 ENTANET ENTANET International Limited, GB (AS 8468)
204.194.237.17 302-DIRECT-MEDIA-ASN - 302 Direct Media LLC, US (AS 30607)

So there are more operators doing this. I was thinking of a quick project to query as many Atlas probes as possible and build up a list of operators who are redirecting DNS traffic.
Pier Carlo Chiodi says:
12 Jul, 2016 12:28 PM
More measurements on a comment I posted on your other article: https://labs.ripe.net/[…]/operator-level-dns-redirection#1468263139949878
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.