New Research shows IPv6 Adoption “is now real”

IPv6 BadgeNew research conducted by a team of researchers shows that IPv6 adoption has fundamentally left behind its experimental origins. Their research paper will be presented at the upcoming 2014 ACM SIGCOMM conference in Chicago.

We are probably all used to the idea that IPv6 adoption is increasing and that every year we see more IPv6 connected hosts on the Internet. What sets this paper apart is the sheer amount of data the researchers collected and analyzed. In total the researchers investigated 12 different metrics from ten different data-sets. Their goal is to achieve the most accurate view of IPv6 adoption to date.

“To achieve our goal we assemble a set of six publicly-accessible datasets that speak to one or more aspects of IPv6 adoption. We add four additional, previously-unpublished datasets, including a global Internet traffic dataset that includes traffic statistics from 260 providers and represents 16,200 petabytes/month, or approximately 33-50% of all Internet traffic—the largest traffic sample reported in an IPv6 study. In addition to the traffic data, we add DNS query data from several of the largest globally-distributed IPv4-based replicas of the .com and .net top-level domains (TLDs), as well as nearly all native IPv6 replicas for these TLDs.”

Their findings reflect the wealth of data collected. What I particularly find interesting is the application of their data-sets to a topological understanding of IPv6 adoption.

One cool thing they measure is increase in IPv4 paths vs. increase in IPv6 paths. By comparing the topology of the global IPv4 and IPv6 networks they find that, “[the] number of IPv6 paths has a 110-fold increase from January 2004 to January 2014, while there is only an eight-fold increase in the number of IPv4 paths.” Rarely do we get such an elegant understanding of the growth of IPv6 compared to that of the total Internet.


They’re also able to show that the number of Autonomous Systems (ASes) with few neighbors, primarily multi-homed edge ASes, that support IPv6 has increased significantly since 2004. This is interesting because this represents networks that usually lag behind first adopters.

Well connected ASes with many neighbors are going to have the easiest time adopting IPv6 because they have the most resources and it benefits them the most. They typically have a scale advantage, and are much more likely to have an immediate neighbor that has already deployed IPv6. Less connected networks at the edge are those networks you would expect to lag significantly behind in IPv6 adoption, so it’s refreshing to see that their adoption rates have increased significantly since 2004.

There are other gems in this research that I’ll leave for the curious reader to find. The paper can be downloaded from the International Computer Science Institute’s website. Here is the direct PDF link, you can also download their data if you wish to perform your own analysis. The paper’s authors are Jakub Czyz, Scott Iekel-Johnson, Mark Allman, Eric Osterweil, Jing Zhang, and Michael Bailey.

If you would like to get started with IPv6, please visit our IPv6 resources or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have an IPv6 case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!

Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security Securing Border Gateway Protocol (BGP)

FCC requests comments on DNSSEC, BGPSec and Anti-Spoofing

fcc-logo_blackOn July 25, 2014 the United States Federal Communications Commission (FCC) posted a request for comments from the ISP community on proposed best practices for US ISPs.

They’re specifically seeking comment on the FCC’s third Communications Security, Reliability and Interoperability Council (CSRIC III) recommendations for ISPs.

The CSRIC III recommendations overlap quite extensively with topics that Deploy360 holds dear, including DNSSEC, BGPSec, and Anti-Spoofing. CSRIC dates from March 2012. However, the FCC says it has not yet received sufficient information, “for a meaningful understanding of either their effectiveness or lessons learned from implementation.” Hence this request for further information from any interested parties. The FCC will be accepting comments until September 26, 2014.

CSRIC III is quite extensive, so if you do plan on providing comment, it’s probably better if you focus on one topic for your comments instead of reading the full report.

The following PDFs will help you better understand specific CSRIC III topic areas.




You can browse the entire CSRIC III recommendations here. Or you can read the FCC’s request for comment here, or download it as a PDF. This document also explains how to submit comments to the FCC.

If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization.

For more information about Anti-Spoofing and implementing filtering, check out our page on Anti-Spoofing. Or visit the IETF’s SAVI working group.

For more information about Securing BGP, and Secure Inter-Domain routing (SIDR), check out our page on Securing BGP. Or visit the IETF’s Secure Inter-Domain Routing(SIDR) working group.

Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security To archive Transport Layer Security (TLS)

