DNS Security Extensions (DNSSEC) were originally introduced in 1997 to address the security limitations of the original DNS protocol.
In a nutshell, DNSSEC provides authenticity of DNS records by leveraging a public key infrastructure (PKI). To do so, each domain maintains a private and public key pair. Each DNS record served is then signed with the private key, with the signature published in a resource record digital signature (RRSIG) record. As a result, a client can confirm the authenticity of the received record by checking this RRSIG against the domain’s public key (published in a separate DNSKEY record).
However, how can a resolver be sure that a received DNSKEY is authentic?
DNSSEC accomplishes this by mirroring existing hierarchy of DNS: each DNSKEY must be signed by its parent zone. For example, the DNSKEY for example.com is signed by the parent, .com. To do so, each domain uploads a hashed version of their DNSKEY (called DS record) to the parent zone; the parent then publishes an RRSIG record for the DS record signed with the parent’s private key. This process repeats up until the DNS root zone, which has a well-known DNSKEY.
As a result, a client should be able to build a chain-of-trust for any DNSSEC-signed record: the root zone signs the top-level domain zone and the top-level domain zone signs the second level domain zone, and so on. Unfortunately, our recent study showed that DNSSEC deployment is still very low (only ~1% of .com, .net and .org domains deploy DNSSEC), and that over 30% of these domains are, in fact, misconfigured due to missing DS records.
In this post, we provide an overview of our follow-up work that attempts to better understand why so few domains successfully deploy DNSSEC and why so many domains that attempt to deploy DNSSEC fail to do so correctly.
Uploading DS records
Because we observe a high fraction of domains with DNSKEYs missing DS records, let us begin by examining the process for installing a DS record. Uploading a DS record to the parent zone means that it needs to be passed to the registry. However, domain owners are not allowed to directly access the registry: only a registrar —an organization certified by ICANN to sell domains to the public—has an authority to access the registry. In other words, if a domain supports DNSSEC, its registrar must provide not only the NS record set (the identity of the authoritative nameservers of the domain name) but also the DS record set to the registry.
Hence, no matter who manages the authoritative nameserver of a domain or generates a DS record, the DS record must be conveyed to the registrar; if a domain’s authoritative nameserver is managed by the registrar, the registrar can simply upload the DS record by directly accessing the registry.
However, if a domain owner or the third party manages the nameserver, the situation is more complicated because the domain owner must somehow convey the DS record to the registrar. As a consequence, if a registrar does not support any methods for customers to upload DS records, the domain cannot support DNSSEC as the domain owner has no way of installing a DS record.
| Registrar (Domain of Auth. Nameservers) | Domains (All) | Domains (With DNSKEY) | DNSSEC Support (Registrar) | DNSSEC Support (Owner) |
| GoDaddy (domaincontrol.com) | 37,652,477 | 8,139 | 🔴 | 🔴 |
| Alibaba (hichina.com) | 4,292,138 | 3 | ❌ | ❌ |
| 1AND1 (1and1) | 3,802,824 | 0 | ❌ | ❌ |
| Network Solution (worldnic.com) | 2,534,673 | 0 | ❌ | ❌ |
| eNom (name-services.com) | 2,525,828 | 10 | ❌ | 🔴 |
| Bluehost (bluehost.com) | 2,066,503 | 0 | ❌ | ❌ |
| NameCheap (registrar-servers.com) | 1,963,717 | 13,232 | 🔺 | 🔴 |
| WIX (wixdns.net) | 1,887,139 | 0 | ❌ | ❌ |
| HostGator (hostgator.com) | 1,849,735 | 0 | ❌ | 🔴 |
| NameBright (namebrightdns.com) | 1,823,823 | 0 | ❌ | 🔴 |
| register.com (register.com) | 1,311,969 | 0 | ❌ | ❌ |
| OVH (ovh.net) | 1,228,578 | 319,580 | 🔴 | 🔴 |
| DreamHost (dreamhost.com) | 1,117,902 | 0 | ❌ | 🔴 |
| WordPress (wordpress.com) | 888,174 | 3 | ❌ | ❌ |
| Amazon (aws-dns) | 865,065 | 0 | ❌ | 🔴 |
| Xinnet (xincache.com) | 836,293 | 0 | ❌ | ❌ |
| Google (googledomains.com) | 813,945 | 1,945 | ❌ | 🔴 |
| 123-reg (123-reg.co.uk) | 720,435 | 1 | ❌ | 🔴 |
| Yahoo (yahoo.com) | 690,823 | 0 | ❌ | ❌ |
| Rightside (name.com) | 663,616 | 0 | ❌ | 🔴 |
Which registrars support DNSSEC?
A common criticism of DNSSEC is that it has been rarely deployed. To understand why it has not been deployed very well, we need to see how the most popular DNS registrars support DNSSEC. To do so, we registered domains ourselves and attempted to deploy DNSSEC by focusing on the most popular 20 DNS operators (i.e., those that serve as the authoritative nameserver for the largest number of domains). Collectively, these registrars cover 54.3% of .com, .net and .org domains.
Table 1 summarizes the results of our experiment. We found that only three registrars support DNSSEC when the registrar is the DNS operator. Thus, customers that purchase domains from the other 17 registrars are not able to deploy DNSSEC on their domains if they use the registrars’ nameservers.
However, we found that 11 registrars do support DNSSEC for external nameservers by allowing customers to upload a DS record through web-based forms or email; this implies that eight registrars support DNSSEC only if a user uses an external nameserver.
Finally, we found that the other popular nine registrars do not support DNSSEC for their nameservers nor external nameservers, which means that it is impossible for customers who purchase a domain from them to deploy DNSSEC.
Encouraging DNSSEC adoption
Having validated that DNSSEC adoption is low among registrars we started to look at ways that various DNS entities (registries, registrars and third-party operators) may be encouraged to deploy DNSSEC.
These included financial incentives, free DNSSEC for customers and support for the CDS/CDNSKEY protocol, as we describe in more detail below.
Registries: Financial incentives
One potential way that registries could incentivize greater DNSSEC deployment is by providing discounts for domains that properly support DNSSEC.
For example, Dutch registrars receive a €0.28 (USD 0.30) discount every year for a .nl domain if it is correctly DNSSEC signed and Swedish registrars used to receive a 10 SEK (USD 1.10) discount every year for a correctly-signed .se domain.
Figure 1 shows how these incentive mechanisms worked for two registrars: KPN (a Dutch registrar) and Loopia (a Swedish registrar). Interestingly, we found that Loopia only supports DNSSEC for .se domains and KPN only does so for .nl domains. These registrars publish DNSKEYs and RRSIGs across all domains, but only upload DS records for .se and .nl domains (respectively). Clearly, the registrars have the capability to upload DS records, but only do so by default for domains where there is a financial incentive; this suggests that financial gain plays a significant role for encouraging DNSSEC support.
Figure 1: The percentage of fully deployed DNSSEC domains for Loopia and KPN. Each registrar supports DNSSEC only in their own country’s domain (.se and .nl, respectively). Note that the measurement of .nl and .se started on 9 February, 2016 and 7 June, 2016 respectively.
Registrars: Free DNSSEC
Another way for registrars to spur greater adoption of DNSSEC is to provide DNSSEC for registrar-operated domains for free.
For example, both GoDaddy and OVH provide DNSSEC on their nameservers, but customers need to explicitly opt-in to deploy it. The difference is that GoDaddy provides DNSSEC as a premium package (at a cost of USD 35 per year), while OVH provides DNSSEC for free.
Figure 2 shows how these different pricing policies correlate with the deployment of DNSSEC. Surprisingly, we found that OVH’s overall DNSSEC adoption ratio is high (over 25%) and growing; this shows that customers are interested in deploying DNSSEC.
Unfortunately, GoDaddy’s fraction of DNSSEC-support domains is very small by comparison: only 0.02% of their domains have a DNSKEY and DS record.
This comparison underscores the crucial role that free support for DNSSEC can have in successfully deploying DNSSEC.
Figure 2: The percentage of all merged domains with DNSKEY and DS records for OVH (free DNSSEC with customer opt-in) GoDaddy (paid DNSSEC). OVH shows a much more robust deployment for DNSSEC.
Third-party DNS Operators: CDS and CDNSKEY
Customers who would like to deploy DNSSEC, but who use the third party-operated nameservers, face special challenges.
The third-party operators typically generate the DNSKEYs and DS record, but the customer is required to copy this record and provide it to the registrar (who then uploads it to the registry). This is because the third-party DNS operator doesn’t have the authority to convey the DS record to the registrar or registry. If the customer fails to properly convey the DS record, or if their registrar does not support DNSSEC, they will fail to properly deploy DNSSEC for their domain.
CloudFlare is one popular third-party DNS operators that does support DNSSEC. They initially announced support for DNSSEC on 11 November 2015, but the domain owners must opt-in to use DNSSEC and need to pass the DS record to their registrar by themselves to correctly deploy DNSSEC.
Figure 3 shows the number of Cloudflare-hosted domains with DNSKEYs (bottom) and the fraction of those that also have DS records (top). We can immediately see how this complex procedure leads to poor overall deployment of DNSSEC: the domains with DNSKEYs are rapidly increasing right after the announcement of universal DNSSEC, but even today, 40% of the domain owners who enabled DNSSEC at Cloudflare failed to upload their DS record to their registrar.
Figure 3: The percentage of Cloudflare-operated domains that enabled DNSSEC (bottom) and the percentage of these domains with DNSKEY that have a DS record as well (top). Roughly 40% of Cloudflare-operated domains that attempt to deploy DNSSEC fail to successfully do so.
To help remedy this situation, CloudFlare supports the CDS and CDNSKEY proposals, which would enable third-party DNS operators to convey the DS record to the registry themselves without any help from the registrar. These proposals will significantly reduce the friction that customers face when trying to deploy DS records, as they will be able to effectively communicate directly with the registry. However, this proposal has seen very slow uptake and we know of only one registry (.cz) that has deployed it and one registry (.ca) that is considering deploying it.
This work was done in collaboration with colleagues from Northeastern University, the University of Twente, the University of Maryland, and Duke University/Akamai Technologies and presented at IMC’17 and USENIX Security’17.
Taejoong Chung is a Postdoctoral Researcher in the College of Computer and Information Science at Northeastern University.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Actually OVH only supports DNSSEC if it’s them as the registrar, they do not support DNSSEC **at all** when it’s just them managing the Zone.
DNSSEC in the UK is a ghost town, no resources, no mention of it on any of the registrar sites…
Funny how goDaddy try to monetize from DNSSEC
The best registrar so far which supports many TLDs with DNSSEC is inwx.de .
Every other big player company should be ashamed, one of them is Google (Domains), which has a limited DNSSEC support. After the Transfer I got the message that .nl domains are not supported for DNSSEC.
Atleast Google supports WHOIS Privacy for .nl Domains compared to the others.
@Fatih K.
In addition to inwx.de there’s also CloudFlare and Zone.ee that support DNSSEC very well. Meaning you aren’t limited to only their name servers or their keys.