idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 directly say this. It does mention RFC2671 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2673, 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Requestors SHOULD place a value in this field that it can actually receive. For example, if a requestor sits behind a firewall which will block fragmented IP packets, a requestor SHOULD not choose a value which will cause fragmentation. Doing so will prevent large responses from being received, and can cause fallback to occur. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The requestor's maximum payload size can change over time. It MUST not be cached for use beyond the transaction in which it is advertised. -- 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 25, 2010) is 5145 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 (~~), 3 warnings (==), 4 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, 2673 Internet Systems Consortium 5 (if approved) March 25, 2010 6 Intended status: Standards Track 7 Expires: September 26, 2010 9 Extension Mechanisms for DNS (EDNS0) 10 draft-ietf-dnsext-rfc2671bis-edns0-03 12 Abstract 14 The Domain Name System's wire protocol includes a number of fixed 15 fields whose range has been or soon will be exhausted and does not 16 allow requestors to advertise their capabilities to responders. This 17 document describes backward compatible mechanisms for allowing the 18 protocol to grow. 20 This document updates the EDNS0 specification (RFC2671) based on 10 21 years of deployment experience. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 26, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 66 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 4 67 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 70 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 71 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5 73 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 74 6.3. Caching behavior . . . . . . . . . . . . . . . . . . . . . 7 75 6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7 77 6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7 78 6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8 79 6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8 80 6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8 81 6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9 83 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 9 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 Appendix A. Document Editing History . . . . . . . . . . . . . . 11 87 Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11 88 Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 11 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 DNS [RFC1035] specifies a Message Format and within such messages 97 there are standard formats for encoding options, errors, and name 98 compression. The maximum allowable size of a DNS Message is fixed. 99 Many of DNS's protocol limits are too small for uses which are or 100 which are desired to become common. There is no way for 101 implementations to advertise their capabilities. 103 Unextended agents will not know how to interpret the protocol 104 extensions detailed here. In practice, these clients will be 105 upgraded when they have need of a new feature, and only new features 106 will make use of the extensions. Extended agents must be prepared 107 for behavior of unextended clients in the face of new protocol 108 elements, and fall back gracefully to unextended DNS. [RFC2671] 109 proposed extensions to the basic DNS protocol to overcome these 110 deficiencies. This memo refines that specification and obsoletes 111 [RFC2671]. 113 [RFC2671] specified extended label types. The only one ever proposed 114 was in RFC2673 for a label type called "Bitstring Labels." For 115 various reasons introducing a new label type was found to be 116 extremely difficult, and RFC2673 was moved to Experimental. This 117 document Obsoletes Extended Labels. 119 2. Terminology 121 "Requestor" is the side which sends a request. "Responder" is an 122 authoritative, recursive resolver, or other DNS component which 123 responds to questions. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. EDNS Support Requirement 131 EDNS support is mandatory in a modern world. DNSSEC requires EDNS 132 support, and many other Features are made possible only by EDNS 133 support to request or advertise them. Many organizations are 134 beginning to require DNSSEC. Without common interoperability, DNSSEC 135 cannot be as easily deployed. 137 DNS publishers are wanting to put more data in answers. DNSSEC 138 DNSKEY records, negative answers, and many other DNSSEC queries cause 139 larger answers to be returned. In order to support this, DNS 140 servers, middleware, and stub resolvers MUST support larger packet 141 sizes advertised via EDNS0. 143 4. Affected Protocol Elements 145 4.1. Message Header 147 The DNS Message Header's second full 16-bit word is divided into a 148 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , 149 section 4.1.1 [RFC1035]). Some of these were marked for future use, 150 and most these have since been allocated. Also, most of the RCODE 151 values are now in use. The OPT pseudo-RR specified below contains 152 subfields that carry a bit field extension of the RCODE field and 153 additional flag bits, respectively. 155 4.2. Label Types 157 The first two bits of a wire format domain label are used to denote 158 the type of the label. [RFC1035] allocates two of the four possible 159 types and reserves the other two. More label types were defined in 160 [RFC2671]. 162 4.3. UDP Message Size 164 Traditional DNS Messages are limited to 512 octets in size when sent 165 over UDP ([RFC1035]). Today, many organizations wish to return many 166 records in a single reply, and special tricks are needed to make the 167 responses fit in this 512-byte limit. Additionally, DNSSEC 168 signatures can easily generate a much larger response than a 512 byte 169 message can hold. 171 EDNS0 is intended to address these larger packet sizes and continue 172 to use UDP. It specifies a way to advertise additional features such 173 as larger response size capability, which is intended to help avoid 174 truncated UDP responses which then cause retry over TCP. 176 5. Extended Label Types 178 The first octet in the on-the-wire representation of a DNS label 179 specifies the label type; the basic DNS specification [RFC1035] 180 dedicates the two most significant bits of that octet for this 181 purpose. 183 [RFC2671] defined DNS label type 0b01 for use as an indication for 184 Extended Label Types. A specific Extended Label Type is selected by 185 the 6 least significant bits of the first octet. Thus, Extended 186 Label Types are indicated by the values 64-127 (0b01xxxxxx) in the 187 first octet of the label. 189 This document does not describe any specific Extended Label Type. 191 In practice, Extended Label Types are difficult to use due to support 192 in clients and intermediate gateways. Therefore, the registry of 193 Extended Label Types is requested to be closed. They cause 194 interoperability problems and at present no defined label types are 195 in use. 197 Bitstring labels were originally created to solve problems with IPv6 198 reverse zones. Due to the problems of introducing a new label type 199 they were moved to experimental. This document moves them from 200 experimental to historical, making them obsoleted. 202 6. OPT pseudo-RR 204 6.1. OPT Record Definition 206 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the 207 additional data section of a request. 209 The OPT RR has been assigned RR type 41. 211 If present in requests, compliant responders MUST include an OPT 212 record in responses. 214 An OPT record does not carry any DNS data. It is used only to 215 contain control information pertaining to the question and answer 216 sequence of a specific transaction. OPT RRs MUST NOT be cached, 217 forwarded, or stored in or loaded from master files. 219 The OPT RR MAY be placed anywhere within the additional data section. 220 Only one OPT RR MAY be included within any DNS message. If a message 221 with more than one OPT RR is received, a FORMERR MUST be returned. 223 6.2. OPT Record Format 225 An OPT RR has a fixed part and a variable set of options expressed as 226 {attribute, value} pairs. The fixed part holds some DNS meta data 227 and also a small collection of basic extension elements which we 228 expect to be so popular that it would be a waste of wire space to 229 encode them as {attribute, value} pairs. 231 The fixed part of an OPT RR is structured as follows: 233 +------------+--------------+------------------------------+ 234 | Field Name | Field Type | Description | 235 +------------+--------------+------------------------------+ 236 | NAME | domain name | empty (root domain) | 237 | TYPE | u_int16_t | OPT | 238 | CLASS | u_int16_t | requestor's UDP payload size | 239 | TTL | u_int32_t | extended RCODE and flags | 240 | RDLEN | u_int16_t | describes RDATA | 241 | RDATA | octet stream | {attribute,value} pairs | 242 +------------+--------------+------------------------------+ 244 OPT RR Format 246 The variable part of an OPT RR is encoded in its RDATA and is 247 structured as zero or more of the following: 249 +0 (MSB) +1 (LSB) 250 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 251 0: | OPTION-CODE | 252 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 253 2: | OPTION-LENGTH | 254 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 255 4: | | 256 / OPTION-DATA / 257 / / 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 260 OPTION-CODE 261 Assigned by Expert Review. 263 OPTION-LENGTH 264 Size (in octets) of OPTION-DATA. 266 OPTION-DATA 267 Varies per OPTION-CODE. 269 The order of appearance of option tuples is not guaranteed. If one 270 option modifies the behavior of another or multiple options are 271 related to one another in some way, they have the same effect 272 regardless of ordering in the RDATA wire encoding. 274 Any OPTION-CODE values not understood by a responder or requestor 275 MUST be ignored. Specifications of such options might wish to 276 include some kind of signaled acknowledgement. For example, an 277 option specification might say that if a responder sees option XYZ, 278 it MUST include option XYZ in its response. 280 6.3. Caching behavior 282 The OPT record must not be cached. 284 6.4. Fallback 286 If a requestor detects that the remote end does not support EDNS0, it 287 MAY issue queries without an OPT record. It MAY cache this knowledge 288 for a brief time in order to avoid fallback delays in the future. 289 However, if DNSSEC is required, no fallback should be performed as 290 DNSSEC is only signaled through EDNS0. 292 6.5. Requestor's Payload Size 294 The requestor's UDP payload size (which OPT stores in the RR CLASS 295 field) is the number of octets of the largest UDP payload that can be 296 reassembled and delivered in the requestor's network stack. Note 297 that path MTU, with or without fragmentation, may be smaller than 298 this. Values lower than 512 MUST be treated as equal to 512. 300 Requestors SHOULD place a value in this field that it can actually 301 receive. For example, if a requestor sits behind a firewall which 302 will block fragmented IP packets, a requestor SHOULD not choose a 303 value which will cause fragmentation. Doing so will prevent large 304 responses from being received, and can cause fallback to occur. 306 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 307 buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. 308 Choosing a very large value will guarantee fragmentation at the IP 309 layer, and may prevent answers from being received due to a single 310 fragment loss or misconfigured firewalls. 312 The requestor's maximum payload size can change over time. It MUST 313 not be cached for use beyond the transaction in which it is 314 advertised. 316 6.6. Responder's Payload Size 318 The responder's maximum payload size can change over time, but can be 319 reasonably expected to remain constant between two sequential 320 transactions; for example, a meaningless QUERY to discover a 321 responder's maximum UDP payload size, followed immediately by an 322 UPDATE which takes advantage of this size. This is considered 323 preferable to the outright use of TCP for oversized requests, if 324 there is any reason to suspect that the responder implements EDNS, 325 and if a request will not fit in the default 512 payload size limit. 327 6.7. Payload Size Selection 329 Due to transaction overhead, it is unwise to advertise an 330 architectural limit as a maximum UDP payload size. Just because your 331 stack can reassemble 64KB datagrams, don't assume that you want to 332 spend more than about 4KB of state memory per ongoing transaction. 334 A requestor MAY choose to implement a fallback to smaller advertised 335 sizes to work around firewall or other network limitations. A 336 requestor SHOULD choose to use a fallback mechanism which begins with 337 a large size, such as 4096. If that fails, a fallback around the 338 1280 byte range SHOULD be tried, as it has a reasonable chance to fit 339 within a single Ethernet frame. Failing that, a requestor MAY choose 340 a 512 byte packet, which with large answers may cause a TCP retry. 342 6.8. Middleware Boxes 344 Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. 346 Middleware boxes which simply forward requests to a recursive 347 resolver MUST NOT modify the OPT record contents in either direction. 349 Middleware boxes which have additional functionality, such as 350 answering certain queries or acting like an intelligent forwarder, 351 MUST understand the OPT record. These boxes MUST consider the 352 incoming request and any outgoing requests as separate transactions 353 if the characteristics of the messages are different. 355 6.9. OPT Record TTL Field Use 357 The extended RCODE and flags (which OPT stores in the RR TTL field) 358 are structured as follows: 360 +0 (MSB) +1 (LSB) 361 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 362 0: | EXTENDED-RCODE | VERSION | 363 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 364 2: | DO| Z | 365 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 367 EXTENDED-RCODE 368 Forms upper 8 bits of extended 12-bit RCODE. Note that 369 EXTENDED-RCODE value 0 indicates that an unextended RCODE is in 370 use (values 0 through 15). 372 VERSION 373 Indicates the implementation level of whoever sets it. Full 374 conformance with this specification is indicated by version 375 ``0.'' Requestors are encouraged to set this to the lowest 376 implemented level capable of expressing a transaction, to 377 minimize the responder and network load of discovering the 378 greatest common implementation level between requestor and 379 responder. A requestor's version numbering strategy MAY 380 ideally be a run time configuration option. 381 If a responder does not implement the VERSION level of the 382 request, then it answers with RCODE=BADVERS. All responses 383 MUST be limited in format to the VERSION level of the request, 384 but the VERSION of each response SHOULD be the highest 385 implementation level of the responder. In this way a requestor 386 will learn the implementation level of a responder as a side 387 effect of every response, including error responses and 388 including RCODE=BADVERS. 390 6.10. Flags 392 DO 393 DNSSEC OK bit as defined by [RFC3225]. 395 Z 396 Set to zero by senders and ignored by receivers, unless 397 modified in a subsequent specification. 399 6.11. OPT Options Code Allocation Procedure 401 Allocations assigned by expert review. Assignment of Option Codes 402 should be liberal, but duplicate functionality is to be avoided. 404 7. Transport Considerations 406 The presence of an OPT pseudo-RR in a request should be taken as an 407 indication that the requestor fully implements the given version of 408 EDNS, and can correctly understand any response that conforms to that 409 feature's specification. 411 Lack of presence of an OPT record in a request MUST be taken as an 412 indication that the requestor does not implement any part of this 413 specification and that the responder MUST NOT include an OPT record 414 in its response. 416 Responders who do not implement these protocol extensions MUST 417 respond with FORMERR messages without any OPT record. 419 If there is a problem with processing the OPT record itself, such as 420 an option value that is badly formatted or includes out of range 421 values, a FORMERR MUST be returned. If this occurs the response MUST 422 include an OPT record. This is intended to allow the requestor to to 423 distinguish between servers which do not implement EDNS and format 424 errors within EDNS. 426 The minimal response must be the DNS header, question section, and an 427 OPT record. This must also occur when an truncated response (using 428 the DNS header's TC bit) is returned. 430 8. Security Considerations 432 Requestor-side specification of the maximum buffer size may open a 433 new DNS denial of service attack if responders can be made to send 434 messages which are too large for intermediate gateways to forward, 435 thus leading to potential ICMP storms between gateways and 436 responders. 438 Announcing very large UDP buffer sizes may result in dropping by 439 firewalls. This could cause retransmissions with no hope of success. 440 Some devices reject fragmented UDP packets. 442 Announcing too small UDP buffer sizes may result in fallback to TCP. 443 This is especially important with DNSSEC, where answers are much 444 larger. 446 9. IANA Considerations 448 The IANA has assigned RR type code 41 for OPT. 450 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 451 NAME SYSTEM PARAMETERS:" 453 o EDNS Extended Label Type 455 o EDNS Option Codes 457 o EDNS Version Numbers 459 o Domain System Response Code 461 IANA is advised to re-parent these sub-registries to this document. 463 [RFC2671] created the "EDNS Extended Label Type Registry". We 464 request that this registry be closed. 466 This document assigns option code 65535 in the "EDNS Option Codes" 467 registry to "Reserved for future expansion." 469 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This 470 allows more than the 16 distinct RCODE values allowed in [RFC1035]. 471 IETF Standards Action is required to add a new RCODE. Adding new 472 RCODEs should be avoided due to the difficulty in upgrading the 473 installed base. 475 This document assigns EDNS Extended RCODE 16 to "BADVERS". 477 IETF Standards Action is required for assignments of new EDNS0 flags. 478 Flags SHOULD be used only when necessary for DNS resolution to 479 function. For many uses, a EDNS Option Code may be preferred. 481 IETF Standards Action is required to create new entries in the EDNS 482 Version Number registry. Expert Review is required for allocation of 483 an EDNS Option Code. 485 Appendix A. Document Editing History 487 Following is a list of high-level changes made to the original 488 RFC2671. 490 Appendix A.1. Changes since RFC2671 492 o Support for the OPT record is now mandatory. 494 o Extended label types obsoleted and the registry is closed. 496 o The bitstring label type, which was already moved from draft to 497 experimental, is requested to be moved to historical. 499 o Changes in how EDNS buffer sizes are selected, with 500 recommendations on how to select them. 502 o Front material (IPR notice and such) was updated to current 503 requirements. 505 Appendix A.2. Changes since -02 507 o Specified the method for allocation of constants. 509 o Cleaned up a lot of wording, along with quite a bit of document 510 structure changes. 512 10. References 514 10.1. Normative References 516 [RFC1035] Mockapetris, P., "Domain names - implementation and 517 specification", STD 13, RFC 1035, November 1987. 519 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 520 RFC 2671, August 1999. 522 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 523 RFC 3225, December 2001. 525 10.2. Informative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 Authors' Addresses 532 Michael Graff 533 Internet Systems Consortium 534 950 Charter Street 535 Redwood City, California 94063 536 US 538 Phone: +1 650.423.1304 539 Email: mgraff@isc.org 541 Paul Vixie 542 Internet Systems Consortium 543 950 Charter Street 544 Redwood City, California 94063 545 US 547 Phone: +1 650.423.1301 548 Email: vixie@isc.org