Summary

  • A validating recursive resolver sets the DNSSEC AD bit when it regards the relevant Answer and Authority data as authentic; the bit reports that resolver's conclusion, not a self-proving property of the packet.
  • A non-validating stub may rely on that conclusion only when it trusts the recursive resolver and protects or authenticates the channel to it. A validating stub should perform its own validation.
  • DNSSEC validation, delivery of the resolver's verdict and the application's eventual decision are separate evidence boundaries; a missing AD bit is not by itself a diagnosis of bogus data.

One illuminated bit at the end of substantial work

A laptop asks its configured recursive resolver for a name. Behind the answer, the resolver may have followed delegations, fetched DNSKEY and DS records, built a chain toward a trust anchor, checked signatures, handled authenticated denial and classified the resulting data. The response that returns to the laptop has room for none of that history. It can instead carry a single header flag: Authenticated Data, or AD.

That compression is useful. A small client does not always need to repeat work already performed by a capable resolver. But compression also removes context. If an interface renders AD=1 as “secure,” the user may reasonably assume that the entire path, destination and requested action have been certified. The RFCs make a narrower claim.

RFC 4035 says a security-aware recursive name server sets AD only when it considers all RRsets in the Answer and Authority sections of the response authentic. The operative subject is the resolver: it evaluated DNS data using its anchors, policy and view of the response. The flag is an output of that evaluation. It is not a signature over the DNS header and it does not carry the evidence needed for a stranger to independently reproduce the conclusion.

This distinction is central to the DNSSEC specification suite on which Scott Rose is named as a co-author with Roy Arends, Rob Austein, Matt Larson and Dan Massey. Their design did not ask a small flag to become universal proof. It defined where validation could occur, how a resolver could communicate its result and what trust was still required at the next boundary.

Four states do not fit into one flag

RFC 4033 describes four broad outcomes for security-aware resolution: Secure, Insecure, Bogus and Indeterminate. Secure data has a valid chain under an accepted trust anchor. Insecure data has a provable unsigned status. Bogus data ought to validate but fails the checks. Indeterminate data cannot be assigned one of the other states under the available information or policy.

AD does not serialize those four states. A set bit communicates the positive authenticated-data result required by the resolver rules. An unset bit can arise for more than one reason. The data may be properly insecure, validation may not have been requested in a way that causes the flag to be returned, the resolver may not validate, or the answer may have encountered another state or policy. Treating AD=0 as a universal “DNSSEC failed” alarm discards the very distinctions the protocol provides.

RFC 6840 makes query behavior especially important. A requester may set AD in a query to say it understands and is interested in the flag even when it does not request DNSSEC records with the DO bit. A validating resolver should return AD only when the validation condition is satisfied and the query carried DO or AD. Consequently, identical validated data can arrive without the flag to a client that expressed neither capability. Absence alone cannot reconstruct the resolver's full state.

Nor is a positive bit a statement that every resolver would reach the same conclusion. Trust anchors can differ. Local policy can differ. Time, cached data and the exact response can differ. DNSSEC defines verification machinery; the bit reports one resolver's application of that machinery to this response.

The bit cannot protect the packet that carries it

Suppose an attacker can alter traffic between the stub and its recursive resolver. The attacker does not need to forge a DNSSEC signature to mislead a client that blindly trusts AD. It may change an unsigned header bit, substitute a response or interfere with the channel. The client would then be trusting an assertion whose transport it never authenticated.

RFC 3655 stated this boundary before the final DNSSEC protocol documents: a security-oblivious stub must not blindly trust the AD bit unless it communicates with a trusted security-aware recursive resolver over a secure transport or uses message authentication. RFC 4033 carries the same architecture forward. A stub relying on another party's validation must trust both the recursive server and the channel between them. For this particular property, integrity and authentication matter; confidentiality is not what makes the verdict reliable.

The requirement has two independent halves. A protected channel to an untrusted resolver merely proves which untrusted party supplied the answer. A trusted resolver reached through an alterable channel cannot vouch for what finally arrived. Only the combination supports delegated validation.

A validating stub takes a different course. RFC 4035 says it should ignore the AD bit and perform its own validation. It can use the response's DNSSEC records as inputs, but its verdict comes from checking the chain under its own trust configuration. The received bit may be an observation; it is not the authority for the result.

Trusting a resolver is a concrete operating relationship

“Trusted resolver” can sound like a product label. The specifications make it an operational relationship. The client must know which resolver it intends to use, authenticate the exchange by an appropriate mechanism and understand that the resolver is applying a validation policy acceptable for that client. Address configuration alone is not evidence that every network between them preserves the claim.

This is why moving validation into a central recursive service changes governance as well as computation. The service chooses trust anchors, software versions, exception handling and failure policy. It decides how long results remain cached and how incidents are surfaced. Clients inherit those choices when they consume only the summarized result. Central validation may be exactly the right architecture, but the AD bit does not make the dependency disappear; it makes the dependency compact.

Rose's career context helps explain why the boundary remains current. His NIST profile describes work on Internet infrastructure protection and secure protocols. NIST's March 2026 revision of its Secure Domain Name System Deployment Guide, co-authored by Rose, Cricket Liu and Ross Gibson, addresses DNSSEC as a deployed operating system rather than a ceremonial feature. A signed zone is only one component. Resolver configuration, protected use of validation results and monitoring determine whether the evidence reaches a decision intact.

Attribution should remain precise. Rose was one of five authors of RFC 4033, RFC 4034 and RFC 4035; he did not single-handedly invent DNSSEC or control its implementations. RFC 3655 and RFC 6840 come from different author groups. His relevance lies in the durable architecture the core suite helped establish: authentication has a scope, and the consumer must know whose conclusion it is receiving.

A DNS verdict is not an application verdict

Even a correctly produced and securely delivered AD result ends at the DNS-data boundary. It can support the conclusion that named RRsets were authenticated under the resolver's DNSSEC chain. It does not prove that a web server is uncompromised, a mail recipient is authorized, an IP address is benign, a certificate is acceptable, content is safe or a transaction should proceed.

Applications combine DNS with other controls: TLS authentication, certificate and name checks, account authorization, content policy, freshness constraints, business rules and user intent. Some protocols deliberately consume DNSSEC-authenticated records as part of a larger decision. That is valuable composition, but it remains composition. The application must specify which record, resolver verdict, channel property and later check justified the action.

An audit trail that saves only AD=true erases those dependencies. A better record separates at least three events: the resolver's validation status and policy, the authenticated delivery of that status to the client, and the application's use or rejection of the returned data. If the final action later proves wrong, investigators can then ask whether validation failed, the verdict was altered in transit, or the application assigned the DNS result more authority than it possessed.

The Authenticated Data bit is therefore neither trivial nor magical. It is a compact statement made by a particular validator about particular DNS data. Its disciplined use preserves the work performed by that validator without converting borrowed trust into end-to-end proof.

Sources