DNSSEC and the chain of trust

What DNSSEC does—and does not do

DNSSEC lets a validating resolver verify that DNS data is authentic and has not been altered since it was signed. It does not encrypt DNS queries or hide which names a client requests. Confidentiality requires a separate transport such as DNS over TLS or DNS over HTTPS.

A signed zone publishes DNSKEY records and signatures called RRSIG records. A validator uses the public key to verify the signature over a record set.

How the chain of trust works

Trust begins with a configured trust anchor, normally for the DNS root. A parent zone publishes a DS record that identifies a key in its signed child zone. The validator checks the parent, follows the DS reference to the child’s DNSKEY, and then validates the child’s signed records.

• DNSKEY publishes the zone’s public signing keys
• RRSIG contains a signature over a DNS record set
• DS in the parent points to a trusted key in the child
• NSEC or NSEC3 provides authenticated denial of existence

Understand validation results

Secure means the answer validated through a chain of trust. Insecure means the namespace is intentionally unsigned, so no DNSSEC authenticity claim is available. Bogus means signatures or the chain failed validation. Indeterminate means the validator could not determine a status.

Bogus responses commonly surface to clients as SERVFAIL. Check time synchronization, expired signatures, incorrect DS records, key rollovers, and delegation before disabling validation.

Operations matter more than the first signature

DNSSEC success depends on repeatable key rollover, signature refresh, monitoring, and coordination with the parent zone. Automation should make state visible and reversible. A stale DS record can make an otherwise healthy zone unreachable to validating resolvers.

DNSSEC protects the authenticity of DNS data. It does not make DNS private.