Babak Farrokhi

Operator Level DNS Hijacking

Babak Farrokhi
4

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.

4

You may also like

View more

About the author

Babak Farrokhi is a Computer Scientist and Researcher with over 20 years of experience in UNIX Systems and Networking. His expertise includes IP Networking, BGP, DNS, Internet Performance, System Scalability and Network Security. He provides consulting services and develops products and services related to his expertise.

Comments 4