upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-11 00:09:59 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

[v9_9] updated published drafts

Browse source
This commit is contained in:
Evan Hunt 2014-02-14 08:54:25 -08:00
parent 3231fac2d5
commit 547fe6d764
28 changed files with 10213 additions and 9913 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1375
doc/draft/draft-faltstrom-uri-06.txt → doc/draft/draft-faltstrom-uri-08.txt
View file

File diff suppressed because it is too large Load diff

1009
doc/draft/draft-ietf-behave-address-format-07.txt
View file

File diff suppressed because it is too large Load diff

7
doc/draft/draft-ietf-dane-protocol-19.txt
View file

@ -1,7 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.ietf.org/id/draft-ietf-dane-protocol-19.txt">here</a>.</p>
</body></html>

504
doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
View file

@ -1,504 +0,0 @@
DNSEXT R. Bellis
Internet-Draft Nominet UK
Updates: 1035, 1123 March 22, 2010
(if approved)
Intended status: Standards Track
Expires: September 23, 2010
DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsext-dns-tcp-requirements-03
Abstract
This document updates the requirements for the support of TCP as a
transport protocol for DNS implementations.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 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
Bellis Expires September 23, 2010 [Page 1]
Internet-Draft DNS over TCP March 2010
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 BSD License.
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 re-ordering . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Bellis Expires September 23, 2010 [Page 2]
Internet-Draft DNS over TCP March 2010
1. Introduction
Most DNS [RFC1035] 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
blocking of DNS over TCP at the network layer) may result in
resolution failure and/or application-level timeouts.
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 (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:
Bellis Expires September 23, 2010 [Page 3]
Internet-Draft DNS over TCP March 2010
... 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 DNSSEC [RFC4033] have shown that truncation
at the 512 byte boundary is now commonplace. For example an NXDOMAIN
(RCODE == 3) response from a DNSSEC signed zone using 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].
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 which 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.
Bellis Expires September 23, 2010 [Page 4]
Internet-Draft DNS over TCP March 2010
o Recursive resolver (or forwarder) implementations MUST support TCP
so that the 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.
An exception may be made for proprietary stub resolver
implementations. These MAY omit support for TCP if operating in an
environment where truncation can never occur, or where DNS lookup
failure is acceptable should truncation occur.
Regarding the choice of when to use UDP or TCP, RFC 1123 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.
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.
This document therefore RECOMMENDS that the default application-level
idle period should be of the order of seconds, but does not specify
any particular value. In practise the idle period may vary
dynamically, and servers MAY allow dormant connections to remain open
for longer periods as resources permit.
Bellis Expires September 23, 2010 [Page 5]
Internet-Draft DNS over TCP March 2010
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 re-ordering
RFC 1035 is ambiguous on the question of whether TCP queries may be
re-ordered - 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 which arrive in a
different order to that in which the requests were sent, regardless
of the transport protocol in use.
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 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
Bellis Expires September 23, 2010 [Page 6]
Internet-Draft DNS over TCP March 2010
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. IANA Considerations
This document requests no IANA actions.
9. 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, Jim Reid, Paul Vixie and Nicholas Weaver.
10. References
10.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.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[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.
10.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
Bellis Expires September 23, 2010 [Page 7]
Internet-Draft DNS over TCP March 2010
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.
Appendix A. Change Log
NB: to be removed by the RFC Editor before publication.
draft-ietf-dnsext-dns-tcp-requirements-03
Editorial nits from WGLC
Clarification on "general purpose"
Fixed ref to UDP (RFC 768)
Included more S.4.2.2 text from RFC 1035 and removed some from
this draft relating to connection resets.
s/long/large/ for packet sizes
draft-ietf-dnsext-dns-tcp-requirements-02
Change of title - more focus on implementation and not operation
Re-write of some of the security section
Added recommendation for minimal concurrent connections
Minor editorial nits from Alfred Hoenes
draft-ietf-dnsext-dns-tcp-requirements-01
Addition of response ordering section
Various minor editorial changes from WG reviewers
draft-ietf-dnsext-dns-tcp-requirements-00
Initial draft
Bellis Expires September 23, 2010 [Page 8]
Internet-Draft DNS over TCP March 2010
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 Expires September 23, 2010 [Page 9]

448
doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt
View file

@ -1,448 +0,0 @@
DNS Extensions Working Group S. Rose
Internet-Draft NIST
Updates: 2536, 2539, 3110, 4034, August 11, 2010
4398, 5155, 5702, 5933
(if approved)
Intended status: Standards Track
Expires: February 12, 2011
Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
Registry
draft-ietf-dnsext-dnssec-registry-fixes-06
Abstract
The DNS Security Extensions (DNSSEC) requires the use of
cryptographic algorithm suites for generating digital signatures over
DNS data. There is currently an IANA registry for these algorithms
that is incomplete in that it lacks the implementation status of each
algorithm. This document provides an applicability statement on
algorithm status for DNSSEC implementations. This document replaces
that registry table with a new IANA registry table for Domain Name
System Security (DNSSEC) Algorithm Numbers which lists each
algorithm's status based on the current reference. If that status is
not defined in the original specification, this document assigns a
status.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Rose Expires February 12, 2011 [Page 1]
Internet-Draft IANA Registry Fixes August 2010
This Internet-Draft will expire on February 12, 2011.
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
2.1. Individual Changes . . . . . . . . . . . . . . . . . . . . 3
2.2. Domain Name System (DNS) Security Algorithm Number
Registry Table . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Specifying New Algorithms and Updating Status of
Existing Entries . . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Rose Expires February 12, 2011 [Page 2]
Internet-Draft IANA Registry Fixes August 2010
1. Introduction
The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
[RFC4034], and [RFC4035] uses digital signatures over DNS data to
provide source authentication and integrity protection. DNSSEC uses
an IANA registry to allocate codes for digital signature algorithms
(consisting of a cryptographic algorithm and one-way hash function).
The original list of algorithm status is found in [RFC4034]. Other
DNSSEC documents have added new algorithms or changed the status of
algorithms in the registry. However, currently implementors must
read through all the documents in order to discover the current
status of each algorithm in the registry.
This document replaces the current IANA registry for Domain Name
System Security (DNSSEC) Algorithm Numbers with a newly defined
registry table. This new table (Section 2.2 below) contains a column
that will list the current status of each digital signature algorithm
in the registry at the time of writing and assigns status for some
algorithms used with DNSSEC that did not have an identified status in
their specification. This document updates the following: [RFC2536],
[RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
[RFC5933].
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. The DNS Security Algorithm Number Subregistry
The DNS Security Algorithm Number subregistry (part of the Domain
Name System (DNS) Security Number registry) will be replaced with the
table below. This table contains a column that contains the current
implementation requirements of the given algorithm.
There are additional differences to entries that are described in
sub-section 2.1. The overall new registry table is in sub-section
2.2. The values for the status were obtained from [RFC4034] with
updates for algorithms specified after the original DNSSEC
specification. If no status was listed in the original
specification, this document assigns one.
2.1. Individual Changes
This document changes three entries in the Domain Name System
Security (DNSSEC) Algorithm Registry. They are:
Rose Expires February 12, 2011 [Page 3]
Internet-Draft IANA Registry Fixes August 2010
The description for assignment number 4 is changed to "Reserved until
2020".
The description for assignment number 9 is changed to "Reserved until
2020".
The description for assignment number 11 is changed to "Reserved
until 2020".
Registry entries 13-251 remains Unassigned.
The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
RECOMMENDED and OPTIONAL respectively. The difference is due to the
fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL. The
status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
believed that these algorithms will replace older algorithms (e.g.
RSA/SHA-1) that have a perceived weakness in their hash algorithm
(SHA-1).
Rose Expires February 12, 2011 [Page 4]
Internet-Draft IANA Registry Fixes August 2010
2.2. Domain Name System (DNS) Security Algorithm Number Registry Table
The Domain Name System (DNS) Security Algorithm Number registry is
hereby specified as follows:
Zone Transaction
Number Description Mnemonic Sign Sign Status Reference
------ ----------- ------ ---- ----- ------------ ---------
0 Reserved [RFC4398]
1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC4034],
IMPLEMENT [RFC3110]
(this memo)
2 Diffie-Hellman DH N Y [RFC2539]
(this memo)
3 DSA/SHA-1 DSASHA1 Y Y [RFC2536],
[RFC4034],
FIPS 186-3,
FIPS 180-3
(this memo)
4 Reserved until ECC (this memo)
2020
5 RSA/SHA-1 RSASHA1 Y Y REQUIRED [RFC4034]
(this memo)
6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155]
-SHA1 (this memo)
7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155]
-SHA1 NSEC3- (this memo)
SHA1
8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702]
(this memo)
9 Reserved until (this memo)
2020
10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702]
(this memo)
11 Reserved until (this memo)
2020
12 GOST R GOST-ECC Y * [RFC5933]
34.10-2001 (this memo)
13-251 Unassigned
252 Reserved for INDIRECT N N [RFC4034]
Indirect keys (this memo)
253 private PRIVATE Y Y [RFC4034]
algorithm (this memo)
254 private PRIVATEOID Y Y [RFC4034]
algorithm OID (this memo)
255 Reserved
Rose Expires February 12, 2011 [Page 5]
Internet-Draft IANA Registry Fixes August 2010
2.3. Specifying New Algorithms and Updating Status of Existing Entries
[I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
procedure for obtaining an algorithm number for new algorithms other
than a standards track document. Algorithms entered into the
registry using that procedure do not have a listed status.
Specifications that follow this path do not need to obsolete or
update this document.
Adding a newly specified algorithm to the registry with a status
SHALL entail obsoleting this document and replacing the registry
table (with the new algorithm entry). Altering the status column
value of any existing algorithm in the registry SHALL entail
obsoleting this document and replacing the registry table.
This document cannot be updated, only made obsolete and replaced by a
successor document.
3. IANA Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. The new registry table is in Section
2.2.
The original Domain Name System (DNS) Security Algorithm Number
registry is available at http://www.iana.org/assignments/
dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
4. Security Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. It is not meant to be a discussion on
algorithm superiority. No new security considerations are raised in
this document.
5. References
5.1. Normative References
[I-D.ietf-dnsext-dnssec-alg-allocation] Hoffman, P., "Cryptographic
Algorithm Identifier
Allocation for DNSSEC", draf
t-ietf-dnsext-dnssec-alg-
allocation-03 (work in
progress), March 2010.
[RFC2119] Bradner, S., "Key words for
use in RFCs to Indicate
Rose Expires February 12, 2011 [Page 6]
Internet-Draft IANA Registry Fixes August 2010
Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC2536] Eastlake, D., "DSA KEYs and
SIGs in the Domain Name
System (DNS)", RFC 2536,
March 1999.
[RFC2539] Eastlake, D., "Storage of
Diffie-Hellman Keys in the
Domain Name System (DNS)",
RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1
SIGs and RSA KEYs in the
Domain Name System (DNS)",
RFC 3110, May 2001.
[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.
[RFC4398] Josefsson, S., "Storing
Certificates in the Domain
Name System (DNS)",
RFC 4398, March 2006.
[RFC5155] Laurie, B., Sisson, G.,
Arends, R., and D. Blacka,
"DNS Security (DNSSEC)
Hashed Authenticated Denial
Rose Expires February 12, 2011 [Page 7]
Internet-Draft IANA Registry Fixes August 2010
of Existence", RFC 5155,
March 2008.
[RFC5702] Jansen, J., "Use of SHA-2
Algorithms with RSA in
DNSKEY and RRSIG Resource
Records for DNSSEC",
RFC 5702, October 2009.
[RFC5933] Dolmatov, V., Chuprina, A.,
and I. Ustinov, "Use of GOST
Signature Algorithms in
DNSKEY and RRSIG Resource
Records for DNSSEC",
RFC 5933, July 2010.
5.2. Informative References
[FIPS.180-3.2008] National Institute of
Standards and Technology,
"Secure Hash Standard",
FIPS PUB 180-3,
October 2008, <http://
csrc.nist.gov/publications/
fips/fips180-3/
fips180-3.pdf>.
[FIPS.186-3.2009] National Institute of
Standards and Technology,
"Digital Signature
Standard", FIPS PUB 186-3,
June 2009, <http://
csrc.nist.gov/publications/
fips/fips186-3/
fips_186-3.pdf>.
Author's Address
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
Rose Expires February 12, 2011 [Page 8]

448
doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt Normal file
View file

@ -0,0 +1,448 @@
DNS Extensions Working Group S. Rose
Internet-Draft NIST
Updates: 2536, 2539, 3110, 4034, 4398, May 26, 2011
5155, 5702, 5933 (if approved)
Intended status: Standards Track
Expires: November 27, 2011
Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
Registry
draft-ietf-dnsext-dnssec-registry-fixes-08
Abstract
The DNS Security Extensions (DNSSEC) requires the use of
cryptographic algorithm suites for generating digital signatures over
DNS data. There is currently an IANA registry for these algorithms
that is incomplete in that it lacks the implementation status of each
algorithm. This document provides an applicability statement on
algorithm implementation compliance status for DNSSEC
implementations. This status is to measure compliance to this RFC
only. This document replaces that registry table with a new IANA
registry table for Domain Name System Security (DNSSEC) Algorithm
Numbers that lists (or assigns) each algorithm's status based on the
current reference.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 27, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rose Expires November 27, 2011 [Page 1]
Internet-Draft IANA Registry Fixes May 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. The DNS Security Algorithm Number Sub-registry . . . . . . . . 3
2.1. Updates and Additions . . . . . . . . . . . . . . . . . . . 4
2.2. Domain Name System (DNS) Security Algorithm Number
Registry Table . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Specifying New Algorithms and Updating Status of
Existing Entries . . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Rose Expires November 27, 2011 [Page 2]
Internet-Draft IANA Registry Fixes May 2011
1. Introduction
The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
[RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] uses
digital signatures over DNS data to provide source authentication and
integrity protection. DNSSEC uses an IANA registry to list codes for
digital signature algorithms (consisting of a cryptographic algorithm
and one-way hash function).
The original list of algorithm status is found in [RFC4034]. Other
DNSSEC RFC's have added new algorithms or changed the status of
algorithms in the registry. However, implementers must read through
all the documents in order to discover which algorithms are
considered wise to implement, which are not, and which algorithms may
become widely used in the future. This document replaces the
original list with a new table that includes the current compliance
status for certain algorithms.
This compliance status indication is only to be considered for
implementation, not deployment or operations. Operators are free to
deploy any digital signature algorithm available in implementations
or algorithms chosen by local security policies. This status is to
measure compliance to this RFC only.
This document replaces the current IANA registry for Domain Name
System Security (DNSSEC) Algorithm Numbers with a newly defined
registry table. This new table (Section 2.2 below) contains a column
that will list the current compliance status of each digital
signature algorithm in the registry at the time of writing and
assigns status for some algorithms used with DNSSEC that did not have
an identified status in their specification. This document updates
the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398],
[RFC5155], [RFC5702], and [RFC5933].
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. The DNS Security Algorithm Number Sub-registry
The DNS Security Algorithm Number sub-registry (part of the Domain
Name System (DNS) Security Number registry) will be replaced with the
table below. This table is based on the existing DNS Security
Algorithm Number sub-registry and adds a column that contains the
current implementation status of the given algorithm.
Rose Expires November 27, 2011 [Page 3]
Internet-Draft IANA Registry Fixes May 2011
There are additional differences to entries that are described in
sub-section 2.1. The overall new registry table is in sub-section
2.2. The values for the compliance status were obtained from
[RFC4034] with updates for algorithms specified after the original
DNSSEC specification. If no status was listed in the original
specification, this document assigns one.
2.1. Updates and Additions
This document updates three entries in the Domain Name System
Security (DNSSEC) Algorithm Registry. They are:
The description for assignment number 4 is changed to "Reserved until
2020".
The description for assignment number 9 is changed to "Reserved until
2020".
The description for assignment number 11 is changed to "Reserved
until 2020".
Registry entries 13-251 remains Unassigned.
The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT.
This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT. The
status of RSA/SHA-256 and RSA/SHA-512 are also set to RECOMMENDED TO
IMPLEMENT as it is believed that these algorithms will replace an
older algorithm (e.g. RSA/SHA-1) that have a perceived weakness in
its hash algorithm (SHA-1).
Rose Expires November 27, 2011 [Page 4]
Internet-Draft IANA Registry Fixes May 2011
2.2. Domain Name System (DNS) Security Algorithm Number Registry Table
The Domain Name System (DNS) Security Algorithm Number registry is
hereby specified as follows below. The new column is titled
"Compliance to RFC TBD" (where TBD will change when published) as the
IANA Registry table is not normative. The IANA registry table is
only a reflection of the RFC, which is normative.
Trans-
Zone action Compliance to
Number Description Mnemonic Sign Sign RFC TBD1 Reference
------ ----------- ------ ---- ----- ------------ ---------
0 Reserved [RFC4398]
1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC2537]
IMPLEMENT
2 Diffie-Hellman DH N Y [RFC2539]
3 DSA/SHA-1 DSASHA1 Y Y [RFC2536]
4 Reserved until
2020
5 RSA/SHA-1 RSASHA1 Y Y MUST [RFC3110]
IMPLEMENT
6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155]
-SHA1
7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155]
-SHA1 NSEC3- TO IMPLEMENT
SHA1
8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702]
TO IMPLEMENT
9 Reserved until
2020
10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702]
TO IMPLEMENT
11 Reserved until
2020
12 GOST R GOST-ECC Y * [RFC5933]
34.10-2001
13-251 Unassigned
252 Reserved for INDIRECT N N [RFC4034]
Indirect keys
253 private PRIVATE Y Y [RFC4034]
algorithm
254 private PRIVATEOID Y Y [RFC4034]
algorithm OID
255 Reserved
Table rows where the compliance column is not filled in are left to
the discretion of implementers. Their implementation (or lack
thereof) therefore cannot be included when judging compliance to this
Rose Expires November 27, 2011 [Page 5]
Internet-Draft IANA Registry Fixes May 2011
document.
2.3. Specifying New Algorithms and Updating Status of Existing Entries
[RFC6014] establishes a parallel procedure for adding a registry
entry for a new algorithm other than a standards track document.
Algorithms entered into the registry using that procedure do not have
a listed compliance status. Specifications that follow this path do
not need to obsolete or update this document.
Adding a newly specified algorithm to the registry with a compliance
status SHALL entail obsolescing this document and replacing the
registry table (with the new algorithm entry). Altering the status
column value of any existing algorithm in the registry SHALL entail
obsoleting this document and replacing the registry table.
This document cannot be updated, only made obsolete and replaced by a
successor document.
3. IANA Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. The new registry table is in Section
2.2. In the column "Compliance to RFC TBD", "RFC TBD" should be
changed to the official RFC when published.
The original Domain Name System (DNS) Security Algorithm Number
registry is available at
http://www.iana.org/assignments/dns-sec-alg-numbers.
4. Security Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. It is not meant to be a discussion on
algorithm superiority. No new security considerations are raised in
this document.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
Rose Expires November 27, 2011 [Page 6]
Internet-Draft IANA Registry Fixes May 2011
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[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.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
[RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC", RFC 5933, July 2010.
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
Allocation for DNSSEC", RFC 6014, November 2010.
Rose Expires November 27, 2011 [Page 7]
Internet-Draft IANA Registry Fixes May 2011
Author's Address
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
Rose Expires November 27, 2011 [Page 8]

426
doc/draft/draft-ietf-dnsext-ecc-key-07.txt → doc/draft/draft-ietf-dnsext-ecc-key-10.txt
View file

@ -1,12 +1,13 @@
INTERNET-DRAFT ECC Keys in the DNS
Expires: January 2006 July 2005
INTERNET-DRAFT Richard C. Schroeppel
Intended status: Proposed Standard Donald E. Eastlake 3rd
Expires: August 2007 March 2007
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-07.txt>
Elliptic Curve Keys and Signatures in the Domain Name System (DNS)
-------- ----- ---- --- ---------- -- --- ------ ---- ------ -----
<draft-ietf-dnsext-ecc-key-10.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
@ -19,7 +20,6 @@ Status of This Document
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@ops.ietf.org>.
@ -31,7 +31,7 @@ Status of This Document
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
@ -42,13 +42,13 @@ Status of This Document
Abstract
The standard method for storing elliptic curve cryptographic keys and
signatures in the Domain Name System is specified.
The standard format for storing elliptic curve cryptographic keys and
elliptic curve SHA-1 based signatures in the Domain Name System (DNS)
is specified.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
@ -57,7 +57,7 @@ Copyright Notice
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
Acknowledgement
@ -71,27 +71,27 @@ Table of Contents
Status of This Document....................................1
Abstract...................................................1
Copyright Notice...........................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Data in Resource Records.................3
2. Elliptic Curve Keys in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve SIG Resource Records....................11
5. Elliptic Curve Signatures..............................11
6. Performance Considerations.............................13
7. Security Considerations................................13
8. IANA Considerations....................................13
Copyright and Disclaimer..................................14
Copyright and Additional IPR Provisions...................14
Informational References..................................15
Normative Refrences.......................................15
Author's Addresses........................................16
Expiration and File Name..................................16
Disclaimer................................................16
@ -115,33 +115,33 @@ Table of Contents
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 4033, 4034,
4035].
other information. [RFC1034] [RFC1035] The DNS stores data in
resource records and has been extended to include digital signatures
and cryptographic keys in some of these resource records.
This document describes how to store elliptic curve cryptographic
(ECC) keys and signatures in the DNS so they can be used for a
variety of security purposes. Familiarity with ECC cryptography is
assumed [Menezes].
This document describes how to format elliptic curve cryptographic
(ECC) key and signature data in the DNS so they can be used for a
variety of purposes. The signatures use the SHA-1 eigest algorithm
[RFC3174]. Familiarity with ECC cryptography is assumed [Menezes].
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].
document are to be interpreted as described in [RFC2119].
2. Elliptic Curve Data in Resource Records
2. Elliptic Curve Keys in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA
portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
structure shown below.
Elliptic curve public keys are stored, using the structure described
below, in the DNS within the RDATA portions of key RRs, such as RRKEY
[RFC4034] and IPSECKEY [RFC4025] RRs.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
@ -173,7 +173,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
@ -231,7 +231,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -289,7 +289,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
@ -347,7 +347,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
determining the bit position of the left most 1-bit in the F data
@ -372,7 +372,7 @@ INTERNET-DRAFT ECC Keys in the DNS
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn't. Assuming
is sometimes irreducible, followed by X^D-1, which isn$t. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc.
@ -405,7 +405,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
@ -463,7 +463,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
LA,A is the first parameter of the elliptic curve equation.
@ -489,7 +489,7 @@ INTERNET-DRAFT ECC Keys in the DNS
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user's public signing key, another curve point of
LY,Y is the user$s public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
@ -521,7 +521,7 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
commonly used.
@ -539,7 +539,7 @@ INTERNET-DRAFT ECC Keys in the DNS
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof's algorithm. This
the number of points is determined with Schoof$s algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
@ -547,7 +547,7 @@ INTERNET-DRAFT ECC Keys in the DNS
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
G may be chosen by selecting a random [RFC4086] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
@ -566,7 +566,7 @@ INTERNET-DRAFT ECC Keys in the DNS
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public
Y is specified by giving the W-coordinate of the user$s public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
@ -579,10 +579,10 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
During the key generation process, a random [RFC 1750] number X must
During the key generation process, a random [RFC4086] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed
as
@ -597,11 +597,11 @@ INTERNET-DRAFT ECC Keys in the DNS
5. Elliptic Curve SIG Resource Records
5. Elliptic Curve Signatures
The signature portion of an RR RDATA area when using the EC
algorithm, for example in the RRSIG and SIG [RFC records] RRs is
shown below.
The signature portion of an RR RDATA area when using the ECC
algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown
below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@ -613,138 +613,138 @@ INTERNET-DRAFT ECC Keys in the DNS
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first.
SIG RR$s RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the
The data signed is determined as specified in [RFC4034]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]:
the public key [Schneier]. For further information on SHA-1, see
[RFC3174].
hash = SHA-1 ( data )
hash = SHA-1 ( data )
Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
different messages with the same K. K should be chosen from a
very large space: If an opponent learns a K value for a single
signature, the user's signing key is compromised, and a forger
can sign arbitrary messages. There is no harm in signing the
same message multiple times with the same key or different
keys.)
Generate random [RFC4086] K such that 0 < K < Q. (Never sign
two different messages with the same K. K should be chosen
from a very large space: If an opponent learns a K value
for a single signature, the user$s signing key is
compromised, and a forger can sign arbitrary messages.
There is no harm in signing the same message multiple times
with the same key or different keys.)
R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
as an integer, and reduced (mod Q). (R must not be 0. In
this astronomically unlikely event, generate a new random K
and recalculate R.)
R = (the W-coordinate of ( K*G on the elliptic curve ))
interpreted as an integer, and reduced (mod Q). (R must
not be 0. In this astronomically unlikely event, generate
a new random K and recalculate R.)
S = ( K^(-1) * (hash + X*R) ) mod Q.
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event, generate a
new random K and recalculate R and S.
S must not be 0. In this astronomically unlikely event,
generate a new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
The pair (R,S) is the signature.
Another party verifies the signature as follows:
Another party verifies the signature as follows. For further
information on SHA-1, see [RFC3174].
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for
hash(data)+Q or hash(data)-Q, if these happen to fall in the range
[0,2^160-1]. It's believed to be computationally infeasible to
find data that hashes to an assigned value, so this is only a
cosmetic blemish. The blemish can be eliminated by using Q >
2^160, at the cost of having slightly longer signatures, 42 octets
instead of 40.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for hash(data)+Q
or hash(data)-Q, if these happen to fall in the range [0,2^160-1].
It$s believed to be computationally infeasible to find data that
hashes to an assigned value, so this is only a cosmetic blemish. The
blemish can be eliminated by using Q > 2^160, at the cost of having
slightly longer signatures, 42 octets instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the
obvious thing". In the (mod P) case, E is simply a residue mod P,
and is taken as an integer in the range [0,P-1]. In the GF[2^D]
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the obvious
thing". In the (mod P) case, E is simply a residue mod P, and is
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
case, E is in the D-bit polynomial basis representation, and is
simply taken as an integer in the range [0,(2^D)-1]. For other
fields GF[P^D], it's necessary to do some radix conversion
arithmetic.
taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is
in the D-bit polynomial basis representation, and is simply taken as
an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it$s
necessary to do some radix conversion arithmetic.
6. Performance Considerations
6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than
RSA and DSA. Creation of a curve is slow, but not done very often.
Key generation is faster than RSA or DSA.
Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA. Creation of a curve is slow, but not done very often. Key
generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
7. Security Considerations
7. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. [RFC4033] [RFC4034] [RFC4035] As with all
cryptographic algorithms, evaluating the necessary strength of the
key is essential and dependent on local policy.
Some specific key generation considerations are given in the body
of this document.
Some specific key generation considerations are given in the body of
this document.
8. IANA Considerations
8. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined
in this document requires an IETF consensus as defined in [RFC2434].
The key and signature data structures defined herein correspond to
the value 4 in the Algorithm number field of the IANA registry
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in
defined in this document requires an IETF consensus as defined in
[RFC 2434].
@ -753,38 +753,38 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS
Copyright and Disclaimer
Copyright (C) The Internet Society 2005. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
INTERNET-DRAFT ECC in the DNS
Copyright and Additional IPR Provisions
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright (C) The IETF Trust (2007)
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
@ -811,104 +811,104 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
Informational References
Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC1034] - P. Mockapetris, "Domain names - concepts and facilities",
11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999.
[RFC2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC4025] - M. Richardson, "A Method for Storing IPsec Keying
Material in DNS", February 2005.
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June
2005.
[RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
Curves", 1986, Springer Graduate Texts in mathematics #106.
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "Resource Records for the DNS Security Extensions", RFC
4034, March 2005.
Normative Refrences
[RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
[RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
R. Schroeppel, et al [Page 15]
INTERNET-DRAFT ECC Keys in the DNS
INTERNET-DRAFT ECC in the DNS
Author's Addresses
Author's Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: +1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2006.
Its file name is draft-ietf-dnsext-ecc-key-07.txt.
Telephone: +1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in September 2007.
Its file name is draft-ietf-dnsext-ecc-key-10.txt.
Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

728
doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt
View file

@ -1,728 +0,0 @@
DNSEXT Working Group J. Damas
Internet-Draft M. Graff
Obsoletes: 2671, 2673 P. Vixie
(if approved) Internet Systems Consortium
Intended status: Standards Track March 7, 2011
Expires: September 8, 2011
Extension Mechanisms for DNS (EDNS0)
draft-ietf-dnsext-rfc2671bis-edns0-05
Abstract
The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not
allow requestors to advertise their capabilities to responders. This
document describes backward compatible mechanisms for allowing the
protocol to grow.
This document updates the EDNS0 specification [RFC2671] based on 10
years of deployment experience.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 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
Damas, et al. Expires September 8, 2011 [Page 1]
Internet-Draft EDNS0 Extensions March 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3
4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4
6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5
6.2. OPT Record Wire Format . . . . . . . . . . . . . . . . . . 5
6.3. Cache behaviour . . . . . . . . . . . . . . . . . . . . . 7
6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7
6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7
6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8
6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8
6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8
6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Document Editing History . . . . . . . . . . . . . . 11
Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11
Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Damas, et al. Expires September 8, 2011 [Page 2]
Internet-Draft EDNS0 Extensions March 2011
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 is limited
to 512 bytes. Many of DNS's protocol limits are too small for uses
which are commom or desired to become common. RFC 1035 does not
define any way for implementations to advertise their capabilities.
[RFC2671] added extension mechanism to DNS, this mechanism is widely
supported and number of new DNS uses and protocol extensions depend
on the presence of these extensions. This memo refines that
specification and obsoletes [RFC2671].
Unextended agents will not know how to interpret the protocol
extensions defined in [RFC2671] and restated here. Extended agents
must be prepared for handling the interactions with unextended
clients in the face of new protocol elements, and fall back
gracefully to unextended DNS. [RFC2671] proposed extensions to the
basic DNS protocol to overcome these deficiencies. This memo refines
that specification and obsoletes [RFC2671].
[RFC2671] specified extended label types. The only one proposed was
in RFC2673 for a label type called "Bitstring Labels." For various
reasons introducing a new label type was found to be extremely
difficult, and RFC2673 was moved to Experimental. This document
Obsoletes Extended Labels.
2. Terminology
"Requestor" is the side which sends a request. "Responder" is an
authoritative, recursive resolver, or other DNS component which
responds to questions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 support is practically mandatory in a modern world. DNSSEC
requires EDNS support, and many other features are made possible only
by EDNS support to request or advertise them. Many organizations are
requiring DNSSEC. Without common interoperability, DNSSEC cannot be
as easily deployed.
Damas, et al. Expires September 8, 2011 [Page 3]
Internet-Draft EDNS0 Extensions March 2011
DNS publishers are wanting to put more data in answers. DNSSEC
DNSKEY records, negative answers, and many other DNSSEC queries cause
larger answers to be returned. In order to support this, DNS
servers, middleware, and stub resolvers MUST support larger packet
sizes advertised via EDNS0.
4. 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 [RFC1035]). Some of these were marked for future use,
and most 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 two bits of a wire format domain label are used to denote
the type of the label. [RFC1035] allocates two of the four possible
types and reserves the other two. More label types were defined in
[RFC2671]. This document obsoletes the use of the 2-bit combination
defined by [RFC2671] to identify extended label types.
4.3. UDP Message Size
Traditional DNS Messages are limited to 512 octets in size when sent
over UDP ([RFC1035]). Today, many organizations wish to return many
records in a single reply, and special tricks are needed to make the
responses fit in this 512-byte limit. Additionally, inclusion of
DNSSEC records frequently requires a much larger response than a 512
byte message can hold.
EDNS0 is intended to address these larger packet sizes and continue
to use UDP. It specifies a way to advertise additional features such
as larger response size capability, which is intended to help avoid
truncated UDP responses which then cause retry over TCP.
5. Extended Label Types
The first octet in the on-the-wire representation of a DNS label
specifies the label type; the basic DNS specification [RFC1035]
dedicates the two most significant bits of that octet for this
purpose.
Damas, et al. Expires September 8, 2011 [Page 4]
Internet-Draft EDNS0 Extensions March 2011
[RFC2671] defined DNS label type 0b01 for use as an indication for
Extended Label Types. A specific Extended Label Type is selected by
the 6 least significant bits of the first octet. Thus, Extended
Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
first octet of the label.
Extended Label Types are difficult to use due to support in clients
and intermediate gateways as described in [RFC3364] which moves them
to experimental status and [RFC3363], which describes the pros and
cons.
Therefore, this document moves them from experimental to historical,
making them obsoleted. Additionally, the registry of Extended Label
Types is requested to be closed.
6. The OPT pseudo-RR
6.1. OPT Record Definition
An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
additional data section of a request.
The OPT RR has RR type 41.
If present in requests, 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.
Only one OPT RR MAY be included within any DNS message. If a 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.2. OPT Record 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 meta data
and also a small collection of basic extension elements which we
expect to be so popular that it would be a waste of wire space to
encode them as {attribute, value} pairs.
Damas, et al. Expires September 8, 2011 [Page 5]
Internet-Draft EDNS0 Extensions March 2011
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 (42) |
| 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
The variable part of an OPT RR may contain zero or more options in
the RDATA. Each option must be treated as binary. Each option is
encoded as:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE
Assigned by Expert Review.
OPTION-LENGTH
Size (in octets) of OPTION-DATA.
OPTION-DATA
Varies per OPTION-CODE. MUST be treated as binary.
The order of appearance of option tuples is not defined. If one
option modifies the behavior 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
Damas, et al. Expires September 8, 2011 [Page 6]
Internet-Draft EDNS0 Extensions March 2011
option specification might say that if a responder sees option XYZ,
it MUST include option XYZ in its response.
6.3. Cache behaviour
The OPT record MUST NOT be cached.
6.4. Fallback
If a requestor detects that the remote end does not support EDNS0, it
MAY issue queries without an OPT record. It MAY cache this knowledge
for a brief time in order to avoid fallback delays in the future.
However, if DNSSEC or any future option using EDNS is required, no
fallback should be performed as they are only signaled through EDNS0.
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 SHOULD be given to those support EDNS(0).
6.5. 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 which
will block fragmented IP packets, a requestor SHOULD not choose a
value which will cause fragmentation. Doing so will prevent large
responses from being received, and can cause fallback to occur.
Note that a 512-octet UDP payload requires a 576-octet IP reassembly
buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over
Ethernet would be reasonable. Choosing a very large value will
guarantee fragmentation at the IP layer, and may prevent answers from
being received due to a single fragment loss or 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.6. Responder's Payload Size
The responder's maximum payload size can change over time, but can be
reasonably expected to remain constant between two closely spaced
sequential transactions; for example, a meaningless QUERY to discover
Damas, et al. Expires September 8, 2011 [Page 7]
Internet-Draft EDNS0 Extensions March 2011
a responder's maximum UDP payload size, followed immediately by an
UPDATE which 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 payload size limit.
6.7. Payload Size Selection
Due to transaction overhead, it is unwise to advertise an
architectural limit as a maximum UDP payload size. Just because your
stack can reassemble 64KB datagrams, don't assume that you want to
spend more than about 4KB of state memory per ongoing transaction.
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 which begins with
a large size, such as 4096. If that fails, a fallback around the
1280-1410 byte range SHOULD be tried, as it has a reasonable chance
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.
6.8. Middleware Boxes
Middleware boxes (e.g. firewalls, SOHO routers, load balancers, etc)
MUST NOT limit DNS messages over UDP to 512 bytes.
Middleware boxes which simply forward requests to a recursive
resolver MUST NOT modify and MUST NOT delete the OPT record contents
in either direction.
Middleware boxes which have additional functionality, such as
answering certain queries or acting like an intelligent forwarder,
MUST understand the OPT record. These boxes MUST consider the
incoming request and any outgoing requests as separate transactions
if the characteristics of the messages are different.
A complete discussion of middleware boxes acting as DNS proxies and
the impact of EDNS in those implementations is described in
[RFC5625].
6.9. OPT Record TTL Field Use
The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows:
Damas, et al. Expires September 8, 2011 [Page 8]
Internet-Draft EDNS0 Extensions March 2011
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE
Forms 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 whoever sets it. Full
conformance with this specification is indicated by version
``0.'' Requestors are encouraged to set this to the lowest
implemented level capable of expressing a transaction, to
minimize the responder and network load of discovering the
greatest common implementation level between requestor and
responder. A requestor's version numbering strategy MAY
ideally be a run time configuration option.
If a responder does not implement the VERSION level of the
request, then it answers with RCODE=BADVERS. All responses
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.10. 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.
6.11. OPT Options Code Allocation Procedure
Allocations assigned by expert review. Assignment of Option Codes
should be liberal, but duplicate functionality is to be avoided.
Damas, et al. Expires September 8, 2011 [Page 9]
Internet-Draft EDNS0 Extensions March 2011
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.
Responders who do not implement these protocol extensions MUST
respond with FORMERR messages without any OPT record.
If there is a problem with processing the OPT record itself, such as
an option value that is badly formatted or includes out of range
values, a FORMERR MUST be returned. If this occurs the response MUST
include an OPT record. This is intended to allow the requestor to to
distinguish between servers which do not implement EDNS and format
errors within EDNS.
The minimal response must be the DNS header, question section, and an
OPT record. This must also occur when an 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 which 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 by
middleboxes (see Section 6.8). This could cause retransmissions with
no hope of success. Some devices have been found to reject
fragmented UDP packets.
Announcing too small UDP buffer sizes 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.
Damas, et al. Expires September 8, 2011 [Page 10]
Internet-Draft EDNS0 Extensions March 2011
[RFC2671] specified a number of IANA sub-registries within "DOMAIN
NAME SYSTEM PARAMETERS:"
o EDNS Extended Label Type
o EDNS Option Codes
o EDNS Version Numbers
o Domain System Response Code
IANA is advised to re-parent these sub-registries to this document.
[RFC2671] created the "EDNS Extended Label Type Registry". We
request that this registry be closed.
This document assigns option code 65535 in the "EDNS Option Codes"
registry to "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 Standards Action is required to add a new RCODE. Adding new
RCODEs should be avoided due to the difficulty in upgrading the
installed base.
This document assigns EDNS Extended RCODE 16 to "BADVERS".
IETF Standards Action is required for assignments of new EDNS0 flags.
Flags SHOULD be used only when necessary for DNS resolution to
function. For many uses, a EDNS Option Code may be preferred.
IETF Standards Action is required to create new entries in the EDNS
Version Number registry. Expert Review is required for allocation of
an EDNS Option Code.
Appendix A. Document Editing History
Following is a list of high-level changes made to the original
RFC2671.
Appendix A.1. Changes since RFC2671
o Support for the OPT record is now mandatory.
o Extended label types obsoleted and the registry is closed.
Damas, et al. Expires September 8, 2011 [Page 11]
Internet-Draft EDNS0 Extensions March 2011
o The bitstring label type, which was already moved from draft to
experimental, is requested to be moved to historical.
o Changes in how EDNS buffer sizes are selected, with
recommendations on how to select them.
o Front material (IPR notice and such) was updated to current
requirements.
Appendix A.2. Changes since -02
o Specified the method for allocation of constants.
o Cleaned up a lot of wording, along with quite a bit of document
structure changes.
10. References
10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. Expires September 8, 2011 [Page 12]
Internet-Draft EDNS0 Extensions March 2011
Authors' Addresses
Joao Damas
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063
US
Phone: +1 650.423.1312
Email: joao@isc.org
Michael Graff
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063
US
Phone: +1 650.423.1304
Email: mgraff@isc.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. Expires September 8, 2011 [Page 13]

1232
doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
View file

File diff suppressed because it is too large Load diff

334
doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt → doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt
View file

@ -4,11 +4,11 @@
Domain Name System Operations W. Wijngaards
Internet-Draft O. Kolkman
Intended status: Standards Track NLnet Labs
Expires: August 26, 2010 February 22, 2010
Expires: December 31, 2010 June 29, 2010
DNSSEC Trust Anchor History Service
draft-ietf-dnsop-dnssec-trust-history-01
draft-ietf-dnsop-dnssec-trust-history-02
Abstract
@ -25,49 +25,43 @@ Requirements Language
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2010.
This Internet-Draft will expire on December 31, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Wijngaards & Kolkman Expires August 26, 2010 [Page 1]
Internet-Draft Trust History Service February 2010
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
Wijngaards & Kolkman Expires December 31, 2010 [Page 1]
Internet-Draft Trust History Service June 2010
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 BSD License.
described in the Simplified BSD License.
1. Introduction
@ -80,7 +74,7 @@ Internet-Draft Trust History Service February 2010
trust-anchor. Using a newly defined resource record (RR) that links
old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
RRsets and checks they form a chain to the latest key (see
Section 2). The lists of old DNSKEYS, linked with the TALINK RRs, do
Section 3). The lists of old DNSKEYS, linked with the TALINK RRs, do
not necessarily need to be published in the zone for which the DNSKEY
history is being maintained but can be published in any DNS domain.
We will call the entity that offers the trust history the History
@ -88,12 +82,123 @@ Internet-Draft Trust History Service February 2010
maintainer of the validator, possibly based on a hint provided, using
the TALINK, by the zone owner.
The algorithm that the validator uses to construct a history and
reconfigure a new key is detailed in Section 3. The algorithms for
how providers of trust history can fetch the DNSKEY data as published
by the zone they track and publish that are explained in Section 4.
Section 2 provides background on the mechanism and usage. It looks
at the viewpoints of publishers and consumers of trust anchors, the
use of keys with revocation flags, and SEP flags.
2. The TALINK Resource Record
The algorithm that the validator uses to construct a history and
reconfigure a new key is detailed in Section 4, it uses the TALINK RR
type defined in Section 3. The algorithms for how providers of trust
history can fetch the DNSKEY data as published by the zone they track
and publish that are explained in Section 5.
2. Motivation and Description
Validators provide a service in DNSSEC that can be seen from two
ways. Seen from the publisher's point of view, they provide
assurance that the data as received is as it was when it left the
publisher's hands. In this way of looking at things, validators
provide a publication integrity service. The publisher can be
confident that nobody can alter the published data (if it is
validated), because any alteration will be detected. So it protects
a publisher from being seen to send someone to the wrong place.
From the consumer's point of view, validators provide a reason to
trust the data from the network. In this view, the validator is
Wijngaards & Kolkman Expires December 31, 2010 [Page 2]
Internet-Draft Trust History Service June 2010
making a claim about whether the data ought to be accepted or not.
This is subtly different from the publisher's point of view, because
the question for the consumer is not whether the data is safe while
the consumer is not looking, but whether the data is safe for the
consumer at the moment of consumption. Validation protects a
consumer from going to the wrong place.
These two slightly different ways of looking at the situation result
in slightly different operational goals. Whereas publishers want to
make assertions about their data, by controlling the roll over of
keys, consumers want to get the best assurance that they can get that
the data they are consuming is correct.
If a validator has been offline during a key rollover event for one
of its trust anchors, then the validator will be unable to validate
answers that need that trust anchor. For the publisher, this state
of affairs is acceptable: the publisher is confident that no
validator ever consumes the wrong data. For the consumer, however,
this state of affairs represents an outage.
Since publishers of trust anchors already use a chained series of
keys to perform rollovers under some circumstances (see [RFC5011]),
it is possible to use the history of that chain to allow a validator
to resume service for the consumer without needing to use an out-of-
band mechanism to obtain a new trust anchor. This improves the
experience for consumers of validated data, and increases the chances
that DNSSEC is useful for consumers of DNS data.
The mechanism to do this is a double-linked list that recounts a
portion of the history of DNSKEY Resource Records. The list is used
by a validator to catch up with the changes that the validator
somehow missed. This approach may be thought of as replaying the
[RFC5011] rollover history, only at a later time.
2.1. Considerations for Using a Revoked Key
The keys that the publisher rolled are marked REVOKED by the RFC5011
protocol. At this point the publisher considers the keys revoked,
but the validators have not yet seen this or marked the keys as
revoked. In the RFC5011 protocol, the validators probe regularly and
can then see if keys are revoked. If unable to probe, they will be
unable to see if keys are revoked. Hence when using a history to
recount rollovers, the consumer's validator has also missed a number
of revocations. The goal is to pick up the right keys and also the
new revocations along the way.
Although the keys have been marked by the publisher as REVOKED a long
time ago, for the consumer these REVOKED keys are new information.
Wijngaards & Kolkman Expires December 31, 2010 [Page 3]
Internet-Draft Trust History Service June 2010
Their storage in the history list makes it possible for consumers to
pick up key revocations if they missed the revocation announcement
because they could not probe.
This is the allowed usage of REVOKED keys. The publisher is
announcing their presence. And the validators mark them as REVOKED
after verification. The initial part of this verification is the
reverse walk through the history list, which is to avoid exposing
which key is trusted. This means that older signatures with keys
that have in the meantime been revoked are used to construct and
verify the history list by the validator.
A consequence is that once a publisher marks keys as REVOKED, there
will still be consumers who are using such keys, because they have
not seen the revocation. From the publishers point of view they are
revoked and the revocation is filed in the historical key list. From
the consumers point of view, it has not seen a revocation yet, and a
historical key list lookup algorithm is a state change where a new
trusted key is obtained while the old key is observed to be revoked.
2.2. Motivation for Requiring the SEP Bit
The SEP bit is used to differentiate Key Signing Keys from other
keys. It is defined in [RFC3757], it is used to designate trust
anchors in [RFC5011]. The protocol herein specified requires that
DNSKEYs that are subject to use for the trust history service have
the SEP bit set. The reason for this is to keep the set of keys that
need to be stored in history small.
3. The TALINK Resource Record
The DNS Resource Record type TALINK (decimal 58) ties the elements of
a linked list of DNSKEY RRs together.
@ -105,17 +210,22 @@ Internet-Draft Trust History Service February 2010
The presentation format is the two domain names. The wire encoding
is the two domain names, with no compression so the type can be
treated according to [RFC3597]. The list is a double linked list,
Wijngaards & Kolkman Expires August 26, 2010 [Page 2]
Internet-Draft Trust History Service February 2010
because this empowers low memory hosts to perform consistency checks.
3. Trust History Lookup
The TALINK used at the zone apex holds the endpoints of the list.
The TALINKs that form the lists hold previous and next entries.
These TALINKs are distinguished by their usage (entrypoint or list
connection). The double linked list is not circular, because lookups
must stop when they reach the oldest entry.
Wijngaards & Kolkman Expires December 31, 2010 [Page 4]
Internet-Draft Trust History Service June 2010
4. Trust History Lookup
This is the algorithm that a validator uses to detect and resolve the
situation in which a trust-anchor is out of sync with the DNSKEYs
@ -123,10 +233,10 @@ Internet-Draft Trust History Service February 2010
which is used to link various old DNSKEYs as published by the History
Provider, to arrive from the outdated configured Trust Anchor to one
that matches the current DNSKEY. The TALINK RR type is defined in
Section 2.
Section 3.
When the algorithm below results in failure the trust history cannot
be build and a new trust anchor will need to be re-configured using
be built and a new trust anchor will need to be re-configured using
another mechanism.
Step 1: The validator performs a DNSKEY lookup to the target zone,
@ -144,12 +254,14 @@ Internet-Draft Trust History Service February 2010
The results can differ if a key-rollover is in progress and not
all nameservers are in sync yet. This case can be detected by
checking that the older keyset signs the newer and take the newer
as result keyset. The keysets are distinguished by the average
over the middle of the inception and expiration dates of the
signatures that are validated by the keyset itself. Otherwise,
the history lookup fails. If the check fails then the
inconsistency may be the result of spoofing, or compromise of
(DNS) infrastructure elements.
as result keyset. If both of the keysets sign each other, the
result keyset has the newest rrsig that validates it using the
other keyset. Use the the average over the middle of the
inception and expiration dates of the signatures that are
validated (and for serial arithmetic assume all dates on these
signatures lie within 2^(SERIAL_BITS-1) distance). If the keysets
do not sign each other then this is not a secure change in the
keyset and the history lookup fails.
Step 2: Fetch the trust history list end points. Perform a query of
QTYPE TALINK and QNAME the domain name that is configured to be
@ -159,24 +271,23 @@ Internet-Draft Trust History Service February 2010
Step 3: Go backwards through the trust history list as provided by
the TALINK linked list. Verify that the keyset validly signs the
next keyset. This is [RFC4034] validation, but the RRSIG
expiration date is ignored. [Editor note: Are we shure that there
are no server implementations that will not serve expired RRSIG,
expiration date is ignored. Replace the owner domain name with
the target zone name for verification. One of the keys that signs
Wijngaards & Kolkman Expires August 26, 2010 [Page 3]
Wijngaards & Kolkman Expires December 31, 2010 [Page 5]
Internet-Draft Trust History Service February 2010
Internet-Draft Trust History Service June 2010
are such 'smart' servers allowed by the specs? In other words do
we need clarification in the DNSSEC-updates document?] Replace
the owner domain name with the target zone name for verification.
One of the keys that signs the next keyset MUST have the SEP bit
set. The middle of inception and expiration date from the valid
signature MUST be older than that of the signature that validates
the next keys in the list. Query type TALINK to get previous and
next locations.
the next keyset MUST have the SEP bit set. The middle of
inception and expiration date from the valid signature MUST be
older than that of the signature that validates the next keys in
the list. Take the average if multiple signatures validate (and
for serial arithmetic assume all dates on these signatures lie
within 2^(SERIAL_BITS-1) distance). Query type TALINK to get
previous and next locations.
If all SEP keys have the REVOKE flag set at this step, and the
keyset is signed by all SEP keys, then continue but store that the
@ -198,7 +309,7 @@ Internet-Draft Trust History Service February 2010
store the result on stable storage. Use the new trust anchor for
validation (if using [RFC5011], put it in state VALID).
4. Trust History Tracker
5. Trust History Tracker
External trackers can poll the target zone DNSKEY RRset regularly.
Ignore date changes in the RRSIG. Ignore changes to keys with no SEP
@ -220,16 +331,18 @@ Internet-Draft Trust History Service February 2010
Wijngaards & Kolkman Expires August 26, 2010 [Page 4]
Wijngaards & Kolkman Expires December 31, 2010 [Page 6]
Internet-Draft Trust History Service February 2010
Internet-Draft Trust History Service June 2010
5. Example
6. Example
In this example example.com is the History Provider for example.net.
The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
and paste of the data from example.net.
In this example the trust history for the 'example.net' zone is
published in the 'example.com' namespace. The DNSKEY rdata and RRSIG
rdata is omitted for brevity, it is a copy and paste of the data from
example.net.
$ORIGIN example.com.
example.com. TALINK h0.example.com. h2.example.com.
@ -250,7 +363,7 @@ Internet-Draft Trust History Service February 2010
by providing the TALINK shown here at example.com at the apex of the
example.net zone. The TALINK at example.com is then not needed.
6. Deployment
7. Deployment
The trust history is advertised with TALINK RRs at the zone apex.
These represent alternative history sources, that can be searched in
@ -275,10 +388,9 @@ Internet-Draft Trust History Service February 2010
Wijngaards & Kolkman Expires August 26, 2010 [Page 5]
Wijngaards & Kolkman Expires December 31, 2010 [Page 7]
Internet-Draft Trust History Service February 2010
Internet-Draft Trust History Service June 2010
In general, the decision can be that any key - no matter how old or
@ -296,13 +408,11 @@ Internet-Draft Trust History Service February 2010
argument that perceived security is worse than no security.
The history lookup can be used on its own. Then, the trust history
is used whenever the key rolls over and no polling is performed.
This has associated risks, in that the immediate rollover without
timeout that it provides could be abused, and certainly when taken
together with leap-of-faith such systems SHOULD inform their user
that the key has changed and urge them to do immediate checks.
Initially we put a hold down timer on such rollovers to mitigate the
abuse risks but these make following normal rollovers impossible.
is used whenever the key rolls over and no polling is performed. The
results of trust history lookup SHOULD be stored on stable storage,
so that the trust history lookup does not need to be performed if the
last results are okay and for use as trusted anchor in the next
history lookup.
If a validator is also using [RFC5011] for the target zone, then the
trust history algorithm SHOULD only be invoked if the [RFC5011]
@ -320,7 +430,7 @@ Internet-Draft Trust History Service February 2010
History Provider. The test History Provider provides access to a
generated back-dated test history.
7. Security Considerations
8. Security Considerations
The History Provider only provides copies of old data. If that
historic data is altered or withheld the lookup algorithm fails
@ -329,16 +439,16 @@ Internet-Draft Trust History Service February 2010
to the original private keys (through theft, cryptanalisis, or
otherwise), history can be altered without failure of the algorithm.
Below we only consider MIMAs and assume the History Provider is a
Wijngaards & Kolkman Expires August 26, 2010 [Page 6]
Internet-Draft Trust History Service February 2010
trusted party.
Wijngaards & Kolkman Expires December 31, 2010 [Page 8]
Internet-Draft Trust History Service June 2010
Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
TALINK and DNSKEY data, can present some alternate history. However
the DNSKEY RR set trusted that the history should arrive at is
@ -376,26 +486,25 @@ Internet-Draft Trust History Service February 2010
Rollover with [RFC5011] revokes keys after use. If a History
Provider is used, then such revoked keys SHOULD be used to perform
history tracking and history lookup. The old keys that the validator
starts with and final current keys MUST NOT be trusted if they are
revoked.
history tracking and history lookup. The trust anchor keys that the
validator has in its own storage and final current keys that it
stores MUST NOT be trusted if they are revoked.
Depending on choices by the validator operator, it may accept a leap-
of-faith, and possibly allow non-hold-down rollovers. Although this
allows very fast emergency rollover if all clients are known to do
trust-history lookups without the RFC5011-algorithm, it also allows
an attacker with the private key to attempt to take over a zone
If the validator operator chooses to operate trust history without
also using [RFC5011] the trust anchor does not get hold-down timer
protection. This has associated risks, in that the immediate
rollover without timeout that it provides could be abused (if private
keys are compromised). Such abuse could result in the stored lookup
results to become compromised. The key changes can be logged, to
inform operators and keep an audit trail.
Wijngaards & Kolkman Expires August 26, 2010 [Page 7]
Wijngaards & Kolkman Expires December 31, 2010 [Page 9]
Internet-Draft Trust History Service February 2010
Internet-Draft Trust History Service June 2010
quickly and get validators to roll to a trust anchor of the
attacker's choosing.
The SEP bit is checked to make sure that control over the KSK is
necessary to change the keyset for the target zone.
@ -409,31 +518,35 @@ Internet-Draft Trust History Service February 2010
enables a replay attack of old DNSSEC data and signatures. This
vulnerability exists also in plain DNSSEC.
8. IANA Considerations
9. IANA Considerations
Resource record type TALINK has been defined using RFC5395 expert
review, it has RR type number 58 (decimal).
9. Acknowledgments
10. Acknowledgments
Thanks to the people who provided review and suggestions, Joe Abley,
George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
Matthijs Mekking.
Thanks to the people who provided review and suggestions, Peter Koch,
Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael
StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill
Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur
Gudmundsson, Roy Arends and Matthijs Mekking.
10. References
11. References
10.1. Informative References
11.1. Informative References
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendations for Key Management", NIST
SP 800-57, March 2007.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, April 2004.
[RFC5011] StJohns, M., "Automated Updates of DNS Security
(DNSSEC) Trust Anchors", RFC 5011, September 2007.
10.2. Normative References
11.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
@ -443,10 +556,9 @@ Internet-Draft Trust History Service February 2010
Wijngaards & Kolkman Expires August 26, 2010 [Page 8]
Wijngaards & Kolkman Expires December 31, 2010 [Page 10]
Internet-Draft Trust History Service February 2010
Internet-Draft Trust History Service June 2010
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
@ -500,5 +612,5 @@ Authors' Addresses
Wijngaards & Kolkman Expires August 26, 2010 [Page 9]
Wijngaards & Kolkman Expires December 31, 2010 [Page 11]

640
doc/draft/draft-ietf-dnsop-respsize-06.txt
View file

@ -1,640 +0,0 @@
DNSOP Working Group Paul Vixie, ISC
INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-06.txt> August 2006
DNS Referral Response Size Issues
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
With a mandated default minimum maximum message size of 512 octets,
the DNS protocol presents some special problems for zones wishing to
expose a moderate or high number of authority servers (NS RRs). This
document explains the operational issues caused by, or related to
this response size limit, and suggests ways to optimize the use of
this limited space. Guidance is offered to DNS server implementors
and to DNS zone operators.
Expires January 2007 [Page 1]
INTERNET-DRAFT August 2006 RESPSIZE
1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum IP
reassembly limit for IPv4, it became a hard DNS protocol limit and is
not implicitly relaxed by changes in transport, for example to IPv6.
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
larger responses by mutual agreement of the requester and responder.
The 512 octet message size limit will remain in practical effect until
there is widespread deployment of EDNS0 in DNS resolvers on the
Internet.
1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets.
Negative responses are quite small, but for positive and delegation
responses, every octet must be carefully and sparingly allocated. This
document specifically addresses delegation response sizes.
2 - Delegation Details
2.1. RELEVANT PROTOCOL ELEMENTS
2.1.1. A delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: empty, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
2.1.2. If the total response size exceeds 512 octets, and if the data
that does not fit was "required", then the TC bit will be set
(indicating truncation). This will usually cause the requester to retry
using TCP, depending on what information was desired and what
information was omitted. For example, truncation in the authority
section is of no interest to a stub resolver who only plans to consume
the answer section. If a retry using TCP is needed, the total cost of
the transaction is much higher. See [RFC1123 6.1.3.2] for details on
the requirement that UDP be attempted before falling back to TCP.
2.1.3. RRsets are never sent partially unless TC bit set to indicate
truncation. When TC bit is set, the final apparent RRset in the final
non-empty section must be considered "possibly damaged" (see [RFC1035
6.2], [RFC2181 9]).
Expires January 2007 [Page 2]
INTERNET-DRAFT August 2006 RESPSIZE
2.1.4. With or without truncation, the glue present in the additional
data section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets. Note
that truncation of the additional data section might not be signalled
via the TC bit since additional data is often optional (see discussion
in [RFC4472 B]).
2.1.5. DNS label compression allows a domain name to be instantiated
only once per DNS message, and then referenced with a two-octet
"pointer" from other locations in that same DNS message (see [RFC1035
4.1.4]). If all nameserver names in a message share a common parent
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will
be available for incompressable data (such as nameserver addresses).
2.1.6. The query name can be as long as 255 octets of network data. In
this worst case scenario, the question section will be 259 octets in
size, which would leave only 240 octets for the authority and additional
sections (after deducting 12 octets for the fixed length header.)
2.2. ADVICE TO ZONE OWNERS
2.2.1. Average and maximum question section sizes can be predicted by
the zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. Note that if the zone
contains any wildcards, it is possible for maximum length queries to
require positive responses, but that it is reasonable to expect
truncation and TCP retry in that case. For cost and performance
reasons, the majority of requests should be satisfied without truncation
or TCP retry.
2.2.2. Some queries to non-existing names can be large, but this is not
a problem because negative responses need not contain any answer,
authority or additional records. See [RFC2308 2.1] for more information
about the format of negative responses.
2.2.3. The minimum useful number of name servers is two, for redundancy
(see [RFC1034 4.1]). A zone's name servers should be reachable by all
IP transport protocols (e.g., IPv4 and IPv6) in common use.
2.2.4. The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically re-
query for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary.
Expires January 2007 [Page 3]
INTERNET-DRAFT August 2006 RESPSIZE
2.3. ADVICE TO SERVER IMPLEMENTORS
2.3.1. In case of multi-homed name servers, it is advantageous to
include an address record from each of several name servers before
including several address records for any one name server. If address
records for more than one transport (for example, A and AAAA) are
available, then it is advantageous to include records of both types
early on, before the message is full.
2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
Each A RR will require 16 octets, and each AAAA RR will require 28
octets.
2.3.3. While DNS distinguishes between necessary and optional resource
records, this distinction is according to protocol elements necessary to
signify facts, and takes no official notice of protocol content
necessary to ensure correct operation. For example, a nameserver name
that is in or below the zone cut being described by a delegation is
"necessary content," since there is no way to reach that zone unless the
parent zone's delegation includes "glue records" describing that name
server's addresses.
2.3.4. It is also necessary to distinguish between "explicit truncation"
where a message could not contain enough records to convey its intended
meaning, and so the TC bit has been set, and "silent truncation", where
the message was not large enough to contain some records which were "not
required", and so the TC bit was not set.
2.3.5. A delegation response should prioritize glue records as follows.
first
All glue RRsets for one name server whose name is in or below the
zone being delegated, or which has multiple address RRsets (currently
A and AAAA), or preferably both;
second
Alternate between adding all glue RRsets for any name servers whose
names are in or below the zone being delegated, and all glue RRsets
for any name servers who have multiple address RRsets (currently A
and AAAA);
thence
All other glue RRsets, in any order.
Expires January 2007 [Page 4]
INTERNET-DRAFT August 2006 RESPSIZE
Whenever there are multiple candidates for a position in this priority
scheme, one should be chosen on a round-robin or fully random basis.
The goal of this priority scheme is to offer "necessary" glue first,
avoiding silent truncation for this glue if possible.
2.3.6. If any "necessary content" is silently truncated, then it is
advisable that the TC bit be set in order to force a TCP retry, rather
than have the zone be unreachable. Note that a parent server's proper
response to a query for in-child glue or below-child glue is a referral
rather than an answer, and that this referral MUST be able to contain
the in-child or below-child glue, and that in outlying cases, only EDNS
or TCP will be large enough to contain that data.
3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet
limit.
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
Expires January 2007 [Page 5]
INTERNET-DRAFT August 2006 RESPSIZE
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
3.2. For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name (which
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
fit, due to the use of DNS compression pointers in the last 12
occurances of the parent domain name. The following output from a
response simulator demonstrates these properties.
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
a.dns.br requires 10 bytes
b.dns.br requires 4 bytes
c.dns.br requires 4 bytes
d.dns.br requires 4 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Expires January 2007 [Page 6]
INTERNET-DRAFT August 2006 RESPSIZE
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
(Note: The response simulator program is shown in Section 5.)
Here we use the term "green" if all address records could fit, or
"yellow" if two or more could fit, or "orange" if only one could fit, or
"red" if no address record could fit. It's clear that without a common
parent for nameserver names, much space would be lost. For these
examples we use an average/common name size of 15 octets, befitting our
assumption of GTLD-SERVERS.NET as our common parent name.
We're assuming a medium query name size of 64 since that is the typical
size seen in trace data at the time of this writing. If
Internationalized Domain Name (IDN) or any other technology which
results in larger query names be deployed significantly in advance of
EDNS, then new measurements and new estimates will have to be made.
4 - Conclusions
4.1. The current practice of giving all nameserver names a common parent
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
responses and allows for more nameservers to be enumerated than would
otherwise be possible, since the common parent domain name only appears
once in a DNS message and is referred to via "compression pointers"
thereafter.
4.2. If all nameserver names for a zone share a common parent, then it
is operationally advisable to make all servers for the zone thus served
also be authoritative for the zone of that common parent. For example,
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
always have the zone's nameservers' glue available when delegating, and
Expires January 2007 [Page 7]
INTERNET-DRAFT August 2006 RESPSIZE
will be able to respond with answers rather than referrals if a
requester who wants that glue comes back asking for it. In this case
the name server will likely be a "stealth server" -- authoritative but
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
information about stealth servers.
4.3. Thirteen (13) is the effective maximum number of nameserver names
usable traditional (non-extended) DNS, assuming a common parent domain
name, and given that implicit referral response truncation is
undesirable in the average case.
4.4. Multi-homing of name servers within a protocol family is
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
indivisible, and will be larger than a single resource record. Larger
RRsets are more likely to lead to or encounter truncation.
4.5. Multi-homing of name servers across protocol families is less
likely to lead to or encounter truncation, partly because multiprotocol
clients are more likely to speak EDNS which can use a larger response
size limit, and partly because the resource records (A and AAAA) are in
different RRsets and are therefore divisible from each other.
4.6. Name server names which are at or below the zone they serve are
more sensitive to referral response truncation, and glue records for
them should be considered "less optional" than other glue records, in
the assembly of referral responses.
4.7. If a zone is served by thirteen (13) name servers having a common
parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
single address record in some protocol family (e.g., an A RR), then all
thirteen name servers or any subset thereof could multi-home in a second
protocol family by adding a second address record (e.g., an AAAA RR)
without reducing the reachability of the zone thus served.
5 - Source Code
#!/usr/bin/perl
#
# SYNOPSIS
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have a same zone suffix,
# such as "jp" in JP TLD servers, specify it in -z option
#
use strict;
use Getopt::Std;
Expires January 2007 [Page 8]
INTERNET-DRAFT August 2006 RESPSIZE
my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0;
getopt('z', %opts);
if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it
}
foreach $name (@ARGV) {
my $len;
$n_ns++;
$len = server_name_len($name);
print "$name requires $len bytes\n";
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
+ $sz_rdlen + $len;
}
print "# of NS: $n_ns\n";
arsect(255, $nssect, $n_ns, "maximum");
arsect(64, $nssect, $n_ns, "average");
sub server_name_len {
my ($name) = @_;
my (@labels, $len, $n, $suffix);
$name =~ tr/A-Z/a-z/;
@labels = split(/\./, $name);
$len = length(join('.', @labels)) + 2;
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
$suffix = join('.', @labels);
return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix}));
$namedb{$suffix} = 1;
}
return $len;
}
sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + 1 + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
Expires January 2007 [Page 9]
INTERNET-DRAFT August 2006 RESPSIZE
$n_a_aaaa = atmost(int($space
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
/ $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf " only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf " A and AAAA are considered: ";
printf "# of A+AAAA is %d (%s)\n",
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
printf " preferred-glue A is assumed: ";
printf "# of A is %d, # of AAAA is %d (%s)\n",
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
}
sub judge {
my ($n, $n_ns) = @_;
return "green" if ($n >= $n_ns);
return "yellow" if ($n >= 2);
return "orange" if ($n == 1);
return "red";
}
sub atmost {
my ($a, $b) = @_;
return 0 if ($a < 0);
return $b if ($a > $b);
return $a;
}
6 - Security Considerations
The recommendations contained in this document have no known security
implications.
7 - IANA Considerations
This document does not call for changes or additions to any IANA
registry.
8 - Acknowledgement
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
for their valuable comments and suggestions.
Expires January 2007 [Page 10]
INTERNET-DRAFT August 2006 RESPSIZE
This work was supported by the US National Science Foundation (research
grant SCI-0427144) and DNS-OARC.
9 - References
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
RFC1034, November 1987.
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and
Specification", RFC1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", RFC1123, October 1989.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC1996, August 1996.
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
RFC2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
August 1999.
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
and Issues with IPV6 DNS", April 2006.
10 - Authors' Addresses
Paul Vixie
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
+1 650 423 1301
vixie@isc.org
Akira Kato
University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
+81 3 5841 2750
kato@wide.ad.jp
Expires January 2007 [Page 11]
INTERNET-DRAFT August 2006 RESPSIZE
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain
all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Expires January 2007 [Page 12]

784
doc/draft/draft-ietf-dnsop-respsize-14.txt Normal file
View file

@ -0,0 +1,784 @@
Internet Engineering Task Force P. Vixie
Internet-Draft Internet Systems Consortium
Intended status: Informational A. Kato
Expires: November 11, 2012 Keio University/WIDE Project
May 10, 2012
DNS Referral Response Size Issues
draft-ietf-dnsop-respsize-14
Abstract
With a mandated default minimum maximum UDP message size of 512
octets, the DNS protocol presents some special problems for zones
wishing to expose a moderate or high number of authority servers (NS
RRs). This document explains the operational issues caused by, or
related to this response size limit, and suggests ways to optimize
the use of this limited space. Guidance is offered to DNS server
implementors and to DNS zone operators.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 11, 2012.
Copyright Notice
Copyright (c) 2012 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
Vixie & Kato Expires November 11, 2012 [Page 1]
Internet-Draft DNS Referral Response Size May 2012
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.
1. Introduction and Overview
The original DNS standard limited the UDP message size to 512 octets
(see Section 4.2.1 of [RFC1035]). Even though this limitation was
due to the required minimum IP reassembly limit for IPv4, it became a
hard DNS protocol limit and is not implicitly relaxed by changes in a
network layer protocol, for example to IPv6.
The EDNS (Extension Mechanisms for DNS) protocol extension starting
with version 0 permits larger responses by mutual agreement of the
requester and responder (see Section 4.3 and Section 6.2 of
[RFC2671bis]), and it is recommended to support EDNS. The 512 octets
UDP message size limit will remain in practical effect until
virtually all DNS servers and resolvers support EDNS.
Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512
octets. Negative responses are quite small, but for positive and
referral responses, every octet must be carefully and sparingly
allocated. While the response size of positive responses is also a
concern in [RFC3226], this document specifically addresses referral
response size.
While more than twelve years passed since the publication of the
original EDNS0 document [RFC2671], approximately 65% of the clients
support it as observed at a root name server and this fraction has
not changed in recent few years. The long tail of EDNS deployment
may eventually be measured in decades.
Even if EDNS deployment reached 100% of all DNS initiators and
responders there will still be cases when path MTU limitations or IP
Vixie & Kato Expires November 11, 2012 [Page 2]
Internet-Draft DNS Referral Response Size May 2012
fragmentation/reassembly problems in firewalls and other middleboxes
will cause EDNS failures which leads to non-extended DNS retries. A
smaller referral response will always be better than a larger one if
the same end result can be achieved either way. See [RFC5625],
[SSAC035], and Section 6.2.6 of [RFC2671bis] for details.
2. Delegation Details
2.1. Relevant Protocol Elements
A positive delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: empty, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
Note: CNAME defines a canonical name ([RFC1034]) while DNAME maps an
entire subtree to another domain ([RFC2672]).
If the total size of the UDP response exceeds 512 octets or the size
advertised in EDNS, and if the data that does not fit was "required",
then the TC bit will be set (indicating truncation). This will
usually cause the requester to retry using TCP, depending on what
information was desired and what information was omitted. For
example, truncation in the authority section is of no interest to a
stub resolver who only plans to consume the answer section. If a
retry using TCP is needed, the total cost of the transaction is much
higher. See Section 6.1.3.2 of [RFC1123] for details on the
requirement that UDP be attempted before falling back to TCP.
RRsets (Resource Record Set, see [RFC2136]) are never sent partially
unless the TC bit is set to indicate truncation. When the TC bit is
set, the final apparent RRset in the final non-empty section must be
considered "possibly damaged" (see Section 6.2 of [RFC1035] and
Section 9 of [RFC2181]).
With or without truncation, the glue present in the additional data
section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets.
Note that truncation of the additional data section might not be
signaled via the TC bit since additional data is often optional (see
discussion in Appendix B of [RFC4472]).
DNS label compression allows the component labels of a domain name to
be instantiated exactly once per DNS message, and then referenced
with a two-octet "pointer" from other locations in that same DNS
Vixie & Kato Expires November 11, 2012 [Page 3]
Internet-Draft DNS Referral Response Size May 2012
message (see Section 4.1.4 of [RFC1035]). If all nameserver names in
a message share a common parent (for example, all of them are in
"ROOT-SERVERS.NET." zone), then more space will be available for
incompressible data (such as nameserver addresses).
The query name can be as long as 255 octets of network data. In this
worst case scenario, the question section will be 259 octets in size,
which would leave only 240 octets for the authority and additional
sections (after deducting 12 octets for the fixed length header) in a
referral.
2.2. Advice to Zone Owners
Average and maximum question section sizes can be predicted by the
zone owner, since they will know what names actually exist and can
measure which ones are queried for most often. Note that if the zone
contains any wildcards, it is possible for maximum length queries to
require positive responses, but that it is reasonable to expect
truncation and TCP retry in that case. For cost and performance
reasons, the majority of requests should be satisfied without
truncation or TCP retry.
Some queries to non-existing names can be large, but this is not a
problem because negative responses need not contain any answer,
authority or additional records. See Section 2.1 of [RFC2308] for
more information about the format of negative responses.
The minimum useful number of name servers is two, for redundancy (see
Section 4.1 of [RFC1034]). A zone's name servers should be reachable
by all IP protocols versions (e.g., IPv4 and IPv6) in common use. As
long as the servers are well managed, the server serving IPv6 might
be different from the server serving IPv4 sharing the same server
name.
The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically
requery for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary.
Anycasting [RFC3258] is a useful tool for performance and reliability
without increasing the size of referral responses.
While it is irrelevant to the response size issue, all zones have to
be served via IPv4 as well to avoid name space fragmentation
[RFC3901].
Vixie & Kato Expires November 11, 2012 [Page 4]
Internet-Draft DNS Referral Response Size May 2012
2.3. Advice to Server Implementors
Each NS RR for a zone will add 12 fixed octets (name, type, class,
ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
Each A RR will require 16 octets, and each AAAA RR will require 28
octets.
While DNS distinguishes between necessary and optional resource
records, this distinction is according to protocol elements necessary
to signify facts, and takes no official notice of protocol content
necessary to ensure correct operation. For example, a nameserver
name that is in or below the zone cut being described by a delegation
is "necessary content", since there is no way to reach that zone
unless the parent zone's delegation includes "glue records"
describing that name server's addresses.
Recall that the TC bit is only set when a required RRset can not be
included in its entirety (see Section 9 of [RFC2181]). Even when
some of the RRsets to be included in the additional section don't fit
in the response size, the TC bit isn't set. These RRsets may be
important for a referral. Some DNS implementations try to resolve
these missing glue records separately which will introduce extra
queries and extra time to resolve a given name.
A delegation response should prioritize glue records as follows.
first:
All glue RRsets for one name server whose name is in or below the
zone being delegated, or which has multiple address RRsets
(currently A and AAAA), or preferably both;
second:
Alternate between adding all glue RRsets for any name servers
whose names are in or below the zone being delegated, and all
glue RRsets for any name servers who have multiple address RRsets
(currently A and AAAA);
thence:
All other glue RRsets, in any order.
Whenever there are multiple candidates for a position in this
priority scheme, one should be chosen on a round-robin or fully
random basis. The goal of this priority scheme is to offer
"necessary" glue first to fill into the response if possible.
If any "necessary" content cannot be fit in the response, then it is
advisable that the TC bit be set in order to force a TCP retry,
rather than have the zone be unreachable. Note that a parent
server's proper response to a query for in-child glue or below-child
glue is a referral rather than an answer, and that this referral must
Vixie & Kato Expires November 11, 2012 [Page 5]
Internet-Draft DNS Referral Response Size May 2012
be able to contain the in-child or below-child glue, and that in
outlying cases, only EDNS or TCP will be large enough to contain that
data.
The glue record order should be independent of the version of IP used
in the query because the DNS server might just see a query from an
intermediate server rather than the query from the original client.
3. Analysis
An instrumented protocol trace of a best case delegation response is
shown in Figure 1. Note that 13 servers are named, and 13 addresses
are given. This query was artificially designed to exactly reach the
512 octets limit.
Vixie & Kato Expires November 11, 2012 [Page 6]
Internet-Draft DNS Referral Response Size May 2012
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 172800 NS E.GTLD-SERVERS.NET. ;; @112
com. 172800 NS F.GTLD-SERVERS.NET. ;; @128
com. 172800 NS G.GTLD-SERVERS.NET. ;; @144
com. 172800 NS H.GTLD-SERVERS.NET. ;; @160
com. 172800 NS I.GTLD-SERVERS.NET. ;; @176
com. 172800 NS J.GTLD-SERVERS.NET. ;; @192
com. 172800 NS K.GTLD-SERVERS.NET. ;; @208
com. 172800 NS L.GTLD-SERVERS.NET. ;; @224
com. 172800 NS M.GTLD-SERVERS.NET. ;; @240
com. 172800 NS A.GTLD-SERVERS.NET. ;; @256
com. 172800 NS B.GTLD-SERVERS.NET. ;; @272
com. 172800 NS C.GTLD-SERVERS.NET. ;; @288
com. 172800 NS D.GTLD-SERVERS.NET. ;; @304
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 172800 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 172800 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 172800 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 172800 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 172800 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 172800 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 172800 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 172800 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 172800 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 172800 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 172800 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 172800 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 172800 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
Figure 1
For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name
(which is "GTLD-SERVERS.NET." in this example) that all 13 addresses
are able to fit, due to the use of DNS compression pointers in the
last 12 occurrences of the parent domain name. The outputs from the
response simulator in Appendix A (written in perl [PERL]) shown in
Figure 2 and Figure 3 demonstrate these properties.
Vixie & Kato Expires November 11, 2012 [Page 7]
Internet-Draft DNS Referral Response Size May 2012
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
a.dns.br requires 10 bytes
b.dns.br requires 4 bytes
c.dns.br requires 4 bytes
d.dns.br requires 4 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Figure 2
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Figure 3
Here we use the term "green" if all address records could fit, or
"yellow" if two or more could fit, or "orange" if only one could fit,
or "red" if no address record could fit. It's clear that without a
common parent for nameserver names, much space would be lost. For
these examples we use an average/common name size of 15 octets,
befitting our assumption of "GTLD-SERVERS.NET." as our common parent
name.
We're assuming a medium query name size of 64 since that is the
typical size seen in trace data at the time of this writing. If
Internationalized Domain Name (IDN) or any other technology that
results in larger query names be deployed significantly in advance of
Vixie & Kato Expires November 11, 2012 [Page 8]
Internet-Draft DNS Referral Response Size May 2012
EDNS, then new measurements and new estimates will have to be made.
4. Conclusions
The current practice of giving all nameserver names a common parent
(such as "GTLD-SERVERS.NET." or "ROOT-SERVERS.NET.") saves space in
DNS responses and allows for more nameservers to be enumerated than
would otherwise be possible, since the common parent domain name only
appears once in a DNS message and is referred to via "compression
pointers" thereafter.
If all nameserver names for a zone share a common parent, then it is
operationally advisable to make all servers for the zone thus served
also be authoritative for the zone of that common parent. For
example, the root name servers (?.ROOT-SERVERS.NET.) can answer
authoritatively for the ROOT-SERVERS.NET. zone. This is to ensure
that the zone's servers always have the zone's nameservers' glue
available when delegating, and will be able to respond with answers
rather than referrals if a requester who wants that glue comes back
asking for it. In this case the name server will likely be a
"stealth server" -- authoritative but unadvertised in the glue zone's
NS RRset. See Section 2 of [RFC1996] for more information about
stealth servers.
Thirteen (13) is the effective maximum number of nameserver names
usable with traditional (non-extended) DNS, assuming a common parent
domain name, and given that implicit referral response truncation is
undesirable in the average case.
More than one address record in a protocol family per server is
inadvisable since the necessary glue RRsets (A or AAAA) are
atomically indivisible, and will be larger than a single resource
record. Larger RRsets are more likely to lead to or encounter
truncation.
More than one address record across protocol families is less likely
to lead to or encounter truncation, partly because multiprotocol
clients, which are required to handle larger RRsets such as AAAA RRs,
are more likely to speak EDNS, which can use a larger UDP response
size limit, and partly because the resource records (A and AAAA) are
in different RRsets and are therefore divisible from each other.
Name server names that are at or below the zone they serve are more
sensitive to referral response truncation, and glue records for them
should be considered "more important" than other glue records, in the
assembly of referral responses.
Vixie & Kato Expires November 11, 2012 [Page 9]
Internet-Draft DNS Referral Response Size May 2012
5. Security Considerations
The recommendations contained in this document have no known security
implications.
6. IANA Considerations
This document does not call for changes or additions to any IANA
registry.
7. Acknowledgement
The authors thank Peter Koch, Rob Austein, Joe Abley, Mark Andrews,
Kenji Rikitake, Stephane Bortzmeyer, Olafur Gudmundsson, Alfred
Hoenes, Alexander Mayrhofer, and Ray Bellis for their valuable
comments and suggestions.
This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC.
8. References
8.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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
8.2. Informative References
[PERL] Wall, L., Christiansen, T., and J. Orwant, "Programming
Perl, 3rd ed.", ISBN 0-596-00027-8, July 2000.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
Vixie & Kato Expires November 11, 2012 [Page 10]
Internet-Draft DNS Referral Response Size May 2012
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2671bis]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 ,
February 2012.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
[SSAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
Broadband Routers and Firewalls", SSAC 035,
September 2008.
Appendix A. The response simulator program
#!/usr/bin/perl
#
# SYNOPSIS
# respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have a same zone suffix,
# such as "jp" in JP TLD servers, specify it in -z option
#
Vixie & Kato Expires November 11, 2012 [Page 11]
Internet-Draft DNS Referral Response Size May 2012
use strict;
use Getopt::Std;
my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0;
getopt('z', %opts);
if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it
}
foreach $name (@ARGV) {
my $len;
$n_ns++;
$len = server_name_len($name);
print "$name requires $len bytes\n";
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
+ $sz_rdlen + $len;
}
print "# of NS: $n_ns\n";
arsect(255, $nssect, $n_ns, "maximum");
arsect(64, $nssect, $n_ns, "average");
sub server_name_len {
my ($name) = @_;
my (@labels, $len, $n, $suffix);
$name =~ tr/A-Z/a-z/;
@labels = split(/\./, $name);
$len = length(join('.', @labels)) + 2;
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
$suffix = join('.', @labels);
return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix}));
$namedb{$suffix} = 1;
}
return $len;
}
sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
Vixie & Kato Expires November 11, 2012 [Page 12]
Internet-Draft DNS Referral Response Size May 2012
$n_a_aaaa = atmost(int($space
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
/ $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf " only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf " A and AAAA are considered: ";
printf "# of A+AAAA is %d (%s)\n",
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
printf " preferred-glue A is assumed: ";
printf "# of A is %d, # of AAAA is %d (%s)\n",
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
}
sub judge {
my ($n, $n_ns) = @_;
return "green" if ($n >= $n_ns);
return "yellow" if ($n >= 2);
return "orange" if ($n == 1);
return "red";
}
sub atmost {
my ($a, $b) = @_;
return 0 if ($a < 0);
return $b if ($a > $b);
return $a;
}
Authors' Addresses
Paul Vixie
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423 1300
Email: vixie@isc.org
Vixie & Kato Expires November 11, 2012 [Page 13]
Internet-Draft DNS Referral Response Size May 2012
Akira Kato
Keio University/WIDE Project
Graduate School of Media Design, 4-1-1 Hiyoshi
Kohoku, Yokohama 223-8526
JP
Phone: +81 45 564 2490
Email: kato@wide.ad.jp
Vixie & Kato Expires November 11, 2012 [Page 14]

1235
doc/draft/draft-irtf-rrg-ilnp-dns-05.txt
View file

File diff suppressed because it is too large Load diff

282
doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt → doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt
View file

@ -3,19 +3,22 @@
Domain Name System Operations W. Mekking
Internet-Draft NLnet Labs
Intended status: Standards Track June 29, 2010
Expires: December 31, 2010
Intended status: Standards Track December 21, 2010
Expires: June 24, 2011
Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
draft-mekking-dnsop-auto-cpsync-00
draft-mekking-dnsop-auto-cpsync-01
Abstract
This document proposes a way to synchronise existing trust anchors
automatically between a child zone and its parent. The algorithm can
automatically between a child zone and its parent. The protocol can
be used for other Resource Records that are required to delegate from
a parent to a child such as NS and glue records.
a parent to a child such as NS and glue records. The synchronization
allows for a third party to be involved, thus the protocol is
suitable for both cases, whether you have to communicate to the
registry or to the registrar.
Requirements Language
@ -38,7 +41,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2010.
This Internet-Draft will expire on June 24, 2011.
Copyright Notice
@ -46,17 +49,17 @@ Copyright Notice
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Mekking Expires June 24, 2011 [Page 1]
Internet-Draft Child Parent Synchronization December 2010
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
Mekking Expires December 31, 2010 [Page 1]
Internet-Draft Child Parent Synchronization June 2010
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
@ -66,9 +69,12 @@ Internet-Draft Child Parent Synchronization June 2010
1. Introduction
This memo defines a way to synchronise existing trust anchors
automatically between a child zone and its parent. The algorithm can
automatically between a child zone and its parent. The protocol can
be used for other Resource Records that are required to delegate from
a parent to a child such as NS and glue records.
a parent to a child such as NS and glue records. The synchronization
allows for a third party to be involved, thus the protocol is
suitable for both cases, whether you have to communicate to the
registry or to the registrar.
To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
must submit their DNSKEYs, or hashes of their DNSKEYs, to their
@ -82,37 +88,60 @@ Internet-Draft Child Parent Synchronization June 2010
The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
changes to the parent.
To bootstrap the direct communication channel, information must be
exchanged in order to detect service location and granting update
privileges. A new or existing child zone can request a direct
communication channel with the parent. If the parent allows for
direct communication with child zones, the parent can share the
required data to set up the channel to the child zone. Once the
child has the required credentials, it can use the direct
communication channel with the parent to request zone changes related
to its delegation.
To bootstrap the communication channel, information must be exchanged
in order to detect service location and granting update privileges.
A new or existing child zone is in need of a communication channel
with the parent. This can be a direct channel or a channel through a
third party:
If a third party is involved, the third party can act on behalf of
the parent. In this case, the third party will give out the required
credentials to set up the communication channel.
If the parent allows for direct communication channel with child
zones, the parent can share the required data to set up the
channel to the child zone. Once the child has the required
credentials, it can use the direct communication channel with the
parent to request zone changes related to its delegation.
It is RECOMMENDED that the direct communication channel is secured
with TSIG [RFC2845] or SIG0 [RFC2931].
If a third party is involved, the third party acts on behalf of
the parent. In this case, the third party will give out the
required credentials to set up the communication channel.
2. Access and Update Control
Allowing for a third party in the communication channel ensures
Mekking Expires June 24, 2011 [Page 2]
Internet-Draft Child Parent Synchronization December 2010
flexibility of the service location.
Please note that the document only describes the front end of the
synchronization service. The first reason for that is that it is not
necessary to write down how the DNS UPDATE is processed after it is
accepted. It is merely a goal to provide a way for the child zone to
automatically update the records at the zone cut. The second reason
is that flexibility is needed in order to fit the protocol into the
multifarious policies that exist among the great number of
registrars.
Thus, it is not required that the DNS UPDATE immediately updates the
name server. Thus, it would still be possible to monitor the
incoming updates with the tools of your choice. It is not a
replacement of your RR provisioning system. The records in the DNS
UPDATE can be converted into any kind of format.
2. Service Discovery
The service location is handed out during bootstrap. If this
information is missing or incorrect, the normal guidelines for
sending DNS UPDATE messages SHOULD be followed.
3. Access and Update Control
The DNS UPDATE normally is used for granting update permissions to a
machine that is within the boundary of the same organization. This
document proposes to grant child zones the same permissions.
However, it MUST NOT be possible that a child zone updates
Mekking Expires December 31, 2010 [Page 2]
Internet-Draft Child Parent Synchronization June 2010
information in the parent zone that falls outside the administrative
domain of the corresponding delegation. For example, it MUST NOT be
possible for a child zone to update the data that the parent is
@ -124,23 +153,34 @@ Internet-Draft Child Parent Synchronization June 2010
delegation specific. Currently those are records with RRtype NS
or DS.
Or: The owner name is a subdomain of the child zone name and RRtype
is glue specific. Currently those are records with RRtype A or
AAAA.
Or: The owner name exists in the right side of the NS RRset
belonging to the child zone and RRtype is is glue specific.
Currently those are records with RRtype A or AAAA.
This list may be expanded in the future, if there is need for more
delegation related zone content.
We can make a distinction here between narrow and wide glue records.
Narrow glue records are said to be glue specific records with an
owner name that is a subdomain of the child zone. Wide glue records
are glue specific records with an owner name that is outside of the
Mekking Expires June 24, 2011 [Page 3]
Internet-Draft Child Parent Synchronization December 2010
delegated child domain.
These updates MAY be refused if it conflicts with the local policy.
This list may be expanded, if there is need for more delegation
related zone content.
In case of adding or deleting delegation specific records, the DNSSEC
related RRs in the parent zone might need to be updated.
The service location may be handed out by the registrar during
bootstrap If this information is missing, the normal guidelines for
sending DNS UPDATE messages SHOULD be followed.
4. Update Mechanism
3. Update Mechanism
3.1. Child Duties
4.1. Update Request
Updating the NS RRset or corresponding glue at the parent, an update
can be sent at any time. Updating the DS RRset is part of key
@ -156,34 +196,35 @@ Internet-Draft Child Parent Synchronization June 2010
this document, the child should poll the parent zone for a short
time, until the DS is visible at all parent name servers.
To discuss: A child zone might be unable to reach all parent name
servers.
[Author's note] To discuss: A child zone might be unable to reach all
parent name servers.
The child notifies the parent of the requested changes by sending a
DNS UPDATE message. If it receives a NOERROR reply in return, the
Mekking Expires December 31, 2010 [Page 3]
Internet-Draft Child Parent Synchronization June 2010
update is acknowledged by the parent zone. Otherwise, the child MAY
retry transmitting the update. In order to prevent duplicate
updates, it SHOULD follow the guidelines described in RFC 2136
[RFC2136].
3.2. Parent Duties
4.2. Processing the Update
When the master DNS server of the parent receives a DNS UPDATE from
one of its children the following must be done:
An incoming DNS UPDATE message is processed as follows:
Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the
parent should follow the TSIG processing described in section 3.2
of RFC 2845. In case of SIG0, the parent should follow the SIG0
processing described in section 3.2 of RFC 2931.
Mekking Expires June 24, 2011 [Page 4]
Internet-Draft Child Parent Synchronization December 2010
Step 2: Verify that the updates matches the update policy for child
zones.
@ -193,15 +234,9 @@ Internet-Draft Child Parent Synchronization June 2010
Step 4: If verified, apply changes. How that is done is a matter of
policy.
3.3. Proxy considerations
5. Examples
Some environments don't allow for direct communication between parent
and child zone. In these case, the parent duties can be performed by
a different party (for example, the registar). The third party will
forward the update to the parent zone. In what format depends on
local policy.
4. Example BIND9 Configuration
5.1. Example BIND9 Configuration
This is how a parent zone can configure a policy to enable a child
zone synchronize delegation specific records. The first rule of the
@ -217,14 +252,6 @@ Internet-Draft Child Parent Synchronization June 2010
key math.example.com. {
algorithm HMAC-MD5;
Mekking Expires December 31, 2010 [Page 4]
Internet-Draft Child Parent Synchronization June 2010
secret "secretformath";
}
@ -238,31 +265,79 @@ Internet-Draft Child Parent Synchronization June 2010
};
};
5. Security Considerations
6. Security Considerations
Automating the synchronization of (DNSSEC) records between the parent
and child created a new channel. We have recommended that this
channel should be secured with TSIG or SIG0. There is an advantage
and a disadvantage of the new security channel. The disadvantage is
that you create a new attack window for your DNSSEC credentials. If
the automated synchronization is used for updating DS records at the
parent, you SHOULD pick a cryptographically an equally strong or
stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
and child creates a new communication channel. It is up to the
policy of the parent, or the third party acting on behalf of the
parent, who is allowed such privileges. A policy would usually
include a form of access control. It is recommended that it involves
transaction authentication, for example TSIG [RFC2845] or SIG0
Mekking Expires June 24, 2011 [Page 5]
Internet-Draft Child Parent Synchronization December 2010
[RFC2931].
In the jungle of the DNS, many stakeholders exist. The registrant of
a zone might not be the one that maintains the zone. That can
possibly mean that many stakeholders need to possess the security
credentials in order to use this synchronization channel. However,
this problem exist with any kind of transaction authentication.
The disadvantage of adding a new communication channel is that you
create a new attack window onto your DNS and DNSSEC records. When
using this synchronization method for your DNSSEC records, a
cryptographically equally strong, or stronger private key SHOULD be
used, compared to the strength of your DNSSEC keys.
The advantage is that if somehow your DNSSEC keys are compromised,
you can still use this channel to perform an emergency key rollover.
6. IANA Considerations
7. IANA Considerations
None.
7. Acknowledgments
8. Acknowledgments
Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
Mark Andrews, Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards.
8. References
9. Changelog
8.1. Informative References
01:
- Make it clear that the solution is flexible and it can fit into
many and diverse environments of registrars.
- Short section about service discovery.
- Add text about narrow glue records.
- Add text about transaction authentication concerns with respect
to many stakeholders involved.
00:
- Initial document
10. References
Mekking Expires June 24, 2011 [Page 6]
Internet-Draft Child Parent Synchronization December 2010
10.1. Informative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
@ -274,14 +349,7 @@ Internet-Draft Child Parent Synchronization June 2010
[keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
Timing Considerations", March 2010.
Mekking Expires December 31, 2010 [Page 5]
Internet-Draft Child Parent Synchronization June 2010
8.2. Normative References
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
@ -320,17 +388,5 @@ Author's Address
Mekking Expires December 31, 2010 [Page 6]
Mekking Expires June 24, 2011 [Page 7]

300
doc/draft/draft-yao-dnsext-bname-04.txt → doc/draft/draft-yao-dnsext-bname-05.txt
View file

@ -3,13 +3,13 @@
Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Standards Track CNNIC
Expires: February 12, 2011 P. Vixie
Expires: February 20, 2011 P. Vixie
Internet Software Consortium
August 11, 2010
August 19, 2010
Bundle DNS Name Redirection
draft-yao-dnsext-bname-04.txt
Bundled DNS Name Redirection
draft-yao-dnsext-bname-05.txt
Abstract
@ -34,7 +34,7 @@ Status of this Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2011.
This Internet-Draft will expire on February 20, 2011.
Copyright Notice
@ -51,7 +51,7 @@ Copyright Notice
Yao, et al. Expires February 12, 2011 [Page 1]
Yao, et al. Expires February 20, 2011 [Page 1]
Internet-Draft bname August 2010
@ -81,33 +81,33 @@ Table of Contents
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4
3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5
4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8
5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9
5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11
9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11
9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11
9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12
9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12
9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12
9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12
9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13
9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Yao, et al. Expires February 12, 2011 [Page 2]
Yao, et al. Expires February 20, 2011 [Page 2]
Internet-Draft bname August 2010
@ -163,7 +163,7 @@ Internet-Draft bname August 2010
Yao, et al. Expires February 12, 2011 [Page 3]
Yao, et al. Expires February 20, 2011 [Page 3]
Internet-Draft bname August 2010
@ -212,18 +212,46 @@ Internet-Draft bname August 2010
restriction applies only to records of the same class as the BNAME
record.
3.4. BNAME Examples
4. Query Processing
To exploit the BNAME mechanism the name resolution algorithms
The table below shows some examples of the BNAME usage.
Yao, et al. Expires February 12, 2011 [Page 4]
Yao, et al. Expires February 20, 2011 [Page 4]
Internet-Draft bname August 2010
QNAME owner BNAME target result
---------------- -------------- -------------- -----------------
com. example.com. example.net. <no match>
com. com. net. net.
example.com. example.com. example.net. example.net.
a.example.com. example.com. example.net. a.example.net.
a.b.example.com. example.com. example.net. a.b.example.net.
ab.example.com. b.example.com. example.net. <no match>
bar.example.com. example.com. example.net. bar.example.net.
a.b.example.com. b.example.com. example.net. a.example.net.
a.example.com. example.com. b.example.net. a.b.example.net.
Table 1. BNAME Usage Examples.
If the owner name of the CNAME RR is regarded as the target of the MX
RR, it may cause some problems. Some mail servers may directly
connect the owner name of the CNAME instead of the name pointed by
CNAME for mail delivery and cause the undelivery of the mails. BNAME
has the similar problems with CNAME. This document specifies that
the owner name of the BNAME should not be the targets of some RRs
such as MX, SRV and PTR. In case that the owner name of the BNAME RR
is the target of some RRs, it should be cautious.
4. Query Processing
To exploit the BNAME mechanism the name resolution algorithms
[RFC1034] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
substitution on a name (either QNAME or SNAME) under control of a
@ -244,42 +272,22 @@ Internet-Draft bname August 2010
If the owner name of the bname is same with the name queryed, when
preparing a response, a server performing a BNAME substitution will
Yao, et al. Expires February 20, 2011 [Page 5]
Internet-Draft bname August 2010
not include the relevant BNAME RR in the answer section unless the
type queryed is BNAME. A CNAME RR will be synthesized and included
in the answer section unless the type queryed is BNAME or the query
is the DNSSEC query.
in the answer section unless the type queryed is BNAME.
The provided synthesized CNAME RR if there has one, MUST have
Yao, et al. Expires February 12, 2011 [Page 5]
Internet-Draft bname August 2010
The same CLASS as the QCLASS of the query,
TTL equal to the corresponding BNAME RR,
@ -323,15 +331,7 @@ Internet-Draft bname August 2010
Yao, et al. Expires February 12, 2011 [Page 6]
Yao, et al. Expires February 20, 2011 [Page 6]
Internet-Draft bname August 2010
@ -387,7 +387,7 @@ Internet-Draft bname August 2010
Yao, et al. Expires February 12, 2011 [Page 7]
Yao, et al. Expires February 20, 2011 [Page 7]
Internet-Draft bname August 2010
@ -443,7 +443,7 @@ Internet-Draft bname August 2010
Yao, et al. Expires February 12, 2011 [Page 8]
Yao, et al. Expires February 20, 2011 [Page 8]
Internet-Draft bname August 2010
@ -499,7 +499,7 @@ Internet-Draft bname August 2010
Yao, et al. Expires February 12, 2011 [Page 9]
Yao, et al. Expires February 20, 2011 [Page 9]
Internet-Draft bname August 2010
@ -535,7 +535,64 @@ Internet-Draft bname August 2010
algorithm identifiers are used with the BNAME hash algorithm SHA1.
Using other BNAME hash algorithms requires allocation of a new alias.
Validating resolvers which follow the BNAME specification MUST
recognize the new alias algorithm identifier.
recognize the new alias algorithm identifier. The future new DNSSEC
algorithms are suggested to indicate the support of BNAME.
5.3. Signaling of BNAME
A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can
be used to signal that the resolvers can understand BNAME in DNSSEC.
BNAME aware resolvers can set the Understand-BNAME (UB bit) to
receive a response without the synthesized CNAMEs. The UB bit is
part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers
should set this in a query to request omission of the synthesized
CNAMEs.
If the query is a DNSSEC query, the BNAME enabled resolvers MUST set
the UB bit in the query. The server receiving the UB bit MUST not
issue synthesized CNAMEs. Servers copy the UB bit to the response,
and should delete the synthesized CNAMEs from the answer if there has
Yao, et al. Expires February 20, 2011 [Page 10]
Internet-Draft bname August 2010
one.
If the query is the DNSSEC query but the UB bit is not set, the
server should follow the rules below:
o If the owner name of the bname is the suffix of the name queryed
but different, when preparing a response, a server performing a
BNAME substitution will in all cases include the relevant BNAME RR
in the answer section. An unsigned CNAME RR is synthesized and
included in the answer section. This will help the client to
reach the correct DNS data.
o If the owner name of the bname is same with the name queryed, when
preparing a response, a DNSSEC enabled server performing a BNAME
substitution will not include the relevant BNAME RR and its RRSIG
RR in the answer section unless the type queryed is BNAME. An
unsigned CNAME RR will be synthesized and included in the answer
section unless the type queryed is BNAME.
o Since the BNAME-unaware DNSSEC resolvers do not know the alias
algorithm defined in secton 5.2 of this document, any response
from these zones signed with these alias algorithms unknown to
them will be regarded as the insecure one according to section 5.2
of [RFC4035].
Below are Updated EDNS extended RCODE and Flags fields [RFC2671]:
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UB| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6. IANA Considerations
@ -544,22 +601,24 @@ Internet-Draft bname August 2010
the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is
requested to assign the number to Y and Z.
[[anchor14: Note in draft: before this document goes to WG Last call,
[[anchor15: Note in draft: before this document goes to WG Last call,
it is better that we list all DNSSEC algorithms that need to be
aliased to reflect compatibility with this extension.]]
Yao, et al. Expires February 20, 2011 [Page 11]
Internet-Draft bname August 2010
7. Security Considerations
Both ASCII domain name labels and non-ASCII ones have some aliases.
Yao, et al. Expires February 12, 2011 [Page 10]
Internet-Draft bname August 2010
We can bundle the domain name labels and their aliases through BNAME
in the DNS resolutions. The name labels and their aliases in the
particular languages are only known by those who know these
@ -583,7 +642,7 @@ Internet-Draft bname August 2010
9. Change History
[[anchor17: RFC Editor: Please remove this section.]]
[[anchor18: RFC Editor: Please remove this section.]]
9.1. draft-yao-dnsext-bname: Version 00
@ -605,17 +664,26 @@ Internet-Draft bname August 2010
o Update the IANA consideration
10. References
Yao, et al. Expires February 12, 2011 [Page 11]
Yao, et al. Expires February 20, 2011 [Page 12]
Internet-Draft bname August 2010
9.5. draft-yao-dnsext-bname: Version 04
o Improve the text
9.6. draft-yao-dnsext-bname: Version 05
o add section: bname examples
o add section: Signaling of BNAME
10. References
10.1. Normative References
[ASCII] American National Standards Institute (formerly United
@ -652,6 +720,14 @@ Internet-Draft bname August 2010
(RR) Types", RFC 3597, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Yao, et al. Expires February 20, 2011 [Page 13]
Internet-Draft bname August 2010
10646", RFC 3629, November 2003.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
@ -664,14 +740,6 @@ Internet-Draft bname August 2010
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Yao, et al. Expires February 12, 2011 [Page 12]
Internet-Draft bname August 2010
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
@ -702,6 +770,20 @@ Authors' Addresses
Email: yaojk@cnnic.cn
Yao, et al. Expires February 20, 2011 [Page 14]
Internet-Draft bname August 2010
Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
@ -723,7 +805,37 @@ Authors' Addresses
Yao, et al. Expires February 12, 2011 [Page 13]
Yao, et al. Expires February 20, 2011 [Page 15]

1320
doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt → doc/rfc/rfc5936.txt
View file

File diff suppressed because it is too large Load diff

602
doc/draft/draft-ietf-6man-text-addr-representation-07.txt → doc/rfc/rfc5952.txt
View file

@ -1,62 +1,67 @@
IPv6 Maintenance Working Group S. Kawamura
Internet-Draft NEC BIGLOBE, Ltd.
Updates: 4291 (if approved) M. Kawashima
Intended status: Standards Track NEC AccessTechnica, Ltd.
Expires: August 29, 2010 February 25, 2010
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
draft-ietf-6man-text-addr-representation-07
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 RFC 4291 section 2.2 describes a flexible model for
text representation of an IPv6 address this flexibility has been
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 is
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.
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
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This is an Internet Standards Track document.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2010.
Kawamura & Kawashima Standards Track [Page 1]
RFC 5952 IPv6 Text Representation August 2010
Copyright Notice
Kawamura & Kawashima Expires August 29, 2010 [Page 1]
Internet-Draft IPv6 Text Representation February 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
@ -68,7 +73,7 @@ Internet-Draft IPv6 Text Representation February 2010
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 BSD License.
described in the Simplified BSD License.
@ -106,21 +111,19 @@ Internet-Draft IPv6 Text Representation February 2010
Kawamura & Kawashima Expires August 29, 2010 [Page 2]
Kawamura & Kawashima Standards Track [Page 2]
Internet-Draft IPv6 Text Representation February 2010
RFC 5952 IPv6 Text Representation August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4
2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 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
@ -130,43 +133,43 @@ Table of Contents
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 9
4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
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.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. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Text Representation of Special Addresses . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
Kawamura & Kawashima Expires August 29, 2010 [Page 3]
Kawamura & Kawashima Standards Track [Page 3]
Internet-Draft IPv6 Text Representation February 2010
RFC 5952 IPv6 Text Representation August 2010
1. Introduction
@ -192,9 +195,9 @@ Internet-Draft IPv6 Text Representation February 2010
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.
Also, a canonical representation format to avoid problems is
introduced in Section 4.
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
@ -202,27 +205,27 @@ Internet-Draft IPv6 Text Representation February 2010
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Text Representation Flexibility of RFC4291
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
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 such as the following
example. The final 16 bit field is different, but all these
addresses represent the same address.
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 Expires August 29, 2010 [Page 4]
Kawamura & Kawashima Standards Track [Page 4]
Internet-Draft IPv6 Text Representation February 2010
RFC 5952 IPv6 Text Representation August 2010
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
@ -238,15 +241,15 @@ Internet-Draft IPv6 Text Representation February 2010
'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 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 case where there is more than one zero fields, there is a choice
of how many fields can be shortened.
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
@ -256,7 +259,7 @@ Internet-Draft IPv6 Text Representation February 2010
2001:db8::1
In addition, [RFC4291] in section 2.2 notes,
In addition, Section 2.2 of [RFC4291] notes,
'The "::" can only appear once in an address.'
@ -267,27 +270,30 @@ Internet-Draft IPv6 Text Representation February 2010
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.
Kawamura & Kawashima Expires August 29, 2010 [Page 5]
Internet-Draft IPv6 Text Representation February 2010
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
@ -295,53 +301,53 @@ Internet-Draft IPv6 Text Representation February 2010
3.1.1. General Summary
A search of an IPv6 address if conducted through a UNIX system is
usually case sensitive and extended options to allow for regular
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
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 a text using regular expression. Moreover,
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 application to manage IP
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 problem is, when the search is
being conducted to assign a new address from a pool, and a check was
being done to see if it was not in use. This may cause problems to
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 also in ISPs.
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
Kawamura & Kawashima Expires August 29, 2010 [Page 6]
Internet-Draft IPv6 Text Representation February 2010
was a need to register the same address 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, this is worth mentioning since the
problems encountered are mostly equal.
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
@ -352,20 +358,21 @@ Internet-Draft IPv6 Text Representation February 2010
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 MTTR in times of trouble.
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 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.
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
@ -375,27 +382,30 @@ Internet-Draft IPv6 Text Representation February 2010
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 will mean the same.
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
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:
Kawamura & Kawashima Expires August 29, 2010 [Page 7]
Internet-Draft IPv6 Text Representation February 2010
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
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.
@ -403,7 +413,7 @@ Internet-Draft IPv6 Text Representation February 2010
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
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
@ -435,24 +445,23 @@ Internet-Draft IPv6 Text Representation February 2010
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 have the same skill in IPv6 technology.
The network operations center will have to take extra steps to
Kawamura & Kawashima Expires August 29, 2010 [Page 8]
Internet-Draft IPv6 Text Representation February 2010
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 address cannot be
abbreviated.
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
@ -463,9 +472,9 @@ Internet-Draft IPv6 Text Representation February 2010
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 an
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 clarify that it is uppercase, which is unnecessary
people tend to specify that it is uppercase, which is unnecessary
information.
3.4. Other Minor Problems
@ -474,7 +483,7 @@ Internet-Draft IPv6 Text Representation February 2010
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.
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.
@ -490,105 +499,104 @@ Internet-Draft IPv6 Text Representation February 2010
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
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
Kawamura & Kawashima Expires August 29, 2010 [Page 9]
Internet-Draft IPv6 Text Representation February 2010
generating an address to represent 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.
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
4.2.1. Shorten as Much as Possible
The use of symbol "::" MUST be used to its maximum capability. For
example, 2001:db8::0:1 is not acceptable, because the symbol "::"
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
4.2.2. Handling One 16-Bit 0 Field
The symbol "::" MUST NOT be used to shorten just 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.
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
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. Lower Case
4.3. Lowercase
The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
be represented in lower case.
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 [I-D.ietf-behave-address-format] have
IPv4 addresses embedded in the low-order 32 bits of the address.
These addresses have special representation that may mix hexadecimal
and dot decimal notations. The decimal notation may be used only for
Kawamura & Kawashima Expires August 29, 2010 [Page 10]
Internet-Draft IPv6 Text Representation February 2010
the last 32 bits of the address. For these addresses, mixed notation
is RECOMMENDED if the following condition is met: The address can be
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.
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
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.
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 exact
match in a search (no dot decimals whatsoever) and recommendation to
help the readability of an addresses (dot decimal whenever possible)
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 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
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
When IPv6 addresses and port numbers are represented in text combined
together, there are many different ways to do so. Examples are shown
below.
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
@ -604,30 +612,28 @@ Internet-Draft IPv6 Text Representation February 2010
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
IPv6 addresses. This style is NOT RECOMMENDED for 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
Kawamura & Kawashima Expires August 29, 2010 [Page 11]
Kawamura & Kawashima Standards Track [Page 11]
Internet-Draft IPv6 Text Representation February 2010
RFC 5952 IPv6 Text Representation August 2010
address literals, [RFC3986] MUST be followed, as well as the rules in
this document.
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 just the same as problems encountered with
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
@ -635,65 +641,95 @@ Internet-Draft IPv6 Text Representation February 2010
security risk if used for access control. The common practice of
comparing X.509 data is done in binary format.
9. IANA Considerations
None.
10. Acknowledgements
9. Acknowledgements
The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
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
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 the light of IETF working groups.
this document to light in IETF working groups.
10. References
11. References
10.1. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
Kawamura & Kawashima Expires August 29, 2010 [Page 12]
Kawamura & Kawashima Standards Track [Page 12]
Internet-Draft IPv6 Text Representation February 2010
RFC 5952 IPv6 Text Representation August 2010
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
10.2. Informative References
11.2. Informative References
[ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators",
Work in Progress, July 2010.
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-04 (work in progress),
January 2010.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[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.
[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
@ -705,7 +741,6 @@ Appendix A. For Developers
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
@ -715,18 +750,7 @@ Authors' Addresses
JAPAN
Phone: +81 3 3798 6085
Email: kawamucho@mesh.ad.jp
Kawamura & Kawashima Expires August 29, 2010 [Page 13]
Internet-Draft IPv6 Text Representation February 2010
EMail: kawamucho@mesh.ad.jp
Masanobu Kawashima
@ -736,7 +760,7 @@ Internet-Draft IPv6 Text Representation February 2010
JAPAN
Phone: +81 537 23 9655
Email: kawashimam@necat.nec.co.jp
EMail: kawashimam@necat.nec.co.jp
@ -759,27 +783,5 @@ Internet-Draft IPv6 Text Representation February 2010
Kawamura & Kawashima Expires August 29, 2010 [Page 14]
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

1585
doc/draft/draft-ietf-behave-dns64-11.txt → doc/rfc/rfc6147.txt
View file

File diff suppressed because it is too large Load diff

713
doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt → doc/rfc/rfc6168.txt
View file

File diff suppressed because it is too large Load diff

1005
doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt → doc/rfc/rfc6672.txt
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

757
doc/draft/draft-ietf-dnsext-dnssec-bis-updates-19.txt → doc/rfc/rfc6840.txt
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]

8
lib/dns/dns64.c
View file

@ -63,7 +63,7 @@ dns_dns64_create(isc_mem_t *mctx, isc_netaddr_t *prefix,
unsigned int nbytes = 16;
REQUIRE(prefix != NULL && prefix->family == AF_INET6);
/* Legal prefix lengths from draft-ietf-behave-address-format-04. */
/* Legal prefix lengths from rfc6052.txt. */
REQUIRE(prefixlen == 32 || prefixlen == 40 || prefixlen == 48 ||
prefixlen == 56 || prefixlen == 64 || prefixlen == 96);
REQUIRE(isc_netaddr_prefixok(prefix, prefixlen) == ISC_R_SUCCESS);
@ -73,7 +73,7 @@ dns_dns64_create(isc_mem_t *mctx, isc_netaddr_t *prefix,
static const unsigned char zeros[16];
REQUIRE(prefix->family == AF_INET6);
nbytes = prefixlen / 8 + 4;
/* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */
/* Bits 64-71 are zeros. rfc6052.txt */
if (prefixlen >= 32 && prefixlen <= 64)
nbytes++;
REQUIRE(memcmp(suffix->type.in6.s6_addr, zeros, nbytes) == 0);
@ -169,13 +169,13 @@ dns_dns64_aaaafroma(const dns_dns64_t *dns64, const isc_netaddr_t *reqaddr,
INSIST(nbytes <= 12);
/* Copy prefix. */
memmove(aaaa, dns64->bits, nbytes);
/* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */
/* Bits 64-71 are zeros. rfc6052.txt */
if (nbytes == 8)
aaaa[nbytes++] = 0;
/* Copy mapped address. */
for (i = 0; i < 4U; i++) {
aaaa[nbytes++] = a[i];
/* Bits 64-71 are zeros. draft-ietf-behave-address-format-04 */
/* Bits 64-71 are zeros. rfc6052.txt */
if (nbytes == 8)
aaaa[nbytes++] = 0;
}

2
lib/dns/rdata/generic/tlsa_52.c
View file

@ -16,7 +16,7 @@
/* $Id$ */
/* draft-ietf-dane-protocol-19.txt */
/* rfc6698.txt */
#ifndef RDATA_GENERIC_TLSA_52_C
#define RDATA_GENERIC_TLSA_52_C

2
lib/dns/rdata/generic/tlsa_52.h
View file

@ -20,7 +20,7 @@
#define GENERIC_TLSA_52_H 1
/*!
* \brief per draft-ietf-dane-protocol-19.txt
* \brief per rfc6698.txt
*/
typedef struct dns_rdata_tlsa {
dns_rdatacommon_t common;