What Is DNSSEC? The Chain of Trust Explained

DNSSEC is a set of DNS extensions that signs DNS records with public-key cryptography so a resolver can prove an answer came from the zone owner and was not altered in transit. 6 record types carry the proof and its settings, and a chain of trust links them from the root zone to your domain. UpMonitor's DNSSEC probe queries a validating resolver for a zone's DNSKEY and DS records on every run and reports the zone as unsigned when neither returns. It protects nothing for a visitor, if that visitor's resolver skips validation.

What Is DNSSEC?

DNSSEC is a set of extensions to the Domain Name System that adds origin authentication and data integrity to DNS answers by attaching a digital signature to every record set a signed zone publishes. 3 RFCs define it: RFC 4033 sets the requirements, RFC 4034 defines the records, and RFC 4035 defines the protocol changes. RFC 4033 names 3 services: origin authentication, data integrity, and authenticated denial of existence for names that do not exist. Confidentiality is not on that list, so a signed answer travels in plain text. In a monitoring workflow, a signed zone that loses its DS record or lets a signature expire disappears for validating resolvers while the authoritative nameserver keeps answering. A probe therefore watches the records, not the server.

How Does DNSSEC Work? The Chain of Trust in 6 Steps

DNSSEC works by signing each record set with the zone's private key, publishing the matching public key as a DNSKEY record, and anchoring that key in the parent zone with a DS record, so a resolver can walk 6 steps from the root trust anchor down to your answer. A record set (RRset) is every record of 1 type at 1 name. The 6 steps, from the zone owner to the resolver:

1. Generate 2 keys and publish them. The zone owner creates a Zone Signing Key (ZSK) and a Key Signing Key (KSK) and publishes both public halves as DNSKEY records: flags 256 for the ZSK, 257 for the KSK with the Secure Entry Point bit set.
2. Sign every record set. The ZSK signs each record set; the KSK signs the DNSKEY set alone. Each signature is an RRSIG record with an inception and an expiration timestamp.
3. Hand the parent a DS record. The KSK is hashed into a DS record. The registrar places it in the parent zone next to the NS delegation.
4. The parent signs the DS. The parent's own ZSK signs its DS set, and the parent's KSK is hashed into a DS record 1 level up, all the way to the root zone.
5. The resolver walks down from the root. A validating resolver holds the root KSK as its trust anchor. For each level it fetches the DNSKEY set, matches the DS digest against the KSK, and verifies the RRSIG on the answer.
6. The resolver answers or refuses. Every link holds: the answer returns with the AD (Authenticated Data) bit set. Any link fails: the resolver returns SERVFAIL, rcode 2, and the client gets nothing.

3 dig commands show the 3 record types on a signed zone:

dig +short example.com DNSKEY
dig +short example.com DS
dig +dnssec +multi example.com A

The 3rd command prints the RRSIG next to the A records and shows ad in the flags line on a validating resolver. example.com is signed, so all 3 commands return records.

UpMonitor's DNSSEC probe reads the same chain from outside the zone. It queries DNSKEY and DS over DNS-over-HTTPS from Cloudflare and moves to Google only when the Cloudflare request fails outright. It reports success when at least 1 DNSKEY or 1 DS record returns. Both resolvers validate, so a zone whose own signatures fail comes back with 0 DNSKEY records; the DS still returns, because the parent signs it, and the probe reports success on either record. The probe never fetches the RRSIG and never verifies a signature itself, so a report of 0 DNSKEY and 1 DS is the signature of a chain that no longer validates. Run the free dnssec checker to see the DNSKEY and DS records a validating resolver returns for your domain.

Is DNSSEC Required, and Does It Encrypt DNS?

