How DNSSEC works is easier to understand if you separate two jobs. DNS still finds records such as an IP address. DNSSEC adds signatures that let a validating resolver check where that DNS data came from and whether it changed in transit.
It does not encrypt a DNS query, hide the domain being requested or prove that the website behind an authenticated address is safe. DNSSEC authenticates DNS data. Other protocols handle privacy, transport security and application trust.
Standards checked: RFC 4033, RFC 9364 and RFC 9499 were reviewed on 26 October 2026. This explainer focuses on the validation chain and its limits.
The short version
A signed zone publishes public keys in DNSKEY records and signatures in RRSIG records. A parent zone can publish a DS record that points to a child’s DNSKEY. A validating resolver starts from a configured trust anchor, usually for the DNS root, and follows that signed chain toward the record it was asked to resolve.
RFC 4033 describes four validation states:
- Secure: the resolver has a trust anchor, builds the chain and verifies the signatures.
- Insecure: the chain proves that a delegation is unsigned.
- Bogus: the zone is expected to be signed, but validation fails.
- Indeterminate: the resolver has no suitable trust anchor to decide.
A signature failure can therefore break resolution even when the authoritative server still holds the record.
Start with an RRset, not a whole zone file
DNS answers are grouped into resource record sets, or RRsets: records with the same owner name, type and class. DNSSEC signs an RRset. The signature is stored in an RRSIG record.
DNSSEC does not place one signature over every record in a zone. Different RRsets have their own signatures and validity periods. A resolver verifies the answer it received with the appropriate public key.
| Record | What it does |
|---|---|
| DNSKEY | Publishes a zone’s DNSSEC public key |
| RRSIG | Carries a signature over an RRset |
| DS | Links a parent delegation to a child DNSKEY |
| NSEC or NSEC3 | Proves that a name or record does not exist |
Private keys remain with the zone operator. The public DNSKEY is distributed through DNS so validators can check signatures.
The chain begins at a trust anchor
A signature is only useful if the validator can trust the key that verifies it. RFC 4033 calls the configured starting key or key hash a trust anchor.
In the common root-based model:
- the resolver already trusts the root DNSKEY;
- the root zone signs a DS record for a top-level domain;
- that DS record matches a DNSKEY in the child zone;
- the child signs another DS record for the next delegation;
- the final zone’s DNSKEY verifies the RRSIG over the requested RRset.
The pattern is DNSKEY → DS → DNSKEY → signed RRset. The resolver repeats the DS-to-DNSKEY step for each signed delegation.
A DS record contains a digest of a child key and lives in the parent zone. The parent can therefore vouch for the child’s key without holding the child’s private key.
Signing and validation are separate
The authoritative side signs zone data and publishes supporting records. The recursive resolver validates what it receives.
A device may not validate directly. It may ask a recursive resolver operated by a network, company or public DNS provider. The device then depends on that resolver and on the channel between them. RFC 4033 notes that a non-validating stub must trust the recursive service performing the checks.
This is why DNSSEC and encrypted DNS are not substitutes. DNS over HTTPS and DNS over TLS protect the channel between a client and resolver. DNSSEC authenticates DNS data through signatures. A deployment can use both.
The browser or operating system may also show a validation failure as an ordinary DNS error. The resolver can know that data is bogus while the application says only that the name did not resolve.
How absence can be authenticated
A forged response could claim that a domain or record does not exist. DNSSEC needs a way to sign that negative answer.
NSEC records link names in a signed ordering and prove that a requested name or type falls in a gap. NSEC3 hashes names and adds options intended to make simple zone enumeration harder. Both support authenticated denial of existence.
The result is evidence that the signed zone says “there is no such record,” rather than an unsigned empty answer.
Original NSEC chains can reveal the names in a zone to someone who walks the chain. NSEC3 reduces straightforward enumeration but adds operational complexity. Neither turns public DNS into a confidential database.
Key roles and rollovers
Operators often separate two roles:
- a zone-signing key signs ordinary zone RRsets;
- a key-signing key signs the DNSKEY RRset.
These are operational roles. DNSSEC validation does not inherently know the labels.
A rollover changes keys without breaking the chain of trust. Old data may remain in caches while new keys and signatures propagate, so operators need enough overlap for validators to learn the new material before the old path disappears.
The parent DS is an extra coordination point. Changing a referenced key requires the parent and child views to remain consistent. A missing or stale DS can make an otherwise healthy zone validate as bogus.
The BGP route leaks and hijacks explainer covers a different internet control plane, but the operational lesson is similar: a small configuration error can have a wide reach.
What the four states mean
Secure
The resolver builds a chain from a trust anchor to the answer and verifies every required signature. Secure means the DNS data authenticated successfully. It does not say whether visiting the returned service is wise.
Insecure
A signed parent proves that the child delegation has no DS record. The resolver establishes that the branch is unsigned and returns the data without DNSSEC authentication.
Bogus
The chain says signed data should be available, but a check fails. Causes can include an expired signature, a missing signature, an unsupported algorithm or inconsistent delegation data. A resolver normally withholds bogus data.
Indeterminate
The resolver lacks a trust anchor that covers the answer, so it cannot decide whether the data is secure. This differs from a proved unsigned delegation.
What DNSSEC protects
RFC 4033 says DNSSEC provides data-origin authentication and integrity protection for signed DNS data. It also supports authenticated denial of existence and public-key distribution.
This can stop an attacker from substituting a forged signed answer without detection, provided the validator has a valid chain and uses the result correctly.
DNSSEC can support other protocols that publish security information in DNS. Those uses still have their own rules; DNSSEC provides authenticated DNS data, not the complete security property by itself.
What DNSSEC does not protect
Confidentiality. RFC 4033 is explicit that DNSSEC does not encrypt queries or responses. An observer may still see the requested name.
Website content. A valid address record authenticates the DNS answer. HTTPS still authenticates and encrypts the web connection. A correctly signed domain can host malicious content.
Denial of service. DNSSEC does not prevent a flood, and signature validation adds cryptographic work that can itself be abused.
Unsigned data. A resolver cannot authenticate records below a delegation that is proved insecure.
Every DNS operation. Some non-authoritative glue and zone-transfer concerns need other protections.
Correctness at the source. If an authorised operator signs the wrong address, the signature authenticates that wrong data. Integrity is not accuracy.
Why a valid deployment can still fail
DNSSEC adds keys, signatures, parent-child coordination and time-sensitive data. Common breakages include:
- an RRSIG expires before a replacement is published;
- a DS record points to a key that is gone;
- a DNSKEY changes without enough rollover overlap;
- clocks are wrong enough to reject a signature period;
- large responses meet a broken network path;
- a resolver or intermediary mishandles required records.
RFC 4033 warns that configuration errors can make legitimate zones unreachable. Monitoring should test from a validating resolver, not merely confirm that an authoritative server answers.
When diagnosing a failure, record the exact name and type, inspect the DS and DNSKEY chain, check signature inception and expiry times, and compare several validating resolvers. Do not permanently disable validation to hide a bogus state.
DNSSEC and HTTPS solve different problems
A useful request path has several checks:
- DNSSEC can authenticate the DNS answer.
- Encrypted DNS can protect the client-to-resolver channel.
- TLS can authenticate the server and encrypt the connection.
- The application still decides what content or action to trust.
HTTP/3 and HTTP/2 change how web data moves after name resolution. They do not replace DNSSEC or TLS.
Thinking in layers prevents a common mistake: calling a domain “secure” because one layer validated. Each layer makes a narrower claim.
A practical operator check
- Confirm the authoritative zone publishes DNSKEY and RRSIG records.
- Confirm the parent publishes the intended DS record.
- Test the full chain with a validating resolver.
- Check signature expiry and rollover schedules.
- Alert on bogus responses from outside your own network.
- Document who can update the parent DS.
- Keep an emergency rollover procedure.
For a domain you visit, missing DNSSEC does not automatically mean the site is fraudulent. It means the DNS answer lacks this authentication chain. HTTPS and other checks still matter.
