idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-09.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 (August 13, 2012) is 4272 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 M. Graff 4 Obsoletes: 2671, 2673 P. Vixie 5 (if approved) Internet Systems Consortium 6 Intended status: Standards Track August 13, 2012 7 Expires: February 14, 2013 9 Extension Mechanisms for DNS (EDNS(0)) 10 draft-ietf-dnsext-rfc2671bis-edns0-09 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 EDNS(0) specification (and obsoletes RFC 21 2671) based on feedback from deployment experience in several 22 implementations. It also closes the IANA registry for extended 23 labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary 24 Labels in the Domain Name System") which depends on the existence of 25 extended labels. 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 February 14, 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 difficult to use due to lack of support in 225 clients and intermediate gateways as described in [RFC3363] which 226 moved [RFC2673] to experimental status, and [RFC3364], which 227 describes the pros and cons. 229 Therefore, this document obsoletes [RFC2673] and deprecates the use 230 of Extended Label Types. 232 Implementations MUST NOT generate or pass Extended Labels in their 233 communications. Additionally, IANA has been requested to close 234 registration of further Extended Label Types in the "DNS Label Types" 235 Registry so that no further registrations will be permitted. 237 6. The OPT pseudo-RR 239 6.1. OPT Record Definition 241 6.1.1. Basic elements 243 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the 244 additional data section of a request. 246 The OPT RR has RR type 41. 248 If present in requests, compliant responders MUST include an OPT 249 record in their respective responses. 251 An OPT record does not carry any DNS data. It is used only to 252 contain control information pertaining to the question and answer 253 sequence of a specific transaction. OPT RRs MUST NOT be cached, 254 forwarded, or stored in or loaded from master files. 256 The OPT RR MAY be placed anywhere within the additional data section. 257 When an OPT RR MUST is included within any DNS message only ONE OPT 258 RR can be present. If a query message with more than one OPT RR is 259 received, a FORMERR (RCODE=1) MUST be returned. The placement 260 flexibility for the OPT RR does not override the need for the TSIG or 261 SIG(0) RRs to be the last in the additional section whenever they are 262 present. 264 6.1.2. Wire Format 266 An OPT RR has a fixed part and a variable set of options expressed as 267 {attribute, value} pairs. The fixed part holds some DNS meta data 268 and also a small collection of basic extension elements which we 269 expect to be so popular that it would be a waste of wire space to 270 encode them as {attribute, value} pairs. 272 The fixed part of an OPT RR is structured as follows: 274 +------------+--------------+------------------------------+ 275 | Field Name | Field Type | Description | 276 +------------+--------------+------------------------------+ 277 | NAME | domain name | MUST be 0 (root domain) | 278 | TYPE | u_int16_t | OPT (41) | 279 | CLASS | u_int16_t | requestor's UDP payload size | 280 | TTL | u_int32_t | extended RCODE and flags | 281 | RDLEN | u_int16_t | length of all RDATA | 282 | RDATA | octet stream | {attribute,value} pairs | 283 +------------+--------------+------------------------------+ 285 OPT RR Format 287 The variable part of an OPT RR may contain zero or more options in 288 the RDATA. Each option MUST be treated as a bit field. Each option 289 is encoded as: 291 +0 (MSB) +1 (LSB) 292 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 293 0: | OPTION-CODE | 294 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 295 2: | OPTION-LENGTH | 296 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 297 4: | | 298 / OPTION-DATA / 299 / / 300 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 302 OPTION-CODE 303 Assigned by the Expert Review process as defined by the dnsext 304 working group and the IESG. 306 OPTION-LENGTH 307 Size (in octets) of OPTION-DATA. 309 OPTION-DATA 310 Varies per OPTION-CODE. MUST be treated as a bit field. 312 The order of appearance of option tuples is not defined. If one 313 option modifies the behavior of another or multiple options are 314 related to one another in some way, they have the same effect 315 regardless of ordering in the RDATA wire encoding. 317 Any OPTION-CODE values not understood by a responder or requestor 318 MUST be ignored. Specifications of such options might wish to 319 include some kind of signaled acknowledgement. For example, an 320 option specification might say that if a responder sees and supports 321 option XYZ, it MUST include option XYZ in its response. 323 6.1.3. OPT Record TTL Field Use 325 The extended RCODE and flags (which OPT stores in the RR TTL field) 326 are structured as follows: 328 +0 (MSB) +1 (LSB) 329 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 330 0: | EXTENDED-RCODE | VERSION | 331 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 332 2: | DO| Z | 333 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 335 EXTENDED-RCODE 336 Forms upper 8 bits of extended 12-bit RCODE (together with the 337 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 338 indicates that an unextended RCODE is in use (values 0 through 339 15). 341 VERSION 342 Indicates the implementation level of the setter. Full 343 conformance with this specification is indicated by version 344 ``0.'' Requestors are encouraged to set this to the lowest 345 implemented level capable of expressing a transaction, to 346 minimize the responder and network load of discovering the 347 greatest common implementation level between requestor and 348 responder. A requestor's version numbering strategy MAY 349 ideally be a run time configuration option. 350 If a responder does not implement the VERSION level of the 351 request, then it MUST respond with RCODE=BADVERS. All 352 responses MUST be limited in format to the VERSION level of the 353 request, but the VERSION of each response SHOULD be the highest 354 implementation level of the responder. In this way a requestor 355 will learn the implementation level of a responder as a side 356 effect of every response, including error responses and 357 including RCODE=BADVERS. 359 6.1.4. Flags 361 DO 362 DNSSEC OK bit as defined by [RFC3225]. 364 Z 365 Set to zero by senders and ignored by receivers, unless 366 modified in a subsequent specification. 368 6.2. Behaviour 370 6.2.1. Cache behaviour 372 The OPT record MUST NOT be cached. 374 6.2.2. Fallback 376 If a requestor detects that the remote end does not support EDNS(0), 377 it MAY issue queries without an OPT record. It MAY cache this 378 knowledge for a brief time in order to avoid fallback delays in the 379 future. However, if DNSSEC or any future option using EDNS is 380 required, no fallback should be performed as they are only signalled 381 through EDNS. If an implementation detects that some servers for the 382 zone support EDNS(0) while others would force the use of TCP to fetch 383 all data, preference MAY be given to those which support EDNS(0). 384 Implementers SHOULD analyse this choice and the impact on both 385 endpoints. 387 6.2.3. Requestor's Payload Size 389 The requestor's UDP payload size (encoded in the RR CLASS field) is 390 the number of octets of the largest UDP payload that can be 391 reassembled and delivered in the requestor's network stack. Note 392 that path MTU, with or without fragmentation, could be smaller than 393 this. 395 Values lower than 512 MUST be treated as equal to 512. 397 The requestor SHOULD place a value in this field that it can actually 398 receive. For example, if a requestor sits behind a firewall which 399 will block fragmented IP packets, a requestor SHOULD NOT choose a 400 value which will cause fragmentation. Doing so will prevent large 401 responses from being received, and can cause fallback to occur. This 402 knowledge may be auto-detected by the implementation or provided by a 403 human administrator. 405 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 406 buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over 407 Ethernet would be reasonable. 409 Bigger values SHOULD be considered by implementers to be used where 410 fragmentation is not a concern. Implementations SHOULD use their 411 largest configured or implemented values as a starting point in an 412 EDNS transaction in the absence of previous knowledge about the 413 destination server. 415 Choosing a very large value will guarantee fragmentation at the IP 416 layer, and may prevent answers from being received due to a single 417 fragment loss or misconfigured firewalls. 419 The requestor's maximum payload size can change over time. It MUST 420 NOT be cached for use beyond the transaction in which it is 421 advertised. 423 6.2.4. Responder's Payload Size 425 The responder's maximum payload size can change over time, but can be 426 reasonably expected to remain constant between two closely spaced 427 sequential transactions; for example, an arbitrary QUERY used as a 428 probe to discover a responder's maximum UDP payload size, followed 429 immediately by an UPDATE which takes advantage of this size. This is 430 considered preferable to the outright use of TCP for oversized 431 requests, if there is any reason to suspect that the responder 432 implements EDNS, and if a request will not fit in the default 512 433 payload size limit. 435 6.2.5. Payload Size Selection 437 Due to transaction overhead, it is not recommended to advertise an 438 architectural limit as a maximum UDP payload size. Even on system 439 stacks capable of reassembling 64KB datagrams, memory usage at low 440 levels in the system will be a concern. A good compromise may be the 441 use of a EDNS maximum payload size of 4096 octets as a starting 442 point. 444 A requestor MAY choose to implement a fallback to smaller advertised 445 sizes to work around firewall or other network limitations. A 446 requestor SHOULD choose to use a fallback mechanism which begins with 447 a large size, such as 4096. If that fails, a fallback around the 448 1280-1410 byte range SHOULD be tried, as it has a reasonable chance 449 to fit within a single Ethernet frame. Failing that, a requestor MAY 450 choose a 512 byte packet, which with large answers may cause a TCP 451 retry. 453 Values of less than 512 bytes MUST be treated as equal to 512 bytes. 455 6.2.6. Support in MiddleBoxes 457 In a network that carries DNS traffic there could be active equipment 458 other than that participating directly in the DNS resolution process 459 (stub and caching resolvers, authoritative servers) that affect the 460 transmission of DNS messages (e.g. firewalls, load balancers, 461 proxies, etc) referred to here as MiddleBoxes. 463 Conformant MiddleBoxes MUST NOT limit DNS messages over UDP to 512 464 bytes. 466 MiddleBoxes which simply forward requests to a recursive resolver 467 MUST NOT modify and MUST NOT delete the OPT record contents in either 468 direction. 470 MiddleBoxes which have additional functionality, such as answering 471 queries or acting as intelligent forwarders, SHOULD be able to 472 process the OPT record and act based on its contents. These boxes 473 MUST consider the incoming request and any outgoing requests as 474 separate transactions if the characteristics of the messages are 475 different. 477 A more in depth discussion of this type of equipment and other 478 considerations regarding their interaction with DNS traffic is found 479 in [RFC5625] 481 7. Transport Considerations 483 The presence of an OPT pseudo-RR in a request should be taken as an 484 indication that the requestor fully implements the given version of 485 EDNS, and can correctly understand any response that conforms to that 486 feature's specification. 488 Lack of presence of an OPT record in a request MUST be taken as an 489 indication that the requestor does not implement any part of this 490 specification and that the responder MUST NOT include an OPT record 491 in its response. 493 Extended agents MUST be prepared for handling the interactions with 494 unextended clients in the face of new protocol elements, and fall 495 back gracefully to unextended DNS when needed. 497 Responders which choose not to implement the protocol extensions 498 defined in this document MUST respond with a return code (RCODE) of 499 FORMERR to messages containing an OPT RR in the additional section 500 and MUST NOT include an OPT record in the response. 502 If there is a problem with processing the OPT record itself, such as 503 an option value that is badly formatted or includes out of range 504 values, a FORMERR MUST be returned. If this occurs the response MUST 505 include an OPT record. This is intended to allow the requestor to 506 distinguish between servers which do not implement EDNS and format 507 errors within EDNS. 509 The minimal response MUST be the DNS header, question section, and an 510 OPT record. This MUST also occur when an truncated response (using 511 the DNS header's TC bit) is returned. 513 8. Security Considerations 515 Requestor-side specification of the maximum buffer size may open a 516 DNS denial of service attack if responders can be made to send 517 messages which are too large for intermediate gateways to forward, 518 thus leading to potential ICMP storms between gateways and 519 responders. 521 Announcing very large UDP buffer sizes may result in dropping by 522 middleboxes (see Section 6.2.6). This could cause retransmissions 523 with no hope of success. Some devices have been found to reject 524 fragmented UDP packets. 526 Announcing too small UDP buffer sizes may result in fallback to TCP 527 with a corresponding load impact on DNS servers. This is especially 528 important with DNSSEC, where answers are much larger. 530 9. IANA Considerations 532 The IANA has assigned RR type code 41 for OPT. 534 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 535 NAME SYSTEM PARAMETERS:" 537 o DNS EDNS(0) Options 539 o EDNS Version Number 541 o EDNS Header Flags 543 Additionally, two entries were generated in existing registries: 545 EDNS Extended Label Type in the DNS Label Types Registry 547 Bad OPT Version in the DNS RCODES registry 549 IANA is advised to update references to [RFC2671] in these entries 550 and sub-registries to this document. 552 [RFC2671] created the "EDNS Extended Label Type Registry". We 553 request that this registry be closed. 555 This document assigns option code 65535 in the "EDNS Option Codes" 556 registry to "Reserved for future expansion." 558 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This 559 allows more than the 16 distinct RCODE values allowed in [RFC1035]. 560 IETF Standards Action is required to add a new RCODE. 562 This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS 563 RCODES registry. 565 [RFC2671] called for the recording of assignment of extended label 566 types 0bxx111111 as "Reserved for future extended label types". This 567 request implied a request to open a new registry for Extended Label 568 Types but due to the possibility of ambiguity new text registrations 569 were instead made within the general "DNS Label Types" registry which 570 also registers entries originally defined by [RFC1035]. 572 This document requests IANA to close registration of further Extended 573 Label Types in the "DNS Label Types" Registry. 575 IETF Standards Action is required for assignments of new EDNS(0) 576 flags. Flags SHOULD be used only when necessary for DNS resolution 577 to function. For many uses, a EDNS Option Code may be preferred. 579 IETF Standards Action is required to create new entries in the EDNS 580 Version Number registry. Within the EDNS Option Code space Expert 581 Review is required for allocation of an EDNS Option Code. IANA is 582 requested to keep a registry for the EDNS Option Code space. 584 9.1. OPT Option Code Allocation Procedure 586 OPT Option Codes are assigned by expert review. 588 Assignment of Option Codes should be liberal, but duplicate 589 functionality is to be avoided. 591 10. References 593 10.1. Normative References 595 [RFC1035] Mockapetris, P., "Domain names - implementation and 596 specification", STD 13, RFC 1035, November 1987. 598 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 599 RFC 2671, August 1999. 601 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 602 RFC 3225, December 2001. 604 10.2. Informative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 610 RFC 2673, August 1999. 612 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 613 Hain, "Representing Internet Protocol version 6 (IPv6) 614 Addresses in the Domain Name System (DNS)", RFC 3363, 615 August 2002. 617 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 618 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 619 August 2002. 621 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 622 BCP 152, RFC 5625, August 2009. 624 Appendix A. Document Editing History 626 Following is a list of high-level changes made to the original 627 RFC2671. 629 A.1. Changes since RFC2671 631 o Support for the OPT record is now mandatory. 633 o Extended label types obsoleted and the registry is closed. 635 o The bitstring label type, which was already moved from draft to 636 experimental, is requested to be moved to historical. 638 o Changes in how EDNS buffer sizes are selected, with 639 recommendations on how to select them. 641 o Front material (IPR notice and such) was updated to current 642 requirements. 644 A.2. Changes since -02 646 o Specified the method for allocation of constants. 648 o Cleaned up a lot of wording, along with quite a bit of document 649 structure changes. 651 Authors' Addresses 653 Joao Damas 654 Internet Systems Consortium 655 950 Charter Street 656 Redwood City, California 94063 657 US 659 Phone: +1 650.423.1312 660 Email: joao@isc.org 661 Michael Graff 662 Internet Systems Consortium 663 950 Charter Street 664 Redwood City, California 94063 665 US 667 Phone: +1 650.423.1304 668 Email: mgraff@isc.org 670 Paul Vixie 671 Internet Systems Consortium 672 950 Charter Street 673 Redwood City, California 94063 674 US 676 Phone: +1 650.423.1301 677 Email: vixie@isc.org