DNSSEC Operations in 2026 – What Keeps 16 TLDs Up at Night
Before building a successor to OpenDNSSEC, we asked 16 TLD operators what they needed. We expected tool talk—instead, we ended up discussing trust, continuity, and compliance.
Executive Summary
Before we wrote a single line of code for our new DNSSEC signing tool, we asked 16 TLD operators a simple question:
"What keeps you up at night?"
We expected the conversation to be about tooling. Instead, the answers went deeper — about trust, continuity, and compliance.
The key takeaways are clear:
- DNSSEC tooling is strategic infrastructure.
- Uptime is no longer enough: resilience, observability, and accountability are now baseline.
- Failure is inevitable. Recovery must be built-in.
This report turns real-world operator input into a picture of what operational excellence in DNSSEC now demands — and what the next phase of resilient signing must look like.
And that changed the course of our design from day one.
About This Research
Between March and June 2025, NLnet Labs conducted in-depth research with 16 TLD operators.
- 6 operators participated in detailed interviews on their operational practices.
- 16 operators provided survey input on requirements, expectations, and weak points.
Participants ranged from small ccTLDs to large global DNS authorities and infrastructure operators.
The research was commissioned by NLnet Labs' DNS team, with more than 25 years of experience in DNS tooling and operations. Our clients include big tech, hyperscalers and various European registries.
All findings in this report are grounded exclusively in operator feedback — not assumptions.
Respondent Overview
Who we spoke to.
| TLD Type | # Respondents | Zone Size Range |
|---|---|---|
| ccTLDs | 9 | 1M–10M domains |
| gTLDs | 4 | 10M+ domains |
| Other | 3 | Critical internal |
This spread illustrates the breadth and relevance of feedback. We keep operators anonymous to protect confidentiality and encourage candor, while highlighting patterns that matter across the industry rather than singling out individual cases.
Context: Why DNSSEC Ops Must Change
DNSSEC has matured technically, but the operating environment around it has changed fundamentally.
- Regulation: Under NIS2 and ENISA guidance, DNSSEC is treated as critical infrastructure. Lifecycle accountability and documented continuity are now mandatory.
- Geopolitics: DNS is increasingly understood as sovereign infrastructure. Operators face heightened scrutiny, including from state-level actors.
- Operational demands: The shift is from technical correctness to operational assurance. Systems must not only run, but prove that they can be transferred, audited, and recovered.
The reality is simple: most signing pipelines in production today do not meet these new standards of resilience.
What Keeps DNSSEC Operators Up at Night?
Top 5 Operator Pain Points
| Pain Point | Mentions | Supporting Quotes |
|---|---|---|
| Reliance on key individuals | 9 | “If they leave, we have a problem.” |
| Fallback or recovery unclear | 8 | “We needed something we could transfer.” |
| No clear support model | 7 | “We don’t have a contract, just people we know.” |
| Validation depends on manual tools | 7 | “We AXFR and check with DNSViz before publish.” |
| Observability between steps lacking | 6 | “We don’t know what’s happening until it breaks.” |
Note: “Observability” wasn’t always named explicitly, but inferred from consistent operator comments.
Support Contract Status
How operators currently secure continuity.
| Support Maturity | % of Respondents | Supporting Quotes |
|---|---|---|
| Formal contract or SLA | ~50% | “We can escalate within hours if needed.” |
| Informal contact (email/forum) | ~35% | “We know who to call, but it’s not official.” |
| No external support path | ~15% | “We’re on our own if it breaks.” |
Validation Workflow Use
How operators validate zones before publishing.
| Validation Method | Mentions | Supporting Quotes |
|---|---|---|
| AXFR from staging signer | 8 | “We AXFR before pushing live.” |
| Manual DNSViz or ldns | 7 | “We use DNSViz to catch errors manually.” |
| Custom validation scripts | 5 | “We have internal scripts that diff the zone.” |
| Built-in tool validation | 3 | “We trust it, but we still double-check.” |
Can Your DNSSEC Operations Pass External Scrutiny?
| Requirement | % Not Covered | Supporting Quote |
|---|---|---|
| Transferability without key individual | ~60% | “We needed something we could hand over.” |
| Documented fallback / recovery | ~50% | “There’s no plan, just a person.” |
| External validation before publish | ~40% | “We test it, but it’s not automated.” |
| Lifecycle support with vendor accountability | ~45% | “Support? We email someone and hope.” |
| Auditable pipeline / CLI state view | ~70% | “We don’t know what it’s doing until it fails.” |
Five Emerging Patterns
1. “It works — but don’t touch it.”
Most DNSSEC systems still rely on tribal knowledge and legacy code. Teams fear updates because they cannot guarantee transferability.
- “We don’t want to be the only ones who understand it.”
- “If our DNSSEC expert leaves, we’d have no idea how to keep it running.”
Implication: Current setups are stable only as long as one person remains in place. That is fragility, not resilience.
2. “Support is no longer optional.”
Operators no longer see support as an afterthought. It is becoming structural. Regulators expect documented continuity and lifecycle assurance, not “best effort.”
- “Support is part of what we consider operational maturity.”
- “The regulator expects a documented lifecycle. That includes support.”
Implication: Support is not reactive. It is a core element of operational credibility.
3. “We don’t see what’s going wrong.”
Monolithic or opaque DNSSEC tools act as black boxes. Failures often go undetected until broken zones are published.
- “With OpenDNSSEC, it was a black box. You had to dive into the code — and even then, we sometimes couldn’t figure it out.”
Implication: Observability is missing. Operators need hooks, logs, and visibility at every stage of the signing chain.
4. “We inherited this mess.”
Many teams run on monolithic legacy tools that block migration and scaling. Containerisation is fragile or impossible.
- “We’ve stopped even trying to Dockerise it — too brittle.”
Implication: Monolithic pipelines create inertia. Modularity is no longer a feature — it is the baseline for recovery and change.
5. “We need to prove we’re in control.”
Compliance and accountability are moving into the open. Operators must not only run DNSSEC, but show evidence that it is resilient and under control.
- “We need to show that we’re in control, not just that it’s up.”
Implication: Trust is not uptime. Trust is the ability to explain, audit, and prove DNSSEC operations under scrutiny.
Designing for DNSSEC in 2026
The operators we interviewed were clear: the next phase of DNSSEC must be built for resilience, not just correctness.
Key expectations:
- Built-in observability at every stage
- Modular, container-ready architecture
- Transferable configurations and documented processes
- Lifecycle support as standard, not optional
- Compliance-by-default, not retrofitted
Resilience Self-Check
Use this checklist to benchmark your current DNSSEC pipeline:
☐ Can a new engineer take over your signing pipeline with confidence?
☐ Is each stage observable and testable in isolation?
☐ Do you know what happens when a failure occurs?
☐ Is support with an SLA part of your lifecycle — or an afterthought?
☐ Could you demonstrate resilience to an auditor tomorrow?
If you cannot answer “yes” to all five, it’s time to step up your game.
Closing Note: From Uptime to Recovery
Designing for 100% uptime is no longer the gold standard.
TLD operators know uptime alone is fragile.
The new benchmark is controlled failure and fast recovery.
Systems must be teachable, testable, and auditable — even under pressure.
DNSSEC is strategic infrastructure.
People, businesses, governments, emergency services, financial institutions, and energy providers rely on it to keep the world moving.
It deserves resilience — not hero ops.
Not systems held together by one expert’s memory, but by a documented, repeatable process with enterprise-grade support.
This report was written and published by NLnet Labs. All findings are based on direct feedback from 16 TLD operators. No assumptions. No promotional claims. Just the operational reality of DNSSEC in 2026.