DNSSEC (DNS Security Extensions) adds digital signatures to DNS records so that resolvers can verify an answer really came from the domain's owner and was not altered on the way. It does not encrypt anything; it proves authenticity through a chain of trust that starts at the DNS root.
Ordinary DNS has no way to tell a genuine answer from a forged one. DNSSEC, standardised in RFCs 4033, 4034 and 4035, closes that gap. This guide explains the record types involved, how validation works, and the mistakes that most often take signed domains offline.
The problem DNSSEC solves
A recursive resolver accepts the first answer that matches its question. An attacker who can inject a forged response, by sitting on the network path or by winning a race against the real server in a cache poisoning attack, can redirect users of that resolver to an IP address of their choice. Everyone sharing that resolver then gets the fake answer until the cached entry expires.
DNSSEC makes forgery detectable. Each set of records is signed with the zone's private key, and the matching public key is published in DNS. A validating resolver checks the signature and rejects anything that does not verify. If you need a refresher on resolvers and authoritative servers first, read what DNS is and how it works.
DNSSEC record types
| Record | Lives in | Purpose |
|---|---|---|
DNSKEY | The signed zone | Public keys used to verify the zone's signatures |
RRSIG | The signed zone | A signature over one record set (for example all A records for a name), with validity start and end times |
DS | The parent zone | Delegation Signer: a hash of the child zone's key-signing key, linking parent to child |
NSEC | The signed zone | Proves a name or record type does not exist by naming the next existing name in sorted order |
NSEC3 | The signed zone | Same as NSEC but with hashed names (RFC 5155), making it harder to list every name in the zone |
CDS / CDNSKEY | The signed zone | Signals to the parent which DS record it should publish, allowing automated updates (RFC 7344) |
Our guide to DNS record types covers the ordinary records, such as A, MX and TXT, that these signatures protect.
Why proving non-existence is needed
Without NSEC or NSEC3, an attacker could forge an NXDOMAIN ("this name does not exist") response, which cannot carry a signature of its own because there is no record to sign. NSEC records give the resolver a signed statement that nothing exists between two names, so a denial can be verified too.
Key-signing keys and zone-signing keys
Most zones use two kinds of key, both published as DNSKEY records:
- Zone-signing key (ZSK), DNSKEY flags
256: signs the zone's ordinary record sets. It can be rotated often without involving anyone else. - Key-signing key (KSK), DNSKEY flags
257: signs only the DNSKEY record set. Its hash is what goes into the DS record at the parent, so changing it requires updating the registrar.
Splitting the roles means routine key changes stay inside your DNS provider, while the rarer KSK change is the only one that touches the parent zone. Some setups use a single combined signing key instead, which is simpler and common with modern elliptic-curve algorithms such as algorithm 13 (ECDSA P-256 with SHA-256).
The chain of trust
A signature only helps if the resolver trusts the key that made it. DNSSEC builds that trust step by step from the root, which was signed in 2010. Validating resolvers ship with the root zone's KSK as a built-in trust anchor. To validate www.example.com, a resolver:
- Uses the root trust anchor to verify the root's DNSKEY set.
- Verifies the signed DS record for
comin the root zone, then checks that it matches the KSK in thecomDNSKEY set. - Verifies the signed DS record for
example.comin thecomzone, then checks that it matches the KSK published byexample.com. - Uses the
example.comDNSKEY set to verify the RRSIG over the A records forwww.example.com.
If every link verifies, the answer is secure. If the parent has no DS record for a zone, the zone is insecure (unsigned) and the answer is returned normally. If a DS exists but the signatures do not verify, the answer is bogus.
What validation looks like: AD and SERVFAIL
When a validating resolver successfully verifies an answer, it sets the AD (Authenticated Data) flag in the response. You can see it with dig:
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)When validation fails, the resolver does not hand back the possibly forged data. It returns SERVFAIL, which to users looks the same as a site that does not exist or a DNS outage. To confirm DNSSEC is the cause, repeat the query with checking disabled:
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, answer returnedIf the +cd (checking disabled) query succeeds and the normal one fails, the zone's DNSSEC is broken. Our DNSSEC checker runs these checks for you and shows the DS, DNSKEY and signature status.
Common ways DNSSEC breaks
Moving DNS providers without removing the DS record
This is the classic failure. The DS record at the registry still points to the old provider's KSK. After the name servers change, the new provider either serves the zone unsigned or signs it with different keys. Validating resolvers find a DS with no matching key, mark the zone bogus, and every lookup returns SERVFAIL.
A safe migration looks like this:
- At the registrar, delete the DS record.
- Wait until the old DS has expired from caches: at least the DS record's TTL in the parent zone, which you can see with
dig example.com DS. Waiting a day or two is a common safety margin. - Change the name servers to the new provider and wait for the old NS records to expire.
- Enable DNSSEC at the new provider and publish its new DS record at the registrar.
Some providers support a multi-signer setup that avoids the unsigned gap, but it requires cooperation between both providers.
Expired signatures
Every RRSIG has an expiry time. If the signing process stops, for example on a self-hosted server whose re-signing job failed, signatures eventually expire and the zone goes bogus.
Key rollovers done too fast
Removing an old key before caches have picked up the new one causes failures for resolvers still holding the old DNSKEY set or DS record. Rollovers must respect the TTLs involved.
How to enable DNSSEC for your domain
- Check that your TLD supports DNSSEC; most generic and many country-code TLDs do.
- Turn on DNSSEC signing at your DNS hosting provider. It will generate keys and sign the zone.
- Copy the DS record details (key tag, algorithm, digest type and digest) into your registrar's DNSSEC settings. If your provider and registrar are the same company, this is often automatic, and some registries pick up CDS records automatically.
- Verify the result with our DNSSEC checker and check that ordinary lookups still work with the DNS lookup tool.
Frequently asked questions
Does DNSSEC encrypt my DNS queries?
No. DNSSEC provides authenticity and integrity, not privacy. Queries and answers are still visible on the network. Encryption comes from DNS over TLS or DNS over HTTPS, which complement DNSSEC.
Do I need DNSSEC if my site uses HTTPS?
HTTPS certificates already stop a forged DNS answer from silently impersonating your site, but DNSSEC also protects mail routing, TXT records used for verification, and other records. It is also required for DANE, which publishes TLS certificate information in DNS.
Why does my domain work on some networks but not others?
If DNSSEC is broken, only validating resolvers return SERVFAIL; non-validating ones still answer. That makes the outage appear to depend on the network.
How do I turn DNSSEC off safely?
Remove the DS record at the registrar first, wait for it to expire from caches, and only then stop signing the zone. Doing it in the other order causes an outage.