idnits 2.17.1 draft-ietf-dnsext-dnssec-okbit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2761' is mentioned on line 158, but not defined == Unused Reference: 'RFC1034' is defined on line 181, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Conrad 3 draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc. 4 May, 2001 6 Indicating Resolver Support of DNSSEC 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 In order to deploy DNSSEC operationally, DNSSEC aware servers should 32 only perform automatic inclusion of DNSSEC RRs when there is an 33 explicit indication that the resolver can understand those RRs. This 34 document proposes the use of a bit in the EDNS0 header to provide 35 that explicit indication and the necessary protocol changes to 36 implement that notification. 38 1. Introduction 40 DNSSEC [RFC2535] has been specified to provide data integrity and 41 authentication to security aware resolvers and applications through 42 the use of cryptographic digital signatures. However, as DNSSEC is 43 deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware 44 servers. In such situations, the DNSSEC-aware server (responding to 45 a request for data in a signed zone) will respond with SIG, KEY, 46 and/or NXT records. For reasons described in the subsequent section, 47 such responses can have significant negative operational impacts for 48 the DNS infrastructure. 50 This document discusses a method to avoid these negative impacts, 51 namely DNSSEC-aware servers should only respond with SIG, KEY, and/or 52 NXT RRs when there is an explicit indication from the resolver that 53 it can understand those RRs. 55 For the purposes of this document, "DNSSEC security RRs" are 56 considered RRs of type SIG, KEY, or NXT. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 2. Rationale 64 Initially, as DNSSEC is deployed, the vast majority of queries will 65 be from resolvers that are not DNSSEC aware and thus do not 66 understand or support the DNSSEC security RRs. When a query from 67 such a resolver is received for a DNSSEC signed zone, the DNSSEC 68 specification indicates the nameserver must respond with the 69 appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to 70 512 bytes [RFC1035], responses including DNSSEC security RRs have a 71 high probability of resulting in a truncated response being returned 72 and the resolver retrying the query using TCP. 74 TCP DNS queries result in significant overhead due to connection 75 setup and teardown. Operationally, the impact of these TCP queries 76 will likely be quite detrimental in terms of increased network 77 traffic (typically five packets for a single query/response instead 78 of two), increased latency resulting from the additional round trip 79 times, increased incidences of queries failing due to timeouts, and 80 significantly increased load on nameservers. 82 In addition, in preliminary and experimental deployment of DNSSEC, 83 there have been reports of non-DNSSEC aware resolvers being unable to 84 handle responses which contain DNSSEC security RRs, resulting in the 85 resolver failing (in the worst case) or entire responses being 86 ignored (in the better case). 88 Given these operational implications, explicitly notifying the 89 nameserver that the client is prepared to receive (if not understand) 90 DNSSEC security RRs would be prudent. 92 Client-side support of DNSSEC is assumed to be binary -- either the 93 client is willing to receive all DNSSEC security RRs or it is not 94 willing to accept any. As such, a single bit is sufficient to 95 indicate client-side DNSSEC support. As effective use of DNSSEC 96 implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS 97 enhanced DNS header) are scarce, and there may be situations in which 98 non-compliant caching or forwarding servers inappropriately copy data 99 from classic headers as queries are passed on to authoritative 100 servers, the use of a bit from the EDNS0 header is proposed. 102 An alternative approach would be to use the existance of an EDNS0 103 header as an implicit indication of client-side support of DNSSEC. 104 This approach was not chosen as there may be applications in which 105 EDNS0 is supported but in which the use of DNSSEC is inappropriate. 107 3. Protocol Changes 109 The mechanism chosen for the explicit notification of the ability of 110 the client to accept (if not understand) DNSSEC security RRs is using 111 the most significant bit of the Z field on the EDNS0 OPT header in 112 the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In 113 the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of 114 the the third and fourth bytes of the "extended RCODE and flags" 115 portion of the EDNS0 OPT meta-RR, structured as follows: 117 +0 (MSB) +1 (LSB) 118 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 119 0: | EXTENDED-RCODE | VERSION | 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 2: |DO| Z | 122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 124 Setting the DO bit to one in a query indicates to the server that the 125 resolver is able to accept DNSSEC security RRs. The DO bit cleared 126 (set to zero) indicates the resolver is unprepared to handle DNSSEC 127 security RRs and those RRs MUST NOT be returned in the response 128 (unless DNSSEC security RRs are explicitly queried for). 130 More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, 131 or NXT RRs to authenticate a response as specified in [RFC2535] 132 unless the DO bit was set on the request. Security records that match 133 an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data 134 for an AXFR or IXFR query, are included whether or not the DO bit was 135 set. 137 A recursive DNSSEC-aware server MUST set the DO bit on recursive 138 requests, regardless of the status of the DO bit on the initiating 139 resolver request. If the initiating resolver request does not have 140 the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC 141 security RRs before returning the data to the client, however cached 142 data MUST NOT be modified. 144 In the event a server returns a NOTIMP, FORMERR or SERVFAIL response 145 to a query that has the DO bit set, the resolver SHOULD NOT expect 146 DNSSEC security RRs and SHOULD retry the query without the EDNS0 in 147 accordance with section 5.3 of [RFC2671]. 149 Security Considerations 151 The absence of DNSSEC data in response to a query with the DO bit set 152 MUST NOT be taken to mean no security information is available for 153 that zone as the response may be forged or a non-forged response of 154 an altered (DO bit cleared) query. 156 IANA considerations: 158 EDNS0[RFC2761] defines 16 bits as extened flags in the OPT record, 159 these bits are encoded into the TTL field of the OPT record (RFC2761 160 section 4.6). 162 This document reserves one of these bits as the OK bit. It is 163 requested that the left most bit be allocated. Thus the USE of the 164 OPT record TTL field would look like 166 +0 (MSB) +1 (LSB) 167 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 168 0: | EXTENDED-RCODE | VERSION | 169 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 170 2: |DO| Z | 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 173 Acknowledgements 175 This document is based on a rough draft by Bob Halley with input from 176 Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, 177 Rob Austein, Steve Bellovin, and Erik Nordmark. 179 References 181 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 182 RFC 1034, November 1987. 184 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 185 Specifications", RFC 1035, November 1987. 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 191 2535, March 1999. 193 [RFC2671] Vixie, P., Extension Mechanisms for DNS (EDNS0)", RFC 2671, 194 August 1999 196 Author's Address 198 David Conrad 199 Nominum Inc. 200 950 Charter Street 201 Redwood City, CA 94063 202 USA 204 Phone: +1 650 779 6003 206 Email: david.conrad@nominum.com 208 Full Copyright Statement 210 Copyright (C) The Internet Society (2000). All Rights Reserved. 212 This document and translations of it may be copied and furnished to 213 others, and derivative works that comment on or otherwise explain it 214 or assist in its implmentation may be prepared, copied, published and 215 distributed, in whole or in part, without restriction of any kind, 216 provided that the above copyright notice and this paragraph are 217 included on all such copies and derivative works. However, this 218 document itself may not be modified in any way, such as by removing 219 the copyright notice or references to the Internet Society or other 220 Internet organizations, except as needed for the purpose of 221 developing Internet standards in which case the procedures for 222 copyrights defined in the Internet Standards process must be 223 followed, or as required to translate it into languages other than 224 English. 226 The limited permissions granted above are perpetual and will not be 227 revoked by the Internet Society or its successors or assigns. 229 This document and the information contained herein is provided on an 230 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 231 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 232 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 233 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 234 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."