draft-ietf-dnsext-rfc2671bis-edns0-07.txt   draft-ietf-dnsext-rfc2671bis-edns0-08.txt 
DNSEXT Working Group J. Damas DNSEXT Working Group J. Damas
Internet-Draft M. Graff Internet-Draft M. Graff
Obsoletes: 2671, 2673 P. Vixie Obsoletes: 2671, 2673 P. Vixie
(if approved) Internet Systems Consortium (if approved) Internet Systems Consortium
Intended status: Standards Track January 18, 2012 Intended status: Standards Track February 7, 2012
Expires: July 21, 2012 Expires: August 10, 2012
Extension Mechanisms for DNS (EDNS0) Extension Mechanisms for DNS (EDNS0)
draft-ietf-dnsext-rfc2671bis-edns0-07 draft-ietf-dnsext-rfc2671bis-edns0-08
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 (RFC 2671) based on
feedback from deployment experience in several implementations. feedback from deployment experience in several implementations. It
also closes the IANA registry for extended labels created as part of
RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name
System") which depends on the existence of extended labels.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 July 21, 2012. This Internet-Draft will expire on August 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 4
4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 5
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 5 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 5 6.1.1. Basic elements . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 6 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 7 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 8
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 8 6.2.1. Cache behaviour . . . . . . . . . . . . . . . . . . . 9
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 8 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 9
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 9 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 10
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 9 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 10
6.2.6. Support in MiddleBoxes . . . . . . . . . . . . . . . . 10 6.2.6. Support in MiddleBoxes . . . . . . . . . . . . . . . . 11
7. OPT Option Code Allocation Procedure . . . . . . . . . . . . . 10 7. OPT Option Code Allocation Procedure . . . . . . . . . . . . . 11
8. Transport Considerations . . . . . . . . . . . . . . . . . . . 10 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Document Editing History . . . . . . . . . . . . . . 13 Appendix A. Document Editing History . . . . . . . . . . . . . . 14
A.1. Changes since RFC2671 . . . . . . . . . . . . . . . . . . 13 A.1. Changes since RFC2671 . . . . . . . . . . . . . . . . . . 14
A.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 14 A.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 other 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.
[RFC2671] specified extended label types. The only one proposed was [RFC2671] specified extended label types. The only one proposed was
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, and therefore Binary Labels, obsoleting
[RFC2673].
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
skipping to change at page 8, line 47 skipping to change at page 9, line 47
The requestor's UDP payload size (encoded in the RR CLASS field) is The requestor's UDP payload size (encoded in the RR CLASS field) is
the number of octets of the largest UDP payload that can be 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, could be smaller than that path MTU, with or without fragmentation, could be smaller than
this. this.
Values lower than 512 MUST be treated as equal to 512. Values lower than 512 MUST be treated as equal to 512.
The requestor SHOULD place a value in this field that it can actually The requestor SHOULD place a value in this field that it can actually
receive. For example, if a requestor sits behind a firewall which receive. For example, if a requestor sits behind a firewall which
will block fragmented IP packets, a requestor SHOULD not choose a will block fragmented IP packets, a requestor SHOULD NOT choose a
value which will cause fragmentation. Doing so will prevent large value which will cause fragmentation. Doing so will prevent large
responses from being received, and can cause fallback to occur. This responses from being received, and can cause fallback to occur. This
knowledge may be auto-detected by the implementation or provided by a knowledge may be auto-detected by the implementation or provided by a
human administrator. human administrator.
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 between 1280 and 1410 bytes for IP (v4 or v6) over buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over
Ethernet would be reasonable. Ethernet would be reasonable.
Bigger values SHOULD be considered here fragmentation is not a Bigger values SHOULD be considered where fragmentation is not a
concern. concern.
Choosing a very large value will guarantee fragmentation at the IP Choosing a very large value will guarantee fragmentation at the IP
layer, and may prevent answers from being received due to a single layer, and may prevent answers from being received due to a single
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
skipping to change at page 13, line 11 skipping to change at page 14, line 11
[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.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
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.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[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", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 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
 End of changes. 13 change blocks. 
48 lines changed or deleted 64 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/