Summary

  • RFC 3655 changed the AD bit from a broad server-policy label into a narrower indication that relevant DNSSEC data had been authenticated under the revised rules.
  • The bit was a report by a resolver, not a signature on the DNS reply or proof that the resolver, its network path, or the user's chosen trust policy was sound.

Analysis

The useful scene is a small application asking a stub resolver for a name. The stub does not carry the full DNSSEC machinery; it forwards the query to a recursive resolver that can follow the chain of keys, fetch signatures and cache the result. When the answer comes back, a single header bit can tell the stub something about work performed upstream. The difficult question is not how many bits the header has. It is who is entitled to make that assertion, and what evidence the assertion represents.

RFC 2535 had assigned the Authenticated Data (AD) bit a broad meaning: a server said that answer and authority data were authenticated according to its policy. RFC 3655, published in November 2003, argued that the original signal was not useful in practice. A conforming server should already avoid returning data that failed its security policy; a bit that mostly described the server's general filtering posture did not help an application distinguish the security status of this answer.

The revision made the hand-off more specific. A recursive server was not to set AD unless the relevant RRsets in the answer and authority sections met the authentication conditions. It should set the bit when the answer records—and the relevant records supporting a negative answer—were authenticated. The point was not that every DNS packet had acquired its own signature. DNSSEC signatures authenticate resource-record sets; the AD bit summarizes a resolver-side judgment about the records in this response.

That distinction also explains why the DNS header's DO and CD bits cannot be collapsed into AD. DO asks for DNSSEC records to be included; RFC 3655 required DNSSEC records to have been requested and relevant SIG records to be returned before AD could be set. CD means checking is disabled for the query. It did not automatically erase an AD result: a server could still mark data already verified or acceptable under its local policy. These bits describe different stages—requesting evidence, controlling checks, and reporting a result.

RFC 3655 made the recursive resolver an intermediary of trust. A host could spare every application from implementing a full validator and could reuse cached validation work. But a stub could not treat AD as self-authenticating. The resolver had to be explicitly trusted, and the communication had to be protected—through a secure channel or message authentication such as TSIG or SIG(0). Otherwise, a bit set by an on-path responder was only a claim about validation, not validation evidence delivered securely.

The authoritative-server rule exposed another seam. An authoritative server for a secure zone could be configured to set AD, but it had to be an explicit choice and off by default. The document recognized that authoritative servers were not required to validate their own zone data; signature verification on load or on every query could impose operational cost. Therefore a clear AD bit in a direct authoritative reply was not a default guarantee that the server had performed recursive-style validation. A client needed to know the server's policy and trust relationship.

The default-clear case is easy to misread. RFC 3655 said an insecure answer must not carry AD, but a clear bit alone did not tell the consumer whether the data was insecure, the resolver had not checked it, a requested DNSSEC record was absent, or the server chose not to assert the status. A positive bit had a defined meaning only inside the trust arrangement; a negative bit was not a complete diagnosis.

Two years later, RFC 4033, RFC 4034 and RFC 4035 revised the DNSSEC framework and obsoleted RFC 3655. The AD hand-off remained part of the architecture, but the 2005 documents placed it within a more complete account of validators, stubs, authoritative servers and authentication paths. RFC 3655 is best read as a repair to one narrow interface: how a recursive resolver's assessment could reach an application without pretending that the header bit itself was cryptographic proof.

The evidence ladder is consequently layered. An RRSIG can support authentication of an RRset under a key chain and trust anchor. A validating resolver can make a local status decision. The AD bit can report that decision in a reply. A secure, trusted resolver channel can bind the reply to the resolver the consumer chose to rely on. None of those facts by itself proves that a name's registrant is honest, that the information is current for an application, or that the application acted safely.

Sources