DNSSEC
What DNSSEC is and why it matters, turning it on for a self-hosted zone, the DS-record step at the registrar (and verify DS), key rollover, and the one critical warning — pull the DS at the registrar BEFORE removing DNSSEC, or the zone goes BOGUS.
DNSSEC signs your DNS answers so a resolver can prove they really came from you and weren't tampered with on the way. Without it, DNS answers can be forged. With it, a forged answer fails validation and is rejected. For self-hosted DNS, where you control the whole chain, turning it on is a strong, cheap win.
How it works here
PowerDNS does the cryptography: when you enable DNSSEC on a zone, PowerDNS generates the keys, signs the zone, and holds the private keys on your nameserver boxes. Your job is one step at the registrar — publishing a DS record that links the parent zone to your keys, completing the "chain of trust" from the root down to your domain.
The panel reads the DS record from PowerDNS and shows it to you to enter at the registrar. It can't write it there (that's Layer 1, the registrar's side), so as with glue and delegation it guides and verifies.
There is nothing to buy and no “dnssec.io” to sign up for
DNSSEC for a self-hosted zone is entirely contained in your own stack. You don't register with any
third party, you don't buy a certificate, and there is no external "DNSSEC service" — dnssec.io is not
part of this. Enabling the toggle has your PowerDNS boxes generate the keys and sign the zone; the only
thing that leaves your infrastructure is the public DS record, which you paste at your registrar once.
The private keys never leave the boxes and never enter the panel database.
Turning it on for a zone
On the zone in Networking → Nameservers → Self-hosted zones (pick the domain in the zone selector), enable DNSSEC. PowerDNS generates the keys and signs the zone on every nameserver box.
The panel shows the DS record (key tag, algorithm, digest type, and digest). At the registrar of that domain, find DNSSEC / DS records and enter the values exactly as shown.
Back in the panel, click Verify DS — it confirms from outside that the parent now publishes a DS that matches your zone's key, so the chain of trust validates end to end.
Add the DS only after the zone is signed
Sign the zone first, then publish the DS. Publishing a DS at the registrar for a zone that isn't yet validly signed tells resolvers to expect signatures that aren't there — which makes the zone fail validation (BOGUS) just like the removal mistake below, only in the other direction. The panel's flow enforces this order: it only hands you the DS once the zone is signed.
Key rollover
Keys are rotated periodically (a "rollover"). PowerDNS handles the signing side; what changes on your side is the DS. When the signing key rolls, the DS that represents it changes, so you re-enter the new DS at the registrar and run Verify DS again. The panel shows a pending rollover and the new DS so you know to update it; validation stays intact through the rollover window.
The critical removal warning
This is the one DNSSEC mistake that takes a domain completely offline — read it before you ever turn DNSSEC off.
Remove the DS at the registrar FIRST, or the zone goes BOGUS
Disabling DNSSEC has a strict order: remove the DS record at the registrar first, wait for that to propagate, and only then unsign the zone in the panel.
If you unsign the zone (or delete the keys) while the parent still publishes a DS, every validating resolver sees "the parent says this zone is signed, but the answers aren't" — and treats the whole zone as BOGUS, refusing all answers. The domain effectively disappears for anyone behind a validating resolver, even though your records are fine. The cure (pulling the DS, then waiting out the cache) is slow and painful. So: DS out at the registrar → verify it's gone → unsign. Never the other order.
Next steps
- Delegate a domain — get the zone onto your nameservers first.
- Failover — signing rides on top of the two-box pair.
- Self-hosted overview — the architecture and trade-offs.
Failover
Why two nameservers give you automatic failover with nothing to configure — resolvers try each NS in turn. What the panel's NS-health probe watches, and what to do when a box goes unreachable.
Git deploys
Deploy a site from git — scoped deploy keys, the fetch→build→release pipeline, zero-downtime cutover, one-click rollback, and push-triggered redeploys.