DNSSEC Explained: Chain of Trust, DS Records and Safe Deployment

DNSSEC is one of the few internet security features that can make your site unreachable if you get it wrong, which is why many site owners either avoid it or switch it on without understanding it. This guide explains what DNSSEC protects against, how the chain of trust is built, which records are involved, and how to enable, maintain and, if necessary, disable it without taking your domain offline.

What DNSSEC does, and what it does not

Plain DNS answers are unauthenticated. A resolver has no cryptographic way to know that the address it received for www.example.com came from the real authoritative server and was not forged or altered in transit, for example through cache poisoning. DNSSEC adds digital signatures to DNS data so that a validating resolver can verify authenticity and integrity. The specifications are RFC 4033, 4034 and 4035.

What it gives you:

• Proof that records were published by the zone's owner and were not modified.
• Authenticated denial of existence: a signed proof that a name or record type does not exist.

What it does not do:

• It does not encrypt DNS queries or answers. Privacy is a separate topic (DNS over TLS or HTTPS).
• It does not protect the connection to your website. That is the job of TLS, which you can check with the SSL Checker.
• It does not help if a resolver does not validate, or if the attacker controls your registrar account or DNS host.

The building blocks

Two kinds of keys

Zones usually use two keys with different jobs:

• ZSK (zone-signing key): signs the actual records in the zone. It is used constantly, so it is rotated more often and can be shorter-lived.
• KSK (key-signing key): signs only the DNSKEY set. The DS record in the parent points to this key, so changing it requires coordination with the registry. It is rotated rarely.

Some deployments use a single combined key, and many DNS providers manage all of this for you, including automated signing. You mostly need to understand the structure so you can deal with the one manual step: publishing the DS record.

The chain of trust

A validating resolver starts from a trusted anchor, the root zone's key, which is built into resolver software. From there each level vouches for the next:

1. The root zone is signed, and contains a DS record for com, signed by the root's keys.
2. The com zone's DNSKEY matches that DS, and com contains a DS record for example.com, signed by com.
3. The example.com zone's DNSKEY (the KSK) matches that DS record, and signs the zone's other keys, which sign every RRset.

If every link verifies, the answer is marked authenticated. If any link is missing or fails, validation fails. If the parent has no DS record for your zone, the resolver treats your zone as unsigned, which is allowed, and answers normally with no authentication.

What breaks: SERVFAIL on validating resolvers

When validation fails, a validating resolver does not fall back to an unauthenticated answer. It returns SERVFAIL, so the site appears to vanish, but only for people using validating resolvers. This makes DNSSEC failures confusing: the site works from some networks and not from others. Many major public resolvers and a large share of ISP resolvers validate, so a broken chain affects a lot of users.

Common failure causes:

• DS mismatch: the DS record at the registry does not match the zone's current KSK. This commonly happens after migrating DNS providers or regenerating keys.
• Expired signatures: RRSIG records carry validity periods. If automated re-signing stops, signatures expire and answers fail.
• Moving DNS hosts while DNSSEC is on: the new host signs with different keys, but the old DS remains in the registry.
• Partial deployment across nameservers: one nameserver serves signed data and another serves unsigned data.
• Wrong algorithm or digest type in the DS.
• Clock problems on an unmanaged signer.

Diagnosing

# Is the zone signed, and what does the parent publish?
dig DNSKEY example.com +dnssec +short
dig DS example.com +short
dig A www.example.com +dnssec

# Compare a validating resolver with a non-validating test
dig @1.1.1.1 A www.example.com          # SERVFAIL if validation fails
dig @1.1.1.1 A www.example.com +cd      # +cd disables validation checking

If the plain query returns SERVFAIL but the same query with +cd (checking disabled) returns an answer, DNSSEC validation is the culprit. The ad flag in a response (authenticated data) shows that the resolver validated it. Use the DNSSEC Checker to walk the chain and see exactly which link is broken, and the DNS Checker to see how different resolvers respond. If you have just migrated, the Nameserver Lookup will confirm whether delegation matches what you expect.

Enabling DNSSEC safely

