idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2671]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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: The requestor 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. This knowledge may be auto-detected by the implementation or provided by a human administrator. == 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 (December 2011) is 4509 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) ** Downref: Normative reference to an Informational RFC: RFC 3363 -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group J.L.S.D. Damas 3 Internet-Draft M.G. Graff 4 Obsoletes: 2671, 2673 (if approved) P.V. Vixie 5 Intended status: Standards Track Internet Systems Consortium 6 Expires: June 01, 2012 December 2011 8 Extension Mechanisms for DNS (EDNS0) 9 draft-ietf-dnsext-rfc2671bis-edns0-06 11 Abstract 13 The Domain Name System's wire protocol includes a number of fixed 14 fields whose range has been or soon will be exhausted and does not 15 allow requestors to advertise their capabilities to responders. This 16 document describes backward compatible mechanisms for allowing the 17 protocol to grow. 19 This document updates the EDNS0 specification [RFC2671] based on 20 feedback from deployment experience in several implementations. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 01, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 57 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 61 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 62 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 4 64 6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 5 65 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 5 66 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 6 67 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 7 70 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 7 72 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 8 73 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 8 74 6.2.6. MiddleBoxes . . . . . . . . . . . . . . . . . . . . . 9 75 7. OPT Option Code Allocation Procedure . . . . . . . . . . . . . 9 76 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Appendix A. Document Editing History . . . . . . . . . . . . . . . 12 83 Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . 12 84 Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 DNS [RFC1035] specifies a Message Format and within such messages 90 there are standard formats for encoding options, errors, and name 91 compression. The maximum allowable size of a DNS Message over UDP 92 not using the extensions described in this document is limited to 512 93 bytes. Many of DNS's protocol limits, such as the maximum message 94 size over UDP, are too small to efficiently support the additional 95 information that can be conveyed in the DNS (e.g. several IPv6 96 addresses or DNSSEC signatures). Finally, RFC 1035 does not define 97 any way for implementations to advertise their capabilities to any of 98 the others actors they interact with. 100 [RFC2671] added an extension mechanism to DNS. This mechanism is 101 widely supported and a number of new DNS uses and protocol extensions 102 depend on the presence of these extensions. This memo refines that 103 specification and obsoletes [RFC2671]. 105 Unextended agents will not know how to interpret the protocol 106 extensions defined in [RFC2671] and restated here. Extended agents 107 MUST be prepared for handling the interactions with unextended 108 clients in the face of new protocol elements, and fall back 109 gracefully to unextended DNS. 111 [RFC2671] specified extended label types. The only one proposed was 112 in [RFC2673] for a label type called "Bitstring Labels." For various 113 reasons introducing a new label type was found to be extremely 114 difficult, and [RFC2673] was moved to Experimental. This document 115 deprecates Extended Labels. 117 2. Terminology 119 "Requestor" is the side which sends a request. "Responder" is an 120 authoritative, recursive resolver, or other DNS component which 121 responds to questions. Other terminology is used as per its use in 122 the references (e.g. middleboxes as in [RFC5625]) 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. EDNS Support Requirement 130 EDNS provides a mechanism to improve the scalability of DNS as its 131 uses get more diverse on the Internet. It does this by enabling the 132 use of UDP transport for DNS messages with sizes beyond the limits 133 specified in RFC 1035 as well as providing extra data space for 134 additional flags and return codes (RCODEs). 136 With time, some applications of DNS have made EDNS a requirement for 137 their deployment. For instance, DNSSEC uses the additional flag 138 space introduced in EDNS to signal the request to include DNSSEC data 139 in a DNS response. 141 Given the increase in DNS response sizes when including larger data 142 items such as AAAA Records, DNSSEC information (e.g. RRSIG or 143 DNSKEY) or large TXT Records, the additional UDP payload capabilities 144 provided by EDNS can help improve the scalability of the DNS by 145 avoiding generalized use of TCP for DNS transport. 147 4. DNS Message changes 149 4.1. Message Header 151 The DNS Message Header's second full 16-bit word is divided into a 152 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , 153 section 4.1.1 [RFC1035]). Some of these were marked for future use, 154 and most these have since been allocated. Also, most of the RCODE 155 values are now in use. The OPT pseudo-RR specified below contains 156 extensions to the RCODE bit field as well as additional flag bits. 158 4.2. Label Types 160 The first two bits of a wire format domain label are used to denote 161 the type of the label. [RFC1035] allocates two of the four possible 162 types and reserves the other two. More label types were defined in 163 [RFC2671]. This document obsoletes the use of the 2-bit combination 164 defined by [RFC2671] to identify extended label types. 166 4.3. UDP Message Size 168 Traditional DNS Messages are limited to 512 octets in size when sent 169 over UDP [RFC1035]. Fitting the increasing amounts of data that can 170 be transported in DNS in this 512-byte limit is becoming more 171 difficult. For instance, inclusion of DNSSEC records frequently 172 requires a much larger response than a 512 byte message can hold. 174 EDNS0 is intended to provide support for transporting these larger 175 packet sizes while continuing to use UDP. It specifies a way to 176 advertise additional features such as larger response size 177 capability, which is intended to help avoid truncated UDP responses 178 which then cause retry over TCP. 180 5. Extended Label Types 182 The first octet in the on-the-wire representation of a DNS label 183 specifies the label type; the basic DNS specification [RFC1035] 184 dedicates the two most significant bits of that octet for this 185 purpose. 187 [RFC2671] defined DNS label type 0b01 for use as an indication for 188 Extended Label Types. A specific Extended Label Type is selected by 189 the 6 least significant bits of the first octet. Thus, Extended 190 Label Types are indicated by the values 64-127 (0b01xxxxxx) in the 191 first octet of the label. 193 Extended Label Types are difficult to use due to support in clients 194 and intermediate gateways as described in [RFC3364] which moves them 195 to experimental status and [RFC3363], which describes the pros and 196 cons. 198 Therefore, this document moves them from experimental to historical, 199 making them deprecated. 201 Implementations MUST NOT generate or pass Extended Labels in their 202 communications. Additionally, no further registrations of Extended 203 Label Types are permitted. 205 6. The OPT pseudo-RR 207 6.1. OPT Record Definition 208 6.1.1. Basic elements 210 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the 211 additional data section of a request. 213 The OPT RR has RR type 41. 215 If present in requests, compliant responders MUST include an OPT 216 record in their respective responses. 218 An OPT record does not carry any DNS data. It is used only to 219 contain control information pertaining to the question and answer 220 sequence of a specific transaction. OPT RRs MUST NOT be cached, 221 forwarded, or stored in or loaded from master files. 223 The OPT RR MAY be placed anywhere within the additional data section. 224 No more than one OPT RR MUST be included within any DNS message. If 225 a query message with more than one OPT RR is received, a FORMERR 226 (RCODE=1) MUST be returned. The placement flexibility for the OPT RR 227 does not override the need for the TSIG or SIG(0) RRs to be the last 228 in the additional section whenever they are present. 230 6.1.2. Wire Format 232 An OPT RR has a fixed part and a variable set of options expressed as 233 {attribute, value} pairs. The fixed part holds some DNS meta data 234 and also a small collection of basic extension elements which we 235 expect to be so popular that it would be a waste of wire space to 236 encode them as {attribute, value} pairs. 238 The fixed part of an OPT RR is structured as follows: 240 +------------+--------------+------------------------------+ 241 | Field Name | Field Type | Description | 242 +------------+--------------+------------------------------+ 243 | NAME | domain name | Must be 0 (root domain) | 244 | TYPE | u_int16_t | OPT (41) | 245 | CLASS | u_int16_t | requestor's UDP payload size | 246 | TTL | u_int32_t | extended RCODE and flags | 247 | RDLEN | u_int16_t | length of all RDATA | 248 | RDATA | octet stream | {attribute,value} pairs | 249 +------------+--------------+------------------------------+ 251 The variable part of an OPT RR may contain zero or more options in 252 the RDATA. Each option MUST be treated as binary. Each option is 253 encoded as: 255 +0 (MSB) +1 (LSB) 256 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 257 0: | OPTION-CODE | 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 259 2: | OPTION-LENGTH | 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 4: | | 262 / OPTION-DATA / 263 / / 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 266 OPTION-CODE 267 Assigned by Expert Review. 269 OPTION-LENGTH 270 Size (in octets) of OPTION-DATA. 272 OPTION-DATA 273 Varies per OPTION-CODE. MUST be treated as binary. 275 The order of appearance of option tuples is not defined. If one 276 option modifies the behavior of another or multiple options are 277 related to one another in some way, they have the same effect 278 regardless of ordering in the RDATA wire encoding. 280 Any OPTION-CODE values not understood by a responder or requestor 281 MUST be ignored. Specifications of such options might wish to 282 include some kind of signaled acknowledgement. For example, an 283 option specification might say that if a responder sees option XYZ, 284 it MUST include option XYZ in its response. 286 6.1.3. OPT Record TTL Field Use 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 (together with the 300 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 301 indicates that an unextended RCODE is in use (values 0 through 302 15). 304 VERSION 305 Indicates the implementation level of the settter. Full 306 conformance with this specification is indicated by version 307 ``0.'' Requestors are encouraged to set this to the lowest 308 implemented level capable of expressing a transaction, to 309 minimize the responder and network load of discovering the 310 greatest common implementation level between requestor and 311 responder. A requestor's version numbering strategy MAY 312 ideally be a run time configuration option. 313 If a responder does not implement the VERSION level of the 314 request, then it MUST respond with RCODE=BADVERS. All 315 responses MUST be limited in format to the VERSION level of the 316 request, 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 6.1.4. Flags 324 DO 325 DNSSEC OK bit as defined by [RFC3225]. 327 Z 328 Set to zero by senders and ignored by receivers, unless 329 modified in a subsequent specification. 331 6.2. Behaviour 333 6.2.1. Cache behaviour 335 The OPT record MUST NOT be cached. 337 6.2.2. Fallback 339 If a requestor detects that the remote end does not support EDNS0, it 340 MAY issue queries without an OPT record. It MAY cache this knowledge 341 for a brief time in order to avoid fallback delays in the future. 342 However, if DNSSEC or any future option using EDNS is required, no 343 fallback should be performed as they are only signaled through EDNS0. 344 If an implementation detects that some servers for the zone support 345 EDNS(0) while others would force the use of TCP to fetch all data, 346 preference SHOULD be given to those support EDNS(0). 348 6.2.3. Requestor's Payload Size 350 The requestor's UDP payload size (encoded in the RR CLASS field) is 351 the number of octets of the largest UDP payload that can be 352 reassembled and delivered in the requestor's network stack. Note 353 that path MTU, with or without fragmentation, could be smaller than 354 this. 356 Values lower than 512 MUST be treated as equal to 512. 358 The requestor SHOULD place a value in this field that it can actually 359 receive. For example, if a requestor sits behind a firewall which 360 will block fragmented IP packets, a requestor SHOULD not choose a 361 value which will cause fragmentation. Doing so will prevent large 362 responses from being received, and can cause fallback to occur. This 363 knowledge may be auto-detected by the implementation or provided by a 364 human administrator. 366 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 367 buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over 368 Ethernet would be reasonable. 370 Bigger values SHOULD be considered here fragmentation is not a 371 concern. 373 Choosing a very large value will guarantee fragmentation at the IP 374 layer, and may prevent answers from being received due to a single 375 fragment loss or misconfigured firewalls. 377 The requestor's maximum payload size can change over time. It MUST 378 not be cached for use beyond the transaction in which it is 379 advertised. 381 6.2.4. Responder's Payload Size 383 The responder's maximum payload size can change over time, but can be 384 reasonably expected to remain constant between two closely spaced 385 sequential transactions; for example, an arbitrary QUERY used as a 386 probe to discover a responder's maximum UDP payload size, followed 387 immediately by an UPDATE which takes advantage of this size. This is 388 considered preferable to the outright use of TCP for oversized 389 requests, if there is any reason to suspect that the responder 390 implements EDNS, and if a request will not fit in the default 512 391 payload size limit. 393 6.2.5. Payload Size Selection 395 Due to transaction overhead, it is not recommended to advertise an 396 architectural limit as a maximum UDP payload size. Even on system 397 stacks capable of reassembling 64KB datagrams, memory usage at low 398 levels in the system will be a concern. A good compromise may be the 399 use of about 4KB of state memory per ongoing transaction, or a EDNS 400 maximum payload size of 4096 octets. 402 A requestor MAY choose to implement a fallback to smaller advertised 403 sizes to work around firewall or other network limitations. A 404 requestor SHOULD choose to use a fallback mechanism which begins with 405 a large size, such as 4096. If that fails, a fallback around the 406 1280-1410 byte range SHOULD be tried, as it has a reasonable chance 407 to fit within a single Ethernet frame. Failing that, a requestor MAY 408 choose a 512 byte packet, which with large answers may cause a TCP 409 retry. 411 Values of less than 512 bytes SHOULD be treated as equal to 512 412 bytes. 414 6.2.6. MiddleBoxes 416 In a network that carries DNS traffic there could be active equipment 417 other than that participating directly in the DNS resolution process 418 (stub and caching resolvers, authoritative servers) that affect the 419 transmission of DNS messages (e.g. firewalls, load balancers, 420 proxies, etc) referred to here as MiddleBoxes. 422 MiddleBoxes MUST NOT limit DNS messages over UDP to 512 bytes. 424 MiddleBoxes which simply forward requests to a recursive resolver 425 MUST NOT modify and MUST NOT delete the OPT record contents in either 426 direction. 428 MiddleBoxes which have additional functionality, such as answering 429 queries or acting as intelligent forwarders, SHOULD understand the 430 OPT record. These boxes MUST consider the incoming request and any 431 outgoing requests as separate transactions if the characteristics of 432 the messages are different. 434 A more in depth discussion of this type of equipment and other 435 considerations regarding their interaction with DNS traffic is found 436 in [RFC5625] 438 7. OPT Option Code Allocation Procedure 440 Allocations are assigned by expert review. 442 Assignment of Option Codes should be liberal, but duplicate 443 functionality is to be avoided. 445 8. Transport Considerations 447 The presence of an OPT pseudo-RR in a request should be taken as an 448 indication that the requestor fully implements the given version of 449 EDNS, and can correctly understand any response that conforms to that 450 feature's specification. 452 Lack of presence of an OPT record in a request MUST be taken as an 453 indication that the requestor does not implement any part of this 454 specification and that the responder MUST NOT include an OPT record 455 in its response. 457 Responders which choose not to implement the protocol extensions 458 defined in this document MUST respond with a return code (RCODE) of 459 FORMERR to messages containing an OPT RR in the additional section 460 and MUST NOT include an OPT record in the response. 462 If there is a problem with processing the OPT record itself, such as 463 an option value that is badly formatted or includes out of range 464 values, a FORMERR MUST be returned. If this occurs the response MUST 465 include an OPT record. This is intended to allow the requestor to 466 distinguish between servers which do not implement EDNS and format 467 errors within EDNS. 469 The minimal response MUST be the DNS header, question section, and an 470 OPT record. This MUST also occur when an truncated response (using 471 the DNS header's TC bit) is returned. 473 9. Security Considerations 475 Requestor-side specification of the maximum buffer size may open a 476 DNS denial of service attack if responders can be made to send 477 messages which are too large for intermediate gateways to forward, 478 thus leading to potential ICMP storms between gateways and 479 responders. 481 Announcing very large UDP buffer sizes may result in dropping by 482 middleboxes (see Section 6.2.6). This could cause retransmissions 483 with no hope of success. Some devices have been found to reject 484 fragmented UDP packets. 486 Announcing too small UDP buffer sizes may result in fallback to TCP 487 with a corresponding load impact on DNS servers. This is especially 488 important with DNSSEC, where answers are much larger. 490 10. IANA Considerations 492 The IANA has assigned RR type code 41 for OPT. 494 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 495 NAME SYSTEM PARAMETERS:" 497 o DNS EDNS0 Options 499 o EDNS Version Number 501 o EDNS Header Flags 503 Additionally, several entries were generated in existing registries: 505 EDNS Extended Label Type in the DNS Label Types Registry 507 Bad OPT Version in the DNS RCODES registry 509 IANA is advised to udpates references to [RFC2671] in these entries 510 and sub-registries to this document. 512 [RFC2671] created the "EDNS Extended Label Type Registry". We 513 request that this registry be closed. 515 This document assigns option code 65535 in the "EDNS Option Codes" 516 registry to "Reserved for future expansion." 518 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This 519 allows more than the 16 distinct RCODE values allowed in [RFC1035]. 520 IETF Standards Action is required to add a new RCODE. Adding new 521 RCODEs should be avoided due to the difficulty in upgrading the 522 installed base. 524 This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS 525 RCODES registry. 527 [RFC2671] called for the recording of assignment of extended label 528 types 0bxx111111 as "Reserved for future extended label types". This 529 request was implicitly a request to open a new registry for Extended 530 Label Types but due to possible ambiguous text registrarions were 531 instead made within the general "DNS Label Types" registry which also 532 registers entries originally defined by [RFC1035]. 534 This document requests IANA to close registration of further Extended 535 Label Types in the "DNS Label Types" Registry. 537 IETF Standards Action is required for assignments of new EDNS0 flags. 538 Flags SHOULD be used only when necessary for DNS resolution to 539 function. For many uses, a EDNS Option Code may be preferred. 541 IETF Standards Action is required to create new entries in the EDNS 542 Version Number registry. Expert Review is required for allocation of 543 an EDNS Option Code. 545 11. References 547 11.1. Normative References 549 [RFC1035] Mockapetris, P., "Domain names - implementation and 550 specification", STD 13, RFC 1035, November 1987. 552 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 553 2671, August 1999. 555 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 556 3225, December 2001. 558 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. 559 Hain, "Representing Internet Protocol version 6 (IPv6) 560 Addresses in the Domain Name System (DNS)", RFC 3363, 561 August 2002. 563 11.2. Informative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 569 RFC 2673, August 1999. 571 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 572 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 573 August 2002. 575 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 576 152, RFC 5625, August 2009. 578 Appendix A. Document Editing History 580 Following is a list of high-level changes made to the original 581 RFC2671. 583 Appendix A.1. Changes since RFC2671 585 o Support for the OPT record is now mandatory. 587 o Extended label types obsoleted and the registry is closed. 589 o The bitstring label type, which was already moved from draft to 590 experimental, is requested to be moved to historical. 592 o Changes in how EDNS buffer sizes are selected, with 593 recommendations on how to select them. 595 o Front material (IPR notice and such) was updated to current 596 requirements. 598 Appendix A.2. Changes since -02 600 o Specified the method for allocation of constants. 602 o Cleaned up a lot of wording, along with quite a bit of document 603 structure changes. 605 Authors' Addresses 606 Joao Damas 607 Internet Systems Consortium 608 950 Charter Street 609 Redwood City, California 94063 610 US 612 Phone: +1 650.423.1312 613 Email: joao@isc.org 615 Michael Graff 616 Internet Systems Consortium 617 950 Charter Street 618 Redwood City, California 94063 619 US 621 Phone: +1 650.423.1304 622 Email: mgraff@isc.org 624 Paul Vixie 625 Internet Systems Consortium 626 950 Charter Street 627 Redwood City, California 94063 628 US 630 Phone: +1 650.423.1301 631 Email: vixie@isc.org