Read the Trust Chain Behind a DNSSEC Answer

Identify the RRset behind the answer

An RRset is a group of resource records sharing an owner name, class and record type. Two address values can belong to one RRset; an address record and a mail-routing record at the same name belong to different sets. RFC 9499, published in March 2024, clarifies this grouping.

The DNS Security Extensions, DNSSEC, authenticate these sets. An RRSIG record carries a signature and identifies the covered record type and signing key. RRSIG records are an exception to the grouping rule: they accompany the RRsets they cover rather than forming an RRset themselves. A DNSKEY record holds the public key used to check the signature; the corresponding private key produces it.

RFC 9364's February 2023 overview connects the March 2005 core specifications with later clarifications. It describes authentication of DNS data, the object evaluated here.

References: [T1][D4][D3]

Connect the signing key to the validator's trusted starting point

A matching public key is not its own reason to trust an answer. The validator needs an authenticated connection from that key to a trusted starting point. A trust anchor is a configured DNSKEY or DS-based key digest obtained through a trusted means outside ordinary DNS resolution.

At a signed parent-to-child delegation, the parent's Delegation Signer record, DS, identifies a child DNSKEY through a digest. The DS belongs to the parent zone; the corresponding DNSKEY belongs to the child. Starting from an authenticated parent, the validator authenticates the DS, matches the child key and uses that key to verify the child's DNSKEY RRset. Keys in that authenticated set can then authenticate the child's signed data. Further delegations repeat the relationship.

The validator also checks that the signature applies to this RRset and that its validity interval includes the validator's current time. RFC 4035 supplies those prerequisites. Successful signature mathematics with an untrusted key does not complete the chain.

Multiple signatures do not mean every supplied signature must succeed. RFC 6840 section 5.4 says a resolver should accept any valid RRSIG as sufficient. The useful evidence identifies the accepted authentication path, rather than merely listing DNSKEY, DS and RRSIG records that happened to be received.

References: [T1][D4][D2][D5]

Distinguish insecure data from a broken expected chain

Use RFC 4033 section 5's foundational meanings for the four state names here. Secure means the validator has an applicable trust anchor, a chain of trust and successful validation. Insecure includes a chain reaching authenticated proof that a delegation has no DS; local policy can also designate insecure space. Bogus means a trust anchor and secure delegation establish an expectation of signed data, but validation fails. Indeterminate means no trust anchor establishes that the relevant portion of the tree should be secure.

RFC 9499 notes that RFC 4033 and RFC 4035 define these states somewhat differently and does not reconcile them. In particular, the meaning of indeterminate above is the explicitly named RFC 4033 meaning.

The distinction matters when comparing reports. Authenticated absence of a DS explains why an ordinary delegation chain does not authenticate the child data. It does not authenticate those address values. A chain that requires authentication but cannot validate its data is a different finding.

References: [D1][T1]

Read AD through the resolver and channel relationship

A nonvalidating stub is a minimal client resolver that delegates validation to a recursive resolver. Its reliance needs both a trusted resolver and a channel providing integrity and message authentication. A validation result reached elsewhere does not, by itself, protect the result's delivery to that stub.

The Authenticated Data flag, AD, is a resolver's signal subject to that relationship. Its absence is not a universal bogus result. RFC 6840 sections 5.7 and 5.8 tie response signaling to whether the requester indicated interest through query AD or DNSSEC OK, DO. A response can therefore omit AD without proving that its data failed validation.

For a report about application-visible DNS results, identify who performed validation and how the client received the assertion. A screenshot containing a flag leaves that trust boundary unexplained.

References: [D1][D5]

A 600-second TTL can allow only 180 seconds of authenticated caching

TTL, or time to live, and signature validity measure different limits. RRSIG's Original TTL preserves the covered RRset's original value for validation while received cache TTLs decrease. Its inception and expiration fields define when the signature can authenticate the data.

RFC 4035 section 5.3.3 requires the accepted RRset and its RRSIG to receive TTLs no greater than the lowest of four quantities: the received RRset TTL, the received RRSIG TTL, the RRSIG Original TTL and the time remaining until signature expiration.

Consider an original hypothetical direct address answer, without aliases or wildcard expansion. At time 0 seconds, stipulate an accepted authentication chain, one accepted signature whose inception is already past, a correct validator clock and all other validation prerequisites. The received RRset TTL is 600 seconds, the received RRSIG TTL is 600 seconds, and Original TTL is 600 seconds. Signature expiration is 180 seconds away. All other chain material remains usable throughout the example.

The upper authenticated cache lifetime is min(600, 600, 600, 180) = 180 seconds. The three 600-second values cannot extend the accepted signature's validity.

At time 60 seconds, without replacement or a newly accepted signature, that ceiling has 180 - 60 = 120 seconds left. If the resolver initially selected the maximum permitted TTL and retained the entry, 120 seconds remain in that stipulated entry's lifetime. A shorter assigned TTL or earlier eviction can leave less, or no entry at all.

This is a bound on the stated authenticated cache claim. It supplies no guarantee of retention or refresh success. Reaching the ceiling also does not show that the address value changed: the same value could later arrive with a new valid signature. All durations and events are illustrative assumptions, not observed resolver behavior.

References: [D4][D2][T1]

An authenticated destination can still fail the buying requirement

Extend the fictional case with a buyer requirement: the returned destination must serve an application that exposes the buyer's approved model revision R2. Stipulate that the authenticated address instead leads to an otherwise reachable endpoint exposing only R1. These are invented application conditions, independent of the DNS validation premises.

At time 60 seconds, the retained RRset can still be authenticated within the calculated limit while its destination fails the R2 requirement. No signature needs to be forged or expired for both statements to be true. Authentication supports accepting the DNS data's origin and integrity under the validator's trust basis; it does not turn the published address into an application acceptance result.

DNSSEC itself supplies neither query confidentiality nor requester access control. Application authorization and evidence of the required model behavior need their own basis.

Suppose a supplier report cites this answer's 600-second TTL and successful DNSSEC validation as proof of 600 seconds of authenticated R2 service readiness. Its claim crosses two unsupported steps. The accepted signature limits the initial authenticated cache lifetime to 180 seconds, and authenticating the address supplies no R2 application result. Even correcting 600 to 180 would leave the application claim unresolved.

A useful report identifies the RRset, validating resolver, accepted trust path, observation time and applicable lifetime, then supplies separate application evidence against the R2 requirement. The buyer can accept the DNS authentication evidence while withholding acceptance of the overstated service-readiness claim.

References: [D1][D3]

Use the cache guides, then scope any separate physical work

The related DNS TTL article explains retained addresses and reuse of existing connections. Name absence, missing record types and resolution failures are separate questions from whether DNS data is authenticated.

If the endpoint project also requires installed fiber or copper connections, the related Structured Cabling & Fiber Installation service and project inquiry can address that physical package. Share a nonconfidential outline of endpoints, approved routes, materials responsibilities, labels and required connection records. DNS validation remains with the appointed platform owner.

References: [L1]