DNSSEC
dnswiz signs your zones with ECDSA P-256 (algorithm 13). You click Enable DNSSEC on the zone, copy the DS record to your registrar, and that’s it. Everything else (key rollovers, signing, NSEC denial, safe disables) happens for you.
Why online signing
Most authoritative servers sign zones offline and serve the cached RRSIGs. That works for static zones. It doesn’t work for ours: dnswiz answers are dynamic. A POOL record picks a target from the healthy members at query time. A GEO record picks by client country. A CANARY record splits by a configured ramp. An ANAME flattens a hostname to its current A/AAAA at query time. There’s no static RRset to sign in advance.
So dnswiz signs at the edge, online, per answer. The cost is a few hundred microseconds of ECDSA per signed response (cached for the RRset TTL). The benefit is that every dynamic feature you use continues to work, signed, without a separate “DNSSEC mode” that limits what you can do.
Enable on a zone
- Open the zone in the console.
- Zone settings → DNSSEC → Enable.
- Copy the DS record shown in the panel.
- Paste it into the DS field at your registrar (or its DNS host).
- Wait for the registrar to publish.
dig DS yourdomain. @1.1.1.1should return the same key tag within minutes.
The zone is now signed end to end. Verify from any validating resolver:
delv yourdomain. A
# expect: ; fully validated
How the keys are split
| Key | Where it lives | Sealed by | Notes |
|---|---|---|---|
| KSK (Key-Signing Key) | Control plane only | Master key (operator-side) | Signs the DNSKEY RRset. Never leaves the CP. |
| ZSK (Zone-Signing Key) | Edges | DNSSEC key (shipped to edges) | Signs every other RRset. Rotated automatically. |
The KSK is what your registrar’s DS commits to. The ZSK is what actually does the signing work on every query. Splitting them is RFC-conformant practice and lets us rotate the ZSK without ever asking you to touch your registrar.
Automatic ZSK rollover
dnswiz pre-publishes the next ZSK 24 hours before it activates, swaps signers when ready, then keeps the old ZSK published for at least 48 hours (or the zone’s max TTL, whichever is longer) before removing it. This is the pre-publish rollover from RFC 6781 §4.1.1.1.
Defaults: 30-day ZSK lifetime, 24-hour pre-publish, 48-hour retire floor. Operator can change these in admin settings; the values apply to every signed zone.
You don’t need to do anything for ZSK rollovers. They happen on the hourly tick and never cause a SERVFAIL because the old key stays published until any cached signatures have expired.
KSK rollover (when you need it)
When you want to rotate your KSK (key compromise, algorithm change, or just hygiene every few years), the console walks you through a double-DS rollover (RFC 6781 §4.1.2):
- Begin KSK rollover. dnswiz generates a new KSK and publishes it alongside the old one. You publish the new DS at your registrar.
- dnswiz probes your parent every minute. Once it sees both DS records, it waits the DS TTL for caches to converge.
- Switch signer. dnswiz starts signing the DNSKEY RRset with the new KSK. The old one is still published.
- Remove old DS at your registrar. dnswiz probes for its absence; once gone, it drops the old KSK.
The wizard tells you exactly which DS to publish or remove, and what the live parent state is right now. You can cancel any time before the signer switches; after that, the only way out is to finish the rollover (or schedule a supervised disable below).
Supervised disable (no SERVFAIL, ever)
The common DNSSEC failure mode is “removed DNSSEC, forgot to remove the DS, every validator now returns SERVFAIL.” dnswiz makes that mistake impossible.
When you click Disable DNSSEC:
- The zone stays signed.
- dnswiz schedules the disable for
grace_hoursfrom now (default 24h, configurable per-disable). - You remove the DS at your registrar.
- dnswiz probes your parent on every hourly tick. Once it sees the DS is gone AND the grace has elapsed, it completes the disable.
If you remove the DS too early, the parent caches will still hold the old DS for its TTL; that’s why the grace window exists. If you remove the DS too late, the disable just waits longer. Either way, no resolver ever sees an inconsistency. Cancel the pending disable any time with one click.
Negative answers
dnswiz uses compact NSEC (RFC 4470 “black lies”). When a name doesn’t exist, the response covers exactly the queried name with a minimal NSEC, signed online. The result is NXDOMAIN that validates cleanly without the operator overhead of NSEC chains or NSEC3 parameters.
What gets signed
Every RRset in the zone gets an RRSIG: A, AAAA, CNAME, MX, SRV, TXT, CAA, PTR, plus DNSKEY at the apex. The dynamic types (POOL, GEO, CANARY, ANAME) sign the answer dnswiz selected for the specific query, so a validating resolver sees the same answer with a valid signature whether the routing changes next second or next hour.
What’s not in scope today
- CDS / CDNSKEY automation. dnswiz publishes the DS in the console; you copy it to your registrar manually. Auto-publish via CDS is coming once a meaningful share of registrars supports it.
- Ed25519 (algorithm 15). ECDSA P-256 is the universally supported strong algorithm right now. Ed25519 is on the list.
- Offline / detached signing. Not compatible with our dynamic answer model, see above.
- Multi-signer (RFC 8901). If you need two DNS providers signing the same zone, talk to us.
Verifying signing yourself
# DNSKEY at the apex
dig +dnssec yourdomain. DNSKEY @ns1.dnswiz.app
# DS at the parent (after publishing at registrar)
dig +dnssec DS yourdomain. @1.1.1.1
# Full chain validation
delv yourdomain. A
delv yourdomain. AAAA
delv yourdomain. SOA
delv nonexistent.yourdomain. A # should validate NXDOMAIN
If any of these fail after enabling, the error catalog covers the common cases (DS not published, DS published with wrong key tag, NS not delegated yet).
What’s stored, and what isn’t
- Your KSK private key is sealed at rest with the operator’s master key. It never leaves the control plane and never reaches the edges.
- Your ZSK private key is sealed at rest with a separate DNSSEC key. It ships to edges (which need it to sign), encrypted in transit and on disk.
- The DS is public by design, that’s the whole point.
Per-rule audit
Every DNSSEC event (enable, disable scheduled, disable completed, KSK rollover begun, phase advance, cancel) lands in Settings → Audit log with who did it and when.