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 resolver has established that there is no authentication chain from its trust anchors to the data; the data may still be signed. It does not establish the zone operator’s intent. Bogus means a chain is expected but validation fails. Indeterminate means the resolver lacks enough information to decide whether the data should be signed.

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.

Worked example: signatures without an authentication chain

These are synthetic lab observations, not live claims about example domains. Use a resolver you trust over a trusted channel. Querying with +dnssec requests DNSSEC records; dig does not become a full validating resolver merely because that option is present.

$ dig @192.0.2.53 signed.example. A +dnssec
;; status: NOERROR; flags: qr rd ra
signed.example. 300 IN A 192.0.2.80
signed.example. 300 IN RRSIG A ...
$ dig @192.0.2.53 signed.example. DS +dnssec
;; status: NOERROR; ANSWER: 0
;; authority: signed NSEC/NSEC3 proof of no DS (abbreviated)

Worked example: investigate a bogus chain

In a second lab, the parent DS refers to an old key that the child no longer publishes. A validating lookup returns SERVFAIL. A diagnostic query with checking disabled returns data, narrowing the investigation toward validation without proving the precise cause.

$ dig @192.0.2.53 broken.example. A +dnssec
;; status: SERVFAIL
$ dig @192.0.2.53 broken.example. A +dnssec +cdflag
;; status: NOERROR; flags: qr rd ra cd
broken.example. 300 IN A 192.0.2.81

Practice: classify evidence and plan recovery

Spend ten minutes classifying three cases: an authenticated chain and valid signature; authenticated no-DS proof with no other trust anchor; and a published DS whose matching child key is missing. Then list what evidence you still need if necessary DNSSEC records cannot be fetched.

• Expected states: Secure, Insecure and Bogus respectively. Insufficient evidence may be Indeterminate; it is not proof of an intentionally unsigned zone.
• For the bogus case, coordinate parent and child changes using the key-rollover plan and cache lifetimes. Never remove a DS casually as a repair shortcut.
• Retest through validating resolvers after correction and confirm the expected authentication status; remove any temporary diagnostic exceptions.

DNSSEC proves origin and integrity within a trust policy. Authority, record presence, encryption, and successful validation are four different facts.