A RIPE Atlas View of Internet Meddling in Turkey

Emile Aben — Mar 31, 2014 10:40 AM
Filed under: , ,
In RIPE Atlas we see latencies to Google's 8.8.8.8 DNS resolver service drop in Turkey. We expect this is due to hijacking of the 8.8.8.8 service. Our measurements show a timeline of these events. Note that even when the Twitter ban had been lifted, RIPE Atlas still saw fake 8.8.8.8 DNS service active in Turkey. In the evening of 7 April the situation returned to normal.

We see decreased latencies for the majority of RIPE Atlas probes in Turkey, starting around midnight of 29 March 2014 (UTC). This could be caused by a routing hijack of 8.8.8.8, as reported by Stéphane Bortzmeyer and BGPMon. BGPMon reports the hijack starting at around 9 UTC, the event we see in our data started 9 hours earlier, around midnight. From what we see today, this event seems to be ongoing.

The figure below shows the latency drops. The latencies drop to less then 10 ms for a couple of probes. Given first mile latency and speed of light constraints this means that whatever picks up the phone and responds to 8.8.8.8 is within Turkey. So either Google has started serving 8.8.8.8 from Turkey, or, more likely, the data from RIPE Atlas points towards the existence of a fake 8.8.8.8 service within Turkey.

Latency v2

Figure 1: Latencies to 8.8.8.8 from RIPE Atlas probes in Turkey. Each colored line represents a single RIPE Atlas probe.

It is interesting to note that the latencies don't go down for all the vantage points we have in Turkey. Let's assume for the moment that the latency drops we see are caused by an attempt to censor Google DNS service. The fact that not all vantage points see lower latencies could indicate that not all networks in Turkey are affected by this attempt to censorship. We also see a drop in latencies in the evening of 21 March 2014, which correlates with earlier reports of Google DNS service censoring. The latencies for this event return to normal in the morning of 22 March, and seem to be limited to fewer RIPE Atlas probes.

In order to protect the network operators of networks that don't seem to implement this censorship from repercussions, we will not name the specific networks where we don't see meddling with Google's DNS service.

We didn't see evidence of an 8.8.8.8/32 host-route or 8.8.8.0/24 being diverted via Turkish networks in our Routing Information Service (RIS) data.

If the reports that only a handful of open DNS services are blocked are true, tech-savy Internet users in Turkey could start running a DNS resolver on their own computer and be able to use a regular and (for now) uncensored Internet without having to resort to using VPNs or Tor.


UPDATE (2014-04-04 7am UTC):

RIPE Atlas still sees the low latency 8.8.8.8-DNS-service active for a majority of vantage points in Turkey, as can be seen in the figure below. As of 3 April  15:14:09 (UTC) we see this fake-8.8.8.8 service stopped redirecting Twitter-users towards an IP address in the Turk Telekom network (195.175.254.2) and we now see real Twitter IP addresses again for all our vantage points in Turkey that do lookups for the hostname twitter.com.

This means that, despite lifting the ban on Twitter in Turkey yesterday, the fake 8.8.8.8 DNS service remains in place as a potential censorship instrument. It still can be used to intercept and potentially redirect traffic of Internet users in Turkey who use this Google DNS service.

 

latencies from Turkey to 8.8.8.8

Figure 2: Latencies to 8.8.8.8 from RIPE Atlas probes in Turkey. Each colored line represents a single RIPE Atlas probe.

UPDATE (2014-04-08 1:40pm UTC):

Latencies to 8.8.8.8 have gone up to normal levels again in the evening of 7 April, as can be seen in Figure 3.

latencies from Turkey to 8.8.8.8

Figure 3: Latencies to 8.8.8.8 from RIPE Atlas probes in Turkey. Each colored line represents a single RIPE Atlas probe.

Looking at traceroute data we see what looks like a normal path to the Google 8.8.8.8 public DNS service again, for instance see the tail end of this traceroute:

