idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-00.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 12. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. 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 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. ** There are 34 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 113 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 (December 27, 2007) is 5964 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 285 looks like a reference -- Missing reference section? 'RFC2119' on line 289 looks like a reference -- Missing reference section? 'RFC3225' on line 296 looks like a reference -- Missing reference section? 'IANAFLAGS' on line 299 looks like a reference -- Missing reference section? 'RFC2671' on line 293 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 December 27, 2007 6 Revised extension mechanisms for DNS (EDNS0) 8 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 32 Copyright (C) The IETF Trust (2007). 34 Abstract 35 The Domain Name System's wire protocol includes a number of fixed 36 fields whose range has been or soon will be exhausted and does not 37 allow clients to advertise their capabilities to servers. This 38 document describes backward compatible mechanisms for allowing the 39 protocol to grow. 41 1 - Introduction 43 1.1. DNS (see [RFC1035]) specifies a Message Format and within such 44 messages there are standard formats for encoding options, errors, and 45 name compression. The maximum allowable size of a DNS Message is 46 fixed. Many of DNS's protocol limits are too small for uses which are 47 or which are desired to become common. There is no way for 48 implementations to advertise their capabilities. 50 1.2. Unextended agents will not know how to interpret the protocol 51 extensions detailed here. In practice, these clients will be upgraded 52 when they have need of a new feature, and only new features will make 53 use of the extensions. Extended agents must be prepared for behaviour 54 of unextended clients in the face of new protocol elements, and fall 55 back gracefully to unextended DNS. 57 1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC 2119 60 [RFC2119]. 62 2 - Affected Protocol Elements 64 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit 65 word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 66 1-bit flags. The original reserved Z bits have been allocated to 67 various purposes, and most of the RCODE values are now in use. More 68 flags and more possible RCODEs are needed. 70 2.2. The first two bits of a wire format domain label are used to 71 denote the type of the label. [RFC1035 4.1.4] allocates two of the 72 four possible types and reserves the other two. Proposals for use of 73 the remaining types far outnumber those available. More label types 74 were needed, and an extension mechanism was proposed in RFC 2671 75 [RFC2671 Section 3]. 77 2.3. DNS Messages are limited to 512 octets in size when sent over 78 UDP. While the minimum maximum reassembly buffer size still allows a 79 limit of 512 octets of UDP payload, most of the hosts now connected to 80 the Internet are able to reassemble larger datagrams. Some mechanism 81 must be created to allow requestors to advertise larger buffer sizes 82 to responders. 84 3 - Extended Label Types 86 [RFC2671 Section 3] reserved label type "0 1" to indicate that an 87 extended label type followed in the next octet, but gave inadequate 88 guidance as to how EDNS, as a hop-by-hop signalling method, could be 89 used to carry a new kind of DNS label. Extended label types might be 90 addressed in a future specification, perhaps requiring that the EDNS 91 VERSION be incremented. 93 4 - OPT pseudo-RR 95 4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional 96 data section of a request, and to responses to such requests. An OPT 97 is called a pseudo-RR because it pertains to a particular transport 98 level message and not to any actual DNS data. OPT RRs MUST NOT be 99 cached, forwarded, or stored in or loaded from master files. The 100 quantity of OPT pseudo-RRs per message MUST be either zero or one, but 101 not greater. 103 4.2. An OPT RR has a fixed part and a variable set of options 104 expressed as {attribute, value} pairs. The fixed part holds some DNS 105 meta data and also a small collection of new protocol elements which 106 we expect to be so popular that it would be a waste of wire space to 107 encode them as {attribute, value} pairs. 109 4.3. The fixed part of an OPT RR is structured as follows: 111 Field Name Field Type Description 112 ------------------------------------------------------ 113 NAME domain name empty (root domain) 114 TYPE u_int16_t OPT 115 CLASS u_int16_t sender's UDP payload size 116 TTL u_int32_t extended RCODE and flags 117 RDLEN u_int16_t describes RDATA 118 RDATA octet stream {attribute,value} pairs 119 4.4. The variable part of an OPT RR is encoded in its RDATA and is 120 structured as zero or more of the following: 122 +0 (MSB) +1 (LSB) 123 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 124 0: | OPTION-CODE | 125 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 126 2: | OPTION-LENGTH | 127 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 128 4: | | 129 / OPTION-DATA / 130 / / 131 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 133 OPTION-CODE (Assigned by IANA.) 135 OPTION-LENGTH Size (in octets) of OPTION-DATA. 137 OPTION-DATA Varies per OPTION-CODE. 139 4.4.1. Order of appearance of option tuples is never relevant. Any 140 option whose meaning is affected by other options is so affected no 141 matter which one comes first in the OPT RDATA. 143 4.4.2. Any OPTION-CODE values not understood by a responder or 144 requestor MUST be ignored. So, specifications of such options might 145 wish to include some kind of signalled acknowledgement. For example, 146 an option specification might say that if a responder sees option XYZ, 147 it SHOULD include option XYZ in its response. 149 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS 150 field) is the number of octets of the largest UDP payload that can be 151 reassembled and delivered in the sender's network stack. Note that 152 path MTU, with or without fragmentation, may be smaller than this. 154 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP 155 reassembly buffer. Choosing 1280 on an Ethernet connected requestor 156 would be reasonable. The consequence of choosing too large a value 157 may be an ICMP message from an intermediate gateway, or even a silent 158 drop of the response message. 160 4.5.2. Both requestors and responders are advised to take account of 161 the path's discovered MTU (if already known) when considering message 162 sizes. 164 4.5.3. The requestor's maximum payload size can change over time, and 165 therefore MUST NOT be cached for use beyond the transaction in which 166 it is advertised. 168 4.5.4. The responder's maximum payload size can change over time, but 169 can be reasonably expected to remain constant between two sequential 170 transactions; for example, a meaningless QUERY to discover a 171 responder's maximum UDP payload size, followed immediately by an 172 UPDATE which takes advantage of this size. (This is considered 173 preferrable to the outright use of TCP for oversized requests, if 174 there is any reason to suspect that the responder implements EDNS, and 175 if a request will not fit in the default 512 payload size limit.) 177 4.5.5. Due to transaction overhead, it is unwise to advertise an 178 architectural limit as a maximum UDP payload size. Just because your 179 stack can reassemble 64KB datagrams, don't assume that you want to 180 spend more than about 4KB of state memory per ongoing transaction. 182 4.6. The extended RCODE and flags (which OPT stores in the RR TTL 183 field) are structured as follows: 185 +0 (MSB) +1 (LSB) 186 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 187 0: | EXTENDED-RCODE | VERSION | 188 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 189 2: | DO| Z | 190 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 192 EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note 193 that EXTENDED-RCODE value "0" indicates that an 194 unextended RCODE is in use (values "0" through "15"). 196 VERSION Indicates the implementation level of whoever sets it. 197 Full conformance with this specification is indicated 198 by version ``0.'' Requestors are encouraged to set 199 this to the lowest implemented level capable of 200 expressing a transaction, to minimize the responder 201 and network load of discovering the greatest common 202 implementation level between requestor and responder. 203 A requestor's version numbering strategy should 204 ideally be a run time configuration option. 206 If a responder does not implement the VERSION level of 207 the request, then it answers with RCODE=BADVERS. All 208 responses MUST be limited in format to the VERSION 209 level of the request, but the VERSION of each response 210 MUST be the highest implementation level of the 211 responder. In this way a requestor will learn the 212 implementation level of a responder as a side effect 213 of every response, including error responses, 214 including RCODE=BADVERS. 216 DO DNSSEC OK bit [RFC3225]. 218 Z Set to zero by senders and ignored by receivers, 219 unless modified in a subsequent specification 220 [IANAFLAGS]. 222 5 - Transport Considerations 224 5.1. The presence of an OPT pseudo-RR in a request is an indication 225 that the requestor fully implements the given version of EDNS, and can 226 correctly understand any response that conforms to that feature's 227 specification. 229 5.2. Lack of use of these features in a request is an indication that 230 the requestor does not implement any part of this specification and 231 that the responder SHOULD NOT use any protocol extension described 232 here in its response. 234 5.3. Responders who do not understand these protocol extensions are 235 expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, 236 or to appear to "time out" due to inappropriate action by a "middle 237 box" such as a NAT. Therefore use of extensions SHOULD be ``probed'' 238 such that a responder who isn't known to support them be allowed a 239 retry with no extensions if it responds with such an RCODE, or does 240 not respond. If a responder's capability level is cached by a 241 requestor, a new probe SHOULD be sent periodically to test for changes 242 to responder capability. 244 6 - Security Considerations 246 Requestor-side specification of the maximum buffer size may open a new 247 DNS denial of service attack if responders can be made to send 248 messages which are too large for intermediate gateways to forward, 249 thus leading to potential ICMP storms between gateways and responders. 251 7 - IANA Considerations 253 IANA has allocated RR type code 41 for OPT. 255 This document controls the following IANA sub-registries in registry 256 "DOMAIN NAME SYSTEM PARAMETERS": 258 "EDNS Extended Label Type" 259 "EDNS Option Codes" 260 "EDNS Version Numbers" 261 "Domain System Response Code" 263 This document assigns label type 0b01xxxxxx as "EDNS Extended Label 264 Type." We request that IANA record this assignment. 266 This document assigns option code 65535 to "Reserved for future 267 expansion." 269 This document assigns EDNS Extended RCODE "16" to "BADVERS". 271 IESG approval is required to create new entries in the EDNS Extended 272 Label Type or EDNS Version Number registries, while any published RFC 273 (including Informational, Experimental, or BCP) is grounds for 274 allocation of an EDNS Option Code. 276 8 - Acknowledgements 278 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 279 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas 280 Narten were each instrumental in creating and refining this 281 specification. 283 9 - References 285 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 286 Specification,'' RFC 1035, USC/Information Sciences 287 Institute, November 1987. 289 [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate 290 Requirement Levels,'' RFC 2119, Harvard University, March 291 1997. 293 [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 294 2671, Internet Software Consortium, August 1999. 296 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC,'' RFC 297 3225, Nominum Inc., December 2001. 299 [IANAFLAGS] IANA, ``DNS Header Flags and EDNS Header Flags,'' web 300 site http://www.iana.org/assignments/dns-header-flags, as 301 of June 2005 or later. 303 10 - Author's Address 305 Paul Vixie 306 Internet Systems Consortium 307 950 Charter Street 308 Redwood City, CA 94063 309 +1 650 423 1301 310 312 Full Copyright Statement 314 Copyright (C) IETF Trust (2007). 316 This document is subject to the rights, licenses and restrictions 317 contained in BCP 78, and except as set forth therein, the authors 318 retain all their rights. 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 323 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 324 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 325 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Intellectual Property 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be found 337 in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this specification 343 can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 352 Acknowledgement 354 Funding for the RFC Editor function is provided by the IETF 355 Administrative Support Activity (IASA).