draft-ietf-dnsext-rfc2671bis-edns0-02.txt   draft-ietf-dnsext-rfc2671bis-edns0-03.txt 
DNSEXT Working Group M. Graff DNSEXT Working Group M. Graff
Internet-Draft P. Vixie Internet-Draft P. Vixie
Obsoletes: 2671 (if approved) Internet Systems Consortium Obsoletes: 2671, 2673 Internet Systems Consortium
Intended status: Standards Track July 28, 2009 (if approved) March 25, 2010
Expires: January 29, 2010 Intended status: Standards Track
Expires: September 26, 2010
Extension Mechanisms for DNS (EDNS0) Extension Mechanisms for DNS (EDNS0)
draft-ietf-dnsext-rfc2671bis-edns0-02 draft-ietf-dnsext-rfc2671bis-edns0-03
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 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 (RFC2671) based on 10
years of deployment experience.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 45
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 29, 2010. This Internet-Draft will expire on September 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (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. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Domain Name System's wire protocol includes a number of fixed described in the BSD License.
fields whose range has been or soon will be exhausted and does not
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3
4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 4
6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5
6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5
6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 6.3. Caching behavior . . . . . . . . . . . . . . . . . . . . . 7
6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7
6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7
6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8
6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Document Editing History . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11
Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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 is fixed. 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 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 which are desired to become common. There is no way for
implementations to advertise their capabilities. implementations to advertise their capabilities.
Unextended agents will not know how to interpret the protocol Unextended agents will not know how to interpret the protocol
extensions detailed here. In practice, these clients will be extensions detailed here. In practice, these clients will be
upgraded when they have need of a new feature, and only new features upgraded when they have need of a new feature, and only new features
will make use of the extensions. Extended agents must be prepared will make use of the extensions. Extended agents must be prepared
for behaviour of unextended clients in the face of new protocol for behavior of unextended clients in the face of new protocol
elements, and fall back gracefully to unextended DNS. [RFC2671] elements, and fall back gracefully to unextended DNS. [RFC2671]
originally proposed extensions to the basic DNS protocol to overcome proposed extensions to the basic DNS protocol to overcome these
these deficiencies. This memo refines that specification and deficiencies. This memo refines that specification and obsoletes
obsoletes [RFC2671]. [RFC2671].
2. Requirements Language [RFC2671] specified extended label types. The only one ever proposed
was in RFC2673 for a label type called "Bitstring Labels." For
various reasons introducing a new label type was found to be
extremely difficult, and RFC2673 was moved to Experimental. This
document Obsoletes Extended Labels.
2. Terminology
"Requestor" is the side which sends a request. "Responder" is an
authoritative, recursive resolver, or other DNS component which
responds to questions.
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 support is manditory in a modern world. DNSSEC requires EDNS EDNS support is mandatory in a modern world. DNSSEC requires EDNS
support, and many other featres are made possible only by EDNS support, and many other Features are made possible only by EDNS
support to request or advertise them. support to request or advertise them. Many organizations are
beginning to require DNSSEC. Without common interoperability, DNSSEC
cannot be as easily deployed.
DNS publishers are wanting to put more data in answers. DNSSEC
DNSKEY records, negative answers, and many other DNSSEC queries cause
larger answers to be returned. In order to support this, DNS
servers, middleware, and stub resolvers MUST support larger packet
sizes advertised via EDNS0.
4. Affected Protocol Elements 4. Affected Protocol Elements
4.1. Message Header 4.1. Message Header
The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full The DNS Message Header's second full 16-bit word is divided into a
16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see ,
number of 1-bit flags. The original reserved Z bits have been section 4.1.1 [RFC1035]). Some of these were marked for future use,
allocated to various purposes, and most of the RCODE values are now and most these have since been allocated. Also, most of the RCODE
in use. More flags and more possible RCODEs are needed. The OPT values are now in use. The OPT pseudo-RR specified below contains
pseudo-RR specified below contains subfields that carry a bit field subfields that carry a bit field extension of the RCODE field and
extension of the RCODE field and additional flag bits, respectively. additional flag bits, respectively.
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. ,section 4.1.4 [RFC1035] allocates two of the the type of the label. [RFC1035] allocates two of the four possible
four possible types and reserves the other two. More label types types and reserves the other two. More label types were defined in
were proposed in [RFC2671] section 3. [RFC2671].
4.3. UDP Message Size 4.3. UDP Message Size
DNS Messages are limited to 512 octets in size when sent over UDP. Traditional DNS Messages are limited to 512 octets in size when sent
While the minimum maximum reassembly buffer size still allows a limit over UDP ([RFC1035]). Today, many organizations wish to return many
of 512 octets of UDP payload, most of the hosts now connected to the records in a single reply, and special tricks are needed to make the
Internet are able to reassemble larger datagrams. Some mechanism responses fit in this 512-byte limit. Additionally, DNSSEC
must be created to allow requestors to advertise larger buffer sizes signatures can easily generate a much larger response than a 512 byte
to responders. To this end, the OPT pseudo-RR specified below message can hold.
contains a maximum payload size field.
EDNS0 is intended to address these larger packet sizes and continue
to use UDP. It specifies a way to advertise additional features such
as larger response size capability, which is intended to help avoid
truncated UDP responses 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.
This document reserves DNS label type 0b01 for use as an indication [RFC2671] defined DNS label type 0b01 for use as an indication for
for Extended Label Types. A specific extended label type is selected Extended Label Types. A specific Extended Label Type is selected by
by the 6 least significant bits of the first octet. Thus, Extended the 6 least significant bits of the first octet. Thus, Extended
Label Types are indicated by the values 64-127 (0b01xxxxxx) in the Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
first octet of the label. first octet of the label.
This document does not describe any specific Extended Label Type. This document does not describe any specific Extended Label Type.
In practice, Extended Label Types are difficult to use due to support In practice, Extended Label Types are difficult to use due to support
in clients and intermediate gateways. Therefore, the registry of in clients and intermediate gateways. Therefore, the registry of
Extended Label Types is requested to be closed. They cause Extended Label Types is requested to be closed. They cause
interoperability problems and at present no defined label types are interoperability problems and at present no defined label types are
in use. in use.
Bitstring labels were originally created to solve problems with IPv6
reverse zones. Due to the problems of introducing a new label type
they were moved to experimental. This document moves them from
experimental to historical, making them obsoleted.
6. OPT pseudo-RR 6. OPT pseudo-RR
6.1. OPT Record Behavior 6.1. OPT Record Definition
One OPT pseudo-RR (RR type 41) MAY be added to the additional data An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
section of a request. If present in requests, compliant responders additional data section of a request.
which implement EDNS MUST include an OPT record in non-truncated
responses, and SHOULD attempt to include them in all responses. An The OPT RR has been assigned RR type 41.
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 If present in requests, compliant responders MUST include an OPT
NOT be cached, forwarded, or stored in or loaded from master files. record in responses.
The quantity of OPT pseudo-RRs per message MUST be either zero or
one, but not greater. An OPT record does not carry any DNS data. It is used only to
contain control information pertaining to the question and answer
sequence of a specific transaction. OPT RRs MUST NOT be cached,
forwarded, or stored in or loaded from master files.
The OPT RR MAY be placed anywhere within the additional data section.
Only one OPT RR MAY be included within any DNS message. If a message
with more than one OPT RR is received, a FORMERR MUST be returned.
6.2. OPT Record Format 6.2. OPT Record 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:
skipping to change at page 6, line 14 skipping to change at page 6, line 41
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. Varies per OPTION-CODE.
Order of appearance of option tuples is never relevant. Any option The order of appearance of option tuples is not guaranteed. If one
whose meaning is affected by other options is so affected no matter option modifies the behavior of another or multiple options are
which one comes first in the OPT RDATA. related to one another in some way, they have the same effect
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 signalled 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 SHOULD include option XYZ in its response. it MUST include option XYZ in its response.
6.3. Requestor's Payload Size 6.3. Caching behavior
The OPT record must not be cached.
6.4. Fallback
If a requestor detects that the remote end does not support EDNS0, it
MAY issue queries without an OPT record. It MAY cache this knowledge
for a brief time in order to avoid fallback delays in the future.
However, if DNSSEC is required, no fallback should be performed as
DNSSEC is only signaled through EDNS0.
6.5. Requestor's Payload Size
The requestor's UDP payload size (which OPT stores in the RR CLASS 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 field) is the number of octets of the largest UDP payload that can be
reassembled and delivered in the requestor's network stack. Note reassembled and delivered in the requestor's network stack. Note
that path MTU, with or without fragmentation, may be smaller than that path MTU, with or without fragmentation, may be smaller than
this. Values lower than 512 MUST be treated as equal to 512. this. Values lower than 512 MUST be treated as equal to 512.
Requestors 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.
Note that a 512-octet UDP payload requires a 576-octet IP reassembly Note that a 512-octet UDP payload requires a 576-octet IP reassembly
buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable.
The consequence of choosing too large a value may be an ICMP message Choosing a very large value will guarantee fragmentation at the IP
from an intermediate gateway, or even a silent drop of the response layer, and may prevent answers from being received due to a single
message. fragment loss or misconfigured firewalls.
The requestor's maximum payload size can change over time, and MUST The requestor's maximum payload size can change over time. It MUST
therefore 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.4. Responder's Payload Size 6.6. 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 sequential reasonably expected to remain constant between two sequential
transactions; for example, a meaningless QUERY to discover a transactions; for example, a meaningless QUERY to discover a
responder's maximum UDP payload size, followed immediately by an responder's maximum UDP payload size, followed immediately by an
UPDATE which takes advantage of this size. (This is considered UPDATE which takes advantage of this size. This is considered
preferrable to the outright use of TCP for oversized requests, if preferable to the outright use of TCP for oversized requests, if
there is any reason to suspect that the responder implements EDNS, 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.) and if a request will not fit in the default 512 payload size limit.
6.5. Payload Size Selection 6.7. Payload Size Selection
Due to transaction overhead, it is unwise to advertise an Due to transaction overhead, it is unwise to advertise an
architectural limit as a maximum UDP payload size. Just because your architectural limit as a maximum UDP payload size. Just because your
stack can reassemble 64KB datagrams, don't assume that you want to stack can reassemble 64KB datagrams, don't assume that you want to
spend more than about 4KB of state memory per ongoing transaction. spend more than about 4KB of state memory per ongoing transaction.
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
1220 byte range SHOULD be tried, as it has a reasonable chance to fit 1280 byte range SHOULD be tried, as it has a reasonable chance to fit
within a single Ethernet frame. Failing that, a requestor MAY choose within a single Ethernet frame. Failing that, a requestor MAY choose
a 512 byte packet, which with large answers may cause a TCP retry. a 512 byte packet, which with large answers may cause a TCP retry.
6.6. Middleware Boxes 6.8. Middleware Boxes
Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes.
Middleware boxes which simply forward requests to a recursive Middleware boxes which simply forward requests to a recursive
resolver MUST NOT modify the OPT record contents in either direction. resolver MUST NOT modify the OPT record contents in either direction.
6.7. Extended RCODE Middleware boxes which have additional functionality, such as
answering certain queries or acting like an intelligent forwarder,
MUST understand the OPT record. These boxes MUST consider the
incoming request and any outgoing requests as separate transactions
if the characteristics of the messages are different.
6.9. 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. Note that Forms upper 8 bits of extended 12-bit RCODE. Note that
EXTENDED-RCODE value "0" indicates that an unextended RCODE is EXTENDED-RCODE value 0 indicates that an unextended RCODE is in
in use (values "0" through "15"). use (values 0 through 15).
VERSION VERSION
Indicates the implementation level of whoever sets it. Full Indicates the implementation level of whoever sets it. 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.
skipping to change at page 8, line 4 skipping to change at page 9, line 14
VERSION VERSION
Indicates the implementation level of whoever sets it. Full Indicates the implementation level of whoever sets it. 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 answers with RCODE=BADVERS. All responses request, then it answers with RCODE=BADVERS. All responses
MUST be limited in format to the VERSION level of the request, MUST be limited in format to the VERSION level of the request,
but the VERSION of each response SHOULD be the highest 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
will learn the implementation level of a responder as a side will learn the implementation level of a responder as a side
effect of every response, including error responses and effect of every response, including error responses and
including RCODE=BADVERS. including RCODE=BADVERS.
6.10. Flags
DO DO
DNSSEC OK bit as defined by [RFC3225]. DNSSEC OK bit as defined by [RFC3225].
Z Z
Set to zero by senders and ignored by receivers, unless Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification. modified in a subsequent specification.
6.8. OPT Options Type Allocation Procedure 6.11. OPT Options Code Allocation Procedure
Allocations assigned by expert review. TBD Allocations assigned by expert review. Assignment of Option Codes
should be liberal, but duplicate functionality is to be avoided.
7. Transport Considerations 7. Transport Considerations
The presence of an OPT pseudo-RR in a request should be taken as an 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 indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to that EDNS, and can correctly understand any response that conforms to that
feature's specification. feature's specification.
Lack of presence of an OPT record in a request MUST be taken as an 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 indication that the requestor does not implement any part of this
specification and that the responder MUST NOT use any protocol specification and that the responder MUST NOT include an OPT record
extension described here in its response. in its response.
Responders who do not implement these protocol extensions MUST Responders who do not implement these protocol extensions MUST
respond with FORMERR messages without any OPT record. respond with FORMERR messages without any OPT record.
If there is a problem with processing the OPT record itself, such as 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 an option value that is badly formatted or includes out of range
values, a FORMERR MAY be retured. If this occurs the response MUST values, a FORMERR MUST be returned. If this occurs the response MUST
include an OPT record. This MAY be used to distinguish between include an OPT record. This is intended to allow the requestor to to
servers whcih do not implement EDNS and format errors within EDNS. distinguish between servers which do not implement EDNS and format
errors within EDNS.
If EDNS is used in a request, and the response arrives with TC set The minimal response must be the DNS header, question section, and an
and with no EDNS OPT RR, a requestor SHOULD assume that truncation OPT record. This must also occur when an truncated response (using
prevented the OPT RR from being appended by the responder, and the DNS header's TC bit) is returned.
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.
8. Security Considerations 8. Security Considerations
Requestor-side specification of the maximum buffer size may open a Requestor-side specification of the maximum buffer size may open a
new DNS denial of service attack if responders can be made to send new DNS denial of service attack if responders can be made to send
messages which are too large for intermediate gateways to forward, messages which are too large for intermediate gateways to forward,
thus leading to potential ICMP storms between gateways and thus leading to potential ICMP storms between gateways and
responders. responders.
Announcing very large UDP buffer sizes may result in dropping by Announcing very large UDP buffer sizes may result in dropping by
skipping to change at page 9, line 28 skipping to change at page 10, line 37
Announcing too small UDP buffer sizes may result in fallback to TCP. Announcing too small UDP buffer sizes may result in fallback to TCP.
This is especially important with DNSSEC, where answers are much This is especially important with DNSSEC, where answers are much
larger. larger.
9. IANA Considerations 9. IANA Considerations
The IANA has assigned RR type code 41 for OPT. The IANA has assigned RR type code 41 for OPT.
[RFC2671] specified a number of IANA sub-registries within "DOMAIN [RFC2671] specified a number of IANA sub-registries within "DOMAIN
NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option NAME SYSTEM PARAMETERS:"
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 o EDNS Extended Label Type
this registry be closed.
This document assigns extended label type 0bxx111111 as "Reserved for o EDNS Option Codes
future extended label types." We request that IANA record this
assignment.
This document assigns option code 65535 to "Reserved for future o EDNS Version Numbers
expansion."
This document expands the RCODE space from 4 bits to 12 bits. This o Domain System Response Code
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". IANA is advised to re-parent these sub-registries to this document.
IESG approval should be required to create new entries in the EDNS [RFC2671] created the "EDNS Extended Label Type Registry". We
Extended Label Type or EDNS Version Number registries, while any request that this registry be closed.
published RFC (including Informational, Experimental, or BCP) should
be grounds for allocation of an EDNS Option Code.
10. Acknowledgements This document assigns option code 65535 in the "EDNS Option Codes"
registry to "Reserved for future expansion."
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, [RFC2671] expands the RCODE space from 4 bits to 12 bits. This
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas allows more than the 16 distinct RCODE values allowed in [RFC1035].
Narten were each instrumental in creating and refining this IETF Standards Action is required to add a new RCODE. Adding new
specification. RCODEs should be avoided due to the difficulty in upgrading the
installed base.
11. References This document assigns EDNS Extended RCODE 16 to "BADVERS".
11.1. Normative References IETF Standards Action is required for assignments of new EDNS0 flags.
Flags SHOULD be used only when necessary for DNS resolution to
function. For many uses, a EDNS Option Code may be preferred.
IETF Standards Action is required to create new entries in the EDNS
Version Number registry. Expert Review is required for allocation of
an EDNS Option Code.
Appendix A. Document Editing History
Following is a list of high-level changes made to the original
RFC2671.
Appendix A.1. Changes since RFC2671
o Support for the OPT record is now mandatory.
o Extended label types obsoleted and the registry is closed.
o The bitstring label type, which was already moved from draft to
experimental, is requested to be moved to historical.
o Changes in how EDNS buffer sizes are selected, with
recommendations on how to select them.
o Front material (IPR notice and such) was updated to current
requirements.
Appendix A.2. Changes since -02
o Specified the method for allocation of constants.
o Cleaned up a lot of wording, along with quite a bit of document
structure changes.
10. References
10.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)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001. RFC 3225, December 2001.
11.2. Informative References 10.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.
Authors' Addresses Authors' Addresses
Michael Graff Michael Graff
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, California 94063 Redwood City, California 94063
 End of changes. 54 change blocks. 
141 lines changed or deleted 237 lines changed or added

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