Google public DNS service provides an open DNS resolver for internet users. It is widely used all over the world and because of that popularity it often becomes a target of abuses. DNS service when hijacked may serve for interference in the communication on the internet what constitutes a tasty morsel for all those who would like to do something abusive. Several hijack incidents over Google public DNS occurred in the past and were widely publicized within the internet community. Some of those cases were easy to spot because relatively wide area of network was affected. But what about those smaller hijacks that took place and remain undetected in the course of our day-to-day activity in internet? In this study I tried to track down such cases.


Some theory

Google public DNS is an anycast cloud that consists of dozen of servers distributed throughout the internet. All those servers are avaible for web users via anycast IP addresses: 8.8.8.8 and 8.8.4.4 (or their IPv6 equivalents: 2001:4860:4860::8888 and 2001:4860:4860::8844). However, during the name resolution process, those servers send queries to the authoratitve name servers using their own, unique unicast IP address. Google discloses some details about its infrustructure1, among others, the addresses from which Google public DNS servers send requests to authoritative name servers. Knowing that information it is possible to determine if Google public DNS IP address (for example 8.8.8.8) was hijacked. In order to evaluate the scale of such hijack phenomenon a measuring infrastructure distributed throughout the internet and a fake DNS server are needed.

First, let’s focus on DNS. Special domain names were registered:

For these names a fake DNS server was running. It was configured to send a custom reply when asked for TXT record, this answer contained some information about the source of query (JSON format, see below).

In a nutshell, when 8.8.8.8 was asked for TXT record for test.ipv4.google-pdns-info.andzinski.pl name, it redirected query to the authoritative server of ipv4.google-pdns-info.andzinski.pl which in reply to that query returned details about the Google server. So eventually, the client of Google public DNS service was able to get information about the Google anycast cloud member that he was directed to. Google had published the list of its cloud members, so it was feasible to determine if 8.8.8.8 was hijacked.

Below there is an example of the answer produced when 8.8.8.8 pointed to a valid Google server. TXT record in a reply contained JSON with some details about Google public DNS cloud member that the client was directed to.

$ dig test.ipv4.google-pdns-info.andzinski.pl. TXT @8.8.8.8 +short
(...)
{
  "city": "Lappeenranta",
  "country": "Finland",
  "iata": "lpp",
  "lon": "28.144397",
  "lat": "61.044553",
  "valid": 1,
  "ip": "74.125.74.146"
 } 

and here is an exmple of alleged hijack case:

$ dig test.ipv4.google-pdns-info.andzinski.pl. TXT @8.8.8.8 +short
(...)
{
  "comment": "Not valid source IP address! Google public DNS IP address space hijacked?",
  "ip": "198.51.100.10", 
  "valid": 0
}

Having fake DNS configured, the only remaining thing to do was to employ distributed measurement system in order to produce an extensive view of 8.8.8.8 IP address throughout the internet. For this purpose an advantage of RIPE Atlas2 was taken.


Results

Each active RIPE Atlas probe was employed to query 8.8.8.8 IP address for TXT record for test.ipv4.google-pdns-info.andzinski.pl domain name (and accordingly 2001:4860:4860::8888 for test.ipv6.google-pdns-info.andzinski.pl). It yielded results from all corners of the internet.

IPv4

There were 6990 RIPE Atlas probes that could get DNS answer from 8.8.8.8. In 44 cases this IP address was identified as hijacked.

Hijack cases were divided into two groups:

  1. “Internal hijack” - when query to 8.8.8.8 resulted in redirection to the IP address within the same AS as probe was installed in
  2. “Foreign hijack” - when query to 8.8.8.8 resulted in redirection to the third-party AS (not Google AS and not probe AS)

For exactly 50% of cases, “internal hijack” took place. Among “foreign hijacks” there was one AS to which traffic was redirected more frequently than to the others. This was AS36692 OpenDNS, LLC and its share in all hijack cases constituted 18.2%. It suggests that some ISP intercepted traffic to 8.8.8.8 and redirected it to OpenDNS servers.

Map visualisation of hijack cases is presented below (click on marker to see details)3

NOTE: The word “hijacker” may be inadequate in some cases. For example when ISP intercepted traffic to 8.8.8.8 or 2001:4860:4860::8888 and redirected it to another open DNS server then AS of this server was listed as “hijacker’s AS”, however it didn’t mean that hijack was commited by this AS operator.

Tables below present most popular destinations of “foreing hijack” (Table 1) and autonomous systems with highest “internal hijack” (Table 2).

Table 1. Top destinations of “foreign hijack”
pos ASN AS description hijacked
1 36692 OpenDNS, LLC 8
2 199484 SAGLAYICI Teknoloji Bilisim Yayincilik Hiz. Ticaret Ltd. Sti. 2
3 10753 Level 3 Communications, Inc. 1
4 12430 VODAFONE ESPANA S.A.U. 1
5 13238 Yandex LLC 1
6 15685 Casablanca INT 1
7 174 Cogent Communications 1
8 25248 RADIOKOMUNIKACE a.s. 1
9 25780 HugeServer Networks, LLC 1
10 35838 CCANet Limited 1
11 36351 SoftLayer Technologies Inc. 1
12 45786 HTSNET - ISP 1
13 4766 Korea Telecom 1
14 6939 Hurricane Electric, Inc. 1
Table 2. Autonomous systems with highest “internal hijack” rate
pos ASN AS description probes total probes with hijack detected % hijack
1 7155 Viasat Communications Inc. 4 4 100.00 %
2 29119 ServiHosting Networks S.L. 1 1 100.00 %
3 41782 BGLAN Ltd 1 1 100.00 %
4 45903 CMC Telecom Infrastructure Company 1 1 100.00 %
5 48747 Lukovitnet Ltd. 1 1 100.00 %
6 58621 Vodien Internet Solutions Pte Ltd 1 1 100.00 %
7 8687 Pelikan & Partner 1 1 100.00 %
8 9556 iiNet Limited 1 1 100.00 %
9 29286 SKYLOGIC S.P.A. 4 3 75.00 %
10 30722 Vodafone Omnitel B.V. 3 2 66.67 %
11 16246 RIO Media a.s. 6 1 16.67 %
12 31200 Novotelecom Ltd 6 1 16.67 %
13 4766 Korea Telecom 6 1 16.67 %
14 15895 Kyivstar PJSC 11 1 9.09 %
15 18106 Viewqwest Pte Ltd 17 1 5.88 %
16 5466 Eircom Limited 17 1 5.88 %

