upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-05-28 04:34:54 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

sync

Browse source
This commit is contained in:
Tinderbox User 2014-02-15 01:05:11 +00:00
parent 2884bc714b
commit 04e104d1c2
11 changed files with 11959 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
FAQ.xml
View file

@ -1,7 +1,7 @@
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
<!--
- Copyright (C) 2004-2010, 2012-2014 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2004-2010, 2013 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@ -30,9 +30,7 @@
<year>2008</year>
<year>2009</year>
<year>2010</year>
<year>2012</year>
<year>2013</year>
<year>2014</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>

1627
doc/rfc/rfc5936.txt Normal file
View file

File diff suppressed because it is too large Load diff

787
doc/rfc/rfc5952.txt Normal file
View file

@ -0,0 +1,787 @@
Internet Engineering Task Force (IETF) S. Kawamura
Request for Comments: 5952 NEC BIGLOBE, Ltd.
Updates: 4291 M. Kawashima
Category: Standards Track NEC AccessTechnica, Ltd.
ISSN: 2070-1721 August 2010
A Recommendation for IPv6 Address Text Representation
Abstract
As IPv6 deployment increases, there will be a dramatic increase in
the need to use IPv6 addresses in text. While the IPv6 address
architecture in Section 2.2 of RFC 4291 describes a flexible model
for text representation of an IPv6 address, this flexibility has been
causing problems for operators, system engineers, and users. This
document defines a canonical textual representation format. It does
not define a format for internal storage, such as within an
application or database. It is expected that the canonical format
will be followed by humans and systems when representing IPv6
addresses as text, but all implementations must accept and be able to
handle any legitimate RFC 4291 format.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5952.
Kawamura & Kawashima Standards Track [Page 1]
RFC 5952 IPv6 Text Representation August 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kawamura & Kawashima Standards Track [Page 2]
RFC 5952 IPv6 Text Representation August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4
2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4
2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
3. Problems Encountered with the Flexible Model . . . . . . . . . 6
3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
3.1.4. Searching for an Address in a Network Diagram . . . . 7
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10
4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Text Representation of Special Addresses . . . . . . . . . . . 11
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
Kawamura & Kawashima Standards Track [Page 3]
RFC 5952 IPv6 Text Representation August 2010
1. Introduction
A single IPv6 address can be text represented in many ways. Examples
are shown below.
2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1
All of the above examples represent the same IPv6 address. This
flexibility has caused many problems for operators, systems
engineers, and customers. The problems are noted in Section 3. A
canonical representation format to avoid problems is introduced in
Section 4.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Text Representation Flexibility of RFC 4291
Examples of flexibility in Section 2.2 of [RFC4291] are described
below.
2.1. Leading Zeros in a 16-Bit Field
'It is not necessary to write the leading zeros in an individual
field.'
Conversely, it is also not necessary to omit leading zeros. This
means that it is possible to select from representations such as
those in the following example. The final 16-bit field is different,
but all of these addresses represent the same address.
Kawamura & Kawashima Standards Track [Page 4]
RFC 5952 IPv6 Text Representation August 2010
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
2.2. Zero Compression
'A special syntax is available to compress the zeros. The use of
"::" indicates one or more groups of 16 bits of zeros.'
It is possible to select whether or not to omit just one 16-bit 0
field.
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
In cases where there is more than one field of only zeros, there is a
choice of how many fields can be shortened.
2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1
In addition, Section 2.2 of [RFC4291] notes,
'The "::" can only appear once in an address.'
This gives a choice on where in a single address to compress the
zero.
2001:db8::aaaa:0:0:1
2001:db8:0:0:aaaa::1
Kawamura & Kawashima Standards Track [Page 5]
RFC 5952 IPv6 Text Representation August 2010
2.3. Uppercase or Lowercase
[RFC4291] does not mention any preference of uppercase or lowercase.
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
3. Problems Encountered with the Flexible Model
3.1. Searching
3.1.1. General Summary
A search of an IPv6 address if conducted through a UNIX system is
usually case sensitive and extended options that allow for regular
expression use will come in handy. However, there are many
applications in the Internet today that do not provide this
capability. When searching for an IPv6 address in such systems, the
system engineer will have to try each and every possibility to search
for an address. This has critical impacts, especially when trying to
deploy IPv6 over an enterprise network.
3.1.2. Searching Spreadsheets and Text Files
Spreadsheet applications and text editors on GUI systems rarely have
the ability to search for text using regular expression. Moreover,
there are many non-engineers (who are not aware of case sensitivity
and regular expression use) that use these applications to manage IP
addresses. This has worked quite well with IPv4 since text
representation in IPv4 has very little flexibility. There is no
incentive to encourage these non-engineers to change their tool or
learn regular expression when they decide to go dual-stack. If the
entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
conducted as 2001:db8:0:0:1::1, this will show a result of no match.
One example where this will cause a problem is, when the search is
being conducted to assign a new address from a pool, and a check is
being done to see if it is not in use. This may cause problems for
the end-hosts or end-users. This type of address management is very
often seen in enterprise networks and ISPs.
3.1.3. Searching with Whois
The "whois" utility is used by a wide range of people today. When a
record is set to a database, one will likely check the output to see
if the entry is correct. If an entity was recorded as 2001:db8::/48,
Kawamura & Kawashima Standards Track [Page 6]
RFC 5952 IPv6 Text Representation August 2010
but the whois output showed 2001:0db8:0000::/48, most non-engineers
would think that their input was wrong and will likely retry several
times or make a frustrated call to the database hostmaster. If there
was a need to register the same prefix on different systems, and each
system showed a different text representation, this would confuse
people even more. Although this document focuses on addresses rather
than prefixes, it is worth mentioning the prefix problems because the
problems encountered with addresses and prefixes are mostly equal.
3.1.4. Searching for an Address in a Network Diagram
Network diagrams and blueprints often show what IP addresses are
assigned to a system devices. In times of trouble shooting there may
be a need to search through a diagram to find the point of failure
(for example, if a traceroute stopped at 2001:db8::1, one would
search the diagram for that address). This is a technique quite
often in use in enterprise networks and managed services. Again, the
different flavors of text representation will result in a time-
consuming search leading to longer mean times to restoration (MTTR)
in times of trouble.
3.2. Parsing and Modifying
3.2.1. General Summary
With all the possible methods of text representation, each
application must include a module, object, link, etc. to a function
that will parse IPv6 addresses in a manner such that no matter how it
is represented, they will mean the same address. Many system
engineers who integrate complex computer systems for corporate
customers will have difficulties finding that their favorite tool
will not have this function, or will encounter difficulties such as
having to rewrite their macros or scripts for their customers.
3.2.2. Logging
If an application were to output a log summary that represented the
address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
the output would be highly unreadable compared to the IPv4 output.
The address would have to be parsed and reformed to make it useful
for human reading. Sometimes logging for critical systems is done by
mirroring the same traffic to two different systems. Care must be
taken so that no matter what the log output is, the logs should be
parsed so they are equivalent.
Kawamura & Kawashima Standards Track [Page 7]
RFC 5952 IPv6 Text Representation August 2010
3.2.3. Auditing: Case 1
When a router or any other network appliance machine configuration is
audited, there are many methods to compare the configuration
information of a node. Sometimes auditing will be done by just
comparing the changes made each day. In this case, if configuration
was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
0000:0000:0000:0001 just because the new engineer on the block felt
it was better, a simple diff will show that a different address was
configured. If this was done on a wide scale network, people will be
focusing on 'why the extra zeros were put in' instead of doing any
real auditing. Lots of tools are just plain diffs that do not take
into account address representation rules.
3.2.4. Auditing: Case 2
Node configurations will be matched against an information system
that manages IP addresses. If output notation is different, there
will need to be a script that is implemented to cover for this. The
result of an SNMP GET operation, converted to text and compared to a
textual address written by a human is highly unlikely to match on the
first try.
3.2.5. Verification
Some protocols require certain data fields to be verified. One
example of this is X.509 certificates. If an IPv6 address field in a
certificate was incorrectly verified by converting it to text and
making a simple textual comparison to some other address, the
certificate may be mistakenly shown as being invalid due to a
difference in text representation methods.
3.2.6. Unexpected Modifying
Sometimes, a system will take an address and modify it as a
convenience. For example, a system may take an input of
2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were
input for a reason, the outcome may be somewhat unexpected.
3.3. Operating
3.3.1. General Summary
When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
0:0:1, the system may take the address and show the configuration
result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address
representation will know that the right address is set, but not
everyone may understand this.
Kawamura & Kawashima Standards Track [Page 8]
RFC 5952 IPv6 Text Representation August 2010
3.3.2. Customer Calls
When a customer calls to inquire about a suspected outage, IPv6
address representation should be handled with care. Not all
customers are engineers, nor do they have a similar skill level in
IPv6 technology. The network operations center will have to take
extra steps to humanly parse the address to avoid having to explain
to the customers that 2001:db8:0:1::1 is the same as
2001:db8::1:0:0:0:1. This is one thing that will never happen in
IPv4 because IPv4 addresses cannot be abbreviated.
3.3.3. Abuse
Network abuse reports generally include the abusing IP address. This
'reporting' could take any shape or form of the flexible model. A
team that handles network abuse must be able to tell the difference
between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
placement of the "::" will result in a critical situation. A system
that handles these incidents should be able to handle any type of
input and parse it in a correct manner. Also, incidents are reported
over the phone. It is unnecessary to report if the letter is
uppercase or lowercase. However, when a letter is spelled uppercase,
people tend to specify that it is uppercase, which is unnecessary
information.
3.4. Other Minor Problems
3.4.1. Changing Platforms
When an engineer decides to change the platform of a running service,
the same code may not work as expected due to the difference in IPv6
address text representation. Usually, a change in a platform (e.g.,
Unix to Windows, Cisco to Juniper) will result in a major change of
code anyway, but flexibility in address representation will increase
the work load.
3.4.2. Preference in Documentation
A document that is edited by more than one author may become harder
to read.
3.4.3. Legibility
Capital case D and 0 can be quite often misread. Capital B and 8 can
also be misread.
Kawamura & Kawashima Standards Track [Page 9]
RFC 5952 IPv6 Text Representation August 2010
4. A Recommendation for IPv6 Text Representation
A recommendation for a canonical text representation format of IPv6
addresses is presented in this section. The recommendation in this
document is one that complies fully with [RFC4291], is implemented by
various operating systems, and is human friendly. The recommendation
in this section SHOULD be followed by systems when generating an
address to be represented as text, but all implementations MUST
accept and be able to handle any legitimate [RFC4291] format. It is
advised that humans also follow these recommendations when spelling
an address.
4.1. Handling Leading Zeros in a 16-Bit Field
Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is
not acceptable and must be represented as 2001:db8::1. A single 16-
bit 0000 field MUST be represented as 0.
4.2. "::" Usage
4.2.1. Shorten as Much as Possible
The use of the symbol "::" MUST be used to its maximum capability.
For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::"
could have been used to produce a shorter representation 2001:db8::1.
4.2.2. Handling One 16-Bit 0 Field
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.
4.2.3. Choice in Placement of "::"
When there is an alternative choice in the placement of a "::", the
longest run of consecutive 16-bit 0 fields MUST be shortened (i.e.,
the sequence with three consecutive zero fields is shortened in 2001:
0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields
are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct
representation.
4.3. Lowercase
The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
MUST be represented in lowercase.
Kawamura & Kawashima Standards Track [Page 10]
RFC 5952 IPv6 Text Representation August 2010
5. Text Representation of Special Addresses
Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses
embedded in the low-order 32 bits of the address. These addresses
have a special representation that may mix hexadecimal and dot
decimal notations. The decimal notation may be used only for the
last 32 bits of the address. For these addresses, mixed notation is
RECOMMENDED if the following condition is met: the address can be
distinguished as having IPv4 addresses embedded in the lower 32 bits
solely from the address field through the use of a well-known prefix.
Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
this writing. If it is known by some external method that a given
prefix is used to embed IPv4, it MAY be represented as mixed
notation. Tools that provide options to specify prefixes that are
(or are not) to be represented as mixed notation may be useful.
There is a trade-off here where a recommendation to achieve an exact
match in a search (no dot decimals whatsoever) and a recommendation
to help the readability of an address (dot decimal whenever possible)
does not result in the same solution. The above recommendation is
aimed at fixing the representation as much as possible while leaving
the opportunity for future well-known prefixes to be represented in a
human-friendly manner as tools adjust to newly assigned prefixes.
The text representation method noted in Section 4 should be applied
for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of
0:0:0:0:0:ffff:192.0.2.1).
6. Notes on Combining IPv6 Addresses with Port Numbers
There are many different ways to combine IPv6 addresses and port
numbers that are represented in text. Examples are shown below.
o [2001:db8::1]:80
o 2001:db8::1:80
o 2001:db8::1.80
o 2001:db8::1 port 80
o 2001:db8::1p80
o 2001:db8::1#80
The situation is not much different in IPv4, but the most ambiguous
case with IPv6 is the second bullet. This is due to the "::"usage in
Kawamura & Kawashima Standards Track [Page 11]
RFC 5952 IPv6 Text Representation August 2010
IPv6 addresses. This style is NOT RECOMMENDED because of its
ambiguity. The [] style as expressed in [RFC3986] SHOULD be
employed, and is the default unless otherwise specified. Other
styles are acceptable when there is exactly one style for the given
context and cross-platform portability does not become an issue. For
URIs containing IPv6 address literals, [RFC3986] MUST be followed, as
well as the rules defined in this document.
7. Prefix Representation
Problems with prefixes are the same as problems encountered with
addresses. The text representation method of IPv6 prefixes should be
no different from that of IPv6 addresses.
8. Security Considerations
This document notes some examples where IPv6 addresses are compared
in text format. The example on Section 3.2.5 is one that may cause a
security risk if used for access control. The common practice of
comparing X.509 data is done in binary format.
9. Acknowledgements
The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
and Toshimitsu Matsuura for their generous and helpful comments in
kick starting this document. We also would like to thank Brian
Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave
Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko,
Heikki Vatiainen, Dan Wing, and Doug Barton for their input. Also, a
very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
this document to light in IETF working groups.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
Kawamura & Kawashima Standards Track [Page 12]
RFC 5952 IPv6 Text Representation August 2010
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
10.2. Informative References
[ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators",
Work in Progress, July 2010.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)",
RFC 5214, March 2008.
Kawamura & Kawashima Standards Track [Page 13]
RFC 5952 IPv6 Text Representation August 2010
Appendix A. For Developers
We recommend that developers use display routines that conform to
these rules. For example, the usage of getnameinfo() with flags
argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
except for the special addresses notes in Section 5. The function
inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
be called directly. See [RFC4038] for details.
Authors' Addresses
Seiichi Kawamura
NEC BIGLOBE, Ltd.
14-22, Shibaura 4-chome
Minatoku, Tokyo 108-8558
JAPAN
Phone: +81 3 3798 6085
EMail: kawamucho@mesh.ad.jp
Masanobu Kawashima
NEC AccessTechnica, Ltd.
800, Shimomata
Kakegawa-shi, Shizuoka 436-8501
JAPAN
Phone: +81 537 23 9655
EMail: kawashimam@necat.nec.co.jp
Kawamura & Kawashima Standards Track [Page 14]

