The Turkish Telecom DNS Hijack (2014)

On March 29, 2014, the Turkish government deployed one of the most brazen state-level BGP hijacks in internet history. Turk Telekom (AS9121), Turkey's incumbent telecommunications provider, used BGP to hijack the IP prefixes of Google Public DNS (8.8.8.8) and Level 3 DNS (4.2.2.1, 4.2.2.2) to intercept and manipulate DNS queries from millions of Turkish internet users. The goal: enforce government censorship of Twitter, YouTube, and other platforms where leaked audio recordings of high-level corruption were being shared.

This was not a misconfiguration or an accident. It was a deliberate, coordinated abuse of core internet routing infrastructure by a nation-state to suppress political speech. The incident remains a defining case study in how BGP's trust-based architecture can be weaponized for censorship, and why technologies like DNS over HTTPS and RPKI matter.

The Political Context

In late February 2014, anonymous recordings surfaced on YouTube and Twitter that appeared to capture senior Turkish government officials discussing corruption, bribery, and efforts to conceal evidence of financial misconduct. The recordings were politically explosive, emerging weeks before critical local elections in March 2014.

The Turkish government, led by then-Prime Minister Recep Tayyip Erdogan, moved quickly. On March 20, 2014, Turkey's telecommunications authority (TIB) ordered ISPs to block access to Twitter. A court order formally blocking YouTube followed on March 27. The stated justification was "national security" and the protection of privacy, but the timing and scope made the political motivation unmistakable.

The initial blocks were implemented via DNS poisoning: Turkey's ISP-operated DNS resolvers were configured to return false answers for twitter.com, youtube.com, and related domains. Users who queried their ISP's resolver for twitter.com would get an NXDOMAIN response (domain not found) or be redirected to a government block page instead of Twitter's actual IP address.

Users Fight Back with Google DNS

Turkish internet users quickly discovered a simple workaround: change their DNS resolver. Instead of using their ISP's DNS servers, they configured their devices to use third-party resolvers like Google Public DNS (8.8.8.8 and 8.8.4.4) or Level 3's DNS servers (4.2.2.1 and 4.2.2.2). Since these resolvers were operated by companies outside Turkey, they were not subject to Turkish government DNS blocking orders and would return the real IP addresses for twitter.com and youtube.com.

This workaround went viral. The IP address 8.8.8.8 was spray-painted on walls in Istanbul and Ankara. It appeared on protest banners and was shared millions of times on social media. For a brief moment, Google's DNS IP address became a symbol of resistance to censorship.

The Turkish government realized that DNS-level blocking was trivially defeated. Users were routing around the censorship by simply pointing their queries at foreign resolvers. The government needed a way to intercept DNS queries even when they were addressed to IP addresses outside Turkey's control.

The BGP Hijack: How It Worked

On March 29, 2014, Turk Telekom (AS9121) began announcing BGP routes for the IP prefixes belonging to Google Public DNS and Level 3's DNS service. Specifically, Turk Telekom injected routes for prefixes including 8.8.8.0/24 (Google DNS) and 4.2.2.0/24 (Level 3 DNS) into its internal routing infrastructure.

Because these routes were injected within Turk Telekom's own network and not advertised to external BGP peers, the hijack was contained to Turkish domestic traffic. This was not a global hijack like the Pakistan-YouTube incident of 2008 where Pakistan Telecom's hijacked route leaked internationally. Turk Telekom deliberately kept the hijack internal to Turkey's network boundaries, making it harder to detect from outside the country.

Here is how the attack worked at a technical level:

Route injection — Turk Telekom's routers were configured to announce the prefixes 8.8.8.0/24 and 4.2.2.0/24 (and potentially more specific prefixes like /25s) internally within AS9121. Because these were local to the AS, they took priority over external routes learned via eBGP from upstream peers.
Traffic interception — Any Turkish internet user sending a DNS query to 8.8.8.8 or 4.2.2.1 would have their packets routed to Turk Telekom's own infrastructure instead of reaching Google's or Level 3's actual DNS servers.
DNS manipulation — Government-controlled DNS resolvers running on the hijacked IP addresses answered queries. For blocked domains like twitter.com and youtube.com, these fake resolvers returned NXDOMAIN or redirect responses. For all other domains, they proxied queries to the real upstream DNS servers and returned legitimate answers, making the interception largely invisible for non-blocked traffic.

