Trust anchor
A validating resolver begins with a configured public key, normally for the DNS root.
DNSSEC
Cryptographic proof for DNS data
DNSSEC lets validators verify data origin and integrity, including proof that signed data does not exist. It does not conceal names or answers, and it does not make the authoritative service available.
The chain of trust
Trust descends through delegations
Parent DS
The parent’s signed DS RRset identifies a key in the child zone.
Child DNSKEY
The matching DNSKEY validates the child’s DNSKEY RRset and establishes trusted keys for that zone.
RRSIG
A trusted DNSKEY verifies the signature over the requested RRset.
What is signed
DNSSEC signs RRsets, not packets or connections
An RRSIG covers an RRset’s owner, type, class, original TTL and record data, together with signature metadata. The DNS response may travel over UDP, TCP, TLS, HTTPS or QUIC; validation is independent of that transport.
Signatures have inception and expiration times. Validators therefore require a reasonably correct clock. A severely incorrect clock can make valid signatures appear not yet valid or expired.
The AD bit is a statement by the resolver.
A stub that trusts its recursive resolver can use the Authenticated Data bit as an indication that validation succeeded. On an untrusted last hop, the bit itself can be altered unless the transport or local channel is protected.
DNSKEYPublishes a zone’s public verification keys.
DSConnects the parent’s signed delegation to a child key.
RRSIGProvides the signature for a specific RRset.
NSEC / NSEC3Authenticates non-existence and wildcard boundaries.
Secure, insecure, bogus
Validation produces a security state
- Secure
- A complete valid chain leads from the trust anchor to the answer.
- Insecure
- The delegation is provably unsigned. The answer can be used, but DNSSEC provides no authenticity.
- Bogus
- The data should validate but does not—for example because a signature expired, a DS no longer matches, or data was modified.
- Indeterminate
- The resolver cannot determine a trustworthy state with the information available.
A validating resolver normally returns SERVFAIL to ordinary clients for bogus data. Bypassing validation may restore reachability, but it removes the protection that exposed the fault.
Authenticated denial
Proving that something is absent
NSEC
Links existing names in canonical order and lists the record types present at each name. A validator can prove that the requested name or type falls into a gap.
Operationally simple and efficient, but enables straightforward zone walking.
NSEC3
Uses hashes of owner names to make casual enumeration less direct. Opt-out can reduce signing cost for delegation-heavy zones.
It mitigates simple walking, but dictionary attacks remain possible for predictable names.
DNSSEC is an authenticity mechanism, not a confidentiality mechanism. Publishing a signed name still publishes that name.
Key management
Signing is an operational process, not a one-time command
A zone must keep signatures fresh, protect private keys, publish DNSKEY changes in the right order and coordinate DS updates with the parent. Many modern deployments use a combined signing key; others retain separate key-signing and zone-signing roles.
Offline or tightly isolated key handling reduces exposure of high-value private material, but increases procedural complexity. Automation should be observable and recoverable rather than opaque.
Safe rollover sequence
- Introduce new key material while the old chain still validates.
- Allow caches to learn the new DNSKEY RRset.
- Update or activate signatures according to the rollover method.
- Change the parent DS only when the corresponding child key is safely published.
- Wait through relevant TTLs and signature lifetimes before removing old material.
Validation tools
Check the chain from several angles
Ask for signatures
dig example.com A +dnssecInspect keys
dig example.com DNSKEY +multilineInspect the parent link
dig example.com DS +dnssecValidate locally
delv example.com A