395
doc/rfc/rfc5966.txt Normal file
View file

@ -0,0 +1,395 @@
Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 5966 Nominet UK
Updates: 1035, 1123 August 2010
Category: Standards Track
ISSN: 2070-1721
DNS Transport over TCP - Implementation Requirements
Abstract
This document updates the requirements for the support of TCP as a
transport protocol for DNS implementations.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5966.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bellis Standards Track [Page 1]
RFC 5966 DNS over TCP August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology Used in This Document . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
6. Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction
Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
Section 6.1.3.2 of [RFC1123] states:
DNS resolvers and recursive servers MUST support UDP, and SHOULD
support TCP, for sending (non-zone-transfer) queries.
However, some implementors have taken the text quoted above to mean
that TCP support is an optional feature of the DNS protocol.
The majority of DNS server operators already support TCP and the
default configuration for most software implementations is to support
TCP. The primary audience for this document is those implementors
whose failure to support TCP restricts interoperability and limits
deployment of new DNS features.
This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation.
Whilst this document makes no specific recommendations to operators
of DNS servers, it should be noted that failure to support TCP (or
the blocking of DNS over TCP at the network layer) may result in
resolution failure and/or application-level timeouts.
Bellis Standards Track [Page 2]
RFC 5966 DNS over TCP August 2010
2. Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Discussion
In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),
the normal behaviour of any DNS server needing to send a UDP response
that would exceed the 512-byte limit is for the server to truncate
the response so that it fits within that limit and then set the TC
flag in the response header. When the client receives such a
response, it takes the TC flag as an indication that it should retry
over TCP instead.
RFC 1123 also says:
... it is also clear that some new DNS record types defined in the
future will contain information exceeding the 512 byte limit that
applies to UDP, and hence will require TCP. Thus, resolvers and
name servers should implement TCP services as a backup to UDP
today, with the knowledge that they will require the TCP service
in the future.
Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown
that truncation at the 512-byte boundary is now commonplace. For
example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from
a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost
invariably larger than 512 bytes.
Since the original core specifications for DNS were written, the
Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
These extensions can be used to indicate that the client is prepared
to receive UDP responses larger than 512 bytes. An EDNS0-compatible
server receiving a request from an EDNS0-compatible client may send
UDP packets up to that client's announced buffer size without
truncation.
However, transport of UDP packets that exceed the size of the path
MTU causes IP packet fragmentation, which has been found to be
unreliable in some circumstances. Many firewalls routinely block
fragmented IP packets, and some do not implement the algorithms
necessary to reassemble fragmented packets. Worse still, some
network devices deliberately refuse to handle DNS packets containing
EDNS0 options. Other issues relating to UDP transport and packet
size are discussed in [RFC5625].
Bellis Standards Track [Page 3]
RFC 5966 DNS over TCP August 2010
The MTU most commonly found in the core of the Internet is around
1500 bytes, and even that limit is routinely exceeded by DNSSEC-
signed responses.
The future that was anticipated in RFC 1123 has arrived, and the only
standardised UDP-based mechanism that may have resolved the packet
size issue has been found inadequate.
4. Transport Protocol Selection
All general-purpose DNS implementations MUST support both UDP and TCP
transport.
o Authoritative server implementations MUST support TCP so that they
do not limit the size of responses to what fits in a single UDP
packet.
o Recursive server (or forwarder) implementations MUST support TCP
so that they do not prevent large responses from a TCP-capable
server from reaching its TCP-capable clients.
o Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would
limit their interoperability with their own clients and with
upstream servers.
Stub resolver implementations MAY omit support for TCP when
specifically designed for deployment in restricted environments where
truncation can never occur or where truncated DNS responses are
acceptable.
Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
RFC 1123 also says:
... a DNS resolver or server that is sending a non-zone-transfer
query MUST send a UDP query first.
That requirement is hereby relaxed. A resolver SHOULD send a UDP
query first, but MAY elect to send a TCP query instead if it has good
reason to expect the response would be truncated if it were sent over
UDP (with or without EDNS0) or for other operational reasons, in
particular, if it already has an open TCP connection to the server.
Bellis Standards Track [Page 4]
RFC 5966 DNS over TCP August 2010
5. Connection Handling
Section 4.2.2 of [RFC1035] says:
If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle for a
period on the order of two minutes. In particular, the server
should allow the SOA and AXFR request sequence (which begins a
refresh operation) to be made on a single connection. Since the
server would be unable to answer queries anyway, a unilateral
close or reset may be used instead of a graceful close.
Other more modern protocols (e.g., HTTP [RFC2616]) have support for
persistent TCP connections and operational experience has shown that
long timeouts can easily cause resource exhaustion and poor response
under heavy load. Intentionally opening many connections and leaving
them dormant can trivially create a "denial-of-service" attack.
It is therefore RECOMMENDED that the default application-level idle
period should be of the order of seconds, but no particular value is
specified. In practise, the idle period may vary dynamically, and
servers MAY allow dormant connections to remain open for longer
periods as resources permit.
To mitigate the risk of unintentional server overload, DNS clients
MUST take care to minimize the number of concurrent TCP connections
made to any individual server. Similarly, servers MAY impose limits
on the number of concurrent TCP connections being handled for any
particular client.
Further recommendations for the tuning of TCP stacks to allow higher
throughput or improved resiliency against denial-of-service attacks
are outside the scope of this document.
6. Response Reordering
RFC 1035 is ambiguous on the question of whether TCP queries may be
reordered -- the only relevant text is in Section 4.2.1, which
relates to UDP:
Queries or their responses may be reordered by the network, or by
processing in name servers, so resolvers should not depend on them
being returned in order.
For the avoidance of future doubt, this requirement is clarified.
Client resolvers MUST be able to process responses that arrive in a
different order to that in which the requests were sent, regardless
of the transport protocol in use.
Bellis Standards Track [Page 5]
RFC 5966 DNS over TCP August 2010
7. Security Considerations
Some DNS server operators have expressed concern that wider use of
DNS over TCP will expose them to a higher risk of denial-of-service
(DoS) attacks.
Although there is a higher risk of such attacks against TCP-enabled
servers, techniques for the mitigation of DoS attacks at the network
level have improved substantially since DNS was first designed.
At the time of writing, the vast majority of Top Level Domain (TLD)
authority servers and all of the root name servers support TCP and
the author knows of no evidence to suggest that TCP-based DoS attacks
against existing DNS infrastructure are commonplace.
That notwithstanding, readers are advised to familiarise themselves
with [CPNI-TCP].
Operators of recursive servers should ensure that they only accept
connections from expected clients, and do not accept them from
unknown sources. In the case of UDP traffic, this will help protect
against reflector attacks [RFC5358] and in the case of TCP traffic it
will prevent an unknown client from exhausting the server's limits on
the number of concurrent connections.
8. Acknowledgements
The author would like to thank the document reviewers from the DNSEXT
Working Group, and in particular, George Barwood, Alex Bligh, Alfred
Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and
Nicholas Weaver.
9. References
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Bellis Standards Track [Page 6]
RFC 5966 DNS over TCP August 2010
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
9.2. Informative References
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
Author's Address
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Bellis Standards Track [Page 7]

