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 Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis 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. 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
complies with local policy. The AD bit MUST only be set if DNSSEC records have been requested via the DO bit [RFC3225] and relevant SIG records are returned. RFC 2535 says: "The AD bit MUST NOT be set on a response unless all of the RRs in the answer and authority sections of the response are either Authenticated or Insecure." The replacement text reads: "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 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." A recursive DNS server following this modified specification will only set the AD bit when it has cryptographically verified the data in the answer.
answering queries. Verifying signatures at query time is also expensive and could lead to resolvers timing out on many queries after the server reloads zones. Organizations requiring that all DNS responses contain cryptographically verified data will need to separate the authoritative name server and signature verification functions, since name servers are not required to validate signatures of data for which they are authoritative. RFC2845] or SIG(0) [RFC2931] and is explicitly configured to trust this recursive name server.
is not advisable to trust these recursive nameservers. A roaming/traveling host SHOULD not use recursive DNS servers offered by DHCP when looking up information where security status matters. In the latter two cases, the end consumer must also completely trust the path to the trusted recursive name servers, or a secure transport must be employed to protect the traffic. When faced with a situation where there are no satisfactory recursive nameservers available, running one locally is RECOMMENDED. This has the advantage that it can be trusted, and the AD bit can still be used to allow applications to use stub resolvers. RFC3225]. Authoritative servers can be explicitly configured to set the AD bit on answers without doing cryptographic checks. This behavior MUST be off by default. The only affected resolvers are those that directly query and trust the authoritative server, and this functionality SHOULD only be used on servers that act both as 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 can not be considered security aware. A resolver MUST NOT blindly trust the AD bit unless it communicates such as IPsec, or using message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931]. In addition, the resolver must have been explicitly configured to trust this recursive name server.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0))", RFC 2931, September 2000. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.