idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 31, 2012) is 4128 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) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group J. Damas 3 Internet-Draft Bond Internet Systems 4 Obsoletes: 2671, 2673 M. Graff 5 (if approved) 6 Intended status: Standards Track P. Vixie 7 Expires: July 4, 2013 Internet Systems Consortium 8 December 31, 2012 10 Extension Mechanisms for DNS (EDNS(0)) 11 draft-ietf-dnsext-rfc2671bis-edns0-10 13 Abstract 15 The Domain Name System's wire protocol includes a number of fixed 16 fields whose range has been or soon will be exhausted and does not 17 allow requestors to advertise their capabilities to responders. This 18 document describes backward compatible mechanisms for allowing the 19 protocol to grow. 21 This document updates the EDNS(0) specification (and obsoletes RFC 22 2671) based on feedback from deployment experience in several 23 implementations. It also obsoletes RFC 2673 ("Binary Labels in the 24 Domain Name System") and adds considerations on the use of extended 25 labels in the DNS. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 4, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5 76 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5 78 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5 79 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 5 80 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6 81 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6 82 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6 83 6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 6 84 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7 85 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 8 86 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 87 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 9 88 6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 9 89 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 9 90 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10 91 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 10 92 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11 93 6.2.6. Support in MiddleBoxes . . . . . . . . . . . . . . . . 11 94 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 14 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 101 Appendix A. Document Editing History . . . . . . . . . . . . . . 15 102 A.1. Changes since RFC2671 . . . . . . . . . . . . . . . . . . 15 103 A.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 DNS [RFC1035] specifies a Message Format and within such messages 109 there are standard formats for encoding options, errors, and name 110 compression. The maximum allowable size of a DNS Message over UDP 111 not using the extensions described in this document is limited to 512 112 bytes. Many of DNS's protocol limits, such as the maximum message 113 size over UDP, are too small to efficiently support the additional 114 information that can be conveyed in the DNS (e.g. several IPv6 115 addresses or DNSSEC signatures). Finally, RFC 1035 does not define 116 any way for implementations to advertise their capabilities to any of 117 the other actors they interact with. 119 [RFC2671] added an extension mechanism to DNS. This mechanism is 120 widely supported and a number of new DNS uses and protocol extensions 121 depend on the presence of these extensions. This memo refines that 122 specification and obsoletes [RFC2671]. 124 Unextended agents will not know how to interpret the protocol 125 extensions defined in [RFC2671] and restated here. Extended agents 126 need to be prepared for handling the interactions with unextended 127 clients in the face of new protocol elements, and fall back 128 gracefully to unextended DNS. 130 EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is 131 negotiated between each pair of hosts in a DNS resolution process. 132 For instance the stub resolver communicating with the recursive 133 resolver or the recursive resolver communicating with an 134 authoritative server. 136 [RFC2671] specified extended label types. The only such label 137 proposed was in [RFC2673] for a label type called "Bitstring Labels." 138 For various reasons introducing a new label type was found to be 139 extremely difficult, and [RFC2673] was moved to Experimental. This 140 document deprecates Extended Labels, and therefore Binary Labels, 141 obsoleting [RFC2673]. 143 2. Terminology 145 "Requestor" is the side which sends a request. "Responder" is an 146 authoritative, recursive resolver, or other DNS component which 147 responds to questions. Other terminology is used as per its use in 148 the references. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. EDNS Support Requirement 156 EDNS provides a mechanism to improve the scalability of DNS as its 157 uses get more diverse on the Internet. It does this by enabling the 158 use of UDP transport for DNS messages with sizes beyond the limits 159 specified in RFC 1035 as well as providing extra data space for 160 additional flags and return codes (RCODEs). However, implementation 161 experiencing indicates that adding new RCODEs should be avoided due 162 to the difficulty in upgrading the installed base. Flags SHOULD be 163 used only when necessary for DNS resolution to function. 165 For many uses, a EDNS Option Code may be preferred. 167 With time, some applications of DNS have made EDNS a requirement for 168 their deployment. For instance, DNSSEC uses the additional flag 169 space introduced in EDNS to signal the request to include DNSSEC data 170 in a DNS response. 172 Given the increase in DNS response sizes when including larger data 173 items such as AAAA Records, DNSSEC information (e.g. RRSIG or 174 DNSKEY) or large TXT Records, the additional UDP payload capabilities 175 provided by EDNS can help improve the scalability of the DNS by 176 avoiding widespread use of TCP for DNS transport. 178 4. DNS Message changes 180 4.1. Message Header 182 The DNS Message Header's second full 16-bit word is divided into a 183 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , 184 section 4.1.1 [RFC1035]). Some of these were marked for future use, 185 and most these have since been allocated. Also, most of the RCODE 186 values are now in use. The OPT pseudo-RR specified below contains 187 extensions to the RCODE bit field as well as additional flag bits. 189 4.2. Label Types 191 The first two bits of a wire format domain label are used to denote 192 the type of the label. [RFC1035] allocates two of the four possible 193 types and reserves the other two. More label types were defined in 194 [RFC2671]. This document obsoletes the use of the 2-bit combination 195 defined by [RFC2671] to identify extended label types. 197 4.3. UDP Message Size 199 Traditional DNS Messages are limited to 512 octets in size when sent 200 over UDP [RFC1035]. Fitting the increasing amounts of data that can 201 be transported in DNS in this 512-byte limit is becoming more 202 difficult. For instance, inclusion of DNSSEC records frequently 203 requires a much larger response than a 512 byte message can hold. 205 EDNS(0) is intended to provide support for transporting these larger 206 packet sizes while continuing to use UDP. It specifies a way to 207 advertise additional features such as larger response size 208 capability, which is intended to help avoid truncated UDP responses 209 which then cause retry over TCP. 211 5. Extended Label Types 213 The first octet in the on-the-wire representation of a DNS label 214 specifies the label type; the basic DNS specification [RFC1035] 215 dedicates the two most significant bits of that octet for this 216 purpose. 218 [RFC2671] defined DNS label type 0b01 for use as an indication for 219 Extended Label Types. A specific Extended Label Type was selected by 220 the 6 least significant bits of the first octet. Thus, Extended 221 Label Types were indicated by the values 64-127 (0b01xxxxxx) in the 222 first octet of the label. 224 Extended Label Types are extremely difficult to deploy due to lack of 225 support in clients and intermediate gateways as described in 226 [RFC3363] which moved [RFC2673] to experimental status, and 227 [RFC3364], which describes the pros and cons. As such proposals that 228 contemplate extended labels SHOULD weigh this deployment cost against 229 the possibility of implementing functionality in other ways. 231 Finally, implementations MUST NOT generate or pass Binary Labels in 232 their communications as they are now deprecated. 234 6. The OPT pseudo-RR 236 6.1. OPT Record Definition 238 6.1.1. Basic elements 240 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the 241 additional data section of a request. 243 The OPT RR has RR type 41. 245 If present in requests, compliant responders MUST include an OPT 246 record in their respective responses. 248 An OPT record does not carry any DNS data. It is used only to 249 contain control information pertaining to the question and answer 250 sequence of a specific transaction. OPT RRs MUST NOT be cached, 251 forwarded, or stored in or loaded from master files. 253 The OPT RR MAY be placed anywhere within the additional data section. 254 When an OPT RR MUST is included within any DNS message only ONE OPT 255 RR can be present. If a query message with more than one OPT RR is 256 received, a FORMERR (RCODE=1) MUST be returned. The placement 257 flexibility for the OPT RR does not override the need for the TSIG or 258 SIG(0) RRs to be the last in the additional section whenever they are 259 present. 261 6.1.2. Wire Format 263 An OPT RR has a fixed part and a variable set of options expressed as 264 {attribute, value} pairs. The fixed part holds some DNS meta data 265 and also a small collection of basic extension elements which we 266 expect to be so popular that it would be a waste of wire space to 267 encode them as {attribute, value} pairs. 269 The fixed part of an OPT RR is structured as follows: 271 +------------+--------------+------------------------------+ 272 | Field Name | Field Type | Description | 273 +------------+--------------+------------------------------+ 274 | NAME | domain name | MUST be 0 (root domain) | 275 | TYPE | u_int16_t | OPT (41) | 276 | CLASS | u_int16_t | requestor's UDP payload size | 277 | TTL | u_int32_t | extended RCODE and flags | 278 | RDLEN | u_int16_t | length of all RDATA | 279 | RDATA | octet stream | {attribute,value} pairs | 280 +------------+--------------+------------------------------+ 282 OPT RR Format 284 The variable part of an OPT RR may contain zero or more options in 285 the RDATA. Each option MUST be treated as a bit field. Each option 286 is encoded as: 288 +0 (MSB) +1 (LSB) 289 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 290 0: | OPTION-CODE | 291 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 292 2: | OPTION-LENGTH | 293 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 294 4: | | 295 / OPTION-DATA / 296 / / 297 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 299 OPTION-CODE 300 Assigned by the Expert Review process as defined by the dnsext 301 working group and the IESG. 303 OPTION-LENGTH 304 Size (in octets) of OPTION-DATA. 306 OPTION-DATA 307 Varies per OPTION-CODE. MUST be treated as a bit field. 309 The order of appearance of option tuples is not defined. If one 310 option modifies the behavior of another or multiple options are 311 related to one another in some way, they have the same effect 312 regardless of ordering in the RDATA wire encoding. 314 Any OPTION-CODE values not understood by a responder or requestor 315 MUST be ignored. Specifications of such options might wish to 316 include some kind of signaled acknowledgement. For example, an 317 option specification might say that if a responder sees and supports 318 option XYZ, it MUST include option XYZ in its response. 320 6.1.3. OPT Record TTL Field Use 322 The extended RCODE and flags (which OPT stores in the RR TTL field) 323 are structured as follows: 325 +0 (MSB) +1 (LSB) 326 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 327 0: | EXTENDED-RCODE | VERSION | 328 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 329 2: | DO| Z | 330 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 332 EXTENDED-RCODE 333 Forms upper 8 bits of extended 12-bit RCODE (together with the 334 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 335 indicates that an unextended RCODE is in use (values 0 through 336 15). 338 VERSION 339 Indicates the implementation level of the setter. Full 340 conformance with this specification is indicated by version 341 ``0.'' Requestors are encouraged to set this to the lowest 342 implemented level capable of expressing a transaction, to 343 minimize the responder and network load of discovering the 344 greatest common implementation level between requestor and 345 responder. A requestor's version numbering strategy MAY 346 ideally be a run time configuration option. 347 If a responder does not implement the VERSION level of the 348 request, then it MUST respond with RCODE=BADVERS. All 349 responses MUST be limited in format to the VERSION level of the 350 request, but the VERSION of each response SHOULD be the highest 351 implementation level of the responder. In this way a requestor 352 will learn the implementation level of a responder as a side 353 effect of every response, including error responses and 354 including RCODE=BADVERS. 356 6.1.4. Flags 358 DO 359 DNSSEC OK bit as defined by [RFC3225]. 361 Z 362 Set to zero by senders and ignored by receivers, unless 363 modified in a subsequent specification. 365 6.2. Behaviour 367 6.2.1. Cache behaviour 369 The OPT record MUST NOT be cached. 371 6.2.2. Fallback 373 If a requestor detects that the remote end does not support EDNS(0), 374 it MAY issue queries without an OPT record. It MAY cache this 375 knowledge for a brief time in order to avoid fallback delays in the 376 future. However, if DNSSEC or any future option using EDNS is 377 required, no fallback should be performed as they are only signalled 378 through EDNS. If an implementation detects that some servers for the 379 zone support EDNS(0) while others would force the use of TCP to fetch 380 all data, preference MAY be given to those which support EDNS(0). 381 Implementers SHOULD analyse this choice and the impact on both 382 endpoints. 384 6.2.3. Requestor's Payload Size 386 The requestor's UDP payload size (encoded in the RR CLASS field) is 387 the number of octets of the largest UDP payload that can be 388 reassembled and delivered in the requestor's network stack. Note 389 that path MTU, with or without fragmentation, could be smaller than 390 this. 392 Values lower than 512 MUST be treated as equal to 512. 394 The requestor SHOULD place a value in this field that it can actually 395 receive. For example, if a requestor sits behind a firewall which 396 will block fragmented IP packets, a requestor SHOULD NOT choose a 397 value which will cause fragmentation. Doing so will prevent large 398 responses from being received, and can cause fallback to occur. This 399 knowledge may be auto-detected by the implementation or provided by a 400 human administrator. 402 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 403 buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over 404 Ethernet would be reasonable. 406 Bigger values SHOULD be considered by implementers to be used where 407 fragmentation is not a concern. Implementations SHOULD use their 408 largest configured or implemented values as a starting point in an 409 EDNS transaction in the absence of previous knowledge about the 410 destination server. 412 Choosing a very large value will guarantee fragmentation at the IP 413 layer, and may prevent answers from being received due to a single 414 fragment loss or misconfigured firewalls. 416 The requestor's maximum payload size can change over time. It MUST 417 NOT be cached for use beyond the transaction in which it is 418 advertised. 420 6.2.4. Responder's Payload Size 422 The responder's maximum payload size can change over time, but can be 423 reasonably expected to remain constant between two closely spaced 424 sequential transactions; for example, an arbitrary QUERY used as a 425 probe to discover a responder's maximum UDP payload size, followed 426 immediately by an UPDATE which takes advantage of this size. This is 427 considered preferable to the outright use of TCP for oversized 428 requests, if there is any reason to suspect that the responder 429 implements EDNS, and if a request will not fit in the default 512 430 payload size limit. 432 6.2.5. Payload Size Selection 434 Due to transaction overhead, it is not recommended to advertise an 435 architectural limit as a maximum UDP payload size. Even on system 436 stacks capable of reassembling 64KB datagrams, memory usage at low 437 levels in the system will be a concern. A good compromise may be the 438 use of a EDNS maximum payload size of 4096 octets as a starting 439 point. 441 A requestor MAY choose to implement a fallback to smaller advertised 442 sizes to work around firewall or other network limitations. A 443 requestor SHOULD choose to use a fallback mechanism which begins with 444 a large size, such as 4096. If that fails, a fallback around the 445 1280-1410 byte range SHOULD be tried, as it has a reasonable chance 446 to fit within a single Ethernet frame. Failing that, a requestor MAY 447 choose a 512 byte packet, which with large answers may cause a TCP 448 retry. 450 Values of less than 512 bytes MUST be treated as equal to 512 bytes. 452 6.2.6. Support in MiddleBoxes 454 In a network that carries DNS traffic there could be active equipment 455 other than that participating directly in the DNS resolution process 456 (stub and caching resolvers, authoritative servers) that affect the 457 transmission of DNS messages (e.g. firewalls, load balancers, 458 proxies, etc) referred to here as MiddleBoxes. 460 Conformant MiddleBoxes MUST NOT limit DNS messages over UDP to 512 461 bytes. 463 MiddleBoxes which simply forward requests to a recursive resolver 464 MUST NOT modify and MUST NOT delete the OPT record contents in either 465 direction. 467 MiddleBoxes which have additional functionality, such as answering 468 queries or acting as intelligent forwarders, SHOULD be able to 469 process the OPT record and act based on its contents. These boxes 470 MUST consider the incoming request and any outgoing requests as 471 separate transactions if the characteristics of the messages are 472 different. 474 A more in depth discussion of this type of equipment and other 475 considerations regarding their interaction with DNS traffic is found 476 in [RFC5625] 478 7. Transport Considerations 480 The presence of an OPT pseudo-RR in a request should be taken as an 481 indication that the requestor fully implements the given version of 482 EDNS, and can correctly understand any response that conforms to that 483 feature's specification. 485 Lack of presence of an OPT record in a request MUST be taken as an 486 indication that the requestor does not implement any part of this 487 specification and that the responder MUST NOT include an OPT record 488 in its response. 490 Extended agents MUST be prepared for handling the interactions with 491 unextended clients in the face of new protocol elements, and fall 492 back gracefully to unextended DNS when needed. 494 Responders which choose not to implement the protocol extensions 495 defined in this document MUST respond with a return code (RCODE) of 496 FORMERR to messages containing an OPT RR in the additional section 497 and MUST NOT include an OPT record in the response. 499 If there is a problem with processing the OPT record itself, such as 500 an option value that is badly formatted or includes out of range 501 values, a FORMERR MUST be returned. If this occurs the response MUST 502 include an OPT record. This is intended to allow the requestor to 503 distinguish between servers which do not implement EDNS and format 504 errors within EDNS. 506 The minimal response MUST be the DNS header, question section, and an 507 OPT record. This MUST also occur when an truncated response (using 508 the DNS header's TC bit) is returned. 510 8. Security Considerations 512 Requestor-side specification of the maximum buffer size may open a 513 DNS denial of service attack if responders can be made to send 514 messages which are too large for intermediate gateways to forward, 515 thus leading to potential ICMP storms between gateways and 516 responders. 518 Announcing very large UDP buffer sizes may result in dropping by 519 middleboxes (see Section 6.2.6). This could cause retransmissions 520 with no hope of success. Some devices have been found to reject 521 fragmented UDP packets. 523 Announcing too small UDP buffer sizes may result in fallback to TCP 524 with a corresponding load impact on DNS servers. This is especially 525 important with DNSSEC, where answers are much larger. 527 9. IANA Considerations 529 The IANA has assigned RR type code 41 for OPT. 531 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 532 NAME SYSTEM PARAMETERS:" 534 o DNS EDNS(0) Options 536 o EDNS Version Number 538 o EDNS Header Flags 540 Additionally, two entries were generated in existing registries: 542 EDNS Extended Label Type in the DNS Label Types Registry 544 Bad OPT Version in the DNS RCODES registry 546 IANA is advised to update references to [RFC2671] in these entries 547 and sub-registries to this document. 549 [RFC2671] created the "EDNS Extended Label Type Registry". We 550 request that this registry be closed. 552 This document assigns option code 65535 in the "EDNS Option Codes" 553 registry to "Reserved for future expansion." 555 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This 556 allows more than the 16 distinct RCODE values allowed in [RFC1035]. 557 IETF Standards Action is required to add a new RCODE. 559 This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS 560 RCODES registry. 562 [RFC2671] called for the recording of assignment of extended label 563 types 0bxx111111 as "Reserved for future extended label types". This 564 request implied a request to open a new registry for Extended Label 565 Types but due to the possibility of ambiguity new text registrations 566 were instead made within the general "DNS Label Types" registry which 567 also registers entries originally defined by [RFC1035]. 569 This document requests IANA to close registration of further Extended 570 Label Types in the "DNS Label Types" Registry. 572 IETF Standards Action is required for assignments of new EDNS(0) 573 flags. Flags SHOULD be used only when necessary for DNS resolution 574 to function. For many uses, a EDNS Option Code may be preferred. 576 IETF Standards Action is required to create new entries in the EDNS 577 Version Number registry. Within the EDNS Option Code space Expert 578 Review is required for allocation of an EDNS Option Code. IANA is 579 requested to keep a registry for the EDNS Option Code space. 581 9.1. OPT Option Code Allocation Procedure 583 OPT Option Codes are assigned by expert review. 585 Assignment of Option Codes should be liberal, but duplicate 586 functionality is to be avoided. 588 10. References 590 10.1. Normative References 592 [RFC1035] Mockapetris, P., "Domain names - implementation and 593 specification", STD 13, RFC 1035, November 1987. 595 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 596 RFC 2671, August 1999. 598 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 599 RFC 3225, December 2001. 601 10.2. Informative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 607 RFC 2673, August 1999. 609 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 610 Hain, "Representing Internet Protocol version 6 (IPv6) 611 Addresses in the Domain Name System (DNS)", RFC 3363, 612 August 2002. 614 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 615 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 616 August 2002. 618 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 619 BCP 152, RFC 5625, August 2009. 621 Appendix A. Document Editing History 623 Following is a list of high-level changes made to the original 624 RFC2671. 626 A.1. Changes since RFC2671 628 o Support for the OPT record is now mandatory. 630 o Extended label types obsoleted and the registry is closed. 632 o The bitstring label type, which was already moved from draft to 633 experimental, is requested to be moved to historical. 635 o Changes in how EDNS buffer sizes are selected, with 636 recommendations on how to select them. 638 o Front material (IPR notice and such) was updated to current 639 requirements. 641 A.2. Changes since -02 643 o Specified the method for allocation of constants. 645 o Cleaned up a lot of wording, along with quite a bit of document 646 structure changes. 648 Authors' Addresses 650 Joao Damas 651 Bond Internet Systems 652 Av Albufera 14 653 S.S. Reyes, Madrid 28701 654 ES 656 Phone: +1 650.423.1312 657 Email: joao@bondis.org 659 Michael Graff 661 Email: explorer@flame.org 662 Paul Vixie 663 Internet Systems Consortium 664 950 Charter Street 665 Redwood City, California 94063 666 US 668 Phone: +1 650.423.1301 669 Email: vixie@isc.org