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 188.8.131.52 yahoo.com
1 google-public-dns-a.google.com (184.108.40.206) 159 ms
% ./dnstraceroute.py -q -s 220.127.116.11 yahoo.com 1 a.resolvers.level3.net (18.104.22.168) 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 22.214.171.124 yahoo.com 1 a.resolvers.level3.net (126.96.36.199) 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.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Stéphane Bortzmeyer •
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.
Hide one reply
Babak Farrokhi •
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 •
On a RIPE mailing list, Pier Carlo Chiodi explains a interesting experience: "It seems  that 10 probes out of 972, when asked for whoami.akamai.net via 188.8.131.52, receive an IP address not mentioned in Google Public DNS FAQ ."  rough edges analysis of RIPE Atlas measurement 4454125, please take it with a grain of salt! https://atlas.ripe.net/measurements/4454125/  https://developers.google.com/speed/public-dns/faq#support
Hide 2 replies
Babak Farrokhi •
The more you test, the nastier it gets. Here is a quick analysis of those IPs you mentioned: 184.108.40.206 BT-UK-AS British Telecommunications PLC, GB (AS 2856) 220.127.116.11 None (AS None) 18.104.22.168 BT-UK-AS British Telecommunications PLC, GB (AS 2856) 22.214.171.124 BT-UK-AS British Telecommunications PLC, GB (AS 2856) 126.96.36.199 INTERLINK-TECH-AS-ID INTERLINK TECHNOLOGY, PT, ID (AS 45298) 188.8.131.52 None (AS None) 184.108.40.206 OPENDNS - OpenDNS, LLC, US (AS 36692) 220.127.116.11 LGI-UPC Liberty Global Operations B.V., AT (AS 6830) 18.104.22.168 ENTANET ENTANET International Limited, GB (AS 8468) 22.214.171.124 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.
Hide one reply
Pier Carlo Chiodi •
More measurements on a comment I posted on your other article: https://labs.ripe.net/Members/babak_farrokhi/operator-level-dns-redirection#1468263139949878