Redefinition of DNS Authenticated Data (AD) bit
obsoleted by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updates
- rfc-2535 — Domain Name System Security Extensions
Extracted elements (23)
Authoritative servers are permitted (with explicit configuration) to set the AD bit without re-verifying signatures because the cost of verifying all signatures on zone load is high and increases startup delay; signature verification at query time could cause resolver timeouts after zone reloads.
Embedding a full DNSSEC resolver into every application was rejected because DNSSEC validation is CPU and network intensive (requiring caching), and requires non-trivial configuration including root key and island-of-security keys; the AD bit approach minimizes configuration points.
The original AD bit definition (RFC 2535 §6.1) was not useful in practice because a conformant server should never reply with data that failed its security policy, making the bit redundant. The redefinition makes AD meaningful by restricting it to cryptographically verified data.
Organizations requiring that all DNS responses contain cryptographically verified data must separate the authoritative name server and signature verification functions, since authoritative servers are not required to validate signatures of data for which they are authoritative.
This document updates RFC 2535 Section 6.1, replacing the AD bit definition. Resolvers trusting the AD bit must confirm the responder supports the updated definition, which is indicated by support for the DO bit (RFC 3225).
A resolver MUST NOT blindly trust the AD bit unless it communicates with a recursive nameserver over a secure transport mechanism or using message authentication such as TSIG or SIG(0) and is explicitly configured to trust that server.
A response containing data marked Insecure in the answer or authority section MUST never have the AD bit set; the resolver SHOULD treat the data as Insecure whether or not SIG records are present.
An authoritative server MUST only set the AD bit for authoritative answers from a secure zone if it has been explicitly configured to do so; the default for this behavior SHOULD be off.
In the absence of trust establishment (fiat, personal, or knowledge-based), the AD bit from a recursive name server SHOULD NOT be trusted. A roaming/traveling host SHOULD NOT use recursive DNS servers offered by DHCP when security status matters.
Iterative resolvers SHOULD ignore the AD bit, as its setting by authoritative servers only affects resolvers configured to directly query and trust authoritative servers.
Secondary servers MAY treat zone data as Authenticated but SHOULD NOT do so unless the zone was transferred securely and/or the data was verified.
The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections of the response are Authenticated.
The AD bit MUST only be set if DNSSEC records have been requested via the DO bit (RFC3225) and relevant SIG records are returned.
The AD bit SHOULD be set if and only if all RRs in the answer section and any relevant negative response RRs in the authority section are Authenticated.
The AD bit SHOULD be used by the local resolver if and only if it has been explicitly configured to trust the remote resolver; it SHOULD be ignored when the recursive name server is not trusted.
The presence of the CD (Checking Disabled) bit in a query does not affect the setting of the AD bit; if CD is set, the server will not perform checking but SHOULD still set AD if data has already been cryptographically verified or complies with local policy.
When no satisfactory recursive nameservers are available, running one locally is RECOMMENDED, as it can be trusted and allows applications using stub resolvers to use the AD bit.
The AD (Authenticated Data) bit is a flag in the DNS response header. As redefined by this document, it is set only when all RRsets in the answer and authority sections have been cryptographically verified or meet the server's local security policy.
The CD (Checking Disabled) bit in a DNS query signals that the server should not perform DNSSEC checking. Its presence does not alter AD bit setting logic for already-verified data.
The DO (DNSSEC OK) bit, defined in RFC 3225, is a prerequisite for the AD bit: the AD bit MUST only be set if DNSSEC records were requested via DO and relevant SIG records are returned.
Authoritative servers can be explicitly configured to set the AD bit without performing cryptographic checks; this behavior MUST be off by default and SHOULD only be used on servers acting as both authoritative and recursive name servers.
Resolvers (full or stub) that blindly trust the AD bit without knowing the security policy of the server generating the answer cannot be considered security aware. Trust in the AD bit requires a secure transport (e.g., IPsec) or message authentication (TSIG, SIG(0)) plus explicit configuration.
The AD bit MUST only be trusted when the end consumer has confidence in the trustworthiness of the intermediary resolver, established via out-of-band mechanisms such as organizational fiat, personal trust/reputation, or published server policy.