Enabling DNSSEC
A step-by-step guide to signing a zone with DNSSEC. For the concepts and cryptographic background, see DNSSEC.
Base path: /api/v1/domains/{domain_id}/dnssec
Required permission: dnssec:* on the domain
Prerequisites#
- Zone is
active(validation completed). - You have access to your registrar's admin panel to publish DS records.
- A DNSSEC-validating resolver is available for testing (
1.1.1.1,8.8.8.8, and most modern resolvers validate).
1. Check current status#
1 2 | |
1 2 3 4 5 | |
1 2 3 4 5 | |
If enabled: false, proceed to step 2. If already enabled, skip ahead to rotation or verification.
2. Enable with algorithm 13#
1 2 3 4 | |
1 2 3 4 5 6 7 8 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
Algorithm selection#
| Algorithm | Number | When to use |
|---|---|---|
| ECDSA P-256/SHA-256 | 13 | Default choice. Small, fast, universally supported |
| Ed25519 | 15 | Modern; use if your TLD and registrar support it |
| RSA/SHA-256 | 8 | Legacy compatibility; avoid for new zones |
When in doubt, use 13.
Response#
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | |
The zone is now signed at the nameserver level. DNSSEC validation will fail until you publish the DS records at the registrar, because the chain of trust isn't established yet.
3. Publish DS records at the registrar#
Log into your registrar's admin panel and find the DS records section. It's often under "DNSSEC" or "Security."
For each DS record in the response, enter:
- Key Tag: the integer
key_tag. - Algorithm: the integer
algorithm. - Digest Type: the integer
digest_type(2 = SHA-256, typical). - Digest: the
digesthex string.
Save. The registrar pushes these to the parent TLD zone on its own schedule — minutes to hours, occasionally longer.
Watch for propagation:
1 | |
When the digest shows up, move on.
4. Confirm DS is published#
Tell ScaiDNS that the chain is complete:
1 2 3 4 5 6 7 8 | |
This step exists for audit purposes — the actual validation happens at resolvers, but recording confirmation gives you a trail of when DNSSEC went live for each zone.
5. Verify end-to-end#
1 2 | |
In the full response, look for:
- Header
flagscontainingad— the resolver validated the answer. - No
adand no errors — the resolver doesn't validate (unusual), but your zone is still signed. SERVFAIL— validation failed. Something in the chain is broken.
Alternatively, use an online analyzer: https://dnssec-analyzer.verisignlabs.com/example.com. Errors at each level explain where the chain breaks.
Rotating keys#
ZSK rotation (safe any time)#
1 2 | |
Transparent to resolvers and registrars. ScaiDNS generates a new ZSK, signs the zone with both during the rollover window, then retires the old one.
KSK rotation (requires registrar coordination)#
1 2 | |
Response includes the new DS record. Steps to complete:
- Add the new DS record at the registrar (keep the old one).
- Wait for propagation.
- Call
/confirm-ds-publishedwith the new DS record. - After the overlap period, the old KSK is retired.
- Remove the old DS record at the registrar.
Do not remove the old DS record before the overlap completes. Validators may still be caching answers signed by the old key.
Disabling DNSSEC#
Remove the DS records at the registrar first. Then disable in ScaiDNS:
1 2 | |
If you disable with DS still at the registrar, resolvers see DS but no DNSKEY in the zone and return SERVFAIL.
Troubleshooting#
| Symptom | Check |
|---|---|
dig +dnssec shows no ad flag |
Resolver may not be validating. Try 1.1.1.1 or 9.9.9.9 |
| Online analyzer shows "no DS at parent" | Registrar hasn't propagated the DS yet; wait or re-submit |
| Online analyzer shows "DS digest mismatch" | DS at registrar doesn't match any KSK. Regenerate DS via GET /dnssec and republish |
SERVFAIL from validating resolvers |
Broken chain. Often the DS at registrar references a retired KSK |
SERVFAIL right after KSK rotation |
Normal briefly; resolvers still have old key cached |
What's next#
- DNSSEC reference — endpoint details.
- DNSSEC concepts — cryptographic background.