The elegance and danger of this attack was its selectivity. Users who configured 8.8.8.8 believed they were sending their queries to Google. The IP address was correct. But the routing infrastructure beneath them had been subverted. Their packets addressed to 8.8.8.8 were being delivered to a completely different machine running on Turk Telekom's network.

Why the Hijack Stayed Local

A critical detail of the Turkish hijack, and what distinguishes it from other famous BGP incidents, is that the false routes were never leaked to the global routing table. Turk Telekom injected the hijacked routes within its own autonomous system using internal routing mechanisms (static routes or iBGP) rather than announcing them via eBGP to external peers.

In BGP, a route learned from a local static route or an iBGP session is typically preferred over one learned from an external peer, because of the way BGP's best-path selection algorithm works. Local and static routes have the highest administrative preference. So even though Turk Telekom's upstream transit providers were still delivering the legitimate routes for 8.8.8.0/24 from Google (AS15169), the locally injected route won on every router within AS9121.

This containment was deliberate. A global leak would have been immediately noticed by Google, by route monitoring systems like RIPE RIS, and by the broader internet operations community. By keeping it internal, Turkey's government could intercept domestic DNS traffic while avoiding the international backlash and rapid remediation that a global hijack would trigger.

Detection and Evidence

Despite the government's effort to keep the hijack invisible, it was detected relatively quickly by the internet security community. Several independent researchers and monitoring systems observed anomalies:

Traceroute analysis — Turkish users running traceroute to 8.8.8.8 noticed that packets were not leaving Turkey. The trace would terminate within Turk Telekom's network instead of crossing international borders to reach Google's infrastructure. Normal traceroutes to 8.8.8.8 from Turkey would show hops through international transit providers before reaching Google's network.
DNS response analysis — The responses from the hijacked resolvers differed from Google's actual responses. Google DNS uses EDNS Client Subnet and returns geographically appropriate answers. The fake resolvers did not replicate these behaviors consistently, and their response patterns for blocked domains (returning NXDOMAIN for twitter.com) were an obvious tell.
RIPE Atlas measurements — The RIPE Atlas network of probes deployed across Turkey confirmed that DNS traffic to 8.8.8.8 was being intercepted. Probes showed inconsistent latency patterns and different DNS response characteristics compared to probes outside Turkey querying the same addresses.
TTL and header analysis — Packets returning from the fake resolver had different IP TTL values and TCP characteristics than real Google DNS responses, because they were originating from local infrastructure rather than Google's distant servers.

The Technical Anatomy of the Intercept

To understand why the hijack was so effective, it helps to understand the interaction between BGP and DNS:

When your computer sends a DNS query to 8.8.8.8, it creates a UDP packet with a destination IP of 8.8.8.8 and sends it to the default gateway. From there, routing takes over. The router looks up 8.8.8.0/24 in its forwarding table (populated by BGP) and sends the packet toward the next hop for that prefix.

Under normal conditions, routers within Turk Telekom would forward this packet toward an upstream transit provider who could route it to Google's network (AS15169), where the real 8.8.8.8 server lives. But with the hijacked route in place, the forwarding table pointed to a local destination within AS9121. The packet never left the building.

The hijacked resolver sitting on the intercepted path was configured as a transparent DNS proxy with a blacklist. For the vast majority of domains, it forwarded queries upstream and returned the real answers. Only queries for blacklisted domains received manipulated responses. This selective approach meant that most users experienced no visible disruption, making the hijack harder to notice through casual observation.

Scope and Impact

The hijack affected every internet user in Turkey who was connected through Turk Telekom's network or any network that purchased transit from Turk Telekom. Given that Turk Telekom is the dominant telecommunications provider in Turkey, with ownership of most of the country's physical network infrastructure, this encompassed a substantial majority of the approximately 35 million internet users in the country at the time.

The intercepted DNS resolvers included at minimum:

Google Public DNS: 8.8.8.8 and 8.8.4.4 (prefix 8.8.8.0/24, origin AS15169)
Level 3 DNS: 4.2.2.1 and 4.2.2.2 (prefix 4.2.2.0/24, origin AS3356)

Reports also suggested that other popular third-party DNS services may have been targeted as well, though Google DNS and Level 3 were the most widely documented cases.

The immediate impact was that the DNS-based bypass that Turkish users had been using to access Twitter and YouTube stopped working. Users who thought they were safe because they had switched to Google DNS found themselves censored again, with no obvious technical explanation unless they understood BGP routing.

Beyond DNS: The Broader Attack Surface

The BGP hijack of DNS resolvers was not just about blocking Twitter. It exposed a much more dangerous capability. By intercepting DNS traffic, the government-controlled resolvers could theoretically:

Perform DNS-based surveillance — Log every domain name queried by every user on the network, building detailed browsing histories for millions of people.
Redirect traffic for any domain — Not just block access, but redirect users to fake versions of websites. This could be used for phishing, credential harvesting, or injecting surveillance software.
Selectively manipulate results — Return different answers based on the source IP, targeting specific users or organizations with tailored DNS manipulation.
Intercept certificate validation — If combined with a compromised Certificate Authority (and Turkey had its own government-controlled CA), DNS manipulation could facilitate man-in-the-middle attacks on HTTPS traffic.

This is why the incident was so alarming to the internet security community. The DNS hijack demonstrated not just censorship capability, but the infrastructure for mass surveillance and traffic manipulation at a national scale.

AS9121: Turkey's Network Gatekeeper

AS9121 (Turk Telekom) occupies a unique position in Turkey's internet topology. As the incumbent operator and owner of most of the country's physical telecommunications infrastructure, Turk Telekom is the dominant transit provider for smaller Turkish ISPs and enterprises. Many Turkish autonomous systems rely on AS9121 as their upstream provider, meaning that Turk Telekom's routing decisions affect traffic for networks far beyond its own direct customers.

You can explore Turk Telekom's position in the BGP routing table by looking up AS9121. The number of downstream ASes and announced prefixes reveals the scope of its influence over Turkish internet routing. When a network this central hijacks routes, there is essentially no domestic path around it.

This structural centrality is not unique to Turkey. In many countries, a single incumbent telecom operator controls the majority of physical infrastructure and transit capacity. This makes BGP hijacking by the incumbent particularly devastating: there is no alternative path for traffic to take, and smaller ISPs connected through the incumbent are affected whether they cooperate or not.

Defenses That Would Have Helped

Several technologies could have mitigated or exposed this attack more effectively:

DNS over HTTPS (DoH) and DNS over TLS (DoT)

DNS over HTTPS encrypts DNS queries inside HTTPS connections to the resolver. If Turkish users had been using DoH to reach Google's DNS service, the BGP hijack would have caused a TLS certificate validation failure. The hijacked resolver would not have been able to present a valid TLS certificate for dns.google, and the DoH client would have refused to connect. The user would have experienced a DNS resolution failure rather than silently receiving censored results.

In 2014, DoH did not yet exist as a standard (RFC 8484 was published in 2018). This incident is one of the reasons the internet community accelerated work on encrypted DNS protocols. Today, DoH and DoT are supported by all major browsers and operating systems, making this exact attack vector significantly harder to exploit without detection.

RPKI and Route Origin Validation

RPKI allows prefix holders to cryptographically declare which AS is authorized to originate their routes. If Google had published a ROA for 8.8.8.0/24 specifying AS15169 as the only authorized origin, and if Turk Telekom's routers had performed Route Origin Validation, the hijacked route (originating from AS9121) would have been flagged as RPKI-invalid.

However, RPKI has a significant limitation here: it validates routes at the eBGP boundary between autonomous systems. The Turkish hijack used locally injected static routes within AS9121 itself, where RPKI validation does not apply. RPKI would have prevented a global leak of the hijacked route, but not the internal interception. The real value of RPKI in this context is forcing attackers to be more brazen about their hijacks, making detection and attribution easier.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with. If the domains being blocked (twitter.com, youtube.com) had DNSSEC-signed zones, and if users' resolvers validated DNSSEC signatures, the forged NXDOMAIN responses from the government resolver would have failed validation.