FakeID, Android, Certificates, and Implementation Details

Android-FAKEID-logo-200x200Security firm Bluebox Security has uncovered a vulnerability in Google’s Android mobile operating system , which could allow attackers to trick an Android device into installing malicious applications. The package installer component of Android doesn’t check the validity of the certificate chain.

We don’t know all of the details yet. Bluebox is waiting on formally presenting the vulnerability at the Blackhat security conference, but it looks bad. Affected versions appear to be all Android releases after version 2.1 and before 4.4.

According to this article, it appears the problem has been traced to the inclusion of code from the now discontinued Apache Harmony project. The worst part of this vulnerability is due to the way Android is deployed in the marketplace. Many Android users will never see a fix, because their handset manufacturer no longer supports their handset. They will remain in the wild, and vulnerable, until they’re taken out of service.

When cryptographic gaffes happen it’s very tempting to point to a new protocol like DNSSEC, and claim it does not have this problem. Indeed, I wrote about the new trust models presented by DNSSEC, DANE, and Certificate Transparency earlier this month. I argued that we need to move away from trusting centralized entities such as Certificate Authorities, and instead distribute our trust model using both Certificate Transparency(RFC 6962), and DNSSEC / DANE.

However, the real culprit here isn’t the hard coding of CA’s in applications, or the Public Key Infrastructure(PKI) that affords the signing of certificates by multiple authorities. The real culprit here is Android’s abject lack of checking the certificate chain. From what we know of the vulnerability, Android’s package installer just implicitly trusts the presented certificate chain, without any verification.

No new technology or protocol can rectify this kind of broken behavior. If Android’s package installer implemented certificate verification via DNSSEC / DANE, it would still need to query DNS for the hash of the certificate and verify it. If Android’s package installer checked a package’s certificate against a public log, a la Certificate Transparency, it would actually have to check it. The lesson here is not that one technology is better than the other, but that actual follow through is important. If your security model is based on certificate chains, then verify the certificate chain.

There are still obvious advantages to an Internet with fully deployed DNSSEC, and an Internet where CAs append their issued certificates to a public log for Certificate Transparency. We just should not forget that implementations matter, it’s usually the implementations where the flaws are found, and not the underlying protocols themselves.

If you would like to learn more about Certificate Transparency, please visit If you would like to learn more about DANE, please visit our resource page on DANE. If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have a Certificate Transparency, DANE, or DNSSEC case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!

Deploy360 Improving Technical Security Securing Border Gateway Protocol (BGP) To archive Transport Layer Security (TLS)

BGP Hijacker Steals Bitcoins

Securing BGPResearchers at Dell’s Secureworks have uncovered multiple BGP incidents used to steal bitcoins. According to Secureworks, the attacker used a compromised administrator account at a yet undisclosed Canadian ISP.

With this account they were able to then inject BGP routes which redirected traffic from machines mining Bitcoins to the attacker’s compromised host. Secureworks estimates that at least $83,000 worth of Bitcoins, Dogecoins, HoboNickels, and Worldcoins were stolen over a period of 4 months.

Details such as the identity of the Canadian ISP or which routes were injected are not included in their report. However, there are two obvious technologies that would have prevented this attack. The first, and most obvious, is Border Gateway Protocol(BGP) security. Something like BGP Resource Public Key Infrastructure (RPKI) would have prevented the receiving BGP peer from accepting bogus routes. The second is Transport Layer Security(TLS) connections between the hosts controlling the *coin miners, and the miners themselves.

If either of these technologies had been deployed in this instance the attack would have been mitigated. The easier of the two is TLS, which only requires the two end-points to start encyrpting their peer-to-peer communications, and does not require anything of the intermediary ISPs. Had the miners been using TLS in this instance, the attacker would not have been able to steal Bitcoins. Instead merely interrupting service for the duration of the hijacking attempt.

The report also contains numerous neat graphics exaplaining how a BGP Man in the Middle(MITM) attack works. They unfortunately use routable IPs in their examples, but the graphics still convey the idea quite nicely.


For more information about TLS, and developing secure applications, check out our page on TLS for Applications. Or visit the IETF’s Using TLS in Applications (UTA) working group.

