Tutorial · dns-ssl · Published 2026-08-16 · 4 min read
DNSSEC explained and how to enable it
DNSSEC guide: what it protects, signing chain, DS records, key rollover, and how to enable it without breaking your zone.
What DNSSEC actually stops
DNSSEC (DNS Security Extensions) answers the question "can I trust this DNS answer?" without encrypting anything. DNS queries and responses are still sent in the clear; DNSSEC adds digital signatures to the records, and a validating resolver can confirm a response is genuine. That protects against DNS cache poisoning, the attack where a poisoned resolver returns the wrong IP for a domain and silently sends visitors to a fake site.
DNSSEC does not hide your data and does not stop a denial of service. It does stop the specific forgery vector in the DNS itself, and it does it for the whole chain, from the root zone down to your subdomain. The DNS resolution guide explains where the trust chain sits, and the server types article covers the comparables a resolver routes between.
How the chain and keys work
Each zone holds two records that matter for the scheme:
- DNSKEY records hold the public keys that can verify signatures within the zone.
- RRSIG records hold the signatures over the zone's own records, and DS (delegation signer) records connect a child zone to its parent: the parent publishes a hash of the child's key, so trust can be established.
The two-key model is what lets a rollover happen without re-signing everything. A zone uses a ZSK (zone signing key) to sign its own records, and a KSK (key signing key) to sign the ZSK and the DS record. When you carry a DS record to your registrar, you publish a hash of the KSK's public half.
Rollovers matter in production because you cannot wait to change keys. Key rollover happens in two passes: publish the new key first, let the new chain propagate, then remove the old key once the TTL has passed. If the parties half-step, the zone goes "bogus" and stops resolving.
Enable it without breaking the zone
The safest path depends on where DNS is hosted, because the DS record has to reach the parent (your registrar or TLD) and must match what your DNS provider published.
| DNS hosted at | How to enable |
|---|---|
| Same provider as registrar | Turn on DNSSEC in one dashboard; provider publishes the DS itself |
| Separate provider | Provider shows DS / DS records, then paste them into the registrar's DNSSEC page |
| Not sure | Read provider docs; never guess a DS from your own key hash |
- Ask your DNS provider to enable signing. It usually generates a KSK and a DS record.
- Contact the registrar's DNSSEC page and upload the exact DS record, with all fields, onto the domain.
- Wait for propagation, commonly up to a day, and confirm a validator shows a secure chain.
- Keep a monitoring check running against
dnsvizor the provider's deep resolver, because a mismatch leaves the domain unresolvable.
If your zone goes "bogus" (resolvers return SERVFAIL) the immediate remedy is to disable the DS at the registrar, because that is the hinge. Never delete the DNSSEC keys first.
When not to bother
Enable DNSSEC when the domain is business-critical and a spoofed DNS answer is costly, or when clients require it. The running costs are a key rollover and a small operational duty. It is usually worth the couple of steps today, and Cloudflare-adjacent content is increasingly signed by default.
Prevention
- Back up the DS values and keys offline before a rollover.
- Keep the zone TTL short during a rollover so resolvers re-fetch the new chain quickly.
- Do not let a third party's claim that "DNSSEC is on" substitute for a validator pass.
- A signed zone sits in front of IP changes as usual, because the record moves apply regardless.
Enable DNSSEC once on a quiet schedule and validate the secure chain before and after any change at the registrar or the DNS provider. Log the window and move on; a signed zone is uneventful, which is the entire point.