From: Mark Andrews Date: Thu, 19 Nov 2009 05:11:47 +0000 (+0000) Subject: new draft X-Git-Tag: v9.4.3-P1~2^2~208 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9dad3e27102700ea9e0be1dfbeb24a8da8f15638;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt deleted file mode 100644 index 8f84fd4db24..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - -DNSEXT Working Group Paul Vixie, ISC -INTERNET-DRAFT - March 17, 2008 - -Intended Status: Standards Track -Obsoletes: 2671 (if approved) - - - Revised extension mechanisms for DNS (EDNS0) - - -Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - - -Expires September 2008 [Page 1] - -INTERNET-DRAFT EDNS0 March 2008 - - -1 - Introduction - -1.1. DNS (see [RFC1035]) specifies a Message Format and within such -messages there are standard formats for encoding options, errors, and -name compression. The maximum allowable size of a DNS Message is fixed. -Many of DNS's protocol limits are too small for uses which are or which -are desired to become common. There is no way for implementations to -advertise their capabilities. - -1.2. Unextended agents will not know how to interpret the protocol -extensions detailed here. In practice, these clients will be upgraded -when they have need of a new feature, and only new features will make -use of the extensions. Extended agents must be prepared for behaviour -of unextended clients in the face of new protocol elements, and fall -back gracefully to unextended DNS. RFC 2671 originally has proposed -extensions to the basic DNS protocol to overcome these deficiencies. -This memo refines that specification and obsoletes RFC 2671. - -1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 [RFC2119]. - -2 - Affected Protocol Elements - -2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit -word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of -1-bit flags. The original reserved Z bits have been allocated to -various purposes, and most of the RCODE values are now in use. More -flags and more possible RCODEs are needed. The OPT pseudo-RR specified -in Section 4 contains subfields that carry a bit field extension of the -RCODE field and additional flag bits, respectively; for details see -Section 4.6 below. - -2.2. The first two bits of a wire format domain label are used to denote -the type of the label. [RFC1035 4.1.4] allocates two of the four -possible types and reserves the other two. Proposals for use of the -remaining types far outnumber those available. More label types were -needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 -Section 3]. Section 3 of this document reserves DNS labels with a first -octet in the range of 64-127 decimal (label type 01) for future -standardization of Extended DNS Labels. - - - - - - - -Expires September 2008 [Page 2] - -INTERNET-DRAFT EDNS0 March 2008 - - -2.3. DNS Messages are limited to 512 octets in size when sent over UDP. -While the minimum maximum reassembly buffer size still allows a limit of -512 octets of UDP payload, most of the hosts now connected to the -Internet are able to reassemble larger datagrams. Some mechanism must -be created to allow requestors to advertise larger buffer sizes to -responders. To this end, the OPT pseudo-RR specified in Section 4 -contains a maximum payload size field; for details see Section 4.5 -below. - -3 - Extended Label Types - -The first octet in the on-the-wire representation of a DNS label -specifies the label type; the basic DNS specification [RFC1035] -dedicates the two most significant bits of that octet for this purpose. - -This document reserves DNS label type 0b01 for use as an indication for -Extended Label Types. A specific extended label type is selected by the -6 least significant bits of the first octet. Thus, Extended Label Types -are indicated by the values 64-127 (0b01xxxxxx) in the first octet of -the label. - -Allocations from this range are to be made for IETF documents fully -describing the syntax and semantics as well as the applicability of the -particular Extended Label Type. - -This document does not describe any specific Extended Label Type. - -4 - OPT pseudo-RR - -4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data -section of a request, and to responses to such requests. An OPT is -called a pseudo-RR because it pertains to a particular transport level -message and not to any actual DNS data. OPT RRs MUST NOT be cached, -forwarded, or stored in or loaded from master files. The quantity of -OPT pseudo-RRs per message MUST be either zero or one, but not greater. - -4.2. An OPT RR has a fixed part and a variable set of options expressed -as {attribute, value} pairs. The fixed part holds some DNS meta data -and also a small collection of new protocol elements which we expect to -be so popular that it would be a waste of wire space to encode them as -{attribute, value} pairs. - - - - - - - -Expires September 2008 [Page 3] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.3. The fixed part of an OPT RR is structured as follows: - -Field Name Field Type Description ------------------------------------------------------- -NAME domain name empty (root domain) -TYPE u_int16_t OPT (41) -CLASS u_int16_t sender's UDP payload size -TTL u_int32_t extended RCODE and flags -RDLEN u_int16_t describes RDATA -RDATA octet stream {attribute,value} pairs - - -4.4. The variable part of an OPT RR is encoded in its RDATA and is -structured as zero or more of the following: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - -OPTION-CODE (Assigned by IANA.) - -OPTION-LENGTH Size (in octets) of OPTION-DATA. - -OPTION-DATA Varies per OPTION-CODE. - -4.4.1. Order of appearance of option tuples is never relevant. Any -option whose meaning is affected by other options is so affected no -matter which one comes first in the OPT RDATA. - -4.4.2. Any OPTION-CODE values not understood by a responder or requestor -MUST be ignored. So, specifications of such options might wish to -include some kind of signalled acknowledgement. For example, an option -specification might say that if a responder sees option XYZ, it SHOULD -include option XYZ in its response. - - - - - - -Expires September 2008 [Page 4] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.5. The sender's UDP payload size (which OPT stores in the RR CLASS -field) is the number of octets of the largest UDP payload that can be -reassembled and delivered in the sender's network stack. Note that path -MTU, with or without fragmentation, may be smaller than this. Values -lower than 512 are undefined, and may be treated as format errors, or -may be treated as equal to 512, at the implementor's discretion. - -4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP -reassembly buffer. Choosing 1280 on an Ethernet connected requestor -would be reasonable. The consequence of choosing too large a value may -be an ICMP message from an intermediate gateway, or even a silent drop -of the response message. - -4.5.2. Both requestors and responders are advised to take account of the -path's discovered MTU (if already known) when considering message sizes. - -4.5.3. The requestor's maximum payload size can change over time, and -therefore MUST NOT be cached for use beyond the transaction in which it -is advertised. - -4.5.4. The responder's maximum payload size can change over time, but -can be reasonably expected to remain constant between two sequential -transactions; for example, a meaningless QUERY to discover a responder's -maximum UDP payload size, followed immediately by an UPDATE which takes -advantage of this size. (This is considered preferrable to the outright -use of TCP for oversized requests, if there is any reason to suspect -that the responder implements EDNS, and if a request will not fit in the -default 512 payload size limit.) - -4.5.5. Due to transaction overhead, it is unwise to advertise an -architectural limit as a maximum UDP payload size. Just because your -stack can reassemble 64KB datagrams, don't assume that you want to spend -more than about 4KB of state memory per ongoing transaction. - -4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) -are structured as follows: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - - - -Expires September 2008 [Page 5] - -INTERNET-DRAFT EDNS0 March 2008 - - -EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value zero (0) indicates that an - unextended RCODE is in use (values zero (0) through - fifteen (15)). - -VERSION Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by - version zero (0). Requestors are encouraged to set this - to the lowest implemented level capable of expressing a - transaction, to minimize the responder and network load - of discovering the greatest common implementation level - between requestor and responder. A requestor's version - numbering strategy should ideally be a run time - configuration option. - - If a responder does not implement the VERSION level of - the request, then it answers with RCODE=BADVERS. All - responses MUST be limited in format to the VERSION level - of the request, but the VERSION of each response MUST be - the highest implementation level of the responder. In - this way a requestor will learn the implementation level - of a responder as a side effect of every response, - including error responses, including RCODE=BADVERS. - -DO DNSSEC OK bit [RFC3225]. - -Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification [IANAFLAGS]. - -5 - Transport Considerations - -5.1. The presence of an OPT pseudo-RR in a request is an indication that -the requestor fully implements the given version of EDNS, and can -correctly understand any response that conforms to that feature's -specification. - -5.2. Lack of use of these features in a request is an indication that -the requestor does not implement any part of this specification and that -the responder SHOULD NOT use any protocol extension described here in -its response. - -5.3. Responders who do not understand these protocol extensions are -expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or -to appear to "time out" due to inappropriate action by a "middle box" -such as a NAT, or to ignore extensions and respond only to unextended - - - -Expires September 2008 [Page 6] - -INTERNET-DRAFT EDNS0 March 2008 - - -protocol elements. Therefore use of extensions SHOULD be "probed" such -that a responder who isn't known to support them be allowed a retry with -no extensions if it responds with such an RCODE, or does not respond. -If a responder's capability level is cached by a requestor, a new probe -SHOULD be sent periodically to test for changes to responder capability. - -5.4. If EDNS is used in a request, and the response arrives with TC set -and with no EDNS OPT RR, a requestor should assume that truncation -prevented the OPT RR from being appended by the responder, and further, -that EDNS is not used in the response. Correspondingly, an EDNS -responder who cannot fit all necessary elements (including an OPT RR) -into a response, should respond with a normal (unextended) DNS response, -possibly setting TC if the response will not fit in the unextended -response message's 512-octet size. - -6 - Security Considerations - -Requestor-side specification of the maximum buffer size may open a new -DNS denial of service attack if responders can be made to send messages -which are too large for intermediate gateways to forward, thus leading -to potential ICMP storms between gateways and responders. - -7 - IANA Considerations - -IANA has allocated RR type code 41 for OPT. - -This document controls the following IANA sub-registries in registry -"DOMAIN NAME SYSTEM PARAMETERS": - - "EDNS Extended Label Type" - "EDNS Option Codes" - "EDNS Version Numbers" - "Domain System Response Code" - -IANA is advised to re-parent these subregistries to this document. - -This document assigns label type 0b01xxxxxx as "EDNS Extended Label -Type." We request that IANA record this assignment. - -This document assigns option code 65535 to "Reserved for future -expansion." - -This document assigns EDNS Extended RCODE "16" to "BADVERS". - - - - - -Expires September 2008 [Page 7] - -INTERNET-DRAFT EDNS0 March 2008 - - -IESG approval is required to create new entries in the EDNS Extended -Label Type or EDNS Version Number registries, while any published RFC -(including Informational, Experimental, or BCP) is grounds for -allocation of an EDNS Option Code. - -8 - Acknowledgements - -Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, -Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, -Alfred Hoenes and Markku Savela were each instrumental in creating and -refining this specification. - -9 - References - -[RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification," RFC 1035, USC/Information Sciences - Institute, November 1987. - -[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, Harvard University, March - 1997. - -[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, - Internet Software Consortium, August 1999. - -[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC - 3225, Nominum Inc., December 2001. - -[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site - http://www.iana.org/assignments/dns-header-flags, as of - June 2005 or later. - -10 - Author's Address - -Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - EMail: vixie@isc.org - - - - - - - - -Expires September 2008 [Page 8] - -INTERNET-DRAFT EDNS0 March 2008 - - -Full Copyright Statement - -Copyright (C) IETF Trust (2007). - -This document is subject to the rights, licenses and restrictions -contained in BCP 78, and except as set forth therein, the authors retain -all their rights. - -This document and the information contained herein are provided on an -"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR -IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE -INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE -INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed to -pertain to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; nor does it represent that it has made any -independent effort to identify any such rights. Information on the -procedures with respect to rights in RFC documents can be found in BCP -78 and BCP 79. - -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, or the result of an attempt -made to obtain a general license or permission for the use of such -proprietary rights by implementers or users of this specification can be -obtained from the IETF on-line IPR repository at -http://www.ietf.org/ipr. - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -that may cover technology that may be required to implement this -standard. Please address the information to the IETF at -ietf-ipr@ietf.org. - -Acknowledgement - -Funding for the RFC Editor function is provided by the IETF -Administrative Support Activity (IASA). - - - - -Expires September 2008 [Page 9] - \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt new file mode 100644 index 00000000000..ba1b4147f4d --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt @@ -0,0 +1,616 @@ + + + +DNSEXT Working Group M. Graff +Internet-Draft P. Vixie +Obsoletes: 2671 (if approved) Internet Systems Consortium +Intended status: Standards Track July 28, 2009 +Expires: January 29, 2010 + + + Extension Mechanisms for DNS (EDNS0) + draft-ietf-dnsext-rfc2671bis-edns0-02 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 29, 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + + + +Graff & Vixie Expires January 29, 2010 [Page 1] + +Internet-Draft EDNS0 Extensions July 2009 + + + allow requestors to advertise their capabilities to responders. This + document describes backward compatible mechanisms for allowing the + protocol to grow. + + This document updates the EDNS0 specification based on 10 years of + operational experience. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 + 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 + 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 + 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 + 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 + 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 + 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 + 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 + 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 + 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 + 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 + 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 + 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 + 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 2] + +Internet-Draft EDNS0 Extensions July 2009 + + +1. Introduction + + DNS [RFC1035] specifies a Message Format and within such messages + there are standard formats for encoding options, errors, and name + compression. The maximum allowable size of a DNS Message is fixed. + Many of DNS's protocol limits are too small for uses which are or + which are desired to become common. There is no way for + implementations to advertise their capabilities. + + Unextended agents will not know how to interpret the protocol + extensions detailed here. In practice, these clients will be + upgraded when they have need of a new feature, and only new features + will make use of the extensions. Extended agents must be prepared + for behaviour of unextended clients in the face of new protocol + elements, and fall back gracefully to unextended DNS. [RFC2671] + originally proposed extensions to the basic DNS protocol to overcome + these deficiencies. This memo refines that specification and + obsoletes [RFC2671]. + + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + +3. EDNS Support Requirement + + EDNS support is manditory in a modern world. DNSSEC requires EDNS + support, and many other featres are made possible only by EDNS + support to request or advertise them. + + +4. Affected Protocol Elements + +4.1. Message Header + + The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full + 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a + number of 1-bit flags. The original reserved Z bits have been + allocated to various purposes, and most of the RCODE values are now + in use. More flags and more possible RCODEs are needed. The OPT + pseudo-RR specified below contains subfields that carry a bit field + extension of the RCODE field and additional flag bits, respectively. + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 3] + +Internet-Draft EDNS0 Extensions July 2009 + + +4.2. Label Types + + The first two bits of a wire format domain label are used to denote + the type of the label. ,section 4.1.4 [RFC1035] allocates two of the + four possible types and reserves the other two. More label types + were proposed in [RFC2671] section 3. + +4.3. UDP Message Size + + DNS Messages are limited to 512 octets in size when sent over UDP. + While the minimum maximum reassembly buffer size still allows a limit + of 512 octets of UDP payload, most of the hosts now connected to the + Internet are able to reassemble larger datagrams. Some mechanism + must be created to allow requestors to advertise larger buffer sizes + to responders. To this end, the OPT pseudo-RR specified below + contains a maximum payload size field. + + +5. Extended Label Types + + The first octet in the on-the-wire representation of a DNS label + specifies the label type; the basic DNS specification [RFC1035] + dedicates the two most significant bits of that octet for this + purpose. + + This document reserves DNS label type 0b01 for use as an indication + for Extended Label Types. A specific extended label type is selected + by the 6 least significant bits of the first octet. Thus, Extended + Label Types are indicated by the values 64-127 (0b01xxxxxx) in the + first octet of the label. + + This document does not describe any specific Extended Label Type. + + In practice, Extended Label Types are difficult to use due to support + in clients and intermediate gateways. Therefore, the registry of + Extended Label Types is requested to be closed. They cause + interoperability problems and at present no defined label types are + in use. + + +6. OPT pseudo-RR + +6.1. OPT Record Behavior + + One OPT pseudo-RR (RR type 41) MAY be added to the additional data + section of a request. If present in requests, compliant responders + which implement EDNS MUST include an OPT record in non-truncated + responses, and SHOULD attempt to include them in all responses. An + + + +Graff & Vixie Expires January 29, 2010 [Page 4] + +Internet-Draft EDNS0 Extensions July 2009 + + + OPT is called a pseudo-RR because it pertains to a particular + transport level message and not to any actual DNS data. OPT RRs MUST + NOT be cached, forwarded, or stored in or loaded from master files. + The quantity of OPT pseudo-RRs per message MUST be either zero or + one, but not greater. + +6.2. OPT Record Format + + An OPT RR has a fixed part and a variable set of options expressed as + {attribute, value} pairs. The fixed part holds some DNS meta data + and also a small collection of basic extension elements which we + expect to be so popular that it would be a waste of wire space to + encode them as {attribute, value} pairs. + + The fixed part of an OPT RR is structured as follows: + + +------------+--------------+------------------------------+ + | Field Name | Field Type | Description | + +------------+--------------+------------------------------+ + | NAME | domain name | empty (root domain) | + | TYPE | u_int16_t | OPT | + | CLASS | u_int16_t | requestor's UDP payload size | + | TTL | u_int32_t | extended RCODE and flags | + | RDLEN | u_int16_t | describes RDATA | + | RDATA | octet stream | {attribute,value} pairs | + +------------+--------------+------------------------------+ + + OPT RR Format + + The variable part of an OPT RR is encoded in its RDATA and is + structured as zero or more of the following: + + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 5] + +Internet-Draft EDNS0 Extensions July 2009 + + + OPTION-CODE + Assigned by Expert Review. + + OPTION-LENGTH + Size (in octets) of OPTION-DATA. + + OPTION-DATA + Varies per OPTION-CODE. + + Order of appearance of option tuples is never relevant. Any option + whose meaning is affected by other options is so affected no matter + which one comes first in the OPT RDATA. + + Any OPTION-CODE values not understood by a responder or requestor + MUST be ignored. Specifications of such options might wish to + include some kind of signalled acknowledgement. For example, an + option specification might say that if a responder sees option XYZ, + it SHOULD include option XYZ in its response. + +6.3. Requestor's Payload Size + + The requestor's UDP payload size (which OPT stores in the RR CLASS + field) is the number of octets of the largest UDP payload that can be + reassembled and delivered in the requestor's network stack. Note + that path MTU, with or without fragmentation, may be smaller than + this. Values lower than 512 MUST be treated as equal to 512. + + Note that a 512-octet UDP payload requires a 576-octet IP reassembly + buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. + The consequence of choosing too large a value may be an ICMP message + from an intermediate gateway, or even a silent drop of the response + message. + + The requestor's maximum payload size can change over time, and MUST + therefore not be cached for use beyond the transaction in which it is + advertised. + +6.4. Responder's Payload Size + + The responder's maximum payload size can change over time, but can be + reasonably expected to remain constant between two sequential + transactions; for example, a meaningless QUERY to discover a + responder's maximum UDP payload size, followed immediately by an + UPDATE which takes advantage of this size. (This is considered + preferrable to the outright use of TCP for oversized requests, if + there is any reason to suspect that the responder implements EDNS, + and if a request will not fit in the default 512 payload size limit.) + + + + +Graff & Vixie Expires January 29, 2010 [Page 6] + +Internet-Draft EDNS0 Extensions July 2009 + + +6.5. Payload Size Selection + + Due to transaction overhead, it is unwise to advertise an + architectural limit as a maximum UDP payload size. Just because your + stack can reassemble 64KB datagrams, don't assume that you want to + spend more than about 4KB of state memory per ongoing transaction. + + A requestor MAY choose to implement a fallback to smaller advertised + sizes to work around firewall or other network limitations. A + requestor SHOULD choose to use a fallback mechanism which begins with + a large size, such as 4096. If that fails, a fallback around the + 1220 byte range SHOULD be tried, as it has a reasonable chance to fit + within a single Ethernet frame. Failing that, a requestor MAY choose + a 512 byte packet, which with large answers may cause a TCP retry. + +6.6. Middleware Boxes + + Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. + + Middleware boxes which simply forward requests to a recursive + resolver MUST NOT modify the OPT record contents in either direction. + +6.7. Extended RCODE + + The extended RCODE and flags (which OPT stores in the RR TTL field) + are structured as follows: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + EXTENDED-RCODE + Forms upper 8 bits of extended 12-bit RCODE. Note that + EXTENDED-RCODE value "0" indicates that an unextended RCODE is + in use (values "0" through "15"). + + VERSION + Indicates the implementation level of whoever sets it. Full + conformance with this specification is indicated by version + ``0.'' Requestors are encouraged to set this to the lowest + implemented level capable of expressing a transaction, to + minimize the responder and network load of discovering the + greatest common implementation level between requestor and + responder. A requestor's version numbering strategy MAY + ideally be a run time configuration option. + + + +Graff & Vixie Expires January 29, 2010 [Page 7] + +Internet-Draft EDNS0 Extensions July 2009 + + + If a responder does not implement the VERSION level of the + request, then it answers with RCODE=BADVERS. All responses + MUST be limited in format to the VERSION level of the request, + but the VERSION of each response SHOULD be the highest + implementation level of the responder. In this way a requestor + will learn the implementation level of a responder as a side + effect of every response, including error responses and + including RCODE=BADVERS. + + DO + DNSSEC OK bit as defined by [RFC3225]. + + Z + Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification. + +6.8. OPT Options Type Allocation Procedure + + Allocations assigned by expert review. TBD + + +7. Transport Considerations + + The presence of an OPT pseudo-RR in a request should be taken as an + indication that the requestor fully implements the given version of + EDNS, and can correctly understand any response that conforms to that + feature's specification. + + Lack of presence of an OPT record in a request MUST be taken as an + indication that the requestor does not implement any part of this + specification and that the responder MUST NOT use any protocol + extension described here in its response. + + Responders who do not implement these protocol extensions MUST + respond with FORMERR messages without any OPT record. + + If there is a problem with processing the OPT record itself, such as + an option value that is badly formatted or includes out of range + values, a FORMERR MAY be retured. If this occurs the response MUST + include an OPT record. This MAY be used to distinguish between + servers whcih do not implement EDNS and format errors within EDNS. + + If EDNS is used in a request, and the response arrives with TC set + and with no EDNS OPT RR, a requestor SHOULD assume that truncation + prevented the OPT RR from being appended by the responder, and + further, that EDNS is not used in the response. Correspondingly, an + EDNS responder who cannot fit all necessary elements (including an + OPT RR) into a response, SHOULD respond with a normal (unextended) + + + +Graff & Vixie Expires January 29, 2010 [Page 8] + +Internet-Draft EDNS0 Extensions July 2009 + + + DNS response, possibly setting TC if the response will not fit in the + unextended response message's 512-octet size. + + +8. Security Considerations + + Requestor-side specification of the maximum buffer size may open a + new DNS denial of service attack if responders can be made to send + messages which are too large for intermediate gateways to forward, + thus leading to potential ICMP storms between gateways and + responders. + + Announcing very large UDP buffer sizes may result in dropping by + firewalls. This could cause retransmissions with no hope of success. + Some devices reject fragmented UDP packets. + + Announcing too small UDP buffer sizes may result in fallback to TCP. + This is especially important with DNSSEC, where answers are much + larger. + + +9. IANA Considerations + + The IANA has assigned RR type code 41 for OPT. + + [RFC2671] specified a number of IANA sub-registries within "DOMAIN + NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option + Codes", "EDNS Version Numbers", and "Domain System Response Code." + IANA is advised to re-parent these subregistries to this document. + + RFC 2671 created an extended label type registry. We request that + this registry be closed. + + This document assigns extended label type 0bxx111111 as "Reserved for + future extended label types." We request that IANA record this + assignment. + + This document assigns option code 65535 to "Reserved for future + expansion." + + This document expands the RCODE space from 4 bits to 12 bits. This + will allow IANA to assign more than the 16 distinct RCODE values + allowed in RFC 1035 [RFC1035]. + + This document assigns EDNS Extended RCODE "16" to "BADVERS". + + IESG approval should be required to create new entries in the EDNS + Extended Label Type or EDNS Version Number registries, while any + + + +Graff & Vixie Expires January 29, 2010 [Page 9] + +Internet-Draft EDNS0 Extensions July 2009 + + + published RFC (including Informational, Experimental, or BCP) should + be grounds for allocation of an EDNS Option Code. + + +10. Acknowledgements + + Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, + Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas + Narten were each instrumental in creating and refining this + specification. + + +11. References + +11.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", + RFC 3225, December 2001. + +11.2. Informative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +Authors' Addresses + + Michael Graff + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1304 + Email: mgraff@isc.org + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 10] + +Internet-Draft EDNS0 Extensions July 2009 + + + Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1301 + Email: vixie@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 11] +