For more information about Securing BGP, and Secure Inter-Domain routing(SIDR), check out our page on Securing BGP. Or visit the IETF’s Secure Inter-Domain Routing(SIDR) working group.

Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security To archive Transport Layer Security (TLS)

Distributed Trust Models:TLS Certificate Transparency and DANE

TLSMany of the Internet’s secure protocols rely on Certificate Authorities(CA)s to issue certificates that we can trust. These certificates are responsible for ensuring that servers are who they say they are. Without this assurance, malicious actors can impersonate the true server, or degrade the Transport Layer Security(TLS) protocol to surreptitiously monitor traffic.

What happens when CA’s are subverted, or otherwise issue malicious certificates? A prime example is the case of Dutch CA Diginotar. In August of 2011, someone penetrated Diginotar’s security and issued at least 500 fraudulent certificates in their name. According to security company F-Secure, these fraudulent certificates were most likely used to impersonate popular websites visited by Iranians through Man In The Middle Attacks(MITM) and identify Iranians critical of their government.

This was not an isloated incident, nor the first time this had happened. In January of 2013 CA Turktrust admitted to having accidentally issued two intermediate certificates in 2011, which allowed the recipients to issue further certificates in Turktrust’s name.

Also in March of 2011 CA Comodo was breached and nine fraudulent certificates were issued. Luckily in this case the breach was noticed almost immediately and the certificates revoked before they could be used.

Because of these incidents and the continued reliance on CAs as trust gatekeepers, it’s clear we need a means to identify these kinds of attacks in the future. It’s also clear that relying on a large set of CA’s which are hardcoded into our browsers is probably not the best way to ensure our security.

