DNSSEC: should you turn it on, and how
What DNSSEC protects against, how the chain of trust works, which algorithms to choose, and a safe path to signing a zone without taking it offline.
What DNSSEC does and does not do
Classic DNS answers carry no proof of where they came from. A resolver that accepts a forged answer, for example through cache poisoning, can send users to an attacker's server for as long as the forged record stays cached. DNSSEC (RFC 4033, 4034 and 4035) adds digital signatures to DNS data so a validating resolver can check that an answer really came from the zone owner and was not changed.
DNSSEC provides authenticity and integrity, not confidentiality. Queries and answers are still visible on the network; encrypting them is the job of DNS over TLS or DNS over HTTPS. It also protects only as far as validation happens: if the resolver your laptop uses validates, you benefit, but the path between your device and that resolver is a separate question.
| Threat | Covered by DNSSEC? |
|---|---|
| Forged answers injected into a resolver cache | Yes, validating resolvers reject them |
| A compromised account at your DNS provider changing records | No, the provider signs whatever is in the zone |
| Someone reading which names you look up | No, use encrypted DNS for that |
| Domain hijacking at the registrar | No, protect the registrar account with MFA and registry lock |
| Trustworthy DNS for DANE (TLSA) and SSHFP records | Yes, those records depend on it |
The chain of trust
Validation starts from a key every validating resolver already trusts: the root zone's key signing key. The root signs a DS record for each top-level domain, the TLD signs a DS record for your domain, and your zone publishes the DNSKEY records that match that DS record. Each link vouches for the next one down.
| Record | Where | Purpose |
|---|---|---|
DNSKEY | Your zone | Public keys used to verify signatures in the zone |
RRSIG | Your zone | Signature over one record set, with inception and expiration times |
DS | Parent zone (registry) | Hash of your key signing key; links your zone to the parent |
NSEC / NSEC3 | Your zone | Signed proof that a name or record type does not exist |
CDS / CDNSKEY | Your zone | Signal to the parent which DS record to publish (RFC 7344, RFC 8078) |
Zones often use two kinds of keys. A key signing key (KSK) signs only the DNSKEY set and is the one referenced by the DS record; a zone signing key (ZSK) signs everything else, so it can be rotated without touching the registrar. Many managed DNS providers use a single combined signing key instead, which is simpler and works the same way for validation.
Should you enable it?
The protection is real, and so is the operational risk. A signed zone with a broken chain is worse than an unsigned zone: validating resolvers return SERVFAIL, and users of those resolvers cannot reach your website or deliver mail to you at all. Large public resolvers validate, so a DNSSEC outage affects a large share of internet users.
| Situation | Recommendation |
|---|---|
| Managed DNS provider signs automatically, registrar supports DS or CDS | Enable it; the provider handles signatures and key rollovers |
| You want DANE for mail (TLSA records) | Required; DANE does not work without DNSSEC |
| Self-hosted authoritative DNS without automation | Only with automated signing and monitoring in place |
| DNS provider migration planned soon | Wait until the migration is done, or plan a multi-signer transition |
| Registrar cannot publish DS records | Not possible until you move the domain or the registrar adds support |
For most organisations using a managed DNS service, enabling DNSSEC is a few clicks at the provider and one DS record at the registrar. The dangerous moments are rare but predictable: changing DNS providers, changing registrars and manual key rollovers. Plan those, and DNSSEC runs unattended.
Choosing algorithms
Each DNSKEY and DS record names an algorithm by number. RFC 8624 gives implementation and usage recommendations; its successors refine them, but the practical choice for new deployments has been stable for years. Pick ECDSA P-256 with SHA-256, algorithm 13, unless your provider offers only something else.
| Number | Name | Use for new signing |
|---|---|---|
| 13 | ECDSAP256SHA256 | Recommended: small signatures, widely validated |
| 15 | ED25519 | Good choice where your provider and validators support it |
| 8 | RSASHA256 | Acceptable; larger answers than ECDSA |
| 14 | ECDSAP384SHA384 | Acceptable, rarely needed |
| 5 / 7 | RSASHA1 / RSASHA1-NSEC3-SHA1 | Do not use for new signing |
Use SHA-256 (digest type 2) for DS records. Small ECDSA signatures keep DNS responses under common UDP size limits, which reduces fallback to TCP and fragmentation problems.
For NSEC3, RFC 9276 recommends zero extra iterations and no salt. Higher iteration counts add load for resolvers without meaningful protection against zone enumeration, and some resolvers treat very high counts as insecure.
Enabling DNSSEC safely
- Confirm the domain's name servers are the ones at your DNS provider, with the WHOIS lookup or an NS query in DNS Lookup.
- Turn on signing at the DNS provider and wait until the zone serves
DNSKEYandRRSIGrecords. - Copy the DS record data the provider shows (key tag, algorithm, digest type, digest), or the DNSKEY if your registrar asks for that instead.
- Add it at the registrar in the domain's DNSSEC settings. Some registries accept CDS or CDNSKEY records from the zone and do this step automatically.
- Verify the chain from outside with
digordelv, then keep watching for a day. - Add monitoring that alerts on validation failures and on signatures close to expiry.
# the DS record published by the parent (com)
dig +short DS example.com
12345 13 2 3F8A...9C1D
# the keys in your zone; one should match the DS key tag
dig +dnssec +multi DNSKEY example.com
# a validating lookup; look for "fully validated"
delv example.com A
# the AD flag from a validating resolver
dig +dnssec example.com A | grep -E 'flags:.* ad'Never publish a DS record before the zone is signed
Key rollovers
Signing keys are replaced from time to time, either on a schedule or after a suspected compromise. Managed providers roll zone signing keys automatically. Rolling the key referenced by the DS record also requires the parent to publish a new DS record, which is either automated through CDS/CDNSKEY or a manual step at the registrar.
The safe pattern is always to overlap: publish the new key alongside the old one, wait for caches to expire (at least the TTL of the DNSKEY set, and of the DS record for KSK rollovers), switch, and only then remove the old key. Removing the old key or DS too early leaves resolvers holding cached data that no longer matches anything in the zone.
Signatures also expire. Each RRSIG has an expiration time, and a zone that stops being re-signed, for example because a signing server was switched off, starts failing validation when those times pass. Monitoring that warns days before expiry prevents that class of outage entirely.
Changing DNS provider or registrar
Moving a signed zone to a new DNS provider is the most common way to break DNSSEC. The new provider signs with different keys, while the registry still publishes the DS record for the old ones. As soon as the name servers change, validating resolvers see a zone whose keys do not match the DS and return SERVFAIL.
| Approach | Steps | Trade-off |
|---|---|---|
| Go unsigned temporarily | Remove the DS at the registrar, wait for the DS TTL (and a margin), move name servers, sign at the new provider, add the new DS | Simple; the zone is unprotected for a short period |
| Multi-signer transition (RFC 8901) | Both providers publish each other's keys, DS records for both are added, then the old provider is removed | No unprotected period; needs support from both providers |
Registrar transfers usually keep the DS record, but check it after the transfer completes. The domain migration checklist puts these steps in order together with mail, TLS and redirects.
Monitoring a signed zone
DNSSEC failures are silent for you and loud for your users: your own resolver may not validate, so everything looks fine from the office while a large share of the internet gets SERVFAIL. Monitoring must therefore query through a validating resolver from outside your network. It should also look ahead, because the most common failure, expiring signatures, is predictable days in advance.
- Alert when a validating resolver returns SERVFAIL for your key names (apex,
www, MX hosts). - Alert when RRSIG expiration times are less than a few days away.
- Alert when the DS record at the parent does not match any DNSKEY in the zone.
- Record DNSKEY and DS changes, so rollovers are visible in your change history.
- Include DNSSEC status in migration and registrar change checklists.
Managed DNS providers usually monitor their own signing, but they cannot see mistakes made at your registrar, such as a DS record left behind after a provider change. Your own external check is the only one that sees the full chain the way users do.
Keep the check simple enough that it keeps running for years. A daily delv for the apex from a cloud machine, with an alert on anything other than "fully validated", covers most of the risk.
Troubleshooting SERVFAIL
If a domain resolves through a non-validating resolver but returns SERVFAIL through a validating one, DNSSEC is the first suspect. Compare the answers from two resolvers and then use dig +cd, which asks the resolver to skip validation. An answer with +cd and SERVFAIL without it confirms a validation failure.
dig @192.0.2.53 example.com A # validating resolver: SERVFAIL
dig @192.0.2.53 example.com A +cd # checking disabled: answer returned| Cause | Fix |
|---|---|
| DS at registrar does not match any DNSKEY | Publish the correct DS, or remove it and re-add after signing |
| Expired RRSIG signatures | Restart or fix automatic signing; re-sign the zone |
| Old DS left after moving DNS provider | Remove the old DS; add the new provider's DS |
| Unsupported or deprecated algorithm | Roll to algorithm 13 or 15 |
| Records edited outside the signer (manual zone file change) | Make changes through the signing system only |
FAQ
Does DNSSEC slow down my website?
Hardly. Validating resolvers do a little more work and cache the results, and ECDSA signatures keep responses small. Users do not notice a difference in practice.
Can I see if a domain uses DNSSEC?
Query the DS record with dig DS example.com, or look for a DNSSEC field such as signedDelegation in the registry's WHOIS output. A DS record in the parent means the domain is expected to be signed.
Does DNSSEC encrypt DNS?
No. It signs records so they can be verified. Encryption of queries and answers comes from DNS over TLS or DNS over HTTPS, which solve a different problem.
What happens if I remove DNSSEC?
Remove the DS record at the registrar first and wait for its TTL to expire, then stop signing. Stopping signing while a DS record is still published causes validation failures.
Is algorithm 8 (RSASHA256) still safe?
Yes, it is widely supported and acceptable. Algorithm 13 is preferred for new deployments because its keys and signatures are much smaller.
Why does my domain work for me but not for some users?
Your resolver may not validate DNSSEC while theirs does. If validation fails, validating resolvers return SERVFAIL. Test through a validating public resolver and with delv.
Do I need DNSSEC for email security?
Not for SPF, DKIM, DMARC or MTA-STS. It is required for DANE, which pins mail server certificates in DNS as an alternative or complement to MTA-STS.
Sources
- RFC 4033: DNS Security Introduction and Requirements
- RFC 4034: Resource Records for the DNS Security Extensions
- RFC 4035: Protocol Modifications for the DNS Security Extensions
- RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
- RFC 9276: Guidance for NSEC3 Parameter Settings
- RFC 8901: Multi-Signer DNSSEC Models
- RFC 7344: Automating DNSSEC Delegation Trust Maintenance (CDS/CDNSKEY)