idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 and authors 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.) -- The document date (July 28, 2009) is 5357 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group M. Graff 3 Internet-Draft P. Vixie 4 Obsoletes: 2671 (if approved) Internet Systems Consortium 5 Intended status: Standards Track July 28, 2009 6 Expires: January 29, 2010 8 Extension Mechanisms for DNS (EDNS0) 9 draft-ietf-dnsext-rfc2671bis-edns0-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Domain Name System's wire protocol includes a number of fixed 48 fields whose range has been or soon will be exhausted and does not 49 allow requestors to advertise their capabilities to responders. This 50 document describes backward compatible mechanisms for allowing the 51 protocol to grow. 53 This document updates the EDNS0 specification based on 10 years of 54 operational experience. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 61 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 62 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 63 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 65 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 66 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 68 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 69 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 70 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 71 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 72 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 73 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 74 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 75 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 DNS [RFC1035] specifies a Message Format and within such messages 87 there are standard formats for encoding options, errors, and name 88 compression. The maximum allowable size of a DNS Message is fixed. 89 Many of DNS's protocol limits are too small for uses which are or 90 which are desired to become common. There is no way for 91 implementations to advertise their capabilities. 93 Unextended agents will not know how to interpret the protocol 94 extensions detailed here. In practice, these clients will be 95 upgraded when they have need of a new feature, and only new features 96 will make use of the extensions. Extended agents must be prepared 97 for behaviour of unextended clients in the face of new protocol 98 elements, and fall back gracefully to unextended DNS. [RFC2671] 99 originally proposed extensions to the basic DNS protocol to overcome 100 these deficiencies. This memo refines that specification and 101 obsoletes [RFC2671]. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. EDNS Support Requirement 111 EDNS support is manditory in a modern world. DNSSEC requires EDNS 112 support, and many other featres are made possible only by EDNS 113 support to request or advertise them. 115 4. Affected Protocol Elements 117 4.1. Message Header 119 The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full 120 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a 121 number of 1-bit flags. The original reserved Z bits have been 122 allocated to various purposes, and most of the RCODE values are now 123 in use. More flags and more possible RCODEs are needed. The OPT 124 pseudo-RR specified below contains subfields that carry a bit field 125 extension of the RCODE field and additional flag bits, respectively. 127 4.2. Label Types 129 The first two bits of a wire format domain label are used to denote 130 the type of the label. ,section 4.1.4 [RFC1035] allocates two of the 131 four possible types and reserves the other two. More label types 132 were proposed in [RFC2671] section 3. 134 4.3. UDP Message Size 136 DNS Messages are limited to 512 octets in size when sent over UDP. 137 While the minimum maximum reassembly buffer size still allows a limit 138 of 512 octets of UDP payload, most of the hosts now connected to the 139 Internet are able to reassemble larger datagrams. Some mechanism 140 must be created to allow requestors to advertise larger buffer sizes 141 to responders. To this end, the OPT pseudo-RR specified below 142 contains a maximum payload size field. 144 5. Extended Label Types 146 The first octet in the on-the-wire representation of a DNS label 147 specifies the label type; the basic DNS specification [RFC1035] 148 dedicates the two most significant bits of that octet for this 149 purpose. 151 This document reserves DNS label type 0b01 for use as an indication 152 for Extended Label Types. A specific extended label type is selected 153 by the 6 least significant bits of the first octet. Thus, Extended 154 Label Types are indicated by the values 64-127 (0b01xxxxxx) in the 155 first octet of the label. 157 This document does not describe any specific Extended Label Type. 159 In practice, Extended Label Types are difficult to use due to support 160 in clients and intermediate gateways. Therefore, the registry of 161 Extended Label Types is requested to be closed. They cause 162 interoperability problems and at present no defined label types are 163 in use. 165 6. OPT pseudo-RR 167 6.1. OPT Record Behavior 169 One OPT pseudo-RR (RR type 41) MAY be added to the additional data 170 section of a request. If present in requests, compliant responders 171 which implement EDNS MUST include an OPT record in non-truncated 172 responses, and SHOULD attempt to include them in all responses. An 173 OPT is called a pseudo-RR because it pertains to a particular 174 transport level message and not to any actual DNS data. OPT RRs MUST 175 NOT be cached, forwarded, or stored in or loaded from master files. 176 The quantity of OPT pseudo-RRs per message MUST be either zero or 177 one, but not greater. 179 6.2. OPT Record Format 181 An OPT RR has a fixed part and a variable set of options expressed as 182 {attribute, value} pairs. The fixed part holds some DNS meta data 183 and also a small collection of basic extension elements which we 184 expect to be so popular that it would be a waste of wire space to 185 encode them as {attribute, value} pairs. 187 The fixed part of an OPT RR is structured as follows: 189 +------------+--------------+------------------------------+ 190 | Field Name | Field Type | Description | 191 +------------+--------------+------------------------------+ 192 | NAME | domain name | empty (root domain) | 193 | TYPE | u_int16_t | OPT | 194 | CLASS | u_int16_t | requestor's UDP payload size | 195 | TTL | u_int32_t | extended RCODE and flags | 196 | RDLEN | u_int16_t | describes RDATA | 197 | RDATA | octet stream | {attribute,value} pairs | 198 +------------+--------------+------------------------------+ 200 OPT RR Format 202 The variable part of an OPT RR is encoded in its RDATA and is 203 structured as zero or more of the following: 205 +0 (MSB) +1 (LSB) 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 207 0: | OPTION-CODE | 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 2: | OPTION-LENGTH | 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 4: | | 212 / OPTION-DATA / 213 / / 214 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 216 OPTION-CODE 217 Assigned by Expert Review. 219 OPTION-LENGTH 220 Size (in octets) of OPTION-DATA. 222 OPTION-DATA 223 Varies per OPTION-CODE. 225 Order of appearance of option tuples is never relevant. Any option 226 whose meaning is affected by other options is so affected no matter 227 which one comes first in the OPT RDATA. 229 Any OPTION-CODE values not understood by a responder or requestor 230 MUST be ignored. Specifications of such options might wish to 231 include some kind of signalled acknowledgement. For example, an 232 option specification might say that if a responder sees option XYZ, 233 it SHOULD include option XYZ in its response. 235 6.3. Requestor's Payload Size 237 The requestor's UDP payload size (which OPT stores in the RR CLASS 238 field) is the number of octets of the largest UDP payload that can be 239 reassembled and delivered in the requestor's network stack. Note 240 that path MTU, with or without fragmentation, may be smaller than 241 this. Values lower than 512 MUST be treated as equal to 512. 243 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 244 buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. 245 The consequence of choosing too large a value may be an ICMP message 246 from an intermediate gateway, or even a silent drop of the response 247 message. 249 The requestor's maximum payload size can change over time, and MUST 250 therefore not be cached for use beyond the transaction in which it is 251 advertised. 253 6.4. Responder's Payload Size 255 The responder's maximum payload size can change over time, but can be 256 reasonably expected to remain constant between two sequential 257 transactions; for example, a meaningless QUERY to discover a 258 responder's maximum UDP payload size, followed immediately by an 259 UPDATE which takes advantage of this size. (This is considered 260 preferrable to the outright use of TCP for oversized requests, if 261 there is any reason to suspect that the responder implements EDNS, 262 and if a request will not fit in the default 512 payload size limit.) 264 6.5. Payload Size Selection 266 Due to transaction overhead, it is unwise to advertise an 267 architectural limit as a maximum UDP payload size. Just because your 268 stack can reassemble 64KB datagrams, don't assume that you want to 269 spend more than about 4KB of state memory per ongoing transaction. 271 A requestor MAY choose to implement a fallback to smaller advertised 272 sizes to work around firewall or other network limitations. A 273 requestor SHOULD choose to use a fallback mechanism which begins with 274 a large size, such as 4096. If that fails, a fallback around the 275 1220 byte range SHOULD be tried, as it has a reasonable chance to fit 276 within a single Ethernet frame. Failing that, a requestor MAY choose 277 a 512 byte packet, which with large answers may cause a TCP retry. 279 6.6. Middleware Boxes 281 Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. 283 Middleware boxes which simply forward requests to a recursive 284 resolver MUST NOT modify the OPT record contents in either direction. 286 6.7. Extended RCODE 288 The extended RCODE and flags (which OPT stores in the RR TTL field) 289 are structured as follows: 291 +0 (MSB) +1 (LSB) 292 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 293 0: | EXTENDED-RCODE | VERSION | 294 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 295 2: | DO| Z | 296 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 298 EXTENDED-RCODE 299 Forms upper 8 bits of extended 12-bit RCODE. Note that 300 EXTENDED-RCODE value "0" indicates that an unextended RCODE is 301 in use (values "0" through "15"). 303 VERSION 304 Indicates the implementation level of whoever sets it. Full 305 conformance with this specification is indicated by version 306 ``0.'' Requestors are encouraged to set this to the lowest 307 implemented level capable of expressing a transaction, to 308 minimize the responder and network load of discovering the 309 greatest common implementation level between requestor and 310 responder. A requestor's version numbering strategy MAY 311 ideally be a run time configuration option. 313 If a responder does not implement the VERSION level of the 314 request, then it answers with RCODE=BADVERS. All responses 315 MUST be limited in format to the VERSION level of the request, 316 but the VERSION of each response SHOULD be the highest 317 implementation level of the responder. In this way a requestor 318 will learn the implementation level of a responder as a side 319 effect of every response, including error responses and 320 including RCODE=BADVERS. 322 DO 323 DNSSEC OK bit as defined by [RFC3225]. 325 Z 326 Set to zero by senders and ignored by receivers, unless 327 modified in a subsequent specification. 329 6.8. OPT Options Type Allocation Procedure 331 Allocations assigned by expert review. TBD 333 7. Transport Considerations 335 The presence of an OPT pseudo-RR in a request should be taken as an 336 indication that the requestor fully implements the given version of 337 EDNS, and can correctly understand any response that conforms to that 338 feature's specification. 340 Lack of presence of an OPT record in a request MUST be taken as an 341 indication that the requestor does not implement any part of this 342 specification and that the responder MUST NOT use any protocol 343 extension described here in its response. 345 Responders who do not implement these protocol extensions MUST 346 respond with FORMERR messages without any OPT record. 348 If there is a problem with processing the OPT record itself, such as 349 an option value that is badly formatted or includes out of range 350 values, a FORMERR MAY be retured. If this occurs the response MUST 351 include an OPT record. This MAY be used to distinguish between 352 servers whcih do not implement EDNS and format errors within EDNS. 354 If EDNS is used in a request, and the response arrives with TC set 355 and with no EDNS OPT RR, a requestor SHOULD assume that truncation 356 prevented the OPT RR from being appended by the responder, and 357 further, that EDNS is not used in the response. Correspondingly, an 358 EDNS responder who cannot fit all necessary elements (including an 359 OPT RR) into a response, SHOULD respond with a normal (unextended) 360 DNS response, possibly setting TC if the response will not fit in the 361 unextended response message's 512-octet size. 363 8. Security Considerations 365 Requestor-side specification of the maximum buffer size may open a 366 new DNS denial of service attack if responders can be made to send 367 messages which are too large for intermediate gateways to forward, 368 thus leading to potential ICMP storms between gateways and 369 responders. 371 Announcing very large UDP buffer sizes may result in dropping by 372 firewalls. This could cause retransmissions with no hope of success. 373 Some devices reject fragmented UDP packets. 375 Announcing too small UDP buffer sizes may result in fallback to TCP. 376 This is especially important with DNSSEC, where answers are much 377 larger. 379 9. IANA Considerations 381 The IANA has assigned RR type code 41 for OPT. 383 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 384 NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option 385 Codes", "EDNS Version Numbers", and "Domain System Response Code." 386 IANA is advised to re-parent these subregistries to this document. 388 RFC 2671 created an extended label type registry. We request that 389 this registry be closed. 391 This document assigns extended label type 0bxx111111 as "Reserved for 392 future extended label types." We request that IANA record this 393 assignment. 395 This document assigns option code 65535 to "Reserved for future 396 expansion." 398 This document expands the RCODE space from 4 bits to 12 bits. This 399 will allow IANA to assign more than the 16 distinct RCODE values 400 allowed in RFC 1035 [RFC1035]. 402 This document assigns EDNS Extended RCODE "16" to "BADVERS". 404 IESG approval should be required to create new entries in the EDNS 405 Extended Label Type or EDNS Version Number registries, while any 406 published RFC (including Informational, Experimental, or BCP) should 407 be grounds for allocation of an EDNS Option Code. 409 10. Acknowledgements 411 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 412 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas 413 Narten were each instrumental in creating and refining this 414 specification. 416 11. References 418 11.1. Normative References 420 [RFC1035] Mockapetris, P., "Domain names - implementation and 421 specification", STD 13, RFC 1035, November 1987. 423 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 424 RFC 2671, August 1999. 426 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 427 RFC 3225, December 2001. 429 11.2. Informative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 Authors' Addresses 436 Michael Graff 437 Internet Systems Consortium 438 950 Charter Street 439 Redwood City, California 94063 440 US 442 Phone: +1 650.423.1304 443 Email: mgraff@isc.org 444 Paul Vixie 445 Internet Systems Consortium 446 950 Charter Street 447 Redwood City, California 94063 448 US 450 Phone: +1 650.423.1301 451 Email: vixie@isc.org