4  81.212.203.77  9121  ulus-t2-1-ulus-t3-4.turktelekom.com.tr.203.212.81.in-addr.arpa [7.387, 8.945, 24.101]
5  81.212.197.62  9121  incesu-t2-2-ulus-t2-1.turktelekom.com.tr.197.212.81.in-addr.arpa [8.07, 7.761, 7.876]
6  72.14.217.118  15169  [84.286, 84.061, 82.204]
7  209.85.240.162 15169  [86.991, 86.506, 87.646]
8  72.14.234.11   15169  [89.665, 101.774, 85.122]
9  209.85.254.118 15169 [87.54, 90.07, 87.654]
10 * * *
11 8.8.8.8    15169 google-public-dns-a.google.com [86.865, 90.175, 87.613]

Specifically, the trace shows multiple hops in AS15169 and latencies are at pre-event levels. It looks like all RIPE Atlas probes in Turkey once again see the real 8.8.8.8 service again.

7 Comments

Sergey Myasoedov
Sergey Myasoedov says:
Mar 31, 2014 11:55 AM
Unfortunately not only Google public DNS network/hosts are blocked. At least Twitter frontends are blocked too according to Turkish Telecom looking glass.
emile.aben@ripe.net
Emile Aben says:
Mar 31, 2014 03:10 PM
Thanks for the comment Sergey. We are aware that there is more going on than we report in this short post (see the reference to the articles by BGPMon and Stephane). What we hadn't seen reports on is a timeline on latency changes. Please read this article as an addition to the information that has already been out there, not as an all encompassing view.
bortzmeyer+ripe@nic.fr
Stéphane Bortzmeyer says:
Mar 31, 2014 02:28 PM
Regarding the "networks that don't seem to implement this censorship". The manager of one of the spared probes (Atlas probes which do see the real Google Public DNS) explained me that he tunnels his entire LAN (including the traffic of the probe) to a remote server, precisely to work around filtering.
emile.aben@ripe.net
Emile Aben says:
Mar 31, 2014 03:18 PM
Thanks for the info Stéphane (and for your excellent article that also uses RIPE Atlas data!).
Seregwethrin
Seregwethrin says:
Apr 01, 2014 03:07 PM
This is my analysis. I reside in Turkey. This clearly shows they forward the packets to one of their DNS Servers. A country makes IP Spoofing and DNS Poisoning scams to their citizens.

http://i.imgur.com/dS6ptJR.jpg
http://i.imgur.com/WoLflZJ.jpg
raitme citterio
raitme citterio says:
Apr 11, 2014 04:18 AM
Hi Emile Aben.

Similar to that of Turkey, a situation happened recently in Venezuela (read http://goo.gl/U1FbHp http://goo.gl/jwVwxw http://goo.gl/VzKCfj) where google dns suffered an anomaly similar characteristics to those of his study of turkey.
If I could tell as I conducted the study using ripe atlas? and that I possess but not exactly I should look to find reference parameters. would greatly appreciate your kind help.

Thanks
emile.aben@ripe.net
Emile Aben says:
Apr 11, 2014 09:55 AM
Hi Raitme,

If you'd want to monitor the situation with regards to DNS resolver services outside of Venezuela, that's certainly possible with RIPE Atlas. We currently have 2 RIPE Atlas probes in Venezuela; having a couple more would help (you can apply for hosting one yourself here: https://atlas.ripe.net/get-involved/become-a-host/ ).
Let us know at labs@ripe.net if you need more info on setting up measurements or analysis of results.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
NTP Measurements with RIPE Atlas

This article describes how RIPE Atlas probes and anchors maintain their clocks, and how accurate ...

Visualising Network Outages With RIPE Atlas

This article shows some prototypes of visualising network outages with RIPE Atlas using CartoDB.

Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Distribution of RIPE Atlas Probes

As the RIPE Atlas network continues to grow, it's useful for ambassadors and potential probes hosts ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

more ...