No on both counts: DNSSEC is optional for every zone, and it signs DNS data without encrypting it, so a signed answer is still readable by anyone on the path. No RFC and no registry makes signing mandatory, and an unsigned zone resolves everywhere, so the decision sits with the zone owner. Confidentiality is out of scope by design: RFC 4033 section 4 states that DNSSEC is not designed to provide it. What DNSSEC does protect is the answer itself. A forged answer from a cache-poisoning or on-path attacker fails validation because the attacker holds no key the chain trusts, the threat class RFC 3833 files under packet interception and name chaining. What it does not protect: a lookalike domain, which its own owner signs; the HTTP session, which TLS covers; and the last hop to a visitor behind a resolver that does not validate. That visitor still receives the forged record, if the resolver never asks for the signatures.

The 6 Record Types DNSSEC Adds

DNSSEC adds 6 record types to a zone: 4 defined in RFC 4034 (DNSKEY, RRSIG, DS, NSEC) and 2 defined in RFC 5155 (NSEC3, NSEC3PARAM). Each carries a wire type number from the IANA registry, and 5 of the 6 live in the zone itself. The 6 records, with where each one lives:

The only record the zone owner places by hand is the DS, and it goes to the registrar, not the DNS host, because the parent zone publishes it. NSEC lists the next name in the zone in canonical order, which lets anyone walk the whole zone; NSEC3 hashes the names first, so the proof still works and the zone cannot be walked name by name. CDS and CDNSKEY (RFC 7344, wire types 59 and 60) are the optional automation path: the child publishes the DS it wants and a parent that supports them pulls it in without a registrar form. RFC 9904, which replaces RFC 8624, lists algorithms 8, 13 and 15 as recommended for signing and 5 and 7 as not recommended.

DNSSEC vs DNS over HTTPS vs TLS Certificates

DNSSEC authenticates DNS data, DNS over HTTPS and DNS over TLS encrypt the path between your device and the resolver, and a TLS certificate authenticates the web server, so the 3 protect 3 different layers and none replaces another. The 3 mechanisms, from the DNS data outward:

DNSSEC signs the records at the zone. Anyone on the path reads them, and a validating resolver verifies the chain from the root trust anchor down (RFC 4033 to RFC 4035).

DNS over HTTPS and DNS over TLS wrap the query in TLS between a device and its resolver (RFC 8484 and RFC 7858). The resolver still sees every query in the clear, and neither transport proves the answer is genuine unless the resolver validates DNSSEC. UpMonitor's probe uses DNS over HTTPS as its transport to 2 validating resolvers.

A TLS certificate proves the server at the far end of the connection holds the name and encrypts the HTTP session (RFC 8446 and RFC 5280). It cannot stop a forged DNS answer from sending the browser to the wrong address first. Check the certificate chain with the free ssl certificate checker; DNSSEC checks the chain that runs before it.

DANE (RFC 6698) is the 1 place the 2 chains meet: a TLSA record in a signed zone pins the certificate, and the record's security rests on DNSSEC.

How to Enable DNSSEC and Fix the 4 Common Errors

Enable DNSSEC in 3 steps, signing at the DNS provider, adding the DS at the registrar, and waiting for the parent to publish it, and then fix the 4 errors below in the order a validating resolver meets them. The 3 enable steps:

1. Turn on signing at the DNS provider. Cloudflare, Route 53 and Google Cloud DNS all sign a zone on request; the provider generates the keys and shows you the DS values.
2. Add the DS record at the registrar. Copy the 4 fields exactly: key tag, algorithm, digest type and digest. 1 wrong character breaks the digest match.
3. Wait for the parent to publish. Allow up to 24 hours. Both halves must exist before validation works: DNSKEY at the zone and DS at the parent. The DS lands in the parent zone on the parent's own schedule; the dns propagation guide explains what sets the wait.

The 4 errors, in the order a validating resolver meets them:

1. SERVFAIL from validating resolvers only. Cause: any broken link in the chain. Fix: (1) run dig +cd to confirm the records exist without validation, then (2) run dig +dnssec level by level to find where ad disappears. Prevention: probe with a validating resolver on a schedule, and watch the DNSKEY count in the report.
2. Missing DS record. Symptom: DNSKEY present, dig DS returns nothing. The zone is signed but not anchored, so validators treat it as unsigned: no outage, and no protection. Fix: (1) add the DS at the registrar, then (2) confirm the DS is visible from every region with the free dns checker. The probe reports this state as success when DNSKEY is present, so a DNSKEY-only success is not proof of a working chain.
3. Expired RRSIG. Symptom: the zone validated last month and fails today, because the RRSIG expiration timestamp has passed. Cause: the signer stopped re-signing, after a stuck job or a migration with stale signatures. Fix: (1) re-sign the zone, or on a managed provider (2) disable and re-enable signing. Prevention: watch the expiration field.
4. Key rollover gone wrong. Symptom: SERVFAIL right after a key change. Cause: the DS at the parent still hashes the old KSK, or the old DS left before the new one arrived. Fix: (1) publish both DS records during the change, the double-DS method of RFC 6781, then (2) remove the old one after the parent's TTL. Prevention: never delete a DS on the same day you add its replacement.

After each fix, ask a validating resolver, not your own cache.

How to Check and Monitor DNSSEC Over Time

Check DNSSEC with a validating resolver on a fixed schedule, because every DNSSEC failure is silent at the nameserver and visible only to the resolvers that validate. A single check proves 2 things: the records exist, and a validating resolver returned them today. It does not prove the RRSIG will still be valid next week, because each signature carries its own expiration date. UpMonitor's DNSSEC probe runs on the monitor's schedule, asks Cloudflare then Google over DNS-over-HTTPS, and records the DNSKEY count, the DS count and the resolver that answered on every run. It fails with NO_DNSSEC_RECORDS_FOUND only when a validating resolver returns neither record, so a chain that breaks in the zone shows up as a DNSKEY count of 0 on a success report, not as a failure. It fails with DOH_QUERY_FAILED when both resolvers are unreachable. Monitors run from up to 12 regions on 6 continents. The DNSSEC answer comes from a validating resolver rather than from the nameserver, so a difference between regions points at the resolver's view, not at the zone. A zone whose DNSKEY count drops to 0 while its DS count stays at 1 has a chain the validating resolver now rejects, and that count pair is in the report at the next run.

Frequently Asked Questions

What is the difference between a ZSK and a KSK?

The ZSK signs the zone's record sets, and the KSK signs the DNSKEY set alone. The KSK is the key the parent's DS record hashes. The flags field tells them apart: 256 for a ZSK, 257 for a KSK with the Secure Entry Point bit. The split lets a zone roll its ZSK without touching the parent.

Does DNSSEC slow down DNS resolution?

Slightly, and mostly on a cold cache. Signed answers carry RRSIG records, so each response is larger, and a validating resolver fetches the DNSKEY and DS sets for every level of the chain before it answers the first query for a zone. Once those sets are cached, later answers cost close to the unsigned price.

Do all resolvers validate DNSSEC?

No, validation is the resolver operator's choice, and a zone owner cannot force it. Cloudflare 1.1.1.1 and Google Public DNS both validate, and Google documents SERVFAIL as its answer on failure. A visitor on a resolver that does not validate receives forged and genuine answers alike.

What does the AD flag mean in a dig response?

AD stands for Authenticated Data: the resolver validated every record set in the answer and authority sections. RFC 4035 forbids a resolver from setting the bit otherwise. The flag is absent on an unsigned zone, on a resolver that does not validate, and on any query that sets +cd, because the CD bit tells the resolver to skip validation.

How often do DNSSEC signatures expire?

Each RRSIG carries its own expiration timestamp, and the signer chooses the validity window. RFC 6781 section 4.4.2 covers the choice and sets no fixed number. A managed provider re-signs on its own cycle before the window ends. The failure mode is a signer that stops, so the date to watch is the expiration on the signature over the DNSKEY set.