Countries with the most noticable hijack intensity are listed in the table below. This data may not be representative because of too small number of probes in some countries.

Table 3. Top 20 countries with highest hijack rate
pos CC country full name probes total probes with hijack detected % hijack
1 VN Viet Nam 3 1 33.33 %
2 KR Korea, Republic of 15 2 13.33 %
3 ID Indonesia 10 1 10.00 %
4 SG Singapore 60 5 8.33 %
5 TR Turkey 27 2 7.41 %
6 IR Iran, Islamic Republic of 38 1 2.63 %
7 BG Bulgaria 77 2 2.60 %
8 IT Italy 215 4 1.86 %
9 ES Spain 118 2 1.69 %
10 AU Australia 65 1 1.54 %
11 CZ Czech Republic 220 3 1.36 %
12 UA Ukraine 170 2 1.18 %
13 IE Ireland 98 1 1.02 %
14 SE Sweden 129 1 0.78 %
15 PL Poland 135 1 0.74 %
16 US United States 815 5 0.61 %
17 BE Belgium 168 1 0.60 %
18 RU Russian Federation 347 2 0.58 %
19 GB United Kingdom 474 2 0.42 %
20 DE Germany 734 3 0.41 %

Map below presents hijack intensity for all countries in which active RIPE Atlas probes extisted.

RIPE Atlas system provided probe tagging feature. For instance, probes located behind NAT had “nat” tag assigned. Furthermore, probe host could define his own tags such as “office”, “datacentre”, etc. Core RIPE Atlas probes called “anchors” also had special tag, such devices were usually located in data centers close to important network nodes. Table below presents hijack intensity in relation to probe tag. Hijack incidents were almost 10 times more frequent on probes with “nat” tag than on probes with “no-nat” tag assigned. It was noticeable that no hijack issues were observed on anchor probes.

Table 4. Hijack intensity in relation to probe tag
pos tag probes total probes with hijack detected probes with “foreign hijack” detected probes with “internal hijack” detected % hijack
1 nat 3270 24 11 13 0.73 %
2 academic 140 1 0 1 0.71 %
3 datacentre 441 3 2 1 0.68 %
4 home 1729 10 5 5 0.58 %
5 office 499 2 1 1 0.40 %
6 no-nat 1289 1 1 0 0.08 %
7 system-anchor 91 0 0 0 0.00 %

IPv6

Collected data from 1947 RIPE Atlas probes. There were no cases of 2001:4860:4860::8888 hijack.


Conclusions

This study resulted in conclusion that every 1 out of 160 internet users was affected by 8.8.8.8 hijack. This rough estimation was based on the data from 6990 probes not equally distributed over the internet, therefore the results should be treated warily. Nontheless, it was demonstrated that the 8.8.8.8 hijack phenomenon existed.

For discussed cases the 8.8.8.8 IP address was not blackholed or filtered out but hijacked, i.e., it was feasible to get DNS answer quering this IP address. It may suggest that somebody intended to tamper with DNS data and consequently redirect the end user without his knowledge. For instance, modifying NXDOMAIN answer is actually a common practice among ISP. They do so for their own purposes such as displaying advertisements. However, hijacking an IP address is a way more aggressive activity that violates more than only DNS standards.

“IP hijacking” term usually refers to “BGP hijacking”, however in this study the majority of cases seemed to have more local form. As it was demonstrated, discussed incidents occurred much more frequently on probes located behind NAT. It may suggest that routing protocols were not involved in hijack, but rather some NAT rules for 8.8.8.8 IP address existed. Low IPv6 popularity among desktop users can presumably explain the fact that there were no hijack issues related to IPv6. Likewise, the observation that none of anchor probes were affected by hijack also appears to confirm the hypothesis that mainly ordinary internet users were targeted.

Unfortunatelly DNSSEC doesn’t protect againts discussed abuses. DNS packet with “Authenticated Data” flag set can be easily forged by hijacker. One could run recursive DNS resolver on his own, however it is not the most efficient solution in the world.

Using commands below you can check if you are directed to legitimate Google public DNS server:

dig test.ipv4.google-pdns-info.andzinski.pl. TXT @8.8.8.8
dig test.ipv6.google-pdns-info.andzinski.pl. TXT @2001:4860:4860::8888


Any comments? remarks?
feel free to contact me: m.andzinski(at)gmail.com


Data for analyses was collected at the beginning of July, 2015.


  1. “Google public DNS FAQ”: https://developers.google.com/speed/public-dns/faq

  2. “RIPE Atlas”: https://atlas.ripe.net/about/

  3. Needs JavaScript enabled