7Network Working Group D. Conrad
8Request for Comments: 3225 Nominum, Inc.
9Category: Standards Track December 2001
12 Indicating Resolver Support of DNSSEC
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (2001). All Rights Reserved.
28 In order to deploy DNSSEC (Domain Name System Security Extensions)
29 operationally, DNSSEC aware servers should only perform automatic
30 inclusion of DNSSEC RRs when there is an explicit indication that the
31 resolver can understand those RRs. This document proposes the use of
32 a bit in the EDNS0 header to provide that explicit indication and
33 describes the necessary protocol changes to implement that
38 DNSSEC [RFC2535] has been specified to provide data integrity and
39 authentication to security aware resolvers and applications through
40 the use of cryptographic digital signatures. However, as DNSSEC is
41 deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
42 servers. In such situations, the DNSSEC-aware server (responding to
43 a request for data in a signed zone) will respond with SIG, KEY,
44 and/or NXT records. For reasons described in the subsequent section,
45 such responses can have significant negative operational impacts for
46 the DNS infrastructure.
48 This document discusses a method to avoid these negative impacts,
49 namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
50 NXT RRs when there is an explicit indication from the resolver that
51 it can understand those RRs.
53 For the purposes of this document, "DNSSEC security RRs" are
54 considered RRs of type SIG, KEY, or NXT.
58Conrad Standards Track [Page 1]
60RFC 3225 Indicating Resolver Support of DNSSEC December 2001
63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
65 document are to be interpreted as described in [RFC2119].
69 Initially, as DNSSEC is deployed, the vast majority of queries will
70 be from resolvers that are not DNSSEC aware and thus do not
71 understand or support the DNSSEC security RRs. When a query from
72 such a resolver is received for a DNSSEC signed zone, the DNSSEC
73 specification indicates the nameserver must respond with the
74 appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
75 512 bytes [RFC1035], responses including DNSSEC security RRs have a
76 high probability of resulting in a truncated response being returned
77 and the resolver retrying the query using TCP.
79 TCP DNS queries result in significant overhead due to connection
80 setup and teardown. Operationally, the impact of these TCP queries
81 will likely be quite detrimental in terms of increased network
82 traffic (typically five packets for a single query/response instead
83 of two), increased latency resulting from the additional round trip
84 times, increased incidences of queries failing due to timeouts, and
85 significantly increased load on nameservers.
87 In addition, in preliminary and experimental deployment of DNSSEC,
88 there have been reports of non-DNSSEC aware resolvers being unable to
89 handle responses which contain DNSSEC security RRs, resulting in the
90 resolver failing (in the worst case) or entire responses being
91 ignored (in the better case).
93 Given these operational implications, explicitly notifying the
94 nameserver that the client is prepared to receive (if not understand)
95 DNSSEC security RRs would be prudent.
97 Client-side support of DNSSEC is assumed to be binary -- either the
98 client is willing to receive all DNSSEC security RRs or it is not
99 willing to accept any. As such, a single bit is sufficient to
100 indicate client-side DNSSEC support. As effective use of DNSSEC
101 implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
102 enhanced DNS header) are scarce, and there may be situations in which
103 non-compliant caching or forwarding servers inappropriately copy data
104 from classic headers as queries are passed on to authoritative
105 servers, the use of a bit from the EDNS0 header is proposed.
107 An alternative approach would be to use the existence of an EDNS0
108 header as an implicit indication of client-side support of DNSSEC.
109 This approach was not chosen as there may be applications in which
110 EDNS0 is supported but in which the use of DNSSEC is inappropriate.
114Conrad Standards Track [Page 2]
116RFC 3225 Indicating Resolver Support of DNSSEC December 2001
121 The mechanism chosen for the explicit notification of the ability of
122 the client to accept (if not understand) DNSSEC security RRs is using
123 the most significant bit of the Z field on the EDNS0 OPT header in
124 the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In
125 the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
126 the third and fourth bytes of the "extended RCODE and flags" portion
127 of the EDNS0 OPT meta-RR, structured as follows:
130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
131 0: | EXTENDED-RCODE | VERSION |
132 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
134 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
136 Setting the DO bit to one in a query indicates to the server that the
137 resolver is able to accept DNSSEC security RRs. The DO bit cleared
138 (set to zero) indicates the resolver is unprepared to handle DNSSEC
139 security RRs and those RRs MUST NOT be returned in the response
140 (unless DNSSEC security RRs are explicitly queried for). The DO bit
141 of the query MUST be copied in the response.
143 More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
144 or NXT RRs to authenticate a response as specified in [RFC2535]
145 unless the DO bit was set on the request. Security records that
146 match an explicit SIG, KEY, NXT, or ANY query, or are part of the
147 zone data for an AXFR or IXFR query, are included whether or not the
150 A recursive DNSSEC-aware server MUST set the DO bit on recursive
151 requests, regardless of the status of the DO bit on the initiating
152 resolver request. If the initiating resolver request does not have
153 the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
154 security RRs before returning the data to the client, however cached
155 data MUST NOT be modified.
157 In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
158 to a query that has the DO bit set, the resolver SHOULD NOT expect
159 DNSSEC security RRs and SHOULD retry the query without EDNS0 in
160 accordance with section 5.3 of [RFC2671].
170Conrad Standards Track [Page 3]
172RFC 3225 Indicating Resolver Support of DNSSEC December 2001
175Security Considerations
177 The absence of DNSSEC data in response to a query with the DO bit set
178 MUST NOT be taken to mean no security information is available for
179 that zone as the response may be forged or a non-forged response of
180 an altered (DO bit cleared) query.
184 EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
185 these bits are encoded into the TTL field of the OPT record (RFC2671
188 This document reserves one of these bits as the OK bit. It is
189 requested that the left most bit be allocated. Thus the USE of the
190 OPT record TTL field would look like
193 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
194 0: | EXTENDED-RCODE | VERSION |
195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
201 This document is based on a rough draft by Bob Halley with input from
202 Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
203 Rob Austein, Steve Bellovin, and Erik Nordmark.
207 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
208 STD 13, RFC 1034, November 1987.
210 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
211 Specifications", STD 13, RFC 1035, November 1987.
213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
214 Requirement Levels", BCP 14, RFC 2119, March 1997.
216 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
219 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
226Conrad Standards Track [Page 4]
228RFC 3225 Indicating Resolver Support of DNSSEC December 2001
236 Redwood City, CA 94063
239 Phone: +1 650 381 6003
240 EMail: david.conrad@nominum.com
282Conrad Standards Track [Page 5]
284RFC 3225 Indicating Resolver Support of DNSSEC December 2001
287Full Copyright Statement
289 Copyright (C) The Internet Society (2001). All Rights Reserved.
291 This document and translations of it may be copied and furnished to
292 others, and derivative works that comment on or otherwise explain it
293 or assist in its implementation may be prepared, copied, published
294 and distributed, in whole or in part, without restriction of any
295 kind, provided that the above copyright notice and this paragraph are
296 included on all such copies and derivative works. However, this
297 document itself may not be modified in any way, such as by removing
298 the copyright notice or references to the Internet Society or other
299 Internet organizations, except as needed for the purpose of
300 developing Internet standards in which case the procedures for
301 copyrights defined in the Internet Standards process must be
302 followed, or as required to translate it into languages other than
305 The limited permissions granted above are perpetual and will not be
306 revoked by the Internet Society or its successors or assigns.
308 This document and the information contained herein is provided on an
309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
317 Funding for the RFC Editor function is currently provided by the
338Conrad Standards Track [Page 6]