1011
doc/rfc/rfc6052.txt Normal file
View file

File diff suppressed because it is too large Load diff

1795
doc/rfc/rfc6147.txt Normal file
View file

File diff suppressed because it is too large Load diff

955
doc/rfc/rfc6168.txt Normal file
View file

@ -0,0 +1,955 @@
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 6168 Sparta, Inc.
Category: Informational May 2011
ISSN: 2070-1721
Requirements for Management of Name Servers for the DNS
Abstract
Management of name servers for the Domain Name System (DNS) has
traditionally been done using vendor-specific monitoring,
configuration, and control methods. Although some service monitoring
platforms can test the functionality of the DNS itself, there is not
an interoperable way to manage (monitor, control, and configure) the
internal aspects of a name server itself.
This document discusses the requirements of a management system for
name servers and can be used as a shopping list of needed features
for such a system.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6168.
Hardaker Informational [Page 1]
RFC 6168 Name Server Management Requirements May 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
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.
Hardaker Informational [Page 2]
RFC 6168 Name Server Management Requirements May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
Hardaker Informational [Page 3]
RFC 6168 Name Server Management Requirements May 2011
1. Introduction
Management of name servers for the Domain Name System (DNS) [RFC1034]
[RFC1035] has traditionally been done using vendor-specific
monitoring, configuration, and control methods. Although some
service monitoring platforms can test the functionality of the DNS
itself, there is not an interoperable way to manage (monitor,
control, and configure) the internal aspects of a name server itself.
Previous standardization work within the IETF resulted in the
creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed
to achieve significant implementation and deployment. The perceived
reasons behind the failure for the two MIB modules are documented in
[RFC3197].
This document discusses the requirements of a management system for
name servers and can be used as a shopping list of needed features
for such a system. This document only discusses requirements for
managing the name server component of a system -- not other elements
of the system itself.
Specifically out of scope for this document are requirements
associated with the management of stub resolvers. It is not the
intent of this document to document stub resolver requirements,
although some of the requirements listed are applicable to stub
resolvers as well.
The task of creating a management system for managing DNS servers is
not expected to be a small one. It is likely that components of the
solution will need to be designed in parts over time; these
requirements take this into consideration. In particular,
Section 5.1 discusses the need for future extensibility of the base
management solution. This document is intended to be a roadmap
towards a desired outcome and is not intended to define an "all-or-
nothing" system. Successful interoperable management of name
servers, even in part, is expected to be beneficial to network
operators compared to the entirely custom solutions that are used at
the time of this writing.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hardaker Informational [Page 4]
RFC 6168 Name Server Management Requirements May 2011
1.2. Terminology
This document is consistent with the terminology defined in Section 2
of [RFC4033]. Additional terminology needed for this document is
described below:
Name Server: When we are discussing servers that don't fall into a
more specific type of server category defined in other documents,
this document will refer to them generically as "name servers".
In particular, "name servers" can be considered to be any valid
combination of authoritative, recursive, validating, or security-
aware. The more specific name server labels will be used when
this document refers only to a specific type of server. However,
the term "name server", in this document, will not include stub
resolvers.
1.3. Document Layout and Requirements
This document is written so that each numbered section will contain
only a single requirement if it contains one at all. Each
requirement will contain needed wording from the terminology
described in Section 1.1. Subsections, however, might exist with
additional related requirements. The document is laid out in this
way so that a specific requirement can be uniquely referred to using
the section number itself and the document version from which it
came.
2. Management Architecture Requirements
This section discusses requirements that reflect the needs of the
expected deployment environments.
2.1. Expected Deployment Scenarios
DNS zones vary greatly in the type of content published within them.
Name servers, too, are deployed with a wide variety of configurations
to support the diversity of the deployed content. It is important
that a management solution trying to meet the criteria specified in
this document consider supporting the largest number of potential
deployment cases as possible. Further deployment scenarios that are
not used as direct examples of specific requirements are listed in
Appendix A.
Hardaker Informational [Page 5]
RFC 6168 Name Server Management Requirements May 2011
2.1.1. Zone Size Constraints
The management solution MUST support both name servers that are
serving a small number of potentially very large zones (e.g., Top
Level Domains (TLDs)) as well as name servers that are serving a very
large number of small zones. Both deployment scenarios are common.
2.1.2. Name Server Discovery
Large enterprise network deployments may contain multiple name
servers operating within the boundaries of the enterprise network.
These name servers may each be serving multiple zones both in and out
of the parent enterprise's zone. Finding and managing large numbers
of name servers would be a useful feature of the resulting management
solution. The management solution MAY support the ability to
discover previously unknown instances of name servers operating
within a deployed network.
2.1.3. Configuration Data Volatility
Configuration data is defined as data that relates only to the
configuration of a server and the zones it serves. It specifically
does not include data from the zone contents that is served through
DNS itself. The solution MUST support servers that remain statically
configured over time as well as servers that have numerous zones
being added and removed within an hour. Both deployment scenarios
are common.
2.1.4. Protocol Selection
There are many requirements in this document for many different types
of management operations (see Section 3 for further details). It is
possible that no one protocol will ideally fill all the needs of the
requirements listed in this document, and thus multiple protocols
might be needed to produce a completely functional management system.
Multiple protocols might be used to create the complete management
solution, but the solution SHOULD require only one.
2.1.5. Common Data Model
Defining a standardized protocol (or set of protocols) to use for
managing name servers would be a step forward in achieving an
interoperable management solution. However, just defining a protocol
to use by itself would not achieve the entire end goal of a complete
interoperable management solution. Devices also need to represent
their internal management interface using a common management data
model. The solution MUST create a common data model that management
stations can make use of when sending or collecting data from a
Hardaker Informational [Page 6]
RFC 6168 Name Server Management Requirements May 2011
managed device so it can successfully manage equipment from vendors
as if they were generic DNS servers. This common data model is
needed for the operations discussion in Section 3. Note that this
does not preclude the fact that name server vendors might provide
additional management infrastructure beyond a base management
specification, as discussed further in Section 5.1.
2.1.6. Operational Impact
It is impossible to add new features to an existing server (such as
the inclusion of a management infrastructure) and not impact the
existing service and/or server in some fashion. At a minimum, for
example, more memory, disk, and/or CPU resources will be required to
implement a new management system. However, the impact to the
existing DNS service MUST be minimized since the DNS service itself
is still the primary service to be offered by the modified name
server. The management solution MUST NOT result in an increase of
the number of unhandled DNS requests.
2.2. Name Server Types
There are multiple ways in which name servers can be deployed. Name
servers can take on any of the following roles:
o Master Servers
o Slave Servers
o Recursive Servers
The management solution SHOULD support all of these types of name
servers as they are all equally important. Note that "Recursive
Servers" can be further broken down by the security sub-roles they
might implement, as defined in section 2 of [RFC4033]. These sub-
roles are also important to support within any management solution.
As stated earlier, the management of stub resolvers is considered out
of scope for this document.
3. Management Operation Types
Management operations can traditionally be broken into four
categories:
o Control
o Configuration
Hardaker Informational [Page 7]
RFC 6168 Name Server Management Requirements May 2011
o Health and Monitoring
o Alarms and Events
This section discusses detailed requirements for each of these four
management categories.
3.1. Control Requirements
The management solution MUST be capable of performing basic service
control operations.
3.1.1. Needed Control Operations
These operations SHOULD include, at a minimum, the following
operations:
o Starting the name server
o Reloading the service configuration
o Reloading all of the zone data
o Reloading individual zone data sets
o Restarting the name server
o Stopping the name server
Note that no restriction is placed on how the management system
implements these operations. In particular, at least "starting the
name server" will require a minimal management system component to
exist independently of the name server itself.
3.1.2. Asynchronous Status Notifications
Some control operations might take a long time to complete. As an
example, some name servers take a long time to perform reloads of
large zones. Because of these timing issues, the management solution
SHOULD take this into consideration and offer a mechanism to ease the
burden associated with awaiting the status of a long-running command.
This could, for example, result in the use of asynchronous
notifications for returning the status of a long-running task, or it
might require the management station to poll for the status of a
given task using monitoring commands. These and other potential
solutions need to be evaluated carefully to select one that balances
the result delivery needs with the perceived implementation costs.
Hardaker Informational [Page 8]
RFC 6168 Name Server Management Requirements May 2011
Also, see the related discussion in Section 3.4 on notification
messages for supporting delivery of alarm and event messages.
3.2. Configuration Requirements
Many features of name servers need to be configured before the server
can be considered functional. The management solution MUST be able
to provide name servers with configuration data. The most important
data to be configured, for example, is the served zone data itself.
3.2.1. Served Zone Modification
The ability to add, modify, and delete zones being served by name
servers is needed. Although there are already solutions for zone
content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
full zone transfer (AXFR) [RFC5936], and incremental zone transfer
(IXFR) [RFC1995]) that might be used as part of the final management
solution, the management system SHOULD still be able to create a new
zone (with enough minimal data to allow the other mechanisms to
function as well) and to delete a zone. This might be, for example,
a management operation that allows for the creation of at least the
initial SOA (Start of Authority) record for a new zone, since that is
the minimum amount of zone data needed for the other operations to
function.
3.2.2. Trust Anchor Management
The solution SHOULD support the ability to add, modify, and delete
trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
[RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
anchors might be configured using the data from the DNSKEY Resource
Records (RRs) themselves or by using Delegation Signer (DS)
fingerprints.
3.2.3. Security Expectations
DNSSEC validating resolvers need to make policy decisions about the
requests being processed. For example, they need to be configured
with a list of zones expected to be secured by DNSSEC. The
management solution SHOULD be able to add, modify, and delete
attributes of DNSSEC security policies.
3.2.4. TSIG Key Management
TSIG [RFC2845] allows transaction-level authentication of DNS
traffic. The management solution SHOULD be able to add, modify, and
delete TSIG keys known to the name server.
Hardaker Informational [Page 9]
RFC 6168 Name Server Management Requirements May 2011
3.2.5. DNS Protocol Authorization Management
The management solution SHOULD have the ability to add, modify, and
delete authorization settings for the DNS protocols itself. Do not
confuse this with the ability to manage the authorization associated
with the management protocol itself, which is discussed later in
Section 4.4. There are a number of authorization settings that are
used by a name server. Example authorization settings that the
solution might need to cover are:
o Access to operations on zone data (e.g., DDNS)
o Access to certain zone data from certain sources (e.g., from
particular network subnets)
o Access to specific DNS protocol services (e.g., recursive service)
Note: the above list is expected to be used as a collection of
examples and is not a complete list of needed authorization
protections.
3.3. Monitoring Requirements
Monitoring is the process of collecting aspects of the internal state
of a name server at a given moment in time. The solution MUST be
able to monitor the health of a name server to determine its
operational status, load, and other internal attributes. Example
parameters that the solution might need to collect and analyze are:
o Number of requests sent, responses sent, number of errors, average
response latency, and other performance counters
o Server status (e.g., "serving data", "starting up", "shutting
down", etc.)
o Access control violations
o List of zones being served
o Detailed statistics about clients interacting with the name server
(e.g., top 10 clients requesting data).
Note: the above list is expected to be used as a collection of
examples and is not a complete list of needed monitoring operations.
In particular, some monitoring statistics are expected to be
computationally or resource expensive and are considered to be "nice
to have" as opposed to "necessary to have".
Hardaker Informational [Page 10]
RFC 6168 Name Server Management Requirements May 2011
3.4. Alarm and Event Requirements
Events occurring at the name server that trigger alarm notifications
can quickly inform a management station about critical issues. A
management solution SHOULD include support for delivery of alarm
conditions.
Example alarm conditions might include:
o The server's status is changing (e.g., it is starting up,
reloading configuration, restarting or shutting down).
o A needed resource (e.g., memory or disk space) is exhausted or
nearing exhaustion.
o An authorization violation was detected.
o The server has not received any data traffic (e.g., DNS requests
or NOTIFYs) recently (aka the "lonely warning"). This condition
might indicate a problem with the server's deployment.
o The number of errors has exceeded a configured threshold.
4. Security Requirements
The management solution will need to be appropriately secured against
attacks on the management infrastructure.
4.1. Authentication
The solution MUST support mutual authentication. The management
client needs to be assured that the management operations are being
transferred to and from the correct name server. The managed name
server needs to authenticate the system that is accessing the
management infrastructure within itself.
4.2. Integrity Protection
Management operations MUST be protected from modification while in
transit from the management client to the server.
4.3. Confidentiality
The management solution MUST support message confidentiality. The
potential transfer of sensitive configuration is expected (such as
TSIG keys or security policies). The solution does not, however,
necessarily need to provide confidentiality to data that would
normally be carried without confidentiality by the DNS system itself.
Hardaker Informational [Page 11]
RFC 6168 Name Server Management Requirements May 2011
4.4. Authorization
The solution SHOULD provide an authorization model capable of
selectively authorizing individual management requests for any
management protocols it introduces to the completed system. This
authorization differs from the authorization previously discussed in
Section 3.2.5 in that this requirement is concerned solely with
authorization of the management system itself.
There are a number of authorization settings that might be used by a
managed system to determine whether the managing entity has
authorization to perform the given management task. Example
authorization settings that the solution might need to cover are:
o Access to the configuration that specifies which zones are to be
served
o Access to the management system infrastructure
o Access to other control operations
o Access to other configuration operations
o Access to monitoring operations
Note: the above list is expected to be used as a collection of
examples and is not a complete list of needed authorization
protections.
4.5. Solution Impacts on Security
The solution MUST minimize the security risks introduced to the
complete name server system. It is impossible to add new
infrastructure to a server and not impact the security in some
fashion as the introduction of a management protocol alone will
provide a new avenue for potential attack. Although the added
management benefits will be worth the increased risks, the solution
still needs to minimize this impact as much as possible.
5. Other Requirements
5.1. Extensibility
The management solution is expected to change and expand over time as
lessons are learned and new DNS features are deployed. Thus, the
solution MUST be flexible and able to accommodate new future
management operations. The solution might, for example, make use of
protocol versioning or capability description exchanges to ensure
Hardaker Informational [Page 12]
RFC 6168 Name Server Management Requirements May 2011
that management stations and name servers that weren't written to the
same specification version can still interoperate to the best of
their combined ability.
5.1.1. Vendor Extensions
It MUST be possible for vendors to extend the standardized management
model with vendor-specific extensions to support additional features
offered by their products.
5.1.2. Extension Identification
It MUST be possible for a management station to understand which
parts of returned data are specific to a given vendor or other
standardized extension. The data returned needs to be appropriately
marked, through the use of name spaces or similar mechanisms, to
ensure that the base management model data can be logically separated
from the extension data without needing to understand the extension
data itself.
5.1.3. Name-Space Collision Protection
It MUST be possible to protect against multiple extensions
conflicting with each other. The use of name-space protection
mechanisms for communicated management variables is common practice
to protect against such problems. Name-space identification
techniques also frequently solve the "Extension Identification"
requirement discussed in Section 5.1.2.
6. Security Considerations
Any management protocol for which conformance to this document is
claimed needs to fully support the criteria discussed in Section 4 in
order to protect the management infrastructure itself. The DNS is a
core Internet service, and management traffic that protects it could
be the target of attacks designed to subvert that service. Because
the management infrastructure will be adding additional interfaces to
that service, it is critical that the management infrastructure
support adequate protections against network attacks.
7. Document History
A requirement-gathering discussion was held at the December 2007 IETF
meeting in Vancouver, BC, Canada, and a follow-up meeting was held at
the March 2008 IETF meeting in Philadelphia. This document is a
compilation of the results of those discussions as well as
discussions on the DCOMA mailing list.
Hardaker Informational [Page 13]
RFC 6168 Name Server Management Requirements May 2011
8. Acknowledgments
This document is the result of discussions within the DCOMA design
team chaired by Jaap Akkerhuis. This team consisted of a large
number of people, all of whom provided valuable insight and input
into the discussions surrounding name server management. The text of
this document was written from notes taken during meetings as well as
from contributions sent to the DCOMA mailing list. This work
documents the consensus of the DCOMA design team.
In particular, the following team members contributed significantly
to the text in the document:
Stephane Bortzmeyer
Stephen Morris
Phil Regnauld
Further editing contributions and wording suggestions were made by
Alfred Hoenes and Doug Barton.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Hardaker Informational [Page 14]
RFC 6168 Name Server Management Requirements May 2011
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010.
9.2. Informative References
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
RFC 1611, May 1994.
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
RFC 1612, May 1994.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.
[RFC3197] Austein, R., "Applicability Statement for DNS MIB
Extensions", RFC 3197, November 2001.
Hardaker Informational [Page 15]
RFC 6168 Name Server Management Requirements May 2011
Appendix A. Deployment Scenarios
This appendix documents some additional deployment scenarios that
have been traditionally difficult to manage. They are provided as
guidance to protocol developers as data points of real-world name
server management problems.
A.1. Non-Standard Zones
If an organization uses non-standard zones (for example a purely
local TLD), synchronizing all the name servers for these zones is
usually a time-consuming task. It is made worse when two
organizations with conflicting zones merge. This situation is not a
recommended deployment scenario (and is even heavily discouraged),
but it is, unfortunately, seen in the wild.
It is typically implemented using "forwarding" zones. But there is
no way to ensure automatically that all the resolvers have the same
set of zones to forward at any given time. New zones might be added
to a local forwarding recursive server, for example, without
modifying the rest of the deployed forwarding servers. It is hoped
that a management solution that could handle the configuration of
zone forwarding would finally allow management of servers deployed in
this fashion.
A.2. Redundancy Sharing
For reliability reasons, it is recommended that zone operators follow
the guidelines documented in [RFC2182], which recommends that
multiple name servers be configured for each zone and that the name
servers be separated both physically and via connectivity routes. A
common solution is to establish DNS-serving partnerships: "I'll host
your zones and you'll host mine". Both entities benefit from
increased DNS reliability via the wider service distribution. This
frequently occurs between cooperating but otherwise unrelated
entities (such as between two distinct companies) as well as between
affiliated organizations (such as between branch offices within a
single company).
The configuration of these relationships are currently required to be
manually configured and maintained. Changes to the list of zones
that are cross-hosted are manually negotiated between the cooperating
network administrators and configured by hand. A management protocol
with the ability to provide selective authorization, as discussed in
Section 4.4, would solve many of the management difficulties between
cooperating organizations.
Hardaker Informational [Page 16]
RFC 6168 Name Server Management Requirements May 2011
A.3. DNSSEC Management
There are many different DNSSEC deployment strategies that may be
used for mission-critical zones. The following list describes some
example deployment scenarios that might warrant different management
strategies.
All contents and DNSSEC keying information controlled and operated
by a single organization
Zone contents controlled and operated by one organization, all
DNSSEC keying information controlled and operated by a second
organization.
Zone contents controlled and operated by one organization, zone
signing keys (ZSKs) controlled and operated by a second
organization, and key signing keys (KSKs) controlled and operated
by a third organization.
Although this list is not exhaustive in the potential ways that zone
data can be divided up, it should be sufficient to illustrate the
potential ways in which zone data can be controlled by multiple
entities.
The end result of all of these strategies, however, will be the same:
a live zone containing DNSSEC-related resource records. Many of the
above strategies are merely different ways of preparing a zone for
serving. A management solution that includes support for managing
DNSSEC zone data may wish to take into account these potential
management scenarios.
Author's Address
Wes Hardaker
Sparta, Inc.
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net
Hardaker Informational [Page 17]

1235
doc/rfc/rfc6672.txt Normal file
View file

File diff suppressed because it is too large Load diff

2075
doc/rfc/rfc6698.txt Normal file
View file

File diff suppressed because it is too large Load diff

1179
doc/rfc/rfc6840.txt Normal file
View file

File diff suppressed because it is too large Load diff

899
doc/rfc/rfc6891.txt Normal file
View file

@ -0,0 +1,899 @@
Internet Engineering Task Force (IETF) J. Damas
Request for Comments: 6891 Bond Internet Systems
STD: 75 M. Graff
Obsoletes: 2671, 2673
Category: Standards Track P. Vixie
ISSN: 2070-1721 Internet Systems Consortium
April 2013
Extension Mechanisms for DNS (EDNS(0))
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 Extension Mechanisms for DNS (EDNS(0))
specification (and obsoletes RFC 2671) based on feedback from
deployment experience in several implementations. It also obsoletes
RFC 2673 ("Binary Labels in the Domain Name System") and adds
considerations on the use of extended labels in the DNS.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6891.
Damas, et al. Standards Track [Page 1]
RFC 6891 EDNS(0) Extensions April 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
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.
Damas, et al. Standards Track [Page 2]
RFC 6891 EDNS(0) Extensions April 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5
4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11
6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16
Damas, et al. Standards Track [Page 3]
RFC 6891 EDNS(0) Extensions April 2013
1. Introduction
DNS [RFC1035] specifies a message format, and within such messages
there are standard formats for encoding options, errors, and name
compression. The maximum allowable size of a DNS message over UDP
not using the extensions described in this document is 512 bytes.
Many of DNS's protocol limits, such as the maximum message size over
UDP, are too small to efficiently support the additional information
that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS
Security (DNSSEC) signatures). Finally, RFC 1035 does not define any
way for implementations to advertise their capabilities to any of the
other actors they interact with.
[RFC2671] added extension mechanisms to DNS. These mechanisms are
widely supported, and a number of new DNS uses and protocol
extensions depend on the presence of these extensions. This memo
refines and obsoletes [RFC2671].
Unextended agents will not know how to interpret the protocol
extensions defined in [RFC2671] and restated here. Extended agents
need to be prepared for handling the interactions with unextended
clients in the face of new protocol elements and fall back gracefully
to unextended DNS.
EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
negotiated between each pair of hosts in a DNS resolution process,
for instance, the stub resolver communicating with the recursive
resolver or the recursive resolver communicating with an
authoritative server.
[RFC2671] specified extended label types. The only such label
proposed was in [RFC2673] for a label type called "Bit-String Label"
or "Binary Labels", with this latest term being the one in common
use. For various reasons, introducing a new label type was found to
be extremely difficult, and [RFC2673] was moved to Experimental.
This document obsoletes [RFC2673], deprecating Binary Labels.
Extended labels remain defined, but their use is discouraged due to
practical difficulties with deployment; their use in the future
SHOULD only be considered after careful evaluation of the deployment
hindrances.
2. Terminology
"Requestor" refers to the side that sends a request. "Responder"
refers to an authoritative, recursive resolver or other DNS component
that responds to questions. Other terminology is used here as
defined in the RFCs cited by this document.
Damas, et al. Standards Track [Page 4]
RFC 6891 EDNS(0) Extensions April 2013
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. EDNS Support Requirement
EDNS provides a mechanism to improve the scalability of DNS as its
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
specified in RFC 1035 as well as providing extra data space for
additional flags and return codes (RCODEs). However, implementation
experience indicates that adding new RCODEs should be avoided due to
the difficulty in upgrading the installed base. Flags SHOULD be used
only when necessary for DNS resolution to function.
For many uses, an EDNS Option Code may be preferred.
Over time, some applications of DNS have made EDNS a requirement for
their deployment. For instance, DNSSEC uses the additional flag
space introduced in EDNS to signal the request to include DNSSEC data
in a DNS response.
Given the increase in DNS response sizes when including larger data
items such as AAAA records, DNSSEC information (e.g., RRSIG or
DNSKEY), or large TXT records, the additional UDP payload
capabilities provided by EDNS can help improve the scalability of the
DNS by avoiding widespread use of TCP for DNS transport.
4. DNS Message Changes
4.1. Message Header
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 Section
4.1.1 of [RFC1035]). Some of these flag values were marked for
future use, and most of these have since been allocated. Also, most
of the RCODE values are now in use. The OPT pseudo-RR specified
below contains extensions to the RCODE bit field as well as
additional flag bits.
4.2. Label Types
The first 2 bits of a wire format domain label are used to denote the
type of the label. [RFC1035] allocates 2 of the 4 possible types and
reserves the other 2. More label types were defined in [RFC2671].
The use of the 2-bit combination defined by [RFC2671] to identify
extended label types remains valid. However, it has been found that
deployment of new label types is noticeably difficult and so is only
Damas, et al. Standards Track [Page 5]
RFC 6891 EDNS(0) Extensions April 2013
recommended after careful evaluation of alternatives and the need for
deployment.
4.3. UDP Message Size
Traditional DNS messages are limited to 512 octets in size when sent
over UDP [RFC1035]. Fitting the increasing amounts of data that can
be transported in DNS in this 512-byte limit is becoming more
difficult. For instance, inclusion of DNSSEC records frequently
requires a much larger response than a 512-byte message can hold.
EDNS(0) specifies a way to advertise additional features such as
larger response size capability, which is intended to help avoid
truncated UDP responses, which in turn cause retry over TCP. It
therefore provides support for transporting these larger packet sizes
without needing to resort to TCP for transport.
5. Extended Label Types
The first octet in the on-the-wire representation of a DNS label
specifies the label type; the basic DNS specification [RFC1035]
dedicates the 2 most significant bits of that octet for this purpose.
[RFC2671] defined DNS label type 0b01 for use as an indication for
extended label types. A specific extended label type was selected by
the 6 least significant bits of the first octet. Thus, extended
label types were indicated by the values 64-127 (0b01xxxxxx) in the
first octet of the label.
Extended label types are extremely difficult to deploy due to lack of
support in clients and intermediate gateways, as described in
[RFC3363], which moved [RFC2673] to Experimental status; and
[RFC3364], which describes the pros and cons. As such, proposals
that contemplate extended labels SHOULD weigh this deployment cost
against the possibility of implementing functionality in other ways.
Finally, implementations MUST NOT generate or pass Binary Labels in
their communications, as they are now deprecated.
6. The OPT Pseudo-RR
6.1. OPT Record Definition
6.1.1. Basic Elements
An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
additional data section of a request.
Damas, et al. Standards Track [Page 6]
RFC 6891 EDNS(0) Extensions April 2013
The OPT RR has RR type 41.
If an OPT record is present in a received request, compliant
responders MUST include an OPT record in their respective responses.
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.
When an OPT RR is included within any DNS message, it MUST be the
only OPT RR in that message. If a query message with more than one
OPT RR is received, a FORMERR (RCODE=1) MUST be returned. The
placement flexibility for the OPT RR does not override the need for
the TSIG or SIG(0) RRs to be the last in the additional section
whenever they are present.
6.1.2. Wire Format
An OPT RR has a fixed part and a variable set of options expressed as
{attribute, value} pairs. The fixed part holds some DNS metadata,
and also a small collection of basic extension elements that we
expect to be so popular that it would be a waste of wire space to
encode them as {attribute, value} pairs.
The fixed part of an OPT RR is structured as follows:
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
OPT RR Format
Damas, et al. Standards Track [Page 7]
RFC 6891 EDNS(0) Extensions April 2013
The variable part of an OPT RR may contain zero or more options in
the RDATA. Each option MUST be treated as a bit field. Each option
is encoded as:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE
Assigned by the Expert Review process as defined by the DNSEXT
working group and the IESG.
OPTION-LENGTH
Size (in octets) of OPTION-DATA.
OPTION-DATA
Varies per OPTION-CODE. MUST be treated as a bit field.
The order of appearance of option tuples is not defined. If one
option modifies the behaviour of another or multiple options are
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
MUST be ignored. Specifications of such options might wish to
include some kind of signaled acknowledgement. For example, an
option specification might say that if a responder sees and supports
option XYZ, it MUST include option XYZ in its response.
Damas, et al. Standards Track [Page 8]
RFC 6891 EDNS(0) Extensions April 2013
6.1.3. OPT Record TTL Field Use
The extended RCODE and flags, which OPT stores in the RR Time to Live
(TTL) field, are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE
Forms the upper 8 bits of extended 12-bit RCODE (together with the
4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0
indicates that an unextended RCODE is in use (values 0 through
15).
VERSION
Indicates the implementation level of the setter. 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 minimise the
responder and network load of discovering the greatest common
implementation level between requestor and responder. A
requestor's version numbering strategy MAY ideally be a run-time
configuration option.
If a responder does not implement the VERSION level of the
request, then it MUST respond with RCODE=BADVERS. All responses
MUST be limited in format to the VERSION level of the request, but
the VERSION of each response SHOULD be the highest implementation
level of the responder. In this way, a requestor will learn the
implementation level of a responder as a side effect of every
response, including error responses and including RCODE=BADVERS.
6.1.4. Flags
DO
DNSSEC OK bit as defined by [RFC3225].
Z
Set to zero by senders and ignored by receivers, unless modified
in a subsequent specification.
Damas, et al. Standards Track [Page 9]
RFC 6891 EDNS(0) Extensions April 2013
6.2. Behaviour
6.2.1. Cache Behaviour
The OPT record MUST NOT be cached.
6.2.2. Fallback
If a requestor detects that the remote end does not support EDNS(0),
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 or any future option using EDNS is
required, no fallback should be performed, as these options are only
signaled through EDNS. If an implementation detects that some
servers for the zone support EDNS(0) while others would force the use
of TCP to fetch all data, preference MAY be given to servers that
support EDNS(0). Implementers SHOULD analyse this choice and the
impact on both endpoints.
6.2.3. Requestor's Payload Size
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
reassembled and delivered in the requestor's network stack. Note
that path MTU, with or without fragmentation, could be smaller than
this.
Values lower than 512 MUST be treated as equal to 512.
The requestor SHOULD place a value in this field that it can actually
receive. For example, if a requestor sits behind a firewall that
will block fragmented IP packets, a requestor SHOULD NOT choose a
value that will cause fragmentation. Doing so will prevent large
responses from being received and can cause fallback to occur. This
knowledge may be auto-detected by the implementation or provided by a
human administrator.
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
Ethernet would be reasonable.
Where fragmentation is not a concern, use of bigger values SHOULD be
considered by implementers. Implementations SHOULD use their largest
configured or implemented values as a starting point in an EDNS
transaction in the absence of previous knowledge about the
destination server.
Damas, et al. Standards Track [Page 10]
RFC 6891 EDNS(0) Extensions April 2013
Choosing a very large value will guarantee fragmentation at the IP
layer, and may prevent answers from being received due to loss of a
single fragment or to misconfigured firewalls.
The requestor's maximum payload size can change over time. It MUST
NOT be cached for use beyond the transaction in which it is
advertised.
6.2.4. Responder's Payload Size
The responder's maximum payload size can change over time but can
reasonably be expected to remain constant between two closely spaced
sequential transactions, for example, an arbitrary QUERY used as a
probe to discover a responder's maximum UDP payload size, followed
immediately by an UPDATE that takes advantage of this size. This is
considered preferable 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-byte payload size limit.
6.2.5. Payload Size Selection
Due to transaction overhead, it is not recommended to advertise an
architectural limit as a maximum UDP payload size. Even on system
stacks capable of reassembling 64 KB datagrams, memory usage at low
levels in the system will be a concern. A good compromise may be the
use of an EDNS maximum payload size of 4096 octets as a starting
point.
A requestor MAY choose to implement a fallback to smaller advertised
sizes to work around firewall or other network limitations. A
requestor SHOULD choose to use a fallback mechanism that begins with
a large size, such as 4096. If that fails, a fallback around the
range of 1280-1410 bytes SHOULD be tried, as it has a reasonable
chance to fit within a single Ethernet frame. Failing that, a
requestor MAY choose a 512-byte packet, which with large answers may
cause a TCP retry.
Values of less than 512 bytes MUST be treated as equal to 512 bytes.
6.2.6. Support in Middleboxes
In a network that carries DNS traffic, there could be active
equipment other than that participating directly in the DNS
resolution process (stub and caching resolvers, authoritative
servers) that affects the transmission of DNS messages (e.g.,
firewalls, load balancers, proxies, etc.), referred to here as
"middleboxes".
Damas, et al. Standards Track [Page 11]
RFC 6891 EDNS(0) Extensions April 2013
Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
bytes.
Middleboxes that simply forward requests to a recursive resolver MUST
NOT modify and MUST NOT delete the OPT record contents in either
direction.
Middleboxes that have additional functionality, such as answering
queries or acting as intelligent forwarders, SHOULD be able to
process the OPT record and act based on its contents. These
middleboxes MUST consider the incoming request and any outgoing
requests as separate transactions if the characteristics of the
messages are different.
A more in-depth discussion of this type of equipment and other
considerations regarding their interaction with DNS traffic is found
in [RFC5625].
7. Transport Considerations
The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS and can correctly understand any response that conforms to that
feature's specification.
Lack of presence of an OPT record in a request MUST be taken as an
indication that the requestor does not implement any part of this
specification and that the responder MUST NOT include an OPT record
in its response.
Extended agents MUST be prepared for handling interactions with
unextended clients in the face of new protocol elements and fall back
gracefully to unextended DNS when needed.
Responders that choose not to implement the protocol extensions
defined in this document MUST respond with a return code (RCODE) of
FORMERR to messages containing an OPT record in the additional
section and MUST NOT include an OPT record in the response.
If there is a problem with processing the OPT record itself, such as
an option value that is badly formatted or that includes out-of-range
values, a FORMERR MUST be returned. If this occurs, the response
MUST include an OPT record. This is intended to allow the requestor
to distinguish between servers that do not implement EDNS and format
errors within EDNS.
Damas, et al. Standards Track [Page 12]
RFC 6891 EDNS(0) Extensions April 2013
The minimal response MUST be the DNS header, question section, and an
OPT record. This MUST also occur when a truncated response (using
the DNS header's TC bit) is returned.
8. Security Considerations
Requestor-side specification of the maximum buffer size may open a
DNS denial-of-service attack if responders can be made to send
messages that are too large for intermediate gateways to forward,
thus leading to potential ICMP storms between gateways and
responders.
Announcing very large UDP buffer sizes may result in dropping of DNS
messages by middleboxes (see Section 6.2.6). This could cause
retransmissions with no hope of success. Some devices have been
found to reject fragmented UDP packets.
Announcing UDP buffer sizes that are too small may result in fallback
to TCP with a corresponding load impact on DNS servers. This is
especially important with DNSSEC, where answers are much larger.
9. IANA Considerations
The IANA has assigned RR type code 41 for OPT.
[RFC2671] specified a number of IANA subregistries within "DOMAIN
NAME SYSTEM PARAMETERS":
o DNS EDNS(0) Options
o EDNS Version Number
o EDNS Header Flags
Additionally, two entries were generated in existing registries:
o EDNS Extended Label Type in the DNS Label Types registry
o Bad OPT Version in the DNS RCODES registry
IANA has updated references to [RFC2671] in these entries and
subregistries to this document.
[RFC2671] created the DNS Label Types registry. This registry is to
remain open.
The registration procedure for the DNS Label Types registry is
Standards Action.
Damas, et al. Standards Track [Page 13]
RFC 6891 EDNS(0) Extensions April 2013
This document assigns option code 65535 in the DNS EDNS0 Options
registry to "Reserved for future expansion".
The current status of the IANA registry for EDNS Option Codes at the
time of publication of this document is
o 0-4 assigned, per references in the registry
o 5-65000 Available for assignment, unassigned
o 65001-65534 Local/Experimental use
o 65535 Reserved for future expansion
[RFC2671] expands the RCODE space from 4 bits to 12 bits. This
allows more than the 16 distinct RCODE values allowed in [RFC1035].
IETF Review is required to add a new RCODE.
This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS
RCODES registry.
[RFC2671] called for the recording of assignment of extended label
types 0bxx111111 as "Reserved for future extended label types"; the
IANA registry currently contains "Reserved for future expansion".
This request implied, at that time, a request to open a new registry
for extended label types, but due to the possibility of ambiguity,
new text registrations were instead made within the general DNS Label
Types registry, which also registers entries originally defined by
[RFC1035]. There is therefore no Extended Label Types registry, with
all label types registered in the DNS Label Types registry.
This document deprecates Binary Labels. Therefore, the status for
the DNS Label Types registration "Binary Labels" is now "Historic".
IETF Standards Action is required for assignments of new EDNS(0)
flags. Flags SHOULD be used only when necessary for DNS resolution
to function. For many uses, an EDNS Option Code may be preferred.
IETF Standards Action is required to create new entries in the EDNS
Version Number registry. Within the EDNS Option Code space, Expert
Review is required for allocation of an EDNS Option Code. Per this
document, IANA maintains a registry for the EDNS Option Code space.
Damas, et al. Standards Track [Page 14]
RFC 6891 EDNS(0) Extensions April 2013
9.1. OPT Option Code Allocation Procedure
OPT Option Codes are assigned by Expert Review.
Assignment of Option Codes should be liberal, but duplicate
functionality is to be avoided.
10. References
10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
10.2. Informative References
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
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)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
Damas, et al. Standards Track [Page 15]
RFC 6891 EDNS(0) Extensions April 2013
Appendix A. Changes since RFCs 2671 and 2673
Following is a list of high-level changes to RFCs 2671 and 2673.
o Support for the OPT record is now mandatory.
o Extended label types remain available, but their use is
discouraged as a general solution due to observed difficulties in
their deployment on the Internet, as illustrated by the work with
the "Binary Labels" type.
o RFC 2673, which defined the "Binary Labels" type and is currently
Experimental, is requested to be moved to Historic.
o Made changes in how EDNS buffer sizes are selected, and provided
recommendations on how to select them.
Authors' Addresses
Joao Damas
Bond Internet Systems
Av Albufera 14
S.S. Reyes, Madrid 28701
ES
Phone: +1 650.423.1312
EMail: joao@bondis.org
Michael Graff
EMail: explorer@flame.org
Paul Vixie
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063
US
Phone: +1 650.423.1301
EMail: vixie@isc.org
Damas, et al. Standards Track [Page 16]