DNSSEC and the chain of trust

DNSSEC lets a validating resolver detect whether DNS data is authentic to a signed zone and unchanged in transit. It does not encrypt DNS queries, hide the queried name, or prove that a website or email sender is trustworthy.

The records in the chain

Type	Role
DNSKEY	Publishes public keys for a signed zone
RRSIG	Carries a signature over an RRset
DS	Lets a parent authenticate selected key material in a delegated child
NSEC / NSEC3	Authenticates denial of existence

RFC 4034 defines these record formats and their wire meaning [2].

Start from a trust anchor

A validator cannot establish trust merely because a DNSKEY claims to be valid. It starts with a configured trust anchor, normally for the DNS root, and works down delegations.

A simplified chain is:

configured root trust anchor
  └─ validates the root DNSKEY and root signatures
       └─ root DS authenticates the TLD DNSKEY
            └─ TLD DS authenticates the child DNSKEY
                 └─ child DNSKEY validates the child RRset signature

At each signed delegation, the parent-side DS record connects trust to key material published in the child zone. RFC 4035 defines how validators use these records and signatures [3].

Signing and validation are different jobs

An authoritative DNS operator signs zone data and publishes DNSKEY and RRSIG records. The registration path publishes the DS record in the parent. A validating recursive resolver evaluates the resulting chain for a client.

That creates separate owners:

• DNS host: keys, signatures, and signed child-zone data;
• registrar or registry path: parent DS submission and removal;
• recursive resolver: validation policy and result;
• application: decides how to handle a resolver failure.

A control panel showing “DNSSEC enabled” is not enough. Verify the parent DS, child DNSKEY, signatures, and a validating resolver result.

Secure, insecure, bogus, and indeterminate

DNSSEC validation distinguishes useful states [1]:

• Secure: the validator built a valid chain to a configured trust anchor.
• Insecure: the chain proves or indicates an unsigned delegation, so the answer is not DNSSEC-authenticated.
• Bogus: DNSSEC was expected, but signatures, keys, denial proofs, or chain data failed validation.
• Indeterminate: the validator could not determine a conclusive state.

An unsigned zone is not automatically bogus. A stale parent DS pointing to keys the child no longer serves commonly makes the child bogus.

Validating resolvers often surface bogus data as SERVFAIL rather than return an unauthenticated answer.

Authenticated denial

DNSSEC must authenticate absence as well as presence. NSEC and NSEC3 records support proofs that a name or record type does not exist in a signed zone.

This is different from an ordinary cached NXDOMAIN response. The validator checks the denial proof and signatures before treating the negative answer as secure.

DNSSEC does not encrypt DNS

Ordinary DNSSEC records and signatures are public DNS data. They provide origin authentication and integrity for DNS answers, not query confidentiality.

Encrypted transports such as DNS over HTTPS or DNS over TLS protect a client-to-resolver transport. They do not replace DNSSEC’s resolver-to-data authentication model. The two solve different problems.

Where migrations break

An authoritative provider migration changes the keys and signatures that may be served. If the old DS remains at the parent after the child starts serving unrelated new keys, validators follow the old chain and reject the new data.

Operational options include:

• a carefully coordinated multi-signer or key transition supported by both providers; or
• an intentional insecure interval: remove DS, wait for cached DS data to expire, change authoritative service, then establish and verify the new DS.

Do not delete the parent DS and immediately assume every validator has forgotten it. Do not stop child signing before the DS cache lifetime has safely elapsed during a rollback.

RFC 6781 discusses DNSSEC operational timing, rollover, and preserving the chain of trust [4].

Diagnose a validating failure

Capture:

1. DS records from the parent and their TTL;
2. DNSKEY records from every intended child authoritative server;
3. RRSIG records and signature inception/expiration;
4. authoritative positive or denial response;
5. result from a named validating resolver;
6. exact response code, flags, and observation time; and
7. any recent registrar, nameserver, key, or signing change.

Then identify the first point where the chain no longer matches. Do not disable DNSSEC merely because a resolver returned SERVFAIL; first establish whether validation is the cause.

Next step

Use the safe DNS-change checklist before altering delegation, DNSSEC, address, web, or email records.