When securing a DNS zone with Domain Name System Security Extensions (DNSSEC) for the first time, it is the parent zone operator’s task to extend their DNSSEC chain of trust by signing and publishing delegation signer (DS) records. These records, placed in the parent zone alongside the domain’s conventional NS records, are computed from the hashes of the zone’s DNSSEC public keys.
Bootstrapping a DNSSEC delegation therefore requires that the parent has authenticated knowledge of these parameters. However, no standard for authenticated sharing of these parameters has emerged so far. This lack of protocol is a major obstacle for the widespread adoption of DNSSEC.
The state of DNSSEC deployment
At deSEC, our managed DNS hosting platform, we can easily see this in our data. We sign all our zones and try to make the process of enabling DNSSEC as easy as possible for domain owners (for example, by proactively showing DNSSEC parameters and a step-by-step tutorial upon zone creation). Still, of all domains delegated to us, we find that the securely delegated fraction is only around 50%.
This is despite the fact that all our zones are signed, and users are actively invited to take action. In this light, it seems likely that numbers are significantly lower for providers where DNSSEC settings are buried deep in the customer portal (as is often the case). But even so, it looks like 50% is some kind of magical barrier that can’t be crossed without further automation.
Looking more closely, we find that the secure delegation rates of some top-level domains (TLDs) stand out. These are the ones that chose to use an automated (albeit unauthenticated) method for DNSSEC provisioning. The method, dubbed ‘CDS/CDNSKEY from insecure’ and specified in RFC 8078, requires DNS operators to equip their customers’ zones with special CDS/CDNSKEY records. These auxiliary records can be queried by the parent and carry the information required for constructing the parent-side DS records. While the number of TLDs implementing this feature is small, deSEC’s statistics firmly show that secure delegation rates for TLDs such as .ch, .cz, .li and .se are close to 100%.
Given these findings, it is very clear that automation is the proper way to advance the number of secure delegations.
Existing approaches to DNSSEC bootstrapping
The above analysis raises questions like: If the CDS/CDNSKEY method from RFC 8078 is unauthenticated, what other methods do exist for bootstrapping DNSSEC? What are their downsides? Are they practical enough? Is there a solution that addresses all concerns?
Indeed, there are several methods for conveying DS information to the parent (see diagram). Unfortunately, they all suffer either from lack of authentication or from insufficient fitness for automation. Existing authenticated approaches generally rely on out-of-band communication and often require the domain owner to interfere manually — a non-trivial task for the average domain owner (who will only in rare cases have any kind of affinity for this process), and certainly not an approach that scales well.
As a result, existing methods are generally either slow, error-prone, or unauthenticated. To get at least some automation, some deployments today use unauthenticated ‘CDS/CDNSKEY from insecure’ and try mitigating the lack of authentication, for example, by observing these auxiliary records for a few days and from several vantage points. While that helps a bit, it’s an unsatisfactory kludge and does not quite fulfill the criteria one would expect from a seamless, automated, and secure solution.
Solving the DNSSEC bootstrapping problem
We propose to solve this problem by extending the unauthenticated CDS/CDNSKEY solution with in-band authentication.
For illustration, let’s say we want to turn on DNSSEC for the domain example.com. We assume that this zone is hosted on nameservers ns1.provider.net and ns2.provider.org, and that the DNS operator has already set up (unauthenticated) CDS/CDNSKEY records under example.com, as described above.
Here’s how to complete the bootstrapping process with in-band authentication:
- As a precondition, we require the DNS operator to use DNSSEC on its own infrastructure domains, ns1.provider.net and ns2.provider.org.
This establishes a chain-of-trust from the root to the DNS operator. As a result, any information published in the DNS below these names can be validated.
- The DNS operator co-publishes the CDS/CDNSKEY records of example.com under a corresponding subdomain of each of its nameserver hostnames, namely: example.com._dsauth.ns1.provider.net and example.com._dsauth.ns2.provider.org.
Publishing these records in the DNS subtrees under ns1.provider.net and ns2.provider.org means that this information is endorsed by the DNS operator and signed with the operator’s private key(s). This fact can be publicly validated using standard DNSSEC validation, because the DNS operator has established a DNSSEC chain of trust for their own infrastructure domains (see Step 1).
- Finally, the parent (registry or registrar) queries these CDS/CDNSKEY records from example.com._dsauth.ns1.provider.net and example.com._dsauth.ns2.provider.org. After validating the responses, the parent has authenticated knowledge of the domain’s DNSSEC parameters and can publish corresponding DS records. As a result, the delegation is secured. ✅
Note: Step 3 does not depend on any additional prerequisites; the parent can construct the bootstrapping query from the nameserver hostnames. This knowledge is used to retrieve the domain’s DNSSEC parameters directly from the DNS operator, via the pre-existing chain of trust.
Figure 2 illustrates how the CDS/CDNSKEY records published at example.com (dashed arrow) are compared against the ones co-published below at a subdomain of the nameserver’s hostname (yellow arrow), where the existing chain of trust (left-hand side) can be used for validation. The parent then uses this validated information to create DS records for the delegation (solid blue arrow).
As the target domain’s chain of trust (DS record set) is created by means of the DNS operator’s preexisting chain of trust, the method can be described as ‘transferring trust from the DNS operator to the child’.
For the technical details of the protocol, see this Internet Draft.
Conclusion
The process of securing a DNS delegation traditionally has suffered from a catch-22 situation where automation is desired, but no trustworthy channel for communicating the sensitive DNSSEC parameters is yet in place. Over the past 15 years, this has led to various methods for signalling the required information to the parent, typically through authenticated out-of-band mechanisms (often involving the domain registrant), or via an unauthenticated in-band mechanism. These methods generally are not suitable for secure, scalable, and automatic deployment of DNSSEC.
Our proposal leverages the fact that the DNS operator is in control of the infrastructure domains that are used as nameserver hostnames for delegation purposes. By activating DNSSEC on these infrastructure domains, DNS operators can put themselves into a position that allows them to publish authenticated information about their customers’ domains, placed at a subdomain to their nameserver hostnames (such as example.com._dsauth.ns1.provider.net).
Using this authenticated signaling mechanism, DNS operators can co-publish the CDS/CDNSKEY records of their customers’ domains in an authenticated fashion, allowing the parent (registry or registrar) to verify the authenticity of each domain’s DNSSEC parameters without the registrant’s involvement.
This allows automatic provisioning of DS records for delegations that were so far insecure, by removing security concerns about unauthenticated DS record information. As the method is scalable and simple to deploy, it has the potential to significantly boost the number of secure delegations in the DNS. Experimental implementations by DNS operators, ccTLDs and registrars are currently underway.
Nils is Ph.D. Candidate at Technische Universität Berlin, Germany. His research interests include the security of the DNS. Beyond academia, he’s a founder and core developer of the not-for-profit deSEC.io DNS hosting service, which aims to provides secure DNS for everyone.
Peter Thomassen contributed to this work. His work is funded by SSE – Secure Systems Engineering. Nils Wisiol is supported by Technische Universität Berlin.
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.