1. Check support. Your DNS host must support signing, and your registrar must allow you to add DS records for your TLD. Not every TLD is signed, although most large ones are.
2. Check TTLs. Know the TTLs on your DNSKEY and DS records, since they define how long mistakes linger. Do not assume you can undo quickly.
3. Enable signing at the DNS host. Wait until the zone is fully signed and all nameservers serve the signed data.
4. Verify the signed zone with dig DNSKEY and the DNSSEC Checker before touching the registrar.
5. Obtain the DS record values from the DNS host: key tag, algorithm, digest type and digest.
6. Add the DS record at the registrar (or via an automated mechanism if both support CDS/CDNSKEY).
7. Verify the full chain again, and test from validating resolvers.
8. Monitor. Keep an eye on expiry of signatures and alerts from the DNS host.

Choose a provider that manages signing automatically. Manual signing with self-managed keys is a legitimate choice for some operators but is error-prone for a small site.

Disabling or moving providers safely

The order is the reverse, and it is the part people skip.

1. Remove the DS record at the registrar first.
2. Wait for the DS record's TTL to expire (and a little longer) so resolvers stop expecting signatures.
3. Only then disable signing at the DNS host or change nameservers.

Removing signing before removing the DS makes the zone appear tampered with, and validating resolvers will fail it. When moving DNS providers, either remove the DS beforehand and re-enable DNSSEC at the new provider afterwards, or use a procedure that keeps both providers signing in compatible ways (multi-signer setups are advanced and need support from both sides).

Key rollovers

Keys should be replaced periodically or after exposure. There are two approaches.

• ZSK rollover: usually automated by the DNS provider using pre-publication of the new key, signing with it, then retiring the old one. No registrar action is needed, because the DS refers to the KSK.
• KSK rollover: requires updating the DS at the parent. The safe order is to publish the new KSK in the zone first, add the new DS at the registry while keeping the old one, wait for caches to expire, switch signing, then remove the old DS and old key. Some TLDs and providers support automated DS updates through CDS and CDNSKEY records, reducing manual steps.

Always keep both the old and new material in place during the overlap, and wait for the relevant TTLs, to avoid a window where some resolvers have cached one and some the other.

Is it worth it?

DNSSEC is valuable when forged DNS answers would do real damage: banks, government sites, email domains that rely on DNS-based authentication or on DANE, software update hosts, and organisations with a regulatory expectation. Some TLDs and sectors encourage or require it.

Reasons to be cautious:

• It adds an operational dependency: expired signatures or a stray DS record cause outages.
• It only helps users behind validating resolvers.
• It does not replace TLS, which already authenticates the site's identity to the browser.
• It is only as strong as the registrar and DNS host accounts that control it.

For a small brochure site on a managed DNS service that offers one-click DNSSEC with automatic DS publication, enabling it is low-risk and mildly beneficial. For a domain with manual DNS processes, multiple providers, or frequent migrations, weigh the operational cost first. Whatever you choose, monitor it: an uptime check that queries from several networks will catch failures local tests miss, and a status tool like Down From Where can reveal regional or resolver-specific outages.

Next steps

• Test the full chain with the DNSSEC Checker.
• Confirm delegation and the DS record's parent using the Nameserver Lookup and WHOIS Lookup.
• Review the basics in DNS explained for website owners and how long DNS propagation takes.
• Make sure registrar access is secure by reading domain expiry, grace and redemption.

FAQ

Does DNSSEC encrypt my DNS traffic?

No. It signs records so their origin and integrity can be verified, but queries and answers still travel in the clear unless you use a separate transport such as DNS over TLS or DNS over HTTPS.

Why does my site fail only for some visitors after enabling DNSSEC?

Only validating resolvers enforce DNSSEC. If your DS record does not match your zone's keys, those resolvers return SERVFAIL while non-validating ones still answer, so the problem looks intermittent and regional.

What is the DS record and who publishes it?

The DS record is a digest of your key-signing key. It is published in the parent zone, which for a .com domain means the registry, and you add it through your registrar. Without it, your signed zone is simply treated as unsigned.

Can I turn DNSSEC off if something breaks?

Yes. Remove the DS record at the registrar first, wait for its TTL to pass, and then disable signing. Doing it in the other order creates a failure window. Until the DS is gone and caches expire, validating resolvers may continue to fail.

Do I need DNSSEC if I already use HTTPS?

They solve different problems. HTTPS protects the connection and verifies the site's certificate, while DNSSEC protects the lookup that sends users to the right server. Many sites run HTTPS without DNSSEC; adding it is a risk-and-benefit decision, not a requirement.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.