idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. -- The draft header indicates that this document obsoletes RFC2671, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 133 has weird spacing: '...in name emp...' -- 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.) -- The document date (March 17, 2008) is 5884 days in the past. Is this intentional? 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 section? 'RFC1035' on line 317 looks like a reference -- Missing reference section? 'RFC2119' on line 321 looks like a reference -- Missing reference section? 'RFC3225' on line 328 looks like a reference -- Missing reference section? 'IANAFLAGS' on line 331 looks like a reference -- Missing reference section? 'RFC2671' on line 325 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Paul Vixie, ISC 3 INTERNET-DRAFT 4 March 17, 2008 6 Intended Status: Standards Track 7 Obsoletes: 2671 (if approved) 9 Revised extension mechanisms for DNS (EDNS0) 11 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 The Domain Name System's wire protocol includes a number of fixed 40 fields whose range has been or soon will be exhausted and does not 41 allow clients to advertise their capabilities to servers. This 42 document describes backward compatible mechanisms for allowing the 43 protocol to grow. 45 1 - Introduction 47 1.1. DNS (see [RFC1035]) specifies a Message Format and within such 48 messages there are standard formats for encoding options, errors, and 49 name compression. The maximum allowable size of a DNS Message is fixed. 50 Many of DNS's protocol limits are too small for uses which are or which 51 are desired to become common. There is no way for implementations to 52 advertise their capabilities. 54 1.2. Unextended agents will not know how to interpret the protocol 55 extensions detailed here. In practice, these clients will be upgraded 56 when they have need of a new feature, and only new features will make 57 use of the extensions. Extended agents must be prepared for behaviour 58 of unextended clients in the face of new protocol elements, and fall 59 back gracefully to unextended DNS. RFC 2671 originally has proposed 60 extensions to the basic DNS protocol to overcome these deficiencies. 61 This memo refines that specification and obsoletes RFC 2671. 63 1.3. 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 RFC 2119 [RFC2119]. 67 2 - Affected Protocol Elements 69 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit 70 word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 71 1-bit flags. The original reserved Z bits have been allocated to 72 various purposes, and most of the RCODE values are now in use. More 73 flags and more possible RCODEs are needed. The OPT pseudo-RR specified 74 in Section 4 contains subfields that carry a bit field extension of the 75 RCODE field and additional flag bits, respectively; for details see 76 Section 4.6 below. 78 2.2. The first two bits of a wire format domain label are used to denote 79 the type of the label. [RFC1035 4.1.4] allocates two of the four 80 possible types and reserves the other two. Proposals for use of the 81 remaining types far outnumber those available. More label types were 82 needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 83 Section 3]. Section 3 of this document reserves DNS labels with a first 84 octet in the range of 64-127 decimal (label type 01) for future 85 standardization of Extended DNS Labels. 87 2.3. DNS Messages are limited to 512 octets in size when sent over UDP. 88 While the minimum maximum reassembly buffer size still allows a limit of 89 512 octets of UDP payload, most of the hosts now connected to the 90 Internet are able to reassemble larger datagrams. Some mechanism must 91 be created to allow requestors to advertise larger buffer sizes to 92 responders. To this end, the OPT pseudo-RR specified in Section 4 93 contains a maximum payload size field; for details see Section 4.5 94 below. 96 3 - Extended Label Types 98 The first octet in the on-the-wire representation of a DNS label 99 specifies the label type; the basic DNS specification [RFC1035] 100 dedicates the two most significant bits of that octet for this purpose. 102 This document reserves DNS label type 0b01 for use as an indication for 103 Extended Label Types. A specific extended label type is selected by the 104 6 least significant bits of the first octet. Thus, Extended Label Types 105 are indicated by the values 64-127 (0b01xxxxxx) in the first octet of 106 the label. 108 Allocations from this range are to be made for IETF documents fully 109 describing the syntax and semantics as well as the applicability of the 110 particular Extended Label Type. 112 This document does not describe any specific Extended Label Type. 114 4 - OPT pseudo-RR 116 4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data 117 section of a request, and to responses to such requests. An OPT is 118 called a pseudo-RR because it pertains to a particular transport level 119 message and not to any actual DNS data. OPT RRs MUST NOT be cached, 120 forwarded, or stored in or loaded from master files. The quantity of 121 OPT pseudo-RRs per message MUST be either zero or one, but not greater. 123 4.2. An OPT RR has a fixed part and a variable set of options expressed 124 as {attribute, value} pairs. The fixed part holds some DNS meta data 125 and also a small collection of new protocol elements which we expect to 126 be so popular that it would be a waste of wire space to encode them as 127 {attribute, value} pairs. 129 4.3. The fixed part of an OPT RR is structured as follows: 131 Field Name Field Type Description 132 ------------------------------------------------------ 133 NAME domain name empty (root domain) 134 TYPE u_int16_t OPT (41) 135 CLASS u_int16_t sender's UDP payload size 136 TTL u_int32_t extended RCODE and flags 137 RDLEN u_int16_t describes RDATA 138 RDATA octet stream {attribute,value} pairs 140 4.4. The variable part of an OPT RR is encoded in its RDATA and is 141 structured as zero or more of the following: 143 : +0 (MSB) : +1 (LSB) : 144 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 145 0: | OPTION-CODE | 146 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 147 2: | OPTION-LENGTH | 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 149 4: | | 150 / OPTION-DATA / 151 / / 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 154 OPTION-CODE (Assigned by IANA.) 156 OPTION-LENGTH Size (in octets) of OPTION-DATA. 158 OPTION-DATA Varies per OPTION-CODE. 160 4.4.1. Order of appearance of option tuples is never relevant. Any 161 option whose meaning is affected by other options is so affected no 162 matter which one comes first in the OPT RDATA. 164 4.4.2. Any OPTION-CODE values not understood by a responder or requestor 165 MUST be ignored. So, specifications of such options might wish to 166 include some kind of signalled acknowledgement. For example, an option 167 specification might say that if a responder sees option XYZ, it SHOULD 168 include option XYZ in its response. 170 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS 171 field) is the number of octets of the largest UDP payload that can be 172 reassembled and delivered in the sender's network stack. Note that path 173 MTU, with or without fragmentation, may be smaller than this. Values 174 lower than 512 are undefined, and may be treated as format errors, or 175 may be treated as equal to 512, at the implementor's discretion. 177 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP 178 reassembly buffer. Choosing 1280 on an Ethernet connected requestor 179 would be reasonable. The consequence of choosing too large a value may 180 be an ICMP message from an intermediate gateway, or even a silent drop 181 of the response message. 183 4.5.2. Both requestors and responders are advised to take account of the 184 path's discovered MTU (if already known) when considering message sizes. 186 4.5.3. The requestor's maximum payload size can change over time, and 187 therefore MUST NOT be cached for use beyond the transaction in which it 188 is advertised. 190 4.5.4. The responder's maximum payload size can change over time, but 191 can be reasonably expected to remain constant between two sequential 192 transactions; for example, a meaningless QUERY to discover a responder's 193 maximum UDP payload size, followed immediately by an UPDATE which takes 194 advantage of this size. (This is considered preferrable to the outright 195 use of TCP for oversized requests, if there is any reason to suspect 196 that the responder implements EDNS, and if a request will not fit in the 197 default 512 payload size limit.) 199 4.5.5. Due to transaction overhead, it is unwise to advertise an 200 architectural limit as a maximum UDP payload size. Just because your 201 stack can reassemble 64KB datagrams, don't assume that you want to spend 202 more than about 4KB of state memory per ongoing transaction. 204 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) 205 are structured as follows: 207 : +0 (MSB) : +1 (LSB) : 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 0: | EXTENDED-RCODE | VERSION | 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 2: | DO| Z | 212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that 215 EXTENDED-RCODE value zero (0) indicates that an 216 unextended RCODE is in use (values zero (0) through 217 fifteen (15)). 219 VERSION Indicates the implementation level of whoever sets it. 220 Full conformance with this specification is indicated by 221 version zero (0). Requestors are encouraged to set this 222 to the lowest implemented level capable of expressing a 223 transaction, to minimize the responder and network load 224 of discovering the greatest common implementation level 225 between requestor and responder. A requestor's version 226 numbering strategy should ideally be a run time 227 configuration option. 229 If a responder does not implement the VERSION level of 230 the request, then it answers with RCODE=BADVERS. All 231 responses MUST be limited in format to the VERSION level 232 of the request, but the VERSION of each response MUST be 233 the highest implementation level of the responder. In 234 this way a requestor will learn the implementation level 235 of a responder as a side effect of every response, 236 including error responses, including RCODE=BADVERS. 238 DO DNSSEC OK bit [RFC3225]. 240 Z Set to zero by senders and ignored by receivers, unless 241 modified in a subsequent specification [IANAFLAGS]. 243 5 - Transport Considerations 245 5.1. The presence of an OPT pseudo-RR in a request is an indication that 246 the requestor fully implements the given version of EDNS, and can 247 correctly understand any response that conforms to that feature's 248 specification. 250 5.2. Lack of use of these features in a request is an indication that 251 the requestor does not implement any part of this specification and that 252 the responder SHOULD NOT use any protocol extension described here in 253 its response. 255 5.3. Responders who do not understand these protocol extensions are 256 expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or 257 to appear to "time out" due to inappropriate action by a "middle box" 258 such as a NAT, or to ignore extensions and respond only to unextended 259 protocol elements. Therefore use of extensions SHOULD be "probed" such 260 that a responder who isn't known to support them be allowed a retry with 261 no extensions if it responds with such an RCODE, or does not respond. 262 If a responder's capability level is cached by a requestor, a new probe 263 SHOULD be sent periodically to test for changes to responder capability. 265 5.4. If EDNS is used in a request, and the response arrives with TC set 266 and with no EDNS OPT RR, a requestor should assume that truncation 267 prevented the OPT RR from being appended by the responder, and further, 268 that EDNS is not used in the response. Correspondingly, an EDNS 269 responder who cannot fit all necessary elements (including an OPT RR) 270 into a response, should respond with a normal (unextended) DNS response, 271 possibly setting TC if the response will not fit in the unextended 272 response message's 512-octet size. 274 6 - Security Considerations 276 Requestor-side specification of the maximum buffer size may open a new 277 DNS denial of service attack if responders can be made to send messages 278 which are too large for intermediate gateways to forward, thus leading 279 to potential ICMP storms between gateways and responders. 281 7 - IANA Considerations 283 IANA has allocated RR type code 41 for OPT. 285 This document controls the following IANA sub-registries in registry 286 "DOMAIN NAME SYSTEM PARAMETERS": 288 "EDNS Extended Label Type" 289 "EDNS Option Codes" 290 "EDNS Version Numbers" 291 "Domain System Response Code" 293 IANA is advised to re-parent these subregistries to this document. 295 This document assigns label type 0b01xxxxxx as "EDNS Extended Label 296 Type." We request that IANA record this assignment. 298 This document assigns option code 65535 to "Reserved for future 299 expansion." 301 This document assigns EDNS Extended RCODE "16" to "BADVERS". 303 IESG approval is required to create new entries in the EDNS Extended 304 Label Type or EDNS Version Number registries, while any published RFC 305 (including Informational, Experimental, or BCP) is grounds for 306 allocation of an EDNS Option Code. 308 8 - Acknowledgements 310 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 311 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, 312 Alfred Hoenes and Markku Savela were each instrumental in creating and 313 refining this specification. 315 9 - References 317 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 318 Specification," RFC 1035, USC/Information Sciences 319 Institute, November 1987. 321 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 322 Requirement Levels," RFC 2119, Harvard University, March 323 1997. 325 [RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, 326 Internet Software Consortium, August 1999. 328 [RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC 329 3225, Nominum Inc., December 2001. 331 [IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site 332 http://www.iana.org/assignments/dns-header-flags, as of 333 June 2005 or later. 335 10 - Author's Address 337 Paul Vixie 338 Internet Systems Consortium 339 950 Charter Street 340 Redwood City, CA 94063 341 +1 650 423 1301 342 EMail: vixie@isc.org 344 Full Copyright Statement 346 Copyright (C) IETF Trust (2007). 348 This document is subject to the rights, licenses and restrictions 349 contained in BCP 78, and except as set forth therein, the authors retain 350 all their rights. 352 This document and the information contained herein are provided on an 353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 354 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 355 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 356 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 357 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 360 Intellectual Property 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in this 365 document or the extent to which any license under such rights might or 366 might not be available; nor does it represent that it has made any 367 independent effort to identify any such rights. Information on the 368 procedures with respect to rights in RFC documents can be found in BCP 369 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an attempt 373 made to obtain a general license or permission for the use of such 374 proprietary rights by implementers or users of this specification can be 375 obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary rights 380 that may cover technology that may be required to implement this 381 standard. Please address the information to the IETF at 382 ietf-ipr@ietf.org. 384 Acknowledgement 386 Funding for the RFC Editor function is provided by the IETF 387 Administrative Support Activity (IASA).