DNSSEC Deployment Today

The Domain Name System Security Extensions (DNSSEC) is a suite of IETF developed specifications designed to validate information provided by the Domain Name System (DNS).

A number of early adopters deployed DNSSEC for the domain they are responsible for. Among these early adopters were the country code Top Level Domains (ccTLDs) .br, .bg, .cz, .pr, .se and the generic Top Level Domain (gTLD) .org. Besides TLD operators, organisations like the RIPE NCC and the RIPE community as a whole were on the forefront of DNSSEC development. The RIPE NCC has signed it’s DNS zones since 2005. However, many TLD operators waited for the root zone to be signed before they started deploying DNSSEC.

When the root zone has been signed in June 2010, this acted as a catalyst for TLD operators to deploy DNSSEC on their side. We have seen a gradual but significant increase in signed TLDs since then.

The maps below show the level of DNSSEC deployment in the world to date. Those countries marked green have deployed DNSSEC in their ccTLD today. Those marked yellow have plans to deploy it in the near future.

Figure 1: DNSSEC in European ccTLDs (green=deployed, yellow=planning to deploy)

Figure 2: DNSSEC Deployment in North America

Figure 3: DNSSEC Deployment in South America

Figure 4: DNSSEC Deployment in Asia Pacific

Figure 5: DNSSEC Deployment in Africa

As far as we are informed, no countries in the Middle East are currently planning to deploy DNSSEC. If you have other information, please let us know so that we can update the article.

At the core of DNSSEC is a so called chain-of-trust which uses the hierarchy by which a domain is delegated from the root zone to a TLD and then to the domain operator. For DNSSEC to be fully useful, this chain of trust needs to be complete. This means that for a domain owner DNSSEC becomes truly useful once the TLD that domain is under is signed, too.

The RIPE NCC is maintaining zones in domains under several TLDs. The vast majority of the zones under these TLDs are by now supporting DNSSEC, because the parent zones allow delegation signer (DS) records to be included and therefore completing the chain of trust. Recently we also enabled the IPv4 reverse zones in the in-addr.arpa parent zone.

Figure 6: Zones with (blue) and without DNSSEC

As shown on the right hand side of Figure 2 above, the only zones in which we cannot yet include the trust anchors in the parent zone, are:

• 203.in-addr.arpa (maintained by APNIC)
• 196.in-addr.arpa (maintained by AfriNIC)
• 6.0.1.0.0.2.ip6.arpa (maintained by SurfNET)
• .int (maintained by IANA)
• .cc (ccTLD of the Cocos (Keeling) Islands)

We expect that at the end of this year, only three of them will be left in which we cannot include our DS records: 196.in-addr.arpa, .int and .cc. That is considered a huge progress since the root zone has been signed.

Below you can see a graph showing DS records inside our reverse zones. We observe a steady increase. In total there are currently 450 DS records in our zones.

Figure 7: Number of DS records in RIPE NCC maintained reverse zones over time

Considering that the RIPE NCC maintains some 500.000 reverse delegations, this number is still very small. However, the recent increase is encouraging.

From our point of view we are pleased with the progress that DNSSEC has made since the root zone has been signed a year ago. There has been a lot of speculation, and in a poll done amongst many industry experts very few expected that signing the root zone would have such a substantial and fast impact on the number of TLDs getting signed.