Network Working Group B. Wellington
Request for Comments: 3655 O. Gudmundsson
Updates: 2535 November 2003
Category: Standards Track
Redefinition of DNS Authenticated Data (AD) bit
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document alters the specification defined in RFC 2535. Based on
implementation experience, the Authenticated Data (AD) bit in the DNS
header is not useful. This document redefines the AD bit such that
it is only set if all answers or records proving that no answers
exist in the response has been cryptographically verified or
otherwise meets the server's local security policy.
Familiarity with the DNS system [RFC1035] and DNS security extensions
[RFC2535] is helpful but not necessary.
As specified in RFC 2535 (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
Wellington & Gudmundsson Standards Track [Page 1]RFC 3655 Redefinition of DNS AD bit November 2003
recursive query can now use the value of the AD bit to determine
whether the data is secure.
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, Section 6.1, is changed.
2. Setting of AD bit
The presence of the CD (Checking Disabled) bit in a query does not
affect the setting of the AD bit in the response. If the CD bit is
set, the server will not perform checking, but SHOULD still set the
AD bit if the data has already been cryptographically verified or
Wellington & Gudmundsson Standards Track [Page 2]RFC 3655 Redefinition of DNS AD bit November 2003
complies with local policy. The AD bit MUST only be set if DNSSEC