dnswizdocs

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

  1. Open the zone in the console.
  2. Zone settings → DNSSEC → Enable.
  3. Copy the DS record shown in the panel.
  4. Paste it into the DS field at your registrar (or its DNS host).
  5. Wait for the registrar to publish. dig DS yourdomain. @1.1.1.1 should 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

KeyWhere it livesSealed byNotes
KSK (Key-Signing Key)Control plane onlyMaster key (operator-side)Signs the DNSKEY RRset. Never leaves the CP.
ZSK (Zone-Signing Key)EdgesDNSSEC 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):

  1. Begin KSK rollover. dnswiz generates a new KSK and publishes it alongside the old one. You publish the new DS at your registrar.
  2. dnswiz probes your parent every minute. Once it sees both DS records, it waits the DS TTL for caches to converge.
  3. Switch signer. dnswiz starts signing the DNSKEY RRset with the new KSK. The old one is still published.
  4. 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:

  1. The zone stays signed.
  2. dnswiz schedules the disable for grace_hours from now (default 24h, configurable per-disable).
  3. You remove the DS at your registrar.
  4. 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

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

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.