1. Introduction
Familiarity with the DNS system [RFC1035] and DNS security extensions
[RFC2535] is helpful but not necessary.
As specified in RFC 2535(-> 4035prop | 4034prop | 4033prop) (section 6.1), the AD (Authenticated Data)
bit indicates in a response that all data included in the answer and
authority sections of the response have been authenticated by the
server according to the policies of that server. This is not
especially useful in practice, since a conformant server SHOULD never
reply with data that failed its security policy.
This document redefines the AD bit such that it is only set if all
data in the response has been cryptographically verified or otherwise
meets the server's local security policy. Thus, neither a response
containing properly delegated insecure data, nor a server configured
without DNSSEC keys, will have the AD set. As before, data that
failed to verify will not be returned. An application running on a
host that has a trust relationship with the server performing the
recursive query can now use the value of the AD bit to determine
whether the data is secure.
1.1. Motivation
A full DNSSEC capable resolver called directly from an application
can return to the application the security status of the RRsets in
the answer. However, most applications use a limited stub resolver
that relies on an external recursive name server which incorporates a
full resolver. The recursive nameserver can use the AD bit in a
response to indicate the security status of the data in the answer,
and the local resolver can pass this information to the application.
The application in this context can be either a human using a DNS
tool or a software application.
The AD bit SHOULD be used by the local resolver if and only if it has
been explicitly configured to trust the remote resolver. The AD bit
SHOULD be ignored when the recursive name server is not trusted.
An alternate solution would be to embed a full DNSSEC resolver into
every application, but this has several disadvantages.
- DNSSEC validation is both CPU and network intensive, and caching
SHOULD be used whenever possible.
- DNSSEC requires non-trivial configuration - the root key must be
configured, as well as keys for any "islands of security" that
will exist until DNSSEC is fully deployed. The number of
configuration points should be minimized.
The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", in this document are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119].
1.3. Updated documents and sections
The definition of the AD bit in RFC 2535(-> 4035prop | 4034prop | 4033prop), Section 6.1, is changed.