However, DNSSEC validates the DNS response content, not the identity of the resolver itself. The hijacked resolver was pretending to be 8.8.8.8, and for non-blocked domains, it was returning valid upstream responses (including valid DNSSEC signatures obtained by proxying to the real resolver). The protection is partial: DNSSEC would catch forged responses but would not prevent traffic interception or query logging.

VPNs and Encrypted Tunnels

A VPN tunnel that encapsulates all traffic (including DNS) inside an encrypted connection to an endpoint outside Turkey would have defeated the BGP hijack entirely. The DNS query to 8.8.8.8 would travel inside the encrypted tunnel to the VPN server, which would forward it to the real Google DNS. Turk Telekom's routers would only see encrypted VPN traffic going to the VPN server's IP address.

Predictably, the Turkish government also took steps to block VPN services during this period, though blanket VPN blocking proved difficult to sustain.

Lessons for Internet Architecture

The Turkish Telecom DNS hijack illustrates several fundamental truths about internet architecture:

BGP is a trust protocol operating in a trustless world. BGP was designed for a cooperative internet where every network operator acts in good faith. It has no built-in mechanism to prevent a network from routing traffic wherever it wants within its own borders. When the network operator is the adversary, BGP's trust model breaks down completely.

DNS without encryption is a censorship lever. Plaintext DNS gives every network operator between the user and the resolver full visibility into which domains are being queried, and the ability to modify the responses. This is not a bug that occasionally gets exploited; it is a feature that governments have systematically used for censorship in Turkey, China, Iran, Russia, and elsewhere. Encrypted DNS (DoH/DoT) eliminates this lever by turning DNS queries into opaque HTTPS traffic.

Domestic BGP hijacks are harder to detect than global ones. When Pakistan Telecom hijacked YouTube in 2008, the route leaked globally and was detected within minutes because route monitoring systems worldwide saw the conflict. Turkey's internal hijack was invisible to external BGP monitors. Detection required active measurement from inside the country, using tools like RIPE Atlas probes and manual traceroute analysis by users on the ground.

The last-mile ISP has ultimate power over its users' traffic. No matter how secure the endpoint (Google DNS, Cloudflare DNS), the network carrying the packets can redirect them. Encryption (TLS, DoH, VPNs) is the only reliable defense, because it shifts trust from the network path to the cryptographic identity of the endpoint. A BGP hijack can steal the IP address, but it cannot steal the private key.

The Aftermath

Turkey's Constitutional Court ruled the Twitter ban unconstitutional in April 2014, and the blocks were lifted over the following months after a series of legal challenges. The YouTube ban lasted longer, remaining in effect until June 2014. However, the technical infrastructure for DNS interception remained in place, and Turkey has continued to use various internet censorship mechanisms in the years since.

The incident galvanized the internet engineering community's push for encrypted DNS. The IETF's work on DNS over HTTPS accelerated, and browser vendors (Google, Mozilla, Apple) began implementing DoH as a default feature. Today, when a user enables DoH in their browser, their DNS queries are encrypted end-to-end to the resolver, making a BGP hijack of the resolver's IP address detectable (the TLS handshake would fail) rather than silently effective.

The Turkish hijack also reinforced the importance of BGP monitoring and measurement networks. RIPE Atlas, BGPStream, and similar tools now provide much greater visibility into routing anomalies, though detecting purely domestic hijacks remains challenging without in-country measurement infrastructure.

Explore the Infrastructure

You can examine the networks and IP addresses involved in this incident using the looking glass:

AS9121 — Turk Telekom's autonomous system, its announced prefixes and peering
8.8.8.8 — Google Public DNS, the primary hijack target
8.8.4.4 — Google's secondary DNS server
4.2.2.1 — Level 3 DNS, also hijacked
AS15169 — Google's autonomous system
AS3356 — Level 3 / Lumen, operator of the 4.2.2.x DNS servers