summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc2671.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2671.txt')
-rw-r--r--doc/rfc/rfc2671.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt
new file mode 100644
index 0000000..ec05f80
--- /dev/null
+++ b/doc/rfc/rfc2671.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group P. Vixie
+Request for Comments: 2671 ISC
+Category: Standards Track August 1999
+
+
+ Extension Mechanisms for DNS (EDNS0)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+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.
+
+1 - Rationale and Scope
+
+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. Existing clients 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. We must however take
+ account of client behaviour in the face of extra fields, and design
+ a fallback scheme for interoperability with these clients.
+
+
+
+
+
+
+
+
+
+Vixie Standards Track [Page 1]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+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.
+
+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 are needed.
+
+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.
+
+3 - Extended Label Types
+
+3.1. The "0 1" label type will now indicate an extended label type,
+ whose value is encoded in the lower six bits of the first octet of
+ a label. All subsequently developed label types should be encoded
+ using an extended label type.
+
+3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
+ expansion of the extended label type code space.
+
+4 - OPT pseudo-RR
+
+4.1. One OPT pseudo-RR can be added to the additional data section of
+ either a request or a response. 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 shall never be cached, forwarded,
+ or stored in or loaded from master files. The quantity of OPT
+ pseudo-RRs per message shall 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.
+
+
+
+
+
+Vixie Standards Track [Page 2]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+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
+ 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.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.
+
+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.
+
+
+
+
+
+Vixie Standards Track [Page 3]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+4.5.3. The requestor's maximum payload size can change over time, and
+ should therefore 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: | 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 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 will be limited in format to the
+
+
+
+Vixie Standards Track [Page 4]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+ VERSION level of the request, but the VERSION of each
+ response will 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.
+
+ Z Set to zero by senders and ignored by receivers,
+ unless modified in a subsequent specification.
+
+5 - Transport Considerations
+
+5.1. 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.
+
+5.2. Lack of use of these features in a request must be taken as an
+ indication that the requestor does not implement any part of this
+ specification and that the responder may make no use of 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. 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. 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.
+
+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
+
+ The IANA has assigned RR type code 41 for OPT.
+
+ It is the recommendation of this document and its working group
+ that IANA create a registry for EDNS Extended Label Types, for EDNS
+ Option Codes, and for EDNS Version Numbers.
+
+ This document assigns label type 0b01xxxxxx as "EDNS Extended Label
+ Type." We request that IANA record this assignment.
+
+
+
+Vixie Standards Track [Page 5]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+ 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 [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
+ published RFC (including Informational, Experimental, or BCP)
+ should be 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, and Thomas
+ Narten were each instrumental in creating and refining this
+ specification.
+
+9 - References
+
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, November 1987.
+
+10 - Author's Address
+
+ Paul Vixie
+ Internet Software Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+
+ Phone: +1 650 779 7001
+ EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie Standards Track [Page 6]
+
+RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
+
+
+11 - Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie Standards Track [Page 7]
+
generated by cgit (git 2.34.1) at 2024-04-26 13:55:06 +0000