The Internet community’s response to these kinds of attacks has taken one form in the IETF working group on Public Notary Transparency. This working group’s first deliverable was RFC 6962, which describes the Certificate Transparency protocol. Certificate Transparency is a method for, “publicly logging the existence of Transport Layer Security(TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority(CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves.” In addition to the IETF working group, is a great place to learn about Certificate Transparency.

RFC 6962 describes a public log which can be appended to, but not otherwise modified. This public log can then be inspected by anyone. The idea is that by having a public distributed log of every certificate ever issued, breakins and malicious behavior such as what occurred at Diginotar, Turktrust, and Comodo can be caught by auditors before it causes too much damage. There is no requirement for CAs to append their issued certificates to this public log. Well acting CAs have it in their interest to eventually all use it, since CAs using the public log will be inherently more trusted than those which do not.

In addition to describing the public append only distributed log system. Certificate Transparency also defines two other components, monitors and auditors. Monitors are servers that periodically check the public log for suspicious behavior. They can be run by anyone, and will probably use heuristics, or algorithmic classifiers to discover bad behavior. Think of methods that credit card companies use to detect misuse of credit cards, although with hopefully fewer false positives. Certificate Transparency also defines auditors. Auditors are responsible for verifying the cryptographic integrity of the public distributed log, and verifying that specific certificates appear in the logs. Monitors and auditors may end up having much functionality cross over, but RFC 6962 defines them as separate components.

Now that you’re an expert on TLS Certificate Transparency, let’s talk about DNS-Based Authentication of Named Entities, or DANE. DANE is another answer to this type of threat. DANE is a way for computers to verify the TLS certificates presented by the servers they connect to are the correct certificates. It uses DNSSEC to host a hash of the correct TLS certificate, which is then signed with DNSSEC to ensure its authenticity. Operators of a server or website publish a hash of their TLS certificate in DNS, then cryptographically sign it using DNSSEC. When a client connects to said server, they can test the certificate proposed by the server against the signed hash stored in DNS. This mitigates MITM attacks since the attacker must also control DNS. DANE is described in RFC 6698.

This is not just about web browsers and user facing software, the problem space also extends to humanless computer-to-computer communications. We’ve written about how DANE makes it easier for operators to deploy STARTTLS for things like the Simple Mail Transfer Protocol(SMTP). That’s really just the start. There’s no reason why DANE cannot be used for any protocol which implements STARTTLS; such as NNTP, or IMAP/POP3, XMPP, FTP, and LDAP.

Both Certificate Transparency and DANE remove a reliance on the trustworthiness of CAs. Certificate Transparency does so by logging all TLS certificates issued by CAs, and then subsequently auditing them. Whereas DANE does so by allowing operators to sign their own TLS certificate using DNSSEC. DANE even allows for operators to create their own TLS certificates, without requiring a CA to issue it at all. Both protocols remove a need to trust CAs implicitly, and will hopefully allow us to move away from a world in which CAs remain hard coded in web browsers. The more we push decisions concerning trust out towards the edges of the network, the better off we’ll all be.

Both Certificate Transparency and DANE are relatively new, and barely deployed. However, one can imagine a future in which CAs have entirely ceased being the trust-anchors that they currently are. Instead replaced with both a massively distributed logging mechanism, and the hierarchical system of trust built upon DNSSEC. We’re getting there. With deployments of DNSSEC increasing, authenticating remote TLS certificates via DANE is becoming more feasible every day.

If you would like to learn more about Certificate Transparency, please visit If you would like to learn more about DANE, please visit our resource page on DANE. If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have a Certificate Transparency, DANE, or DNSSEC case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!

Deploy360 Securing Border Gateway Protocol (BGP) To archive

Video: Selective Blackholing at RIPE 68

Securing BGP

Until such time as we succeed in preventing IP spoofing in the Internet, Distributed Denial of Service(DDOS) attacks are going to be a problem. Job Snijders, gave a presentation at RIPE 68 detailing some work he has been doing on implementing selective blackholing for operators under DDOS attacks.

His selective blackholing configuration and associated scripting is meant to be applied when under a sustained DDOS attack, not during general operation. It essentially gives operators who provide transit services to one or more customers the ability to selectively blackhole traffic based on geographical determinants.

The example given in the presentation is of a customer under sustained DDOS attack who is able to blackhole all traffic coming from more than 1,000km away. This can be effective when that customer knows the only people visiting their website are within their own geograhpic proximity.


The presentation video is available on the RIPE 68 website along with the associated slides. Job has also written a lengthy email explaining in more detail how to implement selective blackholing.

When you’re finished viewing the presentation check out our Securing BGP and Anti-spoofing pages for more information on securing the Internet’s routing protocol.

Deploy360 Domain Name System Security Extensions (DNSSEC) IPv6

OpenWRT and Open Wireless: Bringing IPv6 and DNSSEC to End Users


Interesting things are happening in the home router space. On July 14th, the OpenWRT project released a new version of their software. Called “Barrier Breaker”, or 14.07-rc1, this is the first open router firmware release aimed at home users to support DNSSEC and IPv6 out of the box. This means that Barrier Breaker will perform DNSSEC validation when acting as your recursive DNS server. For IPv6, OpenWRT had previously required manual configuration of IPv6. This had the downside of requiring users of OpenWRT to understand a bit about IPv6. With Barrier Breaker, OpenWRT now supports DHCPv6 and Stateless Address Autoconfiguration(SLAAC). Both of which make it easier for end users to get an IPv6 address quickly and easily.

Imagine an end-user who knows nothing about IPv6, but their ISP happens to issue IPv6 addresses to its customers. They install the latest OpenWRT release, or purchase another device with IPv6 enabled. They receive an IPv6 and an IPv4 address, and since they already have an operating system that supports IPv6 out of the box, they’re now using IPv6. No knowledge or configuration was required on their part. The applications on their machine are hopefully concerned about keeping their eye-balls happy and the packets flowing. This is how deployments happen, this is how we upgrade the Internet.


Another interesting development in the home router space is the Electronic Frontier Foundation(EFF)’s launching of its own home router project. Called Open Wireless, their router firmware is “specifically designed to support secure, shareable Open Wireless networks.” The EFF’s project is based on the CeroWRT project, which is itself based on the OpenWRT project. While probably more focused on launching open access points and general user security, this effort will undoubtably bring DNSSEC and IPv6 functionality to many more users.

The release of OpenWRT Barrier Breaker, and the EFF’s launching of the Open Wireless project mark important milestones in the deployment of DNSSEC and IPv6. If you would like to contribute to OpenWRT, or to the EFF’s Open Wireless project, they’re both looking for volunteers. If you would like to find out more about DNSSEC or IPv6, please visit our basics pages on DNSSEC or IPv6 – or visit our Start Here page to find resources targeted at your type of organization.

Deploy360 Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

Anti-Spoofing, BCP 38, and the Tragedy of the Commons

Anti-SpoofingIn the seminal 1968 paper “The Tragedy of the Commons” , Garrett Hardin introduced the world to an idea which eventually grew into a household phrase. In this blog article I will explore whether Hardin’s tragedy applies to anti-spoofing and Distributed Denial of Service (DDoS) attacks in the Internet, or not.

The Tragedy of the Commons
Hardin was a biologist and ecologist by trade, so he explains “The Tragedy of the Commons” using a field, cattle and herdsmen. To paraphrase by example, imagine a field being used by a group of herdsmen to graze their cattle.

The field is already at its carrying capacity, so if any new cattle are added each cow receives less to eat. The tragedy of the commons strikes when one herdsman adds another cow to the field. This herdsman receives the benefit of an increased cow he can bring to market. All of his cows might be a little skinnier since every cow now has less to eat, but his extra cow more than offsets this loss. Not so for the other herdsmen, all of their cows now receive less food, and they have no extra cow to make up for this loss.

This is the tragedy of the commons in simple terms. An action by one actor results in a substantial gain for that actor and a small loss for everyone else. Now let’s think about DDOS attacks, our new anti-spoofing initiative, and the many attempts to get network operators to install filters which prevent IP address source spoofing.

Imagine if almost every network operator installed filters to prevent IP address spoofing ala BCP 38. A network operator who has not yet installed filters has a decision to make not unlike the decision Hardin’s herdsman made. It costs money to install filters, albeit a very small amount, but it is not free. Nor is the labour capable of installing those filters cheap. Therefore it makes economic sense for this network operator to not install filters. No one is DDOSing their network, that’s someone else’s problem. This network operator can save money by not installing filters, and realize none of the loss associated with DDOS attacks.

No Tragedy Here
I have heard this argument made before as a reason why anti-spoofing initiatives have trouble gaining traction. However, this argument starts to break down when we investigate the real costs of DDOS attacks, the real costs associated of installing filters to stop spoofing, and basic network management principles.

Bandwidth is not free. Operators whose network is being used to generate DDOS attacks are paying someone for those packets to egress their network. And unless their customer base consists of people who buy service from them strictly so they can generate DDOS attacks, not a good business plan IMHO, they receive no utility from these DDOS packets egressing their network.

The cost of installing filters to mitigate IP address source spoofing is minimal and continues to decrease. There may have been an argument ten years ago that buying equipment to support mass filtering by IP source address was cost prohibitive. If that argument was once viable, it certainly no longer is. Any carrier grade BGP router can support many more Access Control Lists(ACLs) than are actually needed to support implementation of BCP 38.

What network operator wants malicious traffic on their network? I’ve talked with hundreds of network operators from around the world in virtually every industry. Never have I met a network operator who wants more malicious traffic on their network, even if they are simply transporting that malicious traffic. Maybe they exist and I just haven’t met them, or maybe network operators as a class recognize that malicious traffic, whether bound for them or not, is bad for business. If only because it attracts more bad actors.

No Tragedy Here Either
It was pointed out to me by Jan Žorž that many operators use their older, leftover, networking equipment in places where filtering is required. This older networking equipment may be limited in its filtering ability and not manage well when attempting to block large amounts of traffic. This is a valid point for operators concerned about their capital equipment expenditures, since buying new equipment is a very real cost. However, as this older equipment gradually dies and gets replaced this problem will become moot. This is a problem now, but will eventually phase out.

Another valid argument of anti-spoofing efforts as a tragedy of the commons is the cost associated with training personnel, and maintaining large lists of filters. This is a valid concern and a definite cost. It’s why we are launching an initiative to provide information on deploying anti-spoofing. We reduce these operational costs by educating operators and providing them with the information they need to implement BCP 38.

New technologies such as Source Address Validation Improvements(SAVI) are also taking the difficulty out of anti-spoofing implementations. For a high level overview of SAVI read this article by Andrei Robachevsky, or read the main SAVI specification, RFC 7039.

While it might be tempting to view the Internet as a commons and DDOS as its tragedy, the comparison doesn’t hold up once operator incentives are understood. If the cost of applying filters were increasing, bandwidth was free, and transiting malicious traffic was benign, we may well find that rational acting operators benefit from not addressing IP source address spoofing. Fortunately for the Internet, this is not the case. It is in everyone’s interest, even selfish operators, to implement anti-spoofing filters. If not for the Internet’s benefit, than for their own.

I am not the first person to make this argument, that honour perhaps going to Joao Luis Silva Damas in this RIPE-NCC document from 2008. Joao describes the business case for filtering quite clearly in self-interested terms similar to those I use in this post.

This post is not meant to trivialize the collective benefits of implementing BCP 38. There has recently been some great work on the Routing Resilience Manifesto for, “Collective Responsibility and Collaboration for Routing Resilience and Security”. The Routing Resilience Manifesto is an attempt to codify some of the shared values of network operators into a set of definitions and ideal behaviors. The Routing Resilience Manifesto is very much a work in progress and is always seeking comment. If you would like to contribute to it please visit them or mail them directly.

UPDATE: Since the time this article was written in 2014, the “Routing Resilience Manifesto” became theMutually Agreed Norms for Routing Security (MANRS)and has now been signed by over 45 ISPs from around the world. We ask anyone working for an ISP or enterprise to view the MANRS document and sign on!

If you’re interested in becoming more involved in the anti-spoofing or BCP 38 conversation , consider  getting involved with the Routing Resilience Manifesto, joining the IETF SAVI working group, or visit our recently launched Anti-Spoofing Start Page.

Deploy360 Securing Border Gateway Protocol (BGP)

Video: BGP Blackholing Project (RIPE 68)

How can network operators cooperate to prevent abuse? How do we educate network operators to ensure they’re connecting their network in a secure way to the Internet? In this lightning talk from Lukasz Bromirski from Cisco, learn how operators in Poland are cooperating to prevent network abuse. Lukasz’s talk, entitled “BGP Blackholing Project” is now available for viewing from the RIPE 68 site, and the slides are available for download.


After watching, check out our page on BGPSEC to learn more about securing BGP.

Deploy360 Securing Border Gateway Protocol (BGP) To archive

Video: RPKI For Provider Independant Resources (RIPE 68)

How can provider independent(PI) address space be validated with the Resource Public Key Infrastructure (RPKI)? How can we get smaller organizations to deploy BGP RPKI? In this lightning talk from Alex Band of RIPE-NCC, learn how an organization with PI address space registered with RIPE-NCC can easily create and access RPKI resources. Previously this was only available to those registered with RIPE-NCC as local Internet registries(LIRs). Alex’s talk, entitled “RPKI for Provider Independent resources” is now available for viewing from the RIPE 68 site, and the slides are available for download.


After watching, check out our page on BGPSEC to learn more about deploying BGPSEC and RPKI.

Deploy360 To archive

Video: DANEs Don’t Lie – DANE/SMTP (RIPE 68)

How can we secure communications between SMTP mail servers? Simply using TLS between servers will not prevent Man In The Middle(MITM) attacks. DNSSEC and DANE to the rescue! Using DANE, SMTP servers can validate X.509 certificates tied to TLS using DNSSEC lookups. In this lightning talk from Carsten Strotmann, learn how this all works and the current status of implementations. His talk, entitled “DANEs don’t lie – DANE/SMTP” is now available for viewing from the RIPE 68 site, and the slides are available for download.


After watching, check out our resources on DNSSEC and DANE.

Deploy360 Securing Border Gateway Protocol (BGP) To archive

Video: Google DNS Hijacking in Turkey (RIPE 68)

Between March 29 and April 7 of 2014, the Turkish government announced a /32 BGP route for Google’s public DNS. This route redirected users to a DNS server which resolved popular addresses such as and to Turkish government websites. We previously wrote about this while it was happening. Now Stéphane Bortzmeyer’s talk, entitled “Google DNS Hijacking in Turkey” provides a technical understanding of how the Turkish Government accomplished this, and how he was able to prove it. His talk is now available for viewing from the RIPE 68 site. His slides are also available for viewing.


When you’re done watching the video, check out our resources on DNSSEC and how you can deploy it for zones your organization manages. While DNSSEC would not have prevented this hijack from occurring, it could have possibly detected this hijack for end users.