draft-ietf-dnsext-rfc2671bis-edns0-06.txt   draft-ietf-dnsext-rfc2671bis-edns0-07.txt 
DNSEXT Working Group J.L.S.D. Damas DNSEXT Working Group J. Damas
Internet-Draft M.G. Graff Internet-Draft M. Graff
Obsoletes: 2671, 2673 (if approved) P.V. Vixie Obsoletes: 2671, 2673 P. Vixie
Intended status: Standards Track Internet Systems Consortium (if approved) Internet Systems Consortium
Expires: June 01, 2012 December 2011 Intended status: Standards Track January 18, 2012
Expires: July 21, 2012
Extension Mechanisms for DNS (EDNS0) Extension Mechanisms for DNS (EDNS0)
draft-ietf-dnsext-rfc2671bis-edns0-06 draft-ietf-dnsext-rfc2671bis-edns0-07
Abstract Abstract
The Domain Name System's wire protocol includes a number of fixed 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 fields whose range has been or soon will be exhausted and does not
allow requestors to advertise their capabilities to responders. This allow requestors to advertise their capabilities to responders. This
document describes backward compatible mechanisms for allowing the document describes backward compatible mechanisms for allowing the
protocol to grow. protocol to grow.
This document updates the EDNS0 specification [RFC2671] based on This document updates the EDNS0 specification [RFC2671] based on
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 01, 2012. This Internet-Draft will expire on July 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3
4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 3 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 5
6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 4 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 4 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5
6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 5 6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 5
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 5 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 6
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 6 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 7
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 7 6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 8
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 7 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 7 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 8
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 8 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 9
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 8 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 9
6.2.6. MiddleBoxes . . . . . . . . . . . . . . . . . . . . . 9 6.2.6. Support in MiddleBoxes . . . . . . . . . . . . . . . . 10
7. OPT Option Code Allocation Procedure . . . . . . . . . . . . . 9 7. OPT Option Code Allocation Procedure . . . . . . . . . . . . . 10
8. Transport Considerations . . . . . . . . . . . . . . . . . . . 9 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document Editing History . . . . . . . . . . . . . . . 12 Appendix A. Document Editing History . . . . . . . . . . . . . . 13
Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . 12 A.1. Changes since RFC2671 . . . . . . . . . . . . . . . . . . 13
Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . 12 A.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
DNS [RFC1035] specifies a Message Format and within such messages DNS [RFC1035] specifies a Message Format and within such messages
there are standard formats for encoding options, errors, and name there are standard formats for encoding options, errors, and name
compression. The maximum allowable size of a DNS Message over UDP compression. The maximum allowable size of a DNS Message over UDP
not using the extensions described in this document is limited to 512 not using the extensions described in this document is limited to 512
bytes. Many of DNS's protocol limits, such as the maximum message bytes. Many of DNS's protocol limits, such as the maximum message
size over UDP, are too small to efficiently support the additional size over UDP, are too small to efficiently support the additional
information that can be conveyed in the DNS (e.g. several IPv6 information that can be conveyed in the DNS (e.g. several IPv6
addresses or DNSSEC signatures). Finally, RFC 1035 does not define addresses or DNSSEC signatures). Finally, RFC 1035 does not define
any way for implementations to advertise their capabilities to any of any way for implementations to advertise their capabilities to any of
the others actors they interact with. the others actors they interact with.
[RFC2671] added an extension mechanism to DNS. This mechanism is [RFC2671] added an extension mechanism to DNS. This mechanism is
widely supported and a number of new DNS uses and protocol extensions widely supported and a number of new DNS uses and protocol extensions
depend on the presence of these extensions. This memo refines that depend on the presence of these extensions. This memo refines that
specification and obsoletes [RFC2671]. specification and obsoletes [RFC2671].
Unextended agents will not know how to interpret the protocol Unextended agents will not know how to interpret the protocol
extensions defined in [RFC2671] and restated here. Extended agents extensions defined in [RFC2671] and restated here. Extended agents
MUST be prepared for handling the interactions with unextended MUST be prepared for handling the interactions with unextended
clients in the face of new protocol elements, and fall back clients in the face of new protocol elements, and fall back
gracefully to unextended DNS. gracefully to unextended DNS.
skipping to change at page 3, line 22 skipping to change at page 3, line 40
in [RFC2673] for a label type called "Bitstring Labels." For various in [RFC2673] for a label type called "Bitstring Labels." For various
reasons introducing a new label type was found to be extremely reasons introducing a new label type was found to be extremely
difficult, and [RFC2673] was moved to Experimental. This document difficult, and [RFC2673] was moved to Experimental. This document
deprecates Extended Labels. deprecates Extended Labels.
2. Terminology 2. Terminology
"Requestor" is the side which sends a request. "Responder" is an "Requestor" is the side which sends a request. "Responder" is an
authoritative, recursive resolver, or other DNS component which authoritative, recursive resolver, or other DNS component which
responds to questions. Other terminology is used as per its use in responds to questions. Other terminology is used as per its use in
the references (e.g. middleboxes as in [RFC5625]) the references (e.g. middleboxes as in [RFC5625])
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. EDNS Support Requirement 3. EDNS Support Requirement
EDNS provides a mechanism to improve the scalability of DNS as its EDNS provides a mechanism to improve the scalability of DNS as its
uses get more diverse on the Internet. It does this by enabling the uses get more diverse on the Internet. It does this by enabling the
use of UDP transport for DNS messages with sizes beyond the limits use of UDP transport for DNS messages with sizes beyond the limits
skipping to change at page 3, line 53 skipping to change at page 4, line 24
DNSKEY) or large TXT Records, the additional UDP payload capabilities DNSKEY) or large TXT Records, the additional UDP payload capabilities
provided by EDNS can help improve the scalability of the DNS by provided by EDNS can help improve the scalability of the DNS by
avoiding generalized use of TCP for DNS transport. avoiding generalized use of TCP for DNS transport.
4. DNS Message changes 4. DNS Message changes
4.1. Message Header 4.1. Message Header
The DNS Message Header's second full 16-bit word is divided into a The DNS Message Header's second full 16-bit word is divided into a
4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see ,
section 4.1.1 [RFC1035]). Some of these were marked for future use, section 4.1.1 [RFC1035]). Some of these were marked for future use,
and most these have since been allocated. Also, most of the RCODE and most these have since been allocated. Also, most of the RCODE
values are now in use. The OPT pseudo-RR specified below contains values are now in use. The OPT pseudo-RR specified below contains
extensions to the RCODE bit field as well as additional flag bits. extensions to the RCODE bit field as well as additional flag bits.
4.2. Label Types 4.2. Label Types
The first two bits of a wire format domain label are used to denote The first two bits of a wire format domain label are used to denote
the type of the label. [RFC1035] allocates two of the four possible the type of the label. [RFC1035] allocates two of the four possible
types and reserves the other two. More label types were defined in types and reserves the other two. More label types were defined in
[RFC2671]. This document obsoletes the use of the 2-bit combination [RFC2671]. This document obsoletes the use of the 2-bit combination
skipping to change at page 4, line 24 skipping to change at page 4, line 46
4.3. UDP Message Size 4.3. UDP Message Size
Traditional DNS Messages are limited to 512 octets in size when sent Traditional DNS Messages are limited to 512 octets in size when sent
over UDP [RFC1035]. Fitting the increasing amounts of data that can over UDP [RFC1035]. Fitting the increasing amounts of data that can
be transported in DNS in this 512-byte limit is becoming more be transported in DNS in this 512-byte limit is becoming more
difficult. For instance, inclusion of DNSSEC records frequently difficult. For instance, inclusion of DNSSEC records frequently
requires a much larger response than a 512 byte message can hold. requires a much larger response than a 512 byte message can hold.
EDNS0 is intended to provide support for transporting these larger EDNS0 is intended to provide support for transporting these larger
packet sizes while continuing to use UDP. It specifies a way to packet sizes while continuing to use UDP. It specifies a way to
advertise additional features such as larger response size advertise additional features such as larger response size
capability, which is intended to help avoid truncated UDP responses capability, which is intended to help avoid truncated UDP responses
which then cause retry over TCP. which then cause retry over TCP.
5. Extended Label Types 5. Extended Label Types
The first octet in the on-the-wire representation of a DNS label The first octet in the on-the-wire representation of a DNS label
specifies the label type; the basic DNS specification [RFC1035] specifies the label type; the basic DNS specification [RFC1035]
dedicates the two most significant bits of that octet for this dedicates the two most significant bits of that octet for this
purpose. purpose.
skipping to change at page 5, line 36 skipping to change at page 6, line 18
6.1.2. Wire Format 6.1.2. Wire Format
An OPT RR has a fixed part and a variable set of options expressed as 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 {attribute, value} pairs. The fixed part holds some DNS meta data
and also a small collection of basic extension elements which we 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 expect to be so popular that it would be a waste of wire space to
encode them as {attribute, value} pairs. encode them as {attribute, value} pairs.
The fixed part of an OPT RR is structured as follows: The fixed part of an OPT RR is structured as follows:
+------------+--------------+------------------------------+ +------------+--------------+------------------------------+
| Field Name | Field Type | Description | | Field Name | Field Type | Description |
+------------+--------------+------------------------------+ +------------+--------------+------------------------------+
| NAME | domain name | Must be 0 (root domain) | | NAME | domain name | Must be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) | | TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size | | CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags | | TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA | | RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs | | RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+ +------------+--------------+------------------------------+
OPT RR Format
The variable part of an OPT RR may contain zero or more options in The variable part of an OPT RR may contain zero or more options in
the RDATA. Each option MUST be treated as binary. Each option is the RDATA. Each option MUST be treated as binary. Each option is
encoded as: encoded as:
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE | 0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH | 2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | | 4: | |
/ OPTION-DATA / / OPTION-DATA /
/ / / /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE OPTION-CODE
Assigned by Expert Review. Assigned by Expert Review.
OPTION-LENGTH OPTION-LENGTH
Size (in octets) of OPTION-DATA. Size (in octets) of OPTION-DATA.
OPTION-DATA OPTION-DATA
Varies per OPTION-CODE. MUST be treated as binary. Varies per OPTION-CODE. MUST be treated as binary.
The order of appearance of option tuples is not defined. If one The order of appearance of option tuples is not defined. If one
option modifies the behavior of another or multiple options are option modifies the behavior of another or multiple options are
related to one another in some way, they have the same effect related to one another in some way, they have the same effect
regardless of ordering in the RDATA wire encoding. regardless of ordering in the RDATA wire encoding.
Any OPTION-CODE values not understood by a responder or requestor Any OPTION-CODE values not understood by a responder or requestor
MUST be ignored. Specifications of such options might wish to MUST be ignored. Specifications of such options might wish to
include some kind of signaled acknowledgement. For example, an include some kind of signaled acknowledgement. For example, an
option specification might say that if a responder sees option XYZ, option specification might say that if a responder sees option XYZ,
it MUST include option XYZ in its response. it MUST include option XYZ in its response.
6.1.3. OPT Record TTL Field Use 6.1.3. OPT Record TTL Field Use
The extended RCODE and flags (which OPT stores in the RR TTL field) The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows: are structured as follows:
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z | 2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE EXTENDED-RCODE
Forms upper 8 bits of extended 12-bit RCODE (together with the Forms upper 8 bits of extended 12-bit RCODE (together with the
4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0
indicates that an unextended RCODE is in use (values 0 through indicates that an unextended RCODE is in use (values 0 through
15). 15).
VERSION VERSION
Indicates the implementation level of the settter. Full Indicates the implementation level of the setter. Full
conformance with this specification is indicated by version conformance with this specification is indicated by version
``0.'' Requestors are encouraged to set this to the lowest ``0.'' Requestors are encouraged to set this to the lowest
implemented level capable of expressing a transaction, to implemented level capable of expressing a transaction, to
minimize the responder and network load of discovering the minimize the responder and network load of discovering the
greatest common implementation level between requestor and greatest common implementation level between requestor and
responder. A requestor's version numbering strategy MAY responder. A requestor's version numbering strategy MAY
ideally be a run time configuration option. ideally be a run time configuration option.
If a responder does not implement the VERSION level of the If a responder does not implement the VERSION level of the
request, then it MUST respond with RCODE=BADVERS. All request, then it MUST respond with RCODE=BADVERS. All
responses MUST be limited in format to the VERSION level of the responses MUST be limited in format to the VERSION level of the
request, but the VERSION of each response SHOULD be the highest request, but the VERSION of each response SHOULD be the highest
implementation level of the responder. In this way a requestor implementation level of the responder. In this way a requestor
skipping to change at page 8, line 35 skipping to change at page 9, line 24
fragment loss or misconfigured firewalls. fragment loss or misconfigured firewalls.
The requestor's maximum payload size can change over time. It MUST The requestor's maximum payload size can change over time. It MUST
not be cached for use beyond the transaction in which it is not be cached for use beyond the transaction in which it is
advertised. advertised.
6.2.4. Responder's Payload Size 6.2.4. Responder's Payload Size
The responder's maximum payload size can change over time, but can be The responder's maximum payload size can change over time, but can be
reasonably expected to remain constant between two closely spaced reasonably expected to remain constant between two closely spaced
sequential transactions; for example, an arbitrary QUERY used as a sequential transactions; for example, an arbitrary QUERY used as a
probe to discover a responder's maximum UDP payload size, followed probe to discover a responder's maximum UDP payload size, followed
immediately by an UPDATE which takes advantage of this size. This is immediately by an UPDATE which takes advantage of this size. This is
considered preferable to the outright use of TCP for oversized considered preferable to the outright use of TCP for oversized
requests, if there is any reason to suspect that the responder requests, if there is any reason to suspect that the responder
implements EDNS, and if a request will not fit in the default 512 implements EDNS, and if a request will not fit in the default 512
payload size limit. payload size limit.
6.2.5. Payload Size Selection 6.2.5. Payload Size Selection
Due to transaction overhead, it is not recommended to advertise an Due to transaction overhead, it is not recommended to advertise an
skipping to change at page 9, line 14 skipping to change at page 9, line 50
A requestor MAY choose to implement a fallback to smaller advertised A requestor MAY choose to implement a fallback to smaller advertised
sizes to work around firewall or other network limitations. A sizes to work around firewall or other network limitations. A
requestor SHOULD choose to use a fallback mechanism which begins with requestor SHOULD choose to use a fallback mechanism which begins with
a large size, such as 4096. If that fails, a fallback around the a large size, such as 4096. If that fails, a fallback around the
1280-1410 byte range SHOULD be tried, as it has a reasonable chance 1280-1410 byte range SHOULD be tried, as it has a reasonable chance
to fit within a single Ethernet frame. Failing that, a requestor MAY 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 choose a 512 byte packet, which with large answers may cause a TCP
retry. retry.
Values of less than 512 bytes SHOULD be treated as equal to 512 Values of less than 512 bytes MUST be treated as equal to 512 bytes.
bytes.
6.2.6. MiddleBoxes 6.2.6. Support in MiddleBoxes
In a network that carries DNS traffic there could be active equipment In a network that carries DNS traffic there could be active equipment
other than that participating directly in the DNS resolution process other than that participating directly in the DNS resolution process
(stub and caching resolvers, authoritative servers) that affect the (stub and caching resolvers, authoritative servers) that affect the
transmission of DNS messages (e.g. firewalls, load balancers, transmission of DNS messages (e.g. firewalls, load balancers,
proxies, etc) referred to here as MiddleBoxes. proxies, etc) referred to here as MiddleBoxes.
MiddleBoxes MUST NOT limit DNS messages over UDP to 512 bytes. Conformant MiddleBoxes MUST NOT limit DNS messages over UDP to 512
bytes.
MiddleBoxes which simply forward requests to a recursive resolver MiddleBoxes which simply forward requests to a recursive resolver
MUST NOT modify and MUST NOT delete the OPT record contents in either MUST NOT modify and MUST NOT delete the OPT record contents in either
direction. direction.
MiddleBoxes which have additional functionality, such as answering MiddleBoxes which have additional functionality, such as answering
queries or acting as intelligent forwarders, SHOULD understand the queries or acting as intelligent forwarders, SHOULD understand the
OPT record. These boxes MUST consider the incoming request and any OPT record. These boxes MUST consider the incoming request and any
outgoing requests as separate transactions if the characteristics of outgoing requests as separate transactions if the characteristics of
the messages are different. the messages are different.
skipping to change at page 11, line 30 skipping to change at page 12, line 30
IETF Standards Action is required to add a new RCODE. Adding new IETF Standards Action is required to add a new RCODE. Adding new
RCODEs should be avoided due to the difficulty in upgrading the RCODEs should be avoided due to the difficulty in upgrading the
installed base. installed base.
This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS
RCODES registry. RCODES registry.
[RFC2671] called for the recording of assignment of extended label [RFC2671] called for the recording of assignment of extended label
types 0bxx111111 as "Reserved for future extended label types". This types 0bxx111111 as "Reserved for future extended label types". This
request was implicitly a request to open a new registry for Extended request was implicitly a request to open a new registry for Extended
Label Types but due to possible ambiguous text registrarions were Label Types but due to possible ambiguous text registrations were
instead made within the general "DNS Label Types" registry which also instead made within the general "DNS Label Types" registry which also
registers entries originally defined by [RFC1035]. registers entries originally defined by [RFC1035].
This document requests IANA to close registration of further Extended This document requests IANA to close registration of further Extended
Label Types in the "DNS Label Types" Registry. Label Types in the "DNS Label Types" Registry.
IETF Standards Action is required for assignments of new EDNS0 flags. IETF Standards Action is required for assignments of new EDNS0 flags.
Flags SHOULD be used only when necessary for DNS resolution to Flags SHOULD be used only when necessary for DNS resolution to
function. For many uses, a EDNS Option Code may be preferred. function. For many uses, a EDNS Option Code may be preferred.
skipping to change at page 11, line 52 skipping to change at page 13, line 5
Version Number registry. Expert Review is required for allocation of Version Number registry. Expert Review is required for allocation of
an EDNS Option Code. an EDNS Option Code.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
2671, August 1999. RFC 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
3225, December 2001. RFC 3225, December 2001.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002. August 2002.
11.2. Informative References 11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999. RFC 2673, August 1999.
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364, Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002. August 2002.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
152, RFC 5625, August 2009. BCP 152, RFC 5625, August 2009.
Appendix A. Document Editing History Appendix A. Document Editing History
Following is a list of high-level changes made to the original Following is a list of high-level changes made to the original
RFC2671. RFC2671.
Appendix A.1. Changes since RFC2671 A.1. Changes since RFC2671
o Support for the OPT record is now mandatory. o Support for the OPT record is now mandatory.
o Extended label types obsoleted and the registry is closed. o Extended label types obsoleted and the registry is closed.
o The bitstring label type, which was already moved from draft to o The bitstring label type, which was already moved from draft to
experimental, is requested to be moved to historical. experimental, is requested to be moved to historical.
o Changes in how EDNS buffer sizes are selected, with o Changes in how EDNS buffer sizes are selected, with
recommendations on how to select them. recommendations on how to select them.
o Front material (IPR notice and such) was updated to current o Front material (IPR notice and such) was updated to current
requirements. requirements.
Appendix A.2. Changes since -02 A.2. Changes since -02
o Specified the method for allocation of constants. o Specified the method for allocation of constants.
o Cleaned up a lot of wording, along with quite a bit of document o Cleaned up a lot of wording, along with quite a bit of document
structure changes. structure changes.
Authors' Addresses Authors' Addresses
Joao Damas Joao Damas
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, California 94063 Redwood City, California 94063
US US
Phone: +1 650.423.1312 Phone: +1 650.423.1312
Email: joao@isc.org Email: joao@isc.org
Michael Graff Michael Graff
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, California 94063 Redwood City, California 94063
US US
Phone: +1 650.423.1304 Phone: +1 650.423.1304
Email: mgraff@isc.org Email: mgraff@isc.org
Paul Vixie Paul Vixie
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, California 94063 Redwood City, California 94063
US US
Phone: +1 650.423.1301 Phone: +1 650.423.1301
Email: vixie@isc.org Email: vixie@isc.org
 End of changes. 36 change blocks. 
96 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/