Following my recent research on DNS hijacking and the cases I have personally observed, I wondered whether this is a common practice among the operators. With the help of RIPE Atlas, I started to think of a solution to figure out whether such practice is widespread in other areas of the world.
When I published my first article on the subject, a reader emailed me to remind me that a service is available that returns the query source address of your DNS server. Here is how it works:
% dig txt maxmind.test-ipv6.com @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> txt maxmind.test-ipv6.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37643 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;maxmind.test-ipv6.com. IN TXT
;; ANSWER SECTION: maxmind.test-ipv6.com. 0 IN TXT "ip=74.125.47.130 as=15169 isp='Google Inc.'"
;; Query time: 242 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Jun 20 13:22:13 2016 ;; MSG SIZE rcvd: 95
I queried maxmind.test-ipv6.com from Google’s public DNS server. The DNS server does not have a cached answer to my query (hence TTL=0 as shown in the above output of the dig command), so it will recurse to the domain’s name servers. Those name servers will then respond with a specially crafted answer, which contains the source address of the query they just received, as well as AS Number and description of the IP block (taken from MaxMind's GeoIP database). This is how you can figure out the source address of your DNS server with which it sends out queries to other DNS servers.
I used this trick in conjunction with RIPE Atlas probes to figure out what happens when I send a query through to Google's public DNS. Under normal conditions, the source address of the outgoing query should be held by Google. Otherwise (if the traffic is rerouted to a rogue DNS server), the source IP address as well as its netblock owner will be revealed.
I chose 500 probes from around the world and asked them to issue a similar query as shown above. Then I gathered the RDATA from all the responses and did a quick analysis:
% curl -s "https://atlas.ripe.net/api/v2/measurements/4460436/results?start=1468108800&stop=1468195199&format=json" \
| json_pp | awk -F\" '/isp/ {print $2}' \
| sort | uniq -c | sort -n | grep -iv google
The above fetches the result from my measurement and feeds it to json_pp for a clean and indented JSON output. After that I ran some awk, sort, uniq and grep magic to remove unwanted characters, eliminated duplicates and filtered out any responses that did not contain the word “Google”. Here is the result:
1 ip=146.112.129.12 as=36692 isp='OpenDNS, LLC' 1 ip=203.171.221.201 as=45298 isp='INTERLINK TECHNOLOGY, PT' 1 ip=213.192.34.234 as=6830 isp='Liberty Global Operations B.V.' 1 ip=2620:0:cca::21 as=36692 isp='OpenDNS, LLC' 1 ip=2a04:e4c0:15::11 as=36692 isp='OpenDNS, LLC'
As I initially suspected, five of the 499 responses that RIPE Atlas gathered originate from a non-Google network. This means there are rogue instances of 8.8.8.8 installed on those networks that catch customers' queries and answer on their behalf. The above data shows that some operators are basically forwarding Google DNS traffic to OpenDNS, and others are serving it locally using their own resolvers.
Conclusion
This was one example of DNS traffic hijacking on the network-operator level. This demonstrates that some users may believe they are sending their DNS traffic to Google, while their DNS traffic actually never reaches Google.
Comments 4
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.
Giovane Moura •
Nice article, Babak. We came across the same issue in another study we performed[1]. By using all Atlas probes (from built-in DNS root measurements), we found that only they redirect, but also that some mobile operators and others also do it. Out of the 9,000 we used, 67 showed patters of hijacking -- low RTT and unusual hostname.bind names. See also [2]. [1] http://www.isi.edu/~johnh/PAPERS/Moura16a.html [2] https://www.isi.edu/~johnh/PAPERS/Fan13a.html
Hide replies
Babak Farrokhi •
It seems like most of these ISPs are doing mass DNS hijacking, be it a root-server or a resolver. However I have seen cases in which only certain DNS traffic were hijacked or tampered.
Pier Carlo Chiodi •
I put together a Python script [1] to analyze 5 RIPE Atlas measurements that I ran against some public DNS resolver project to see which the real IP addresses seen by the domain's name servers were. I used 1000 random probes to send DNS queries for whoami.akamai.net to 8.8.8.8 (msm 4454125), 209.244.0.3 (msm 4459168), 4.2.2.1 (msm 4459167), 64.6.64.6 (msm 4459166) and 208.67.222.222 (msm 4459170). I found that 15 unique probes received at least one unexpected answers, that is one or more IP addresses that do not fall within a range whose holder is the same as the public resolver project's owner (the list of expected holders I used is within the script itself). Finally, I queried those 15 probes (msm 4461438) about whoami.akamai.net against www.ripe.net [2] (that, AFAIK, does not offer DNS resolving services) and I found that 9 probes received an answer too. Please note that, with this, I don't want to blame nor to endorse such behaviours. Script and results on GitHub: https://gist.github.com/pierky/fe8ad5395ff1cf0e3c8a3096e426fd8d 1] it's a draft work: please review it before seriously consider its results! 2] sorry to have bothered you! EDIT: fixed the GitHub URL EDIT-2: I missed one entry in the "expected_holders" of msm 4459166, so the number of probes that received unexpected results dropped from 17 to 15.
Alexander Dupuy •
This is an interesting use of the RIPE Atlas technology to probe worldwide DNS infrastructure. You should be careful about drawing conclusions stronger than "DNS hijacking is taking place and these are the targets and redirections." The probe data doesn't provide enough information to identify the "perpetrator" of the DNS hijacking, and depending on the hijacking approach taken, it can be difficult to make that identification. If the hijacker is making BGP (or other routing) advertisements to redirect 8.8.8.8 or other Google Public DNS addresses to a different nameserver running with that IP address as an alias, you can see where the hijacking is being done with a traceroute. If BGP is used for the hijacking it is often visible globally through BGP monitors and looking glasses, for example: http://thehackernews.com/2014/03/google-public-dns-server-traffic.html http://www.bgpmon.net/turkey-hijacking-ip-addresses-for-popular-global-dns-providers/ The other approach for DNS hijacking is to insert a "transparent" proxy, where the IP header of DNS requests and responses are rewritten to redirect queries to another DNS server (and fix up the replies). This requires in-line presence, and if you are not operating the Great Firewall, it is more usual to see this deployed in smaller (corporate) scopes. This can be hard to detect, since non-DNS traffic is unaffected. Depending on the transparent proxy implementation, traceroute -U (defaults to port 53) may provide some visibility into the redirection. Traceroute does not send actual DNS queries, just random data, so the traffic may be entirely unaffected, but you may see the traceroute stop at the hijack point (whereas a non-DNS traceroute keeps going). If you are lucky, the transparent proxy will be stupid enough to forward the mis-formatted packet rather than drop it, and you can trace the hijack path fully. However, without these sorts of additional diagnostics, you cannot legitimately accuse the ISPs of the hijacking. In particular, I suspect the redirections to OpenDNS are more likely to be happening at a corporate than an ISP level (although without traceroute or BGP evidence it is impossible to know for sure).