This post was co-authored by Peter Thomassen.
The adoption of Domain Name System Security Extensions (DNSSEC), while steadily rising, is still low after 20 years, at least in terms of secure delegation rates. In the past, DNSSEC scepticism was arguably caused by overly complex implementations and breakage-prone maintenance processes.
But by now, however, tooling has massively improved, making the DNSSEC experience much smoother than before. However, DNSSEC validation and secure delegation rates have maintained their inching growth, reaching 36% and 7% respectively in 2025.
So what? Why care about DNSSEC adoption anyway? It isn’t the first thing to fail despite great expectations, and it sure won’t be the last.
Well, we should care. Because it’s not about DNSSEC in itself. It’s about fencing off real threats to data authenticity and integrity (like DNS spoofing, BGP hijacking, and so on) and, in doing so, raising Internet security on a larger scale. So, we’d better get interested in the shape of DNSSEC’s adoption curve, and in the causes that keep it from being steeper.
Accessibility and usability challenges
The fact is, even when someone explicitly wants DNSSEC switched on, it doesn’t mean they will succeed. Multi-step and multi-channel processes, terms of art, and a broad variance of user interface design across DNS actors throw all kinds of obstacles in the inclined user’s way. And what is true for an initial DNSSEC setup is also true for key rollovers: Procedures are manual, complicated (partly due to multi-provider setups), error-prone, and support-intensive. Breakage is only just a step away.
The resemblance to the pre-automation certificate world is striking.
Automation is the answer
So, how about emulating Let’s Encrypt? What if we designed reliable automation of DS record provisioning, making all the trouble go away, and keeping humans out of the loop once they have expressed their wish to have DNSSEC switched on (or off)?
If that sounds like a pipe dream to you, you’ll be surprised to hear that DNSSEC automation already exists — not only in RFCs, but in successful operational practice as well.
And here’s how it works: Authenticated CDS or CDNSKEY records in the child zone indicate the desired DS records that should be provisioned in the parent zone.
- For updates, apply the ‘old signs new’ principle (RFC 7344).
- For initialization, use the provider’s existing chain of trust (RFC 9615).
- For improved efficiency, instead of routine across-the-board scanning by the parent, allow the child to nudge the parent (RFC 9859).
Presently, there are several successful parent-side implementations in ccTLDs (like .ch, .cr, .cz, .li, .se, .uz, .za, and others, most of them in Europe, in economies with high validation and secure delegation rates). And while these ccTLDs have made different implementation choices regarding validity checks, locks, and so on, all implementations have one big thing in common — they work!
Guidelines for the gTLD space
Yet, while each of these implementations is running successfully, it’s the small differences in handling of details across implementing ccTLDs that are currently blocking the deployment of DNSSEC automation for gTLDs.
gTLDs cannot use DNSSEC automation without the approval of the Internet Corporation for Names and Numbers (ICANN).
That is a big deal, as .com alone totals 159.4 million domains, comprising 42% of all domains worldwide. With regard to DNS security, this amounts to a lose-lose situation. If DNSSEC automation makes DNSSEC more accessible and widely deployable, but a substantial part of domains cannot deploy it, then DNSSEC adoption will not improve to substantial numbers.
But because of this reciprocity, the situation can become a win-win situation the moment ICANN approves DNSSEC automation for gTLDs (some of which have clearly manifested their wish to deploy it). The DNS community is well aware of that.
For context, part of ICANN’s mission is to secure interoperability for the gTLD space. Technical innovations at the registry level must get approved for use by the ICANN community.
The Security and Stability Advisory Committee (SSAC) report SAC 126 has made a first step towards admitting DNSSEC automation into the gTLD arena. The report identified operational issues in need of clarification and guidance in order to maximize interoperability and minimize surprise in new deployments.
In response to this call for clarification, the Internet Engineering Task Force (IETF) Domain Name System Operations (DNSOP) Working Group has been developing a guideline draft. They’ve been circulating it widely among the parties involved (DNS operators, registrars, and registries) for both awareness and feedback. The Working Group intends to craft a set of consensual, real-life-compatible and reliable deployment guidelines.
Over the next few months, these guidelines are expected to be published as an RFC. They cover the problem space in four different topic areas. Here’s what they say.
Acceptance checks and safety measures
As the DS record links the child domain’s DNSSEC signing key into the chain of trust used for validation, DS configuration mistakes will quickly lead to validation failures. Therefore, when a parent operator (such as a registry) can foresee that a requested DS record update would cause such failures, the guidelines recommend not applying that flawed update. This entails a double check that:
CDSandCDNSKEYinformation are consistent both with each other and across all nameservers of the child domain.- DNSSEC validation will still work if the update is applied.
In addition, the document recommends that DS records should receive a short Time to Live (TTL, between 5 and 15 minutes) whenever a change is applied, and return to regular TTL values a few days later. As the resolver-side caching of DS records is capped by the TTL, this helps to quickly undo any DS record changes when the domain owner determines that the applied update isn’t working as intended.
This would eliminate the scenario where domains could be down for the regular TTL duration, which has been preventing risk-averse domain operators from enabling DNSSEC.
Reporting and transparency
When DS records are installed for the first time, changed, or removed, you may ask whether someone should be notified about this — and if so, who? The guidelines recommend notifying the domain’s technical contact when DNSSEC is turned on or off, but not for routine maintenance operations like changing a key. This communication can happen through whatever means the registry usually uses to interact with its customers. In addition, customers should have visibility into the current DS configuration through their usual management interface.
When there are technical issues (such as an update being rejected, see above), the parent operator should first contact the child’s DNS operator, and only involve humans once the problem persists for a longer time. Also, notifications should not be repeated too frequently.
Lastly, DS automation can be performed either by the registrar (who forwards updates to the registry) or directly by the registry. In the latter case, it is recommended to keep the registrar in the loop when applying a DS record update, for example, by using the Extensible Provisioning Protocol (EPP) Change Poll extension, RFC 8590.
Registration locks
You may wonder whether locks on the domain registration, such as an EPP update lock, should prevent DS automation. However, these locks are intended to prevent accidental or malicious change, not routine DNSSEC maintenance, which comes with strong authentication. For a more detailed analysis of different types of locks, please refer to the rationale section in the guidelines document.
Multiple submitting parties
The last question is what should happen if the registry or registrar performs DS automation, but additional DS record updates are requested at (almost) the same time. This could happen if the domain owner manually changes the DS configuration (which should always be possible), and this update occurs shortly before or after an automatically applied update. This could also happen when the registry and registrar are not aware that the other party is performing DS automation, in which case they both may end up applying automated updates.
Working through all the different scenarios, it turns out that it’s best to not second-guess any particular update request but simply always apply the update according to the request received most recently, as long as its legitimacy can be verified. In the case of a manual update, this would usually be through a web form log-in. In case of automated updates, this is ensured by the fact that new CDS and CDNSKEY update requests have to be signed with a key pertaining to the trust chain already in place before the update (‘old signs new’).
For a detailed look at the various edge cases, please refer to the analysis section in the guidelines document itself. In any case, it turns out that race conditions are not a problem in practice.
A new hope
Despite a saddening history of actual breakages and bad publicity, DNSSEC is a good thing for DNS security and should be easily available to anyone wishing to have it. After automation has made DNSSEC smooth and accessible, the guidelines in the best-practice document will be pivotal for ICANN’s crucial approval to deploy DNSSEC automation in the gTLD space. This could be a game-changer for DNS security as a whole.
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.