Indicating Resolver Support of DNSSEC (RFC3225)
Original Publication Date: 2001-Dec-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]
Network Working Group D. Conrad Request for Comments: 3225 Nominum, Inc. Category: Standards Track December 2001
Indicating Resolver Support of DNSSEC
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 (2001). All Rights Reserved.
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.
DNSSEC [RFC2535] has been specified to provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. However, as DNSSEC is deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware servers. In such situations, the DNSSEC-aware server (responding to a request for data in a signed zone) will respond with SIG, KEY, and/or NXT records. For reasons described in the subsequent section, such responses can have significant negative operational impacts for the DNS infrastructure.
This document discusses a method to avoid these negative impacts, namely DNSSEC-aware servers should only respond with SIG, KEY, and/or NXT RRs when there is an explicit indication from the resolver that it can understand those RRs.
For the purposes of this document, "DNSSEC security RRs" are considered RRs of type SIG, KEY, or NXT.
Conrad Standards Track [Page 1]
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Initially, as DNSSEC is deployed, the vast majority of queries will be from resolvers that are not DNSSEC aware and thus do not understand or support the DNSSEC security RRs. When a query from such a resolver is received for a DNSSEC signed zone, the DNSSEC specification indicates the nameserver must respond with the appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to 512 bytes [RFC1035], responses including DNSSEC security RRs have a high probability of resulting in a truncated response being returned and the resolver retrying the query using TCP.
TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries will likely be quite detrimental in terms of increased network traffic...