Operating DNSSEC: plan delegation and key rollovers
After a nameserver change, a website works from one network but fails from another. Email may be affected too. One possible cause is a broken DNSSEC chain of trust. Recording signing, delegation and responsibilities separately helps you prepare changes and investigate failures.
How DS, DNSKEY and signatures connect
DNSSEC makes the origin and integrity of DNS data verifiable. It encrypts neither DNS queries nor website content. RRSIG records contain signatures; DNSKEY records provide public keys. A DS record in the parent zone identifies a child-zone key through a cryptographic digest. Together with a trusted starting key, these records form a verifiable chain.
A signing switch at the DNS provider therefore does not prove that the complete chain is secured. What matters is whether a validating resolver can verify it. Conversely, a DS record without matching keys and valid signatures can cause validation failures.
Establish responsibilities before a change
Record who manages registration, who operates the authoritative nameservers and who submits DS changes to the registry. These may be different providers. Before moving, confirm the specific DNSSEC procedure, support on the destination platform and an available contact for the cut-over.
A registrar transfer, a nameserver change and a change of signing keys are separate operations. Moving only the website or mailboxes does not automatically require a key rollover. Explicitly agree which layers will actually change.
Key rollovers need a coordinated sequence
During a rollover, resolvers must remain able to build a valid chain using cached answers as well. The sequence depends on the chosen method. RFC 6781 describes different rollover procedures; a generic instruction to delete the old key and add the new one is insufficient. Lowering a TTL later does not retroactively remove cached answers.
Automation helps, but does not replace coordination with the parent zone. For BIND, ISC distinguishes automatic ZSK rollovers from KSK or CSK rollovers requiring the corresponding DS update. Monitor the confirmed DS state and failed automation steps too. Retire old keys or signatures only when the chosen procedure permits it.
Investigate SERVFAIL before changing settings
SERVFAIL is not a definitive DNSSEC diagnosis. Google also identifies unreachable nameservers or faulty authoritative responses as causes. Compare the same name and query type through several resolvers and directly against the authoritative servers. Save complete responses, including status and any Extended DNS Errors.
Cloudflare describes comparing a normal dig query with the same query using +cd as a diagnostic aid. If only the query with checking disabled succeeds, that indicates a validation problem. The unchecked answer does not establish authenticity. Next inspect DS, DNSKEY, signatures and recent changes; do not permanently disable validation as a workaround.
The +dnssec option requests DNSSEC data; it does not make dig perform its own cryptographic validation. An AD flag from a trusted validating resolver signals a validated answer. The ISC guide also covers expired signatures and an incorrect resolver clock as possible causes of failure.
Change and acceptance checklist
- Record the domain, nameservers, DNS operator and responsible registrar.
- Document the initial DS and DNSKEY state and relevant TTLs.
- Confirm the procedure, sequence, waiting periods and rollback with both providers.
- Check validation of website and mail DNS records before and after the change.
- Record discrepancies with timestamps, resolver, query type and the complete response.
- Complete acceptance after external tests and the agreed cache intervals.
Plan domain transfers and DNSSEC together
When planning a domain transfer to NUXOA, provide the existing DNSSEC state and any planned nameserver change in advance. Confirm support for your specific extension and intended DNS setup. The linked migration guide helps you plan registration, DNS and email separately.