<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
<!--
- - Copyright (C) 2004-2010, 2012-2014 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010, 2013 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
<year>2008</year>
<year>2009</year>
<year>2010</year>
- <year>2012</year>
<year>2013</year>
- <year>2014</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Lewis
+Request for Comments: 5936 NeuStar, Inc.
+Updates: 1034, 1035 A. Hoenes, Ed.
+Category: Standards Track TR-Sys
+ISSN: 2070-1721 June 2010
+
+
+ DNS Zone Transfer Protocol (AXFR)
+
+Abstract
+
+ The standard means within the Domain Name System protocol for
+ maintaining coherence among a zone's authoritative name servers
+ consists of three mechanisms. Authoritative Transfer (AXFR) is one
+ of the mechanisms and is defined in RFC 1034 and RFC 1035.
+
+ The definition of AXFR has proven insufficient in detail, thereby
+ forcing implementations intended to be compliant to make assumptions,
+ impeding interoperability. Yet today we have a satisfactory set of
+ implementations that do interoperate. This document is a new
+ definition of AXFR -- new in the sense that it records an accurate
+ definition of an interoperable AXFR mechanism.
+
+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/rfc5936.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 1]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 2]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Definition of Terms ........................................4
+ 1.2. Scope ......................................................5
+ 1.3. Context ....................................................5
+ 1.4. Coverage and Relationship to Original AXFR Specification ...5
+ 2. AXFR Messages ...................................................6
+ 2.1. AXFR Query .................................................8
+ 2.1.1. Header Values .......................................8
+ 2.1.2. Question Section ...................................10
+ 2.1.3. Answer Section .....................................10
+ 2.1.4. Authority Section ..................................10
+ 2.1.5. Additional Section .................................10
+ 2.2. AXFR Response .............................................11
+ 2.2.1. Header Values ......................................12
+ 2.2.2. Question Section ...................................14
+ 2.2.3. Answer Section .....................................14
+ 2.2.4. Authority Section ..................................14
+ 2.2.5. Additional Section .................................14
+ 2.3. TCP Connection Aborts .....................................15
+ 3. Zone Contents ..................................................15
+ 3.1. Records to Include ........................................15
+ 3.2. Delegation Records ........................................16
+ 3.3. Glue Records ..............................................18
+ 3.4. Name Compression ..........................................19
+ 3.5. Occluded Names ............................................19
+ 4. Transport ......................................................20
+ 4.1. TCP .......................................................20
+ 4.1.1. AXFR Client TCP ....................................21
+ 4.1.2. AXFR Server TCP ....................................22
+ 4.2. UDP .......................................................22
+ 5. Authorization ..................................................22
+ 6. Zone Integrity .................................................23
+ 7. Backwards Compatibility ........................................24
+ 7.1. Server ....................................................24
+ 7.2. Client ....................................................25
+ 8. Security Considerations ........................................25
+ 9. IANA Considerations ............................................25
+ 10. Internationalization Considerations ...........................25
+ 11. Acknowledgments ...............................................25
+ 12. References ....................................................26
+ 12.1. Normative References .....................................26
+ 12.2. Informative References ...................................28
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 3]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+1. Introduction
+
+ The Domain Name System standard facilities for maintaining coherent
+ servers for a zone consist of three elements. Authoritative Transfer
+ (AXFR) is defined in "Domain Names - Concepts and Facilities"
+ [RFC1034] (referred to in this document as RFC 1034) and "Domain
+ Names - Implementation and Specification" [RFC1035] (henceforth RFC
+ 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental
+ Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification
+ of zone changes (NOTIFY) is defined in "A Mechanism for Prompt
+ Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of
+ these mechanisms is to enable a set of DNS name servers to remain
+ coherently authoritative for a given zone.
+
+ This document re-specifies the AXFR mechanism as it is deployed in
+ the Internet at large, hopefully with the precision expected from
+ modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
+
+1.1. Definition of Terms
+
+ 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 "Key words for use in
+ RFCs to Indicate Requirement Levels" [BCP14].
+
+ Use of "newer"/"new" and "older"/"old" DNS refers to implementations
+ written after and prior to the publication of this document.
+
+ "General-purpose DNS implementation" refers to DNS software developed
+ for widespread use. This includes resolvers and servers freely
+ accessible as libraries and standalone processes. This also includes
+ proprietary implementations used only in support of DNS service
+ offerings.
+
+ "Turnkey DNS implementation" refers to custom-made, single-use
+ implementations of DNS. Such implementations consist of software
+ that employs the DNS protocol message format yet does not conform to
+ the entire range of DNS functionality.
+
+ The terms "AXFR session", "AXFR server", and "AXFR client" will be
+ introduced in the first paragraph of Section 2, after some more
+ context has been established.
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 4]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+1.2. Scope
+
+ In general terms, authoritative name servers for a given zone can use
+ various means to achieve coherency of the zone contents they serve.
+ For example, there are DNS implementations that assemble answers from
+ data stored in relational databases (as opposed to master files),
+ relying on the database's non-DNS means to synchronize the database
+ instances. Some of these non-DNS solutions interoperate in some
+ fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
+ defined in-band mechanisms to provide coherence of a set of name
+ servers, and they are the only mechanisms specified by the IETF.
+
+ This document does not cover incoherent DNS situations. There are
+ applications of the DNS in which servers for a zone are designed to
+ be incoherent. For these configurations, a coherency mechanism as
+ described here would be unsuitable.
+
+ A DNS implementation is not required to support AXFR, IXFR, and
+ NOTIFY, but it should have some means for maintaining name server
+ coherency. A general-purpose DNS implementation will likely support
+ AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
+ implementations may exist without AXFR.
+
+1.3. Context
+
+ Besides describing the mechanisms themselves, there is the context in
+ which they operate to consider. In the initial specifications of
+ AXFR (and IXFR and NOTIFY), little consideration was given to
+ security and privacy issues. Since the original definition of AXFR,
+ new opinions have appeared on the access to an entire zone's
+ contents. In this document, the basic mechanisms will be discussed
+ separately from the permission to use these mechanisms.
+
+1.4. Coverage and Relationship to Original AXFR Specification
+
+ This document concentrates on just the definition of AXFR. Any
+ effort to update the specification of the IXFR or NOTIFY mechanisms
+ is left to different documents.
+
+ The original "specification" of the AXFR sub-protocol is scattered
+ through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
+ depicts the scenario for which AXFR has been designed. Section 4.3.5
+ of RFC 1034 describes the zone synchronization strategies in general
+ and rules for the invocation of a full zone transfer via AXFR; the
+ fifth paragraph of that section contains a very short sketch of the
+ AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
+ flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
+ the code point for the AXFR QTYPE (see Section 2.1.2 below for more
+
+
+
+Lewis & Hoenes Standards Track [Page 5]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ details). Section 4.2 of RFC 1035 discusses how the DNS uses the
+ transport layer and briefly explains why UDP transport is deemed
+ inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
+ details regarding TCP connection management for AXFR. Finally, the
+ second paragraph of Section 6.3 in RFC 1035 mandates server behavior
+ when zone data changes occur during an ongoing zone transfer using
+ AXFR.
+
+ This document will update the specification of AXFR. To this end, it
+ fully specifies the record formats and processing rules for AXFR,
+ largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
+ details the transport considerations for AXFR, thus amending Section
+ 4.2.2 of RFC 1035. Furthermore, it discusses backward-compatibility
+ issues and provides policy/management considerations, as well as
+ specific security considerations for AXFR. The goal of this document
+ is to define AXFR as it is understood by the DNS community to exist
+ today.
+
+2. AXFR Messages
+
+ An AXFR session consists of an AXFR query message and the sequence of
+ AXFR response messages returned for it. In this document, the AXFR
+ client is the sender of the AXFR query, and the AXFR server is the
+ responder. (Use of terms such as master, slave, primary, and
+ secondary are not important for defining AXFR.) The use of the word
+ "session" without qualification refers to an AXFR session.
+
+ An important aspect to keep in mind is that the definition of AXFR is
+ restricted to TCP [RFC0793] (see Section 4 for details). The design
+ of the AXFR process has certain inherent features that are not easily
+ ported to UDP [RFC0768].
+
+ The basic format of an AXFR message is the DNS message as defined in
+ Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
+ following documents.
+
+ o The "Basic" DNS specification:
+
+ - "A Mechanism for Prompt Notification of Zone Changes
+ (DNS NOTIFY)" [RFC1996]
+
+ - "Dynamic Updates in the Domain Name System (DNS UPDATE)"
+ [RFC2136]
+
+ - "Clarifications to the DNS Specification" [RFC2181]
+
+ - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
+
+
+
+
+Lewis & Hoenes Standards Track [Page 6]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ - "Secret Key Transaction Authentication for DNS (TSIG)"
+ [RFC2845]
+
+ - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
+
+ - "Obsoleting IQUERY" [RFC3425]
+
+ - "Handling of Unknown DNS Resource Record (RR) Types"
+ [RFC3597]
+
+ - "HMAC SHA (Hashed Message Authentication Code, Secure Hash
+ Algorithm) TSIG Algorithm Identifiers" [RFC4635]
+
+ - "Domain Name System (DNS) IANA Considerations" [RFC5395]
+
+ o Further additions related to the DNS Security Extensions (DNSSEC),
+ defined in these base documents:
+
+ - "DNS Security Introduction and Requirements" [RFC4033]
+
+ - "Resource Records for the DNS Security Extensions"
+ [RFC4034]
+
+ - "Protocol Modifications for the DNS Security Extensions"
+ [RFC4035]
+
+ - "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource
+ Records (RRs)" [RFC4509]
+
+ - "DNS Security (DNSSEC) Hashed Authenticated Denial of
+ Existence" [RFC5155]
+
+ - "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG
+ Resource Records for DNSSEC" [RFC5702]
+
+ - "Clarifications and Implementation Notes for DNSSECbis"
+ [DNSSEC-U]
+
+ These documents contain information about the syntax and semantics of
+ DNS messages. They do not interfere with AXFR but are also helpful
+ in understanding what will be carried via AXFR.
+
+ For convenience, the synopsis of the DNS message header from
+ [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
+ reproduced here informally:
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 7]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ID |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT/ZOCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT/PRCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT/UPCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ This document makes use of the field names as they appear in this
+ diagram. The names of sections in the body of DNS messages are
+ capitalized in this document for clarity, e.g., "Additional section".
+
+ The DNS message size limit from [RFC1035] for DNS over UDP (and its
+ extension via the EDNS0 mechanism specified in [RFC2671]) is not
+ relevant for AXFR, as explained in Section 4. The upper limit on the
+ permissible size of a DNS message over TCP is only restricted by the
+ TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
+ two-octet message length field, understood to be unsigned, and thus
+ causing a limit of 65535 octets. This limit is not changed by EDNS0.
+
+ Note that the TC (truncation) bit is never set by an AXFR server nor
+ considered/read by an AXFR client.
+
+2.1. AXFR Query
+
+ An AXFR query is sent by a client whenever there is a reason to ask.
+ This might be because of scheduled or triggered zone maintenance
+ activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
+ respectively) or as a result of a command line request, say for
+ debugging.
+
+2.1.1. Header Values
+
+ These are the DNS message header values for an AXFR query.
+
+ ID Selected by client; see Note a)
+
+ QR MUST be 0 (Query)
+
+ OPCODE MUST be 0 (Standard Query)
+
+
+
+
+Lewis & Hoenes Standards Track [Page 8]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Flags:
+ AA "n/a" -- see Note b)
+ TC "n/a" -- see Note b)
+ RD "n/a" -- see Note b)
+ RA "n/a" -- see Note b)
+ Z "mbz" -- see Note c)
+ AD "n/a" -- see Note b)
+ CD "n/a" -- see Note b)
+
+ RCODE MUST be 0 (No error)
+
+ QDCOUNT Number of entries in Question section; MUST be 1
+
+ ANCOUNT Number of entries in Answer section; MUST be 0
+
+ NSCOUNT Number of entries in Authority section; MUST be 0
+
+ ARCOUNT Number of entries in Additional section -- see Note d)
+
+ Notes:
+
+ a) Set to any value that the client is not already using with the
+ same server. There is no specific means for selecting the value
+ in this field. (Recall that AXFR is done only via TCP connections
+ -- see Section 4, "Transport".)
+
+ A server MUST reply using messages that use the same message ID to
+ allow a client to have multiple queries outstanding concurrently
+ over the same TCP connection -- see Note a) in Section 2.2.1 for
+ more details.
+
+ b) "n/a" -- The value in this field has no meaning in the context of
+ AXFR query messages. For the client, it is RECOMMENDED that the
+ value be zero. The server MUST ignore this value.
+
+ c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore
+ it.
+
+ d) The client MUST set this field to the number of resource records
+ it places into the Additional section. In the absence of explicit
+ specification of new RRs to be carried in the Additional section
+ of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5,
+ "Additional Section", for details on the currently applicable RRs.
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 9]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+2.1.2. Question Section
+
+ The Question section of the AXFR query MUST conform to Section 4.1.2
+ of RFC 1035, and contain a single resource record with the following
+ values:
+
+ QNAME the name of the zone requested
+
+ QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
+ [DNSVALS]
+
+ QCLASS the class of the zone requested [DNSVALS]
+
+2.1.3. Answer Section
+
+ The Answer section MUST be empty.
+
+2.1.4. Authority Section
+
+ The Authority section MUST be empty.
+
+2.1.5. Additional Section
+
+ Currently, two kinds of resource records are defined that can appear
+ in the Additional section of AXFR queries and responses: EDNS and DNS
+ transaction security. Future specifications defining RRs that can be
+ carried in the Additional section of normal DNS transactions need to
+ explicitly describe their use with AXFR, should that be desired.
+
+ The client MAY include one OPT resource record [RFC2671]. If the
+ server does not support EDNS0, the client MUST send this section
+ without an OPT resource record if there is a retry. However, the
+ protocol does not define an explicit indication that the server does
+ not support EDNS0; that needs to be inferred by the client. Often,
+ the server will return a FormErr(1) that might be related to the OPT
+ resource record. Note that, at the time of this writing, only the
+ EXTENDED-RCODE field of the OPT RR is meaningful in the context of
+ AXFR; future specifications of EDNS flags and/or EDNS options must
+ describe their usage in the context of AXFR, if applicable.
+
+ The client MAY include one transaction integrity and authentication
+ resource record, currently a choice of TSIG [RFC2845] or SIG(0)
+ [RFC2931]. If the server has indicated that it does not recognize
+ the resource record, and that the error is indeed caused by the
+ resource record, the client probably should not try again. Removing
+ the security data in the face of an obstacle ought to only be done
+ with full awareness of the implication of doing so.
+
+
+
+
+Lewis & Hoenes Standards Track [Page 10]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ In general, if an AXFR client is aware that an AXFR server does not
+ support a particular mechanism, the client SHOULD NOT attempt to
+ engage the server using the mechanism (or engage the server at all).
+ A client could become aware of a server's abilities via a
+ configuration setting or via some other (as yet) undefined means.
+
+ The range of permissible resource records that MAY appear in the
+ Additional section might change over time. If either a change to an
+ existing resource record (like the OPT RR for EDNS) is made or a new
+ Additional section record is created, the new definitions ought to
+ include a discussion on the applicability and impact upon AXFR.
+ Future resource records residing in the Additional section might have
+ an effect that is orthogonal to AXFR, and so can ride through the
+ session as opaque data. In this case, a "wise" implementation ought
+ to be able to pass these records through without disruption.
+
+2.2. AXFR Response
+
+ The AXFR response will consist of one or more messages. The special
+ case of a server closing the TCP connection without sending an AXFR
+ response is covered in Section 2.3.
+
+ An AXFR response that is transferring the zone's contents will
+ consist of a series (which could be a series of length 1) of DNS
+ messages. In such a series, the first message MUST begin with the
+ SOA resource record of the zone, and the last message MUST conclude
+ with the same SOA resource record. Intermediate messages MUST NOT
+ contain the SOA resource record. The AXFR server MUST copy the
+ Question section from the corresponding AXFR query message into the
+ first response message's Question section. For subsequent messages,
+ it MAY do the same or leave the Question section empty.
+
+ The AXFR protocol treats the zone contents as an unordered collection
+ (or to use the mathematical term, a "set") of RRs. Except for the
+ requirement that the transfer must begin and end with the SOA RR,
+ there is no requirement to send the RRs in any particular order or
+ grouped into response messages in any particular way. Although
+ servers typically do attempt to send related RRs (such as the RRs
+ forming an RRset, and the RRsets of a name) as a contiguous group or,
+ when message space allows, in the same response message, they are not
+ required to do so, and clients MUST accept any ordering and grouping
+ of the non-SOA RRs. Each RR SHOULD be transmitted only once, and
+ AXFR clients MUST ignore any duplicate RRs received.
+
+ Each AXFR response message SHOULD contain a sufficient number of RRs
+ to reasonably amortize the per-message overhead, up to the largest
+ number that will fit within a DNS message (taking the required
+ content of the other sections into account, as described below).
+
+
+
+Lewis & Hoenes Standards Track [Page 11]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Some old AXFR clients expect each response message to contain only a
+ single RR. To interoperate with such clients, the server MAY
+ restrict response messages to a single RR. As there is no standard
+ way to automatically detect such clients, this typically requires
+ manual configuration at the server.
+
+ To indicate an error in an AXFR response, the AXFR server sends a
+ single DNS message when the error condition is detected, with the
+ response code set to the appropriate value for the condition
+ encountered. Such a message terminates the AXFR session; it MUST
+ contain a copy of the Question section from the AXFR query in its
+ Question section, but the inclusion of the terminating SOA resource
+ record is not necessary.
+
+ An AXFR server may send a number of AXFR response messages free of an
+ error condition before it sends the message indicating an error.
+
+2.2.1. Header Values
+
+ These are the DNS message header values for AXFR responses.
+
+ ID MUST be copied from request -- see Note a)
+
+ QR MUST be 1 (Response)
+
+ OPCODE MUST be 0 (Standard Query)
+
+ Flags:
+ AA normally 1 -- see Note b)
+ TC MUST be 0 (Not truncated)
+ RD RECOMMENDED: copy request's value; MAY be set to 0
+ RA SHOULD be 0 -- see Note c)
+ Z "mbz" -- see Note d)
+ AD "mbz" -- see Note d)
+ CD "mbz" -- see Note d)
+
+ RCODE See Note e)
+
+ QDCOUNT MUST be 1 in the first message;
+ MUST be 0 or 1 in all following messages;
+ MUST be 1 if RCODE indicates an error
+
+ ANCOUNT See Note f)
+
+ NSCOUNT MUST be 0
+
+ ARCOUNT See Note g)
+
+
+
+
+Lewis & Hoenes Standards Track [Page 12]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Notes:
+
+ a) Because some old implementations behave differently than is now
+ desired, the requirement on this field is stated in detail. New
+ DNS servers MUST set this field to the value of the AXFR query ID
+ in each AXFR response message for the session. AXFR clients MUST
+ be able to manage sessions resulting from the issuance of multiple
+ outstanding queries, whether AXFR queries or other DNS queries. A
+ client SHOULD discard responses that do not correspond (via the
+ message ID) to any outstanding queries.
+
+ Unless the client is sure that the server will consistently set
+ the ID field to the query's ID, the client is NOT RECOMMENDED to
+ issue any other queries until the end of the zone transfer. A
+ client MAY become aware of a server's abilities via a
+ configuration setting.
+
+ b) If the RCODE is 0 (no error), then the AA bit MUST be 1. For any
+ other value of RCODE, the AA bit MUST be set according to the
+ rules for that error code. If in doubt, it is RECOMMENDED that it
+ be set to 1. It is RECOMMENDED that the value be ignored by the
+ AXFR client.
+
+ c) It is RECOMMENDED that the server set the value to 0; the client
+ MUST ignore this value.
+
+ The server MAY set this value according to the local policy
+ regarding recursive service, but doing so might confuse the
+ interpretation of the response, as AXFR cannot be retrieved
+ recursively. A client MAY note the server's policy regarding
+ recursive service from this value, but SHOULD NOT conclude that
+ the AXFR response was obtained recursively, even if the RD bit was
+ 1 in the query.
+
+ d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore
+ it.
+
+ e) In the absence of an error, the server MUST set the value of this
+ field to NoError(0). If a server is not authoritative for the
+ queried zone, the server SHOULD set the value to NotAuth(9).
+ (Reminder: Consult the appropriate IANA registry [DNSVALS].) If a
+ client receives any other value in response, it MUST act according
+ to the error. For example, a malformed AXFR query or the presence
+ of an OPT resource record sent to an old server will result in a
+ FormErr(1) value. This value is not set as part of the AXFR-
+ specific response processing. The same is true for other values
+ indicating an error.
+
+
+
+
+Lewis & Hoenes Standards Track [Page 13]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ f) The count of answer records MUST equal the number of resource
+ records in the AXFR Answer section. When a server is aware that a
+ client will only accept response messages with a single resource
+ record, then the value MUST be 1. A server MAY be made aware of a
+ client's limitations via configuration data.
+
+ g) The server MUST set this field to the number of resource records
+ it places into the Additional section. In the absence of explicit
+ specification of new RRs to be carried in the Additional section
+ of AXFR response messages, the value MAY be 0, 1, or 2. See
+ Section 2.1.5 above for details on the currently applicable RRs
+ and Section 2.2.5 for additional considerations specific to AXFR
+ servers.
+
+2.2.2. Question Section
+
+ In the first response message, this section MUST be copied from the
+ query. In subsequent messages, this section MAY be copied from the
+ query, or it MAY be empty. However, in an error response message
+ (see Section 2.2), this section MUST be copied as well. The content
+ of this section MAY be used to determine the context of the message,
+ that is, the name of the zone being transferred.
+
+2.2.3. Answer Section
+
+ The Answer section MUST be populated with the zone contents. See
+ Section 3 below on encoding zone contents.
+
+2.2.4. Authority Section
+
+ The Authority section MUST be empty.
+
+2.2.5. Additional Section
+
+ The contents of this section MUST follow the guidelines for the OPT,
+ TSIG, and SIG(0) RRs, or whatever other future record is possible
+ here. The contents of Section 2.1.5 apply analogously as well.
+
+ The following considerations specifically apply to AXFR responses:
+
+ If the client has supplied an EDNS OPT RR in the AXFR query and if
+ the server supports EDNS as well, it SHOULD include one OPT RR in the
+ first response message and MAY do so in subsequent response messages
+ (see Section 2.2); the specifications of EDNS options to be carried
+ in the OPT RR may impose stronger requirements.
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 14]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ If the client has supplied a transaction security resource record
+ (currently a choice of TSIG and SIG(0)) and the server supports the
+ method chosen by the client, it MUST place the corresponding resource
+ record into the AXFR response message(s), according to the rules
+ specified for that method.
+
+2.3. TCP Connection Aborts
+
+ If an AXFR client sends a query on a TCP connection and the
+ connection is closed at any point, the AXFR client MUST consider the
+ AXFR session terminated. The message ID MAY be used again on a new
+ connection, even if the question and AXFR server are the same.
+
+ Facing a dropped connection, a client SHOULD try to make some
+ determination as to whether the connection closure was the result of
+ network activity or due to a decision by the AXFR server. This
+ determination is not an exact science. It is up to the AXFR client
+ to react, but the implemented reaction SHOULD NOT be either an
+ endless cycle of retries or an increasing (in frequency) retry rate.
+
+ An AXFR server implementer should take into consideration the dilemma
+ described above when a connection is closed with an outstanding query
+ in the pipeline. For this reason, a server ought to reserve this
+ course of action for situations in which it believes beyond a doubt
+ that the AXFR client is attempting abusive behavior.
+
+3. Zone Contents
+
+ The objective of the AXFR session is to request and transfer the
+ contents of a zone, in order to permit the AXFR client to faithfully
+ reconstruct the zone as it exists at the primary server for the given
+ zone serial number. The word "exists" here designates the externally
+ visible behavior, i.e., the zone content that is being served (handed
+ out to clients) -- not its persistent representation in a zone file
+ or database used by the server -- and that for consistency should be
+ served subsequently by the AXFR client in an identical manner.
+
+ Over time the definition of a zone has evolved from denoting a static
+ set of records to also cover a dynamically updated set of records,
+ and then a potentially continually regenerated set of records (e.g.,
+ RRs synthesized "on the fly" from rule sets or database lookup
+ results in other forms than RR format) as well.
+
+3.1. Records to Include
+
+ In the Answer section of AXFR response messages, the resource records
+ within a zone for the given serial number MUST appear. The
+ definition of what belongs in a zone is described in RFC 1034,
+
+
+
+Lewis & Hoenes Standards Track [Page 15]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Section 4.2, "How the database is divided into zones" (in particular
+ Section 4.2.1, "Technical considerations"), and it has been clarified
+ in Section 6 of RFC 2181.
+
+ Zones for which it is impractical to list the entire zone for a
+ serial number are not suitable for AXFR retrieval. A typical (but
+ not limiting) description of such a zone is a zone consisting of
+ responses generated via other database lookups and/or computed based
+ upon ever-changing data.
+
+3.2. Delegation Records
+
+ In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
+ the "should" in the quotation predates [BCP14], cf. Section 1.1):
+
+ The RRs that describe cuts ... should be exactly the same as the
+ corresponding RRs in the top node of the subzone.
+
+ There has been some controversy over this statement and the impact on
+ which NS resource records are included in a zone transfer.
+
+ The phrase "that describe cuts" is a reference to the NS set and
+ applicable glue records. It does not mean that the cut point and
+ apex resource records are identical. For example, the SOA resource
+ record is only found at the apex. The discussion here is restricted
+ to just the NS resource record set and glue, as these "describe
+ cuts".
+
+ DNSSEC resource records have special specifications regarding their
+ occurrence at a zone cut and the apex of a zone. This was first
+ described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
+ specification of DNSSEC), which parts of RFC 2181 now in fact are
+ historical. The current DNSSEC core document set (see second bullet
+ in Section 2 above) gives the full details for DNSSEC(bis) resource
+ record placement, and Section 3.1.5 of RFC 4035 normatively specifies
+ their treatment during AXFR; the alternate NSEC3 resource record
+ defined later in RFC 5155 behaves identically to the NSEC RR, for the
+ purpose of AXFR.
+
+ Informally:
+
+ o The DS RRSet only occurs at the parental side of a zone cut and is
+ authoritative data in the parent zone, not the secure child zone.
+
+ o The DNSKEY RRSet only occurs at the apex of a signed zone and is
+ part of the authoritative data of the zone it serves.
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 16]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ o Independent RRSIG RRSets occur at the signed parent side of a zone
+ cut and at the apex of a signed zone; they are authoritative data
+ in the respective zone; simple queries for RRSIG resource records
+ may return both RRSets at once if the same server is authoritative
+ for the parent zone and the child zone (Section 3.1.5 of RFC 4035
+ describes how to distinguish these RRs); this seeming ambiguity
+ does not occur for AXFR, since each such RRSIG RRset belongs to a
+ single zone.
+
+ o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
+ equally may occur at the parental side of a zone cut and at the
+ apex of a zone; each such resource record belongs to exactly one
+ of these zones and is to be included in the AXFR of that zone.
+
+ One issue is that in operations there are times when the NS resource
+ records for a zone might be different at a cut point in the parent
+ and at the apex of a zone. Sometimes this is the result of an error,
+ and sometimes it is part of an ongoing change in name servers. The
+ DNS protocol is robust enough to overcome inconsistencies up to (but
+ not including) there being no parent-indicated NS resource record
+ referencing a server that is able to serve the child zone. This
+ robustness is one quality that has fueled the success of the DNS.
+ Still, the inconsistency is an error state, and steps need to be
+ taken to make it apparent (if it is unplanned).
+
+ Another issue is that the AXFR server could be authoritative for a
+ different set of zones than the AXFR client. It is possible that the
+ AXFR server be authoritative for both halves of an inconsistent cut
+ point and that the AXFR client is authoritative for just the parent
+ side of the cut point.
+
+ When facing a situation in which a cut point's NS resource records do
+ not match the authoritative set, the question arises whether an AXFR
+ server responds with the NS resource record set that is in the zone
+ being transferred or the one that is at the authoritative location.
+
+ The AXFR response MUST contain the cut point NS resource record set
+ registered with the zone whether it agrees with the authoritative set
+ or not. "Registered with" can be widely interpreted to include data
+ residing in the zone file of the zone for the particular serial
+ number (in zone file environments) or as any data configured to be in
+ the zone (database), statically or dynamically.
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 17]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ The reasons for this requirement are:
+
+ 1) The AXFR server might not be able to determine that there is an
+ inconsistency given local data; hence, requiring consistency would
+ mean a lot more needed work and even network retrieval of data.
+ An authoritative server ought not be required to perform any
+ queries.
+
+ 2) By transferring the inconsistent NS resource records from a server
+ that is authoritative for both the cut point and the apex to a
+ client that is not authoritative for both, the error is exposed.
+ For example, an authorized administrator can manually request the
+ AXFR and inspect the results to see the inconsistent records. (A
+ server authoritative for both halves would otherwise always answer
+ from the more authoritative set, concealing the error.)
+
+ 3) The inconsistent NS resource record set might indicate a problem
+ in a registration database.
+
+ 4) This requirement is necessary to ensure that retrieving a given
+ (zone, serial) pair by AXFR yields the exact same set of resource
+ records, no matter which of the zone's authoritative servers is
+ chosen as the source of the transfer.
+
+ If an AXFR server were allowed to respond with the authoritative NS
+ RRset of a child zone instead of a parent-side NS RRset in the zone
+ being transferred, the set of records returned could vary depending
+ on whether or not the server happened to be authoritative for the
+ child zone as well.
+
+ The property that a given (zone, serial) pair corresponds to a
+ single, well-defined set of records is necessary for the correct
+ operation of incremental transfer protocols such as IXFR [RFC1995].
+ For example, a client may retrieve a zone by AXFR from one server,
+ and then apply an incremental change obtained by IXFR from a
+ different server. If the two servers have different ideas of the
+ zone contents, the client can end up attempting to incrementally add
+ records that already exist or to delete records that do not exist.
+
+3.3. Glue Records
+
+ As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
+ guidance and rationale for the inclusion of glue records as part of
+ an AXFR response. And, as also argued in the previous section of
+ this document, even when there is an inconsistency between the
+ address in a glue record and the authoritative copy of the name
+ server's address, the glue resource record that is registered as part
+ of the zone for that serial number is to be included.
+
+
+
+Lewis & Hoenes Standards Track [Page 18]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ This applies to glue records for any address family [IANA-AF].
+
+ The AXFR response MUST contain the appropriate glue records as
+ registered with the zone. The interpretation of "registered with" in
+ the previous section applies here. Inconsistent glue records are an
+ operational matter.
+
+3.4. Name Compression
+
+ Compression of names in DNS messages is described in RFC 1035,
+ Section 4.1.4, "Message compression". The issue highlighted here
+ relates to a comment made in RFC 1034, Section 3.1, "Name space
+ specifications and terminology", which says:
+
+ When you receive a domain name or label, you should preserve its
+ case.
+
+ ("Should" in the quote predates [BCP14].)
+
+ Since the primary objective of AXFR is to enable the client to serve
+ the same zone content as the server, unlike such normal DNS responses
+ that are expected to preserve the case in the query, the actual zone
+ transfer needs to retain the case of the labels in the zone content.
+ Hence, name compression in an AXFR message SHOULD be performed in a
+ case-preserving manner, unlike how it is done for "normal" DNS
+ responses. That is, although when comparing a domain name for
+ matching, "a" equals "A", when comparing for the purposes of message
+ compression for AXFR, "a" is not equal to "A". Note that this is not
+ the usual definition of name comparison in the DNS protocol and
+ represents a new understanding of the requirement on AXFR servers.
+
+ Rules governing name compression of RDATA in an AXFR message MUST
+ abide by the specification in "Handling of Unknown DNS Resource
+ Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
+ Compression".
+
+3.5. Occluded Names
+
+ Dynamic Update [RFC2136] operations, and in particular their
+ interaction with DNAME [RFC2672], can have a side effect of occluding
+ names in a zone. The addition of a delegation point via dynamic
+ update will render all subordinate domain names to be in a limbo,
+ still part of the zone but not available to the lookup process. The
+ addition of a DNAME resource record has the same impact. The
+ subordinate names are said to be "occluded".
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 19]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Occluded names MUST be included in AXFR responses. An AXFR client
+ MUST be able to identify and handle occluded names. The rationale
+ for this action is based on a speedy recovery if the dynamic update
+ operation was in error and is to be undone.
+
+4. Transport
+
+ AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
+ 1034, which states:
+
+ Because accuracy is essential, TCP or some other reliable protocol
+ must be used for AXFR requests.
+
+ The restriction to TCP is also mentioned in Section 6.1.3.2 of
+ "Requirements for Internet Hosts - Application and Support"
+ [RFC1123].
+
+ The most common scenario is for an AXFR client to open a TCP
+ connection to the AXFR server, send an AXFR query, receive the AXFR
+ response, and then close the connection. But variations of that most
+ simple scenario are legitimate and likely: in particular, sending a
+ query for the zone's SOA resource record first over the same TCP
+ connection, and reusing an existing TCP connection for other queries.
+
+ Therefore, the assumption that a TCP connection is dedicated to a
+ single AXFR session is incorrect. This wrong assumption has led to
+ implementation choices that prevent either multiple concurrent zone
+ transfers or the use of an open connection for other queries.
+
+ Since the early days of the DNS, operators who have sets of name
+ servers that are authoritative for a common set of zones have found
+ it desirable to be able to have multiple concurrent zone transfers in
+ progress; this way, a name server does not have to wait for one zone
+ transfer to complete before the next can begin. RFC 1035 did not
+ exclude this possibility, but legacy implementations failed to
+ support this functionality efficiently, over a single TCP connection.
+ The remaining presence of such legacy implementations makes it
+ necessary that new general-purpose client implementations still
+ provide options for graceful fallback to the old behavior in their
+ support of concurrent DNS transactions and AXFR sessions on a single
+ TCP connection.
+
+4.1. TCP
+
+ In the original definition, there arguably is an implicit assumption
+ (probably unintentional) that a TCP connection is used for one and
+ only one AXFR session. This is evidenced in the lack of an explicit
+ requirement to copy the Question section and/or the message ID into
+
+
+
+Lewis & Hoenes Standards Track [Page 20]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ responses, no explicit ordering information within the AXFR response
+ messages, and the lack of an explicit notice indicating that a zone
+ transfer continues in the next message.
+
+ The guidance given below is intended to enable better performance of
+ the AXFR exchange as well as provide guidelines on interactions with
+ older software. Better performance includes being able to multiplex
+ DNS message exchanges including zone transfer sessions. Guidelines
+ for interacting with older software are generally applicable to new
+ AXFR clients. In the reverse situation -- older AXFR client and
+ newer AXFR server -- the server ought to operate within the
+ specification for an older server.
+
+4.1.1. AXFR Client TCP
+
+ An AXFR client MAY request a connection to an AXFR server for any
+ reason. An AXFR client SHOULD close the connection when there is no
+ apparent need to use the connection for some time period. The AXFR
+ server ought not have to maintain idle connections; the burden of
+ connection closure ought to be on the client. "Apparent need" for
+ the connection is a judgment for the AXFR client and the DNS client.
+ If the connection is used for multiple sessions, or if it is known
+ that sessions will be coming, or if there is other query/response
+ traffic anticipated or currently on the open connection, then there
+ is "apparent need".
+
+ An AXFR client can cancel the delivery of a zone only by closing the
+ connection. However, this action will also cancel all other
+ outstanding activity using the connection. There is no other
+ mechanism by which an AXFR response can be cancelled.
+
+ When a TCP connection is closed remotely (relative to the client),
+ whether by the AXFR server or due to a network event, the AXFR client
+ MUST cancel all outstanding sessions and non-AXFR transactions.
+ Recovery from this situation is not straightforward. If the
+ disruption was a spurious event, attempting to restart the connection
+ would be proper. If the disruption was caused by a failure that
+ proved to be persistent, the AXFR client would be wise not to spend
+ too many resources trying to rebuild the connection. Finally, if the
+ connection was dropped because of a policy at the AXFR server (as can
+ be the case with older AXFR servers), the AXFR client would be wise
+ not to retry the connection. Unfortunately, knowing which of the
+ three cases above (momentary disruption, failure, policy) applies is
+ not possible with certainty, and can only be assessed by heuristics.
+ This exemplifies the general complications for clients in connection-
+ oriented protocols not receiving meaningful error responses.
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 21]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ An AXFR client MAY use an already opened TCP connection to start an
+ AXFR session. Using an existing open connection is RECOMMENDED over
+ opening a new connection. (Non-AXFR session traffic can also use an
+ open connection.) If in doing so the AXFR client realizes that the
+ responses cannot be properly differentiated (lack of matching query
+ IDs, for example) or the connection is terminated for a remote
+ reason, then the AXFR client SHOULD NOT attempt to reuse an open
+ connection with the specific AXFR server until the AXFR server is
+ updated (which is, of course, not an event captured in the DNS
+ protocol).
+
+4.1.2. AXFR Server TCP
+
+ An AXFR server MUST be able to handle multiple AXFR sessions on a
+ single TCP connection, as well as to handle other query/response
+ transactions over it.
+
+ If a TCP connection is closed remotely, the AXFR server MUST cancel
+ all AXFR sessions in place. No retry activity is necessary; that is
+ initiated by the AXFR client.
+
+ Local policy MAY dictate that a TCP connection is to be closed. Such
+ an action SHOULD be in reaction to limits such as those placed on the
+ number of outstanding open connections. Closing a connection in
+ response to a suspected security event SHOULD be done only in extreme
+ cases, when the server is certain the action is warranted. An
+ isolated request for a zone not on the AXFR server SHOULD receive a
+ response with the appropriate response code and not see the
+ connection broken.
+
+4.2. UDP
+
+ With the addition of EDNS0 and applications that require many small
+ zones, such as in web hosting and some ENUM scenarios, AXFR sessions
+ on UDP would now seem desirable. However, there are still some
+ aspects of AXFR sessions that are not easily translated to UDP.
+
+ Therefore, this document does not update RFC 1035 in this respect:
+ AXFR sessions over UDP transport are not defined.
+
+5. Authorization
+
+ A zone administrator has the option to restrict AXFR access to a
+ zone. This was not envisioned in the original design of the DNS but
+ has emerged as a requirement as the DNS has evolved. Restrictions on
+ AXFR could be for various reasons including a desire (or in some
+ instances, having a legal requirement) to keep the bulk version of
+ the zone concealed or to prevent the servers from handling the load
+
+
+
+Lewis & Hoenes Standards Track [Page 22]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ incurred in serving AXFR. It has been argued that these reasons are
+ questionable, but this document, driven by the desire to leverage the
+ interoperable practice that has evolved since RFC 1035, acknowledges
+ the factual requirement to provide mechanisms to restrict AXFR.
+
+ A DNS implementation SHOULD provide means to restrict AXFR sessions
+ to specific clients.
+
+ An implementation SHOULD allow access to be granted to Internet
+ Protocol addresses and ranges, regardless of whether a source address
+ could be spoofed. Combining this with techniques such as Virtual
+ Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be
+ effective.
+
+ A general-purpose implementation is RECOMMENDED to implement access
+ controls based upon "Secret Key Transaction Authentication for DNS
+ (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures
+ ( SIG(0)s )" [RFC2931].
+
+ A general-purpose implementation SHOULD allow access to be open to
+ all AXFR requests. That is, an operator ought to be able to allow
+ any AXFR query to be granted.
+
+ A general-purpose implementation SHOULD NOT have a default policy for
+ AXFR requests to be "open to all". For example, a default could be
+ to restrict transfers to addresses selected by the DNS
+ administrator(s) for zones on the server.
+
+6. Zone Integrity
+
+ An AXFR client MUST ensure that only a successfully transferred copy
+ of the zone data can be used to serve this zone. Previous
+ description and implementation practice has introduced a two-stage
+ model of the whole zone synchronization procedure: Upon a trigger
+ event (e.g., when polling of a SOA resource record detects a change
+ in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is
+ received), the AXFR session is initiated, whereby the zone data are
+ saved in a zone file or database (this latter step is necessary
+ anyway to ensure proper restart of the server); upon successful
+ completion of the AXFR operation and some sanity checks, this data
+ set is "loaded" and made available for serving the zone in an atomic
+ operation, and flagged "valid" for use during the next restart of the
+ DNS server; if any error is detected, this data set MUST be deleted,
+ and the AXFR client MUST continue to serve the previous version of
+ the zone, if it did before. The externally visible behavior of an
+ AXFR client implementation MUST be equivalent to that of this two-
+ stage model.
+
+
+
+
+Lewis & Hoenes Standards Track [Page 23]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ If an AXFR client rejects data obtained in an AXFR session, it SHOULD
+ remember the serial number and MAY attempt to retrieve the same zone
+ version again. The reason the same retrieval could make sense is
+ that the reason for the rejection could be rooted in an
+ implementation detail of one AXFR server used for the zone and not
+ present in another AXFR server used for the zone.
+
+ Ensuring that an AXFR client does not accept a forged copy of a zone
+ is important to the security of a zone. If a zone operator has the
+ opportunity, protection can be afforded via dedicated links, physical
+ or virtual via a VPN among the authoritative servers. But there are
+ instances in which zone operators have no choice but to run AXFR
+ sessions over the global public Internet.
+
+ Besides best attempts at securing TCP connections, DNS
+ implementations SHOULD provide means to make use of "Secret Key
+ Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS
+ Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow
+ AXFR clients to verify the contents. These techniques MAY also be
+ used for authorization.
+
+7. Backwards Compatibility
+
+ Describing backwards compatibility is difficult because of the lack
+ of specifics in the original definition. In this section, some hints
+ at building in backwards compatibility are given, mostly repeated
+ from the relevant earlier sections.
+
+ Backwards compatibility is not necessary, but the greater the extent
+ of an implementation's compatibility, the greater its
+ interoperability. For turnkey implementations, this is not usually a
+ concern. For general-purpose implementations, this takes on varying
+ levels of importance, depending on the implementer's desire to
+ maintain interoperability.
+
+ It is unfortunate that a need to fall back to older behavior cannot
+ be discovered, and thus has to be noted in a configuration file. An
+ implementation SHOULD, in its documentation, encourage operators to
+ periodically review AXFR clients and servers it has made notes about
+ repeatedly, as old software gets updated from time to time.
+
+7.1. Server
+
+ An AXFR server has the luxury of being able to react to an AXFR
+ client's abilities, with the exception of knowing whether the client
+ can accept multiple resource records per AXFR response message. The
+ knowledge that a client is so restricted cannot be discovered; hence,
+ it has to be set by configuration.
+
+
+
+Lewis & Hoenes Standards Track [Page 24]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ An implementation of an AXFR server MAY permit configuring, on a per
+ AXFR client basis, the necessity to revert to a single resource
+ record per message; in that case, the default SHOULD be to use
+ multiple records per message.
+
+7.2. Client
+
+ An AXFR client has the opportunity to try other features (i.e., those
+ not defined by this document) when querying an AXFR server.
+
+ Attempting to issue multiple DNS queries over a TCP transport for an
+ AXFR session SHOULD be aborted if it interrupts the original request,
+ and SHOULD take into consideration whether the AXFR server intends to
+ close the connection immediately upon completion of the original
+ (connection-causing) zone transfer.
+
+8. Security Considerations
+
+ This document is a clarification of a mechanism outlined in RFCs 1034
+ and 1035 and as such does not add any new security considerations.
+ RFC 3833 [RFC3833] is devoted entirely to security considerations for
+ the DNS; its Section 4.3 delineates zone transfer security aspects
+ from the security threats addressed by DNSSEC.
+
+ Concerns regarding authorization, traffic flooding, and message
+ integrity are mentioned in "Authorization" (Section 5), "TCP"
+ (Section 4.1), and "Zone Integrity" (Section 6).
+
+9. IANA Considerations
+
+ IANA has added a reference to this RFC in the AXFR (252) row of the
+ "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
+ (DNS) Parameters" registry.
+
+10. Internationalization Considerations
+
+ The AXFR protocol is transparent to the parts of DNS zone content
+ that can possibly be subject to Internationalization considerations.
+ It is assumed that for DNS labels and domain names, the issue has
+ been solved via "Internationalizing Domain Names in Applications
+ (IDNA)" [RFC3490] or its successor(s).
+
+11. Acknowledgments
+
+ Earlier draft versions of this document have been edited by Andreas
+ Gustafsson. In his latest draft version, this acknowledgment
+ appeared:
+
+
+
+
+Lewis & Hoenes Standards Track [Page 25]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ Many people have contributed input and commentary to earlier
+ versions of this document, including but not limited to Bob
+ Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin
+ Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton,
+ Peter Koch, Sam Trenholme, and Brian Wellington.
+
+ Comments on later draft versions have come from these individuals:
+ Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
+ Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
+ Bill Manning, and other participants of the DNSEXT working group.
+ Significant comments from the IETF at large have been received from
+ Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
+
+ Edward Lewis served as a patiently listening sole document editor for
+ two years.
+
+12. References
+
+ All "RFC" references below -- like all RFCs -- and information about
+ the RFC series can be obtained from the RFC Editor web site at
+ http://www.rfc-editor.org.
+
+12.1. Normative References
+
+ [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [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.
+
+ [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
+ Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+
+
+
+Lewis & Hoenes Standards Track [Page 26]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+ 2672, August 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for
+ DNS (TSIG)", RFC 2845, May 2000.
+
+ [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
+ ( SIG(0)s )", RFC 2931, September 2000.
+
+ [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+ 2002.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+ (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+ [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
+ Authentication Code, Secure Hash Algorithm) TSIG
+ Algorithm Identifiers", RFC 4635, August 2006.
+
+
+
+
+Lewis & Hoenes Standards Track [Page 27]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008.
+
+ [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
+ Considerations", BCP 42, RFC 5395, November 2008.
+
+ [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+ and RRSIG Resource Records for DNSSEC", RFC 5702, October
+ 2009.
+
+12.2. Informative References
+
+ [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
+ http://www.iana.org/.
+
+ [IANA-AF] IANA Registry "Address Family Numbers",
+ http://www.iana.org/.
+
+ [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+ Malis, "A Framework for IP Based Virtual Private
+ Networks", RFC 2764, February 2000.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
+
+ [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
+ Name System (DNS)", RFC 3833, August 2004.
+
+ [DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and
+ Implementation Notes for DNSSECbis", Work in Progress,
+ March 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 28]
+\f
+RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
+
+
+Authors' Addresses
+
+ Edward Lewis
+ 46000 Center Oak Plaza
+ Sterling, VA 20166
+ US
+
+ EMail: ed.lewis@neustar.biz
+
+
+ Alfred Hoenes, Editor
+ TR-Sys
+ Gerlinger Str. 12
+ Ditzingen D-71254
+ Germany
+
+ EMail: ah@TR-Sys.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Standards Track [Page 29]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Kawamura
+Request for Comments: 5952 NEC BIGLOBE, Ltd.
+Updates: 4291 M. Kawashima
+Category: Standards Track NEC AccessTechnica, Ltd.
+ISSN: 2070-1721 August 2010
+
+
+ A Recommendation for IPv6 Address Text Representation
+
+Abstract
+
+ As IPv6 deployment increases, there will be a dramatic increase in
+ the need to use IPv6 addresses in text. While the IPv6 address
+ architecture in Section 2.2 of RFC 4291 describes a flexible model
+ for text representation of an IPv6 address, this flexibility has been
+ causing problems for operators, system engineers, and users. This
+ document defines a canonical textual representation format. It does
+ not define a format for internal storage, such as within an
+ application or database. It is expected that the canonical format
+ will be followed by humans and systems when representing IPv6
+ addresses as text, but all implementations must accept and be able to
+ handle any legitimate RFC 4291 format.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5952.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 1]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 2]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
+ 2. Text Representation Flexibility of RFC 4291 . . . . . . . . . 4
+ 2.1. Leading Zeros in a 16-Bit Field . . . . . . . . . . . . . 4
+ 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
+ 3. Problems Encountered with the Flexible Model . . . . . . . . . 6
+ 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
+ 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
+ 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
+ 3.1.4. Searching for an Address in a Network Diagram . . . . 7
+ 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
+ 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
+ 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
+ 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
+ 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
+ 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
+ 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
+ 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
+ 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
+ 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
+ 4.1. Handling Leading Zeros in a 16-Bit Field . . . . . . . . . 10
+ 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.2.1. Shorten as Much as Possible . . . . . . . . . . . . . 10
+ 4.2.2. Handling One 16-Bit 0 Field . . . . . . . . . . . . . 10
+ 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
+ 4.3. Lowercase . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5. Text Representation of Special Addresses . . . . . . . . . . . 11
+ 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
+ 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 3]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+1. Introduction
+
+ A single IPv6 address can be text represented in many ways. Examples
+ are shown below.
+
+ 2001:db8:0:0:1:0:0:1
+
+ 2001:0db8:0:0:1:0:0:1
+
+ 2001:db8::1:0:0:1
+
+ 2001:db8::0:1:0:0:1
+
+ 2001:0db8::1:0:0:1
+
+ 2001:db8:0:0:1::1
+
+ 2001:db8:0000:0:1::1
+
+ 2001:DB8:0:0:1::1
+
+ All of the above examples represent the same IPv6 address. This
+ flexibility has caused many problems for operators, systems
+ engineers, and customers. The problems are noted in Section 3. A
+ canonical representation format to avoid problems is introduced in
+ Section 4.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Text Representation Flexibility of RFC 4291
+
+ Examples of flexibility in Section 2.2 of [RFC4291] are described
+ below.
+
+2.1. Leading Zeros in a 16-Bit Field
+
+ 'It is not necessary to write the leading zeros in an individual
+ field.'
+
+ Conversely, it is also not necessary to omit leading zeros. This
+ means that it is possible to select from representations such as
+ those in the following example. The final 16-bit field is different,
+ but all of these addresses represent the same address.
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 4]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
+
+2.2. Zero Compression
+
+ 'A special syntax is available to compress the zeros. The use of
+ "::" indicates one or more groups of 16 bits of zeros.'
+
+ It is possible to select whether or not to omit just one 16-bit 0
+ field.
+
+ 2001:db8:aaaa:bbbb:cccc:dddd::1
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:0:1
+
+ In cases where there is more than one field of only zeros, there is a
+ choice of how many fields can be shortened.
+
+ 2001:db8:0:0:0::1
+
+ 2001:db8:0:0::1
+
+ 2001:db8:0::1
+
+ 2001:db8::1
+
+ In addition, Section 2.2 of [RFC4291] notes,
+
+ 'The "::" can only appear once in an address.'
+
+ This gives a choice on where in a single address to compress the
+ zero.
+
+ 2001:db8::aaaa:0:0:1
+
+ 2001:db8:0:0:aaaa::1
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 5]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+2.3. Uppercase or Lowercase
+
+ [RFC4291] does not mention any preference of uppercase or lowercase.
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
+
+ 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
+
+3. Problems Encountered with the Flexible Model
+
+3.1. Searching
+
+3.1.1. General Summary
+
+ A search of an IPv6 address if conducted through a UNIX system is
+ usually case sensitive and extended options that allow for regular
+ expression use will come in handy. However, there are many
+ applications in the Internet today that do not provide this
+ capability. When searching for an IPv6 address in such systems, the
+ system engineer will have to try each and every possibility to search
+ for an address. This has critical impacts, especially when trying to
+ deploy IPv6 over an enterprise network.
+
+3.1.2. Searching Spreadsheets and Text Files
+
+ Spreadsheet applications and text editors on GUI systems rarely have
+ the ability to search for text using regular expression. Moreover,
+ there are many non-engineers (who are not aware of case sensitivity
+ and regular expression use) that use these applications to manage IP
+ addresses. This has worked quite well with IPv4 since text
+ representation in IPv4 has very little flexibility. There is no
+ incentive to encourage these non-engineers to change their tool or
+ learn regular expression when they decide to go dual-stack. If the
+ entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
+ conducted as 2001:db8:0:0:1::1, this will show a result of no match.
+ One example where this will cause a problem is, when the search is
+ being conducted to assign a new address from a pool, and a check is
+ being done to see if it is not in use. This may cause problems for
+ the end-hosts or end-users. This type of address management is very
+ often seen in enterprise networks and ISPs.
+
+3.1.3. Searching with Whois
+
+ The "whois" utility is used by a wide range of people today. When a
+ record is set to a database, one will likely check the output to see
+ if the entry is correct. If an entity was recorded as 2001:db8::/48,
+
+
+
+Kawamura & Kawashima Standards Track [Page 6]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+ but the whois output showed 2001:0db8:0000::/48, most non-engineers
+ would think that their input was wrong and will likely retry several
+ times or make a frustrated call to the database hostmaster. If there
+ was a need to register the same prefix on different systems, and each
+ system showed a different text representation, this would confuse
+ people even more. Although this document focuses on addresses rather
+ than prefixes, it is worth mentioning the prefix problems because the
+ problems encountered with addresses and prefixes are mostly equal.
+
+3.1.4. Searching for an Address in a Network Diagram
+
+ Network diagrams and blueprints often show what IP addresses are
+ assigned to a system devices. In times of trouble shooting there may
+ be a need to search through a diagram to find the point of failure
+ (for example, if a traceroute stopped at 2001:db8::1, one would
+ search the diagram for that address). This is a technique quite
+ often in use in enterprise networks and managed services. Again, the
+ different flavors of text representation will result in a time-
+ consuming search leading to longer mean times to restoration (MTTR)
+ in times of trouble.
+
+3.2. Parsing and Modifying
+
+3.2.1. General Summary
+
+ With all the possible methods of text representation, each
+ application must include a module, object, link, etc. to a function
+ that will parse IPv6 addresses in a manner such that no matter how it
+ is represented, they will mean the same address. Many system
+ engineers who integrate complex computer systems for corporate
+ customers will have difficulties finding that their favorite tool
+ will not have this function, or will encounter difficulties such as
+ having to rewrite their macros or scripts for their customers.
+
+3.2.2. Logging
+
+ If an application were to output a log summary that represented the
+ address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
+ the output would be highly unreadable compared to the IPv4 output.
+ The address would have to be parsed and reformed to make it useful
+ for human reading. Sometimes logging for critical systems is done by
+ mirroring the same traffic to two different systems. Care must be
+ taken so that no matter what the log output is, the logs should be
+ parsed so they are equivalent.
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 7]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+3.2.3. Auditing: Case 1
+
+ When a router or any other network appliance machine configuration is
+ audited, there are many methods to compare the configuration
+ information of a node. Sometimes auditing will be done by just
+ comparing the changes made each day. In this case, if configuration
+ was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+ 0000:0000:0000:0001 just because the new engineer on the block felt
+ it was better, a simple diff will show that a different address was
+ configured. If this was done on a wide scale network, people will be
+ focusing on 'why the extra zeros were put in' instead of doing any
+ real auditing. Lots of tools are just plain diffs that do not take
+ into account address representation rules.
+
+3.2.4. Auditing: Case 2
+
+ Node configurations will be matched against an information system
+ that manages IP addresses. If output notation is different, there
+ will need to be a script that is implemented to cover for this. The
+ result of an SNMP GET operation, converted to text and compared to a
+ textual address written by a human is highly unlikely to match on the
+ first try.
+
+3.2.5. Verification
+
+ Some protocols require certain data fields to be verified. One
+ example of this is X.509 certificates. If an IPv6 address field in a
+ certificate was incorrectly verified by converting it to text and
+ making a simple textual comparison to some other address, the
+ certificate may be mistakenly shown as being invalid due to a
+ difference in text representation methods.
+
+3.2.6. Unexpected Modifying
+
+ Sometimes, a system will take an address and modify it as a
+ convenience. For example, a system may take an input of
+ 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were
+ input for a reason, the outcome may be somewhat unexpected.
+
+3.3. Operating
+
+3.3.1. General Summary
+
+ When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
+ 0:0:1, the system may take the address and show the configuration
+ result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address
+ representation will know that the right address is set, but not
+ everyone may understand this.
+
+
+
+Kawamura & Kawashima Standards Track [Page 8]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+3.3.2. Customer Calls
+
+ When a customer calls to inquire about a suspected outage, IPv6
+ address representation should be handled with care. Not all
+ customers are engineers, nor do they have a similar skill level in
+ IPv6 technology. The network operations center will have to take
+ extra steps to humanly parse the address to avoid having to explain
+ to the customers that 2001:db8:0:1::1 is the same as
+ 2001:db8::1:0:0:0:1. This is one thing that will never happen in
+ IPv4 because IPv4 addresses cannot be abbreviated.
+
+3.3.3. Abuse
+
+ Network abuse reports generally include the abusing IP address. This
+ 'reporting' could take any shape or form of the flexible model. A
+ team that handles network abuse must be able to tell the difference
+ between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
+ placement of the "::" will result in a critical situation. A system
+ that handles these incidents should be able to handle any type of
+ input and parse it in a correct manner. Also, incidents are reported
+ over the phone. It is unnecessary to report if the letter is
+ uppercase or lowercase. However, when a letter is spelled uppercase,
+ people tend to specify that it is uppercase, which is unnecessary
+ information.
+
+3.4. Other Minor Problems
+
+3.4.1. Changing Platforms
+
+ When an engineer decides to change the platform of a running service,
+ the same code may not work as expected due to the difference in IPv6
+ address text representation. Usually, a change in a platform (e.g.,
+ Unix to Windows, Cisco to Juniper) will result in a major change of
+ code anyway, but flexibility in address representation will increase
+ the work load.
+
+3.4.2. Preference in Documentation
+
+ A document that is edited by more than one author may become harder
+ to read.
+
+3.4.3. Legibility
+
+ Capital case D and 0 can be quite often misread. Capital B and 8 can
+ also be misread.
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 9]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+4. A Recommendation for IPv6 Text Representation
+
+ A recommendation for a canonical text representation format of IPv6
+ addresses is presented in this section. The recommendation in this
+ document is one that complies fully with [RFC4291], is implemented by
+ various operating systems, and is human friendly. The recommendation
+ in this section SHOULD be followed by systems when generating an
+ address to be represented as text, but all implementations MUST
+ accept and be able to handle any legitimate [RFC4291] format. It is
+ advised that humans also follow these recommendations when spelling
+ an address.
+
+4.1. Handling Leading Zeros in a 16-Bit Field
+
+ Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is
+ not acceptable and must be represented as 2001:db8::1. A single 16-
+ bit 0000 field MUST be represented as 0.
+
+4.2. "::" Usage
+
+4.2.1. Shorten as Much as Possible
+
+ The use of the symbol "::" MUST be used to its maximum capability.
+ For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
+ Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::"
+ could have been used to produce a shorter representation 2001:db8::1.
+
+4.2.2. Handling One 16-Bit 0 Field
+
+ The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
+ For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+ 2001:db8::1:1:1:1:1 is not correct.
+
+4.2.3. Choice in Placement of "::"
+
+ When there is an alternative choice in the placement of a "::", the
+ longest run of consecutive 16-bit 0 fields MUST be shortened (i.e.,
+ the sequence with three consecutive zero fields is shortened in 2001:
+ 0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields
+ are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
+ bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct
+ representation.
+
+4.3. Lowercase
+
+ The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
+ MUST be represented in lowercase.
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 10]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+5. Text Representation of Special Addresses
+
+ Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+ IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses
+ embedded in the low-order 32 bits of the address. These addresses
+ have a special representation that may mix hexadecimal and dot
+ decimal notations. The decimal notation may be used only for the
+ last 32 bits of the address. For these addresses, mixed notation is
+ RECOMMENDED if the following condition is met: the address can be
+ distinguished as having IPv4 addresses embedded in the lower 32 bits
+ solely from the address field through the use of a well-known prefix.
+ Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+ this writing. If it is known by some external method that a given
+ prefix is used to embed IPv4, it MAY be represented as mixed
+ notation. Tools that provide options to specify prefixes that are
+ (or are not) to be represented as mixed notation may be useful.
+
+ There is a trade-off here where a recommendation to achieve an exact
+ match in a search (no dot decimals whatsoever) and a recommendation
+ to help the readability of an address (dot decimal whenever possible)
+ does not result in the same solution. The above recommendation is
+ aimed at fixing the representation as much as possible while leaving
+ the opportunity for future well-known prefixes to be represented in a
+ human-friendly manner as tools adjust to newly assigned prefixes.
+
+ The text representation method noted in Section 4 should be applied
+ for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of
+ 0:0:0:0:0:ffff:192.0.2.1).
+
+6. Notes on Combining IPv6 Addresses with Port Numbers
+
+ There are many different ways to combine IPv6 addresses and port
+ numbers that are represented in text. Examples are shown below.
+
+ o [2001:db8::1]:80
+
+ o 2001:db8::1:80
+
+ o 2001:db8::1.80
+
+ o 2001:db8::1 port 80
+
+ o 2001:db8::1p80
+
+ o 2001:db8::1#80
+
+ The situation is not much different in IPv4, but the most ambiguous
+ case with IPv6 is the second bullet. This is due to the "::"usage in
+
+
+
+Kawamura & Kawashima Standards Track [Page 11]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+ IPv6 addresses. This style is NOT RECOMMENDED because of its
+ ambiguity. The [] style as expressed in [RFC3986] SHOULD be
+ employed, and is the default unless otherwise specified. Other
+ styles are acceptable when there is exactly one style for the given
+ context and cross-platform portability does not become an issue. For
+ URIs containing IPv6 address literals, [RFC3986] MUST be followed, as
+ well as the rules defined in this document.
+
+7. Prefix Representation
+
+ Problems with prefixes are the same as problems encountered with
+ addresses. The text representation method of IPv6 prefixes should be
+ no different from that of IPv6 addresses.
+
+8. Security Considerations
+
+ This document notes some examples where IPv6 addresses are compared
+ in text format. The example on Section 3.2.5 is one that may cause a
+ security risk if used for access control. The common practice of
+ comparing X.509 data is done in binary format.
+
+9. Acknowledgements
+
+ The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
+ and Toshimitsu Matsuura for their generous and helpful comments in
+ kick starting this document. We also would like to thank Brian
+ Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave
+ Thaler, Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko,
+ Heikki Vatiainen, Dan Wing, and Doug Barton for their input. Also, a
+ very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+ Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+ this document to light in IETF working groups.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+ (SIIT)", RFC 2765, February 2000.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 12]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+10.2. Informative References
+
+ [ADDR-FORMAT] Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators",
+ Work in Progress, July 2010.
+
+ [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+ Castro, "Application Aspects of IPv6 Transition",
+ RFC 4038, March 2005.
+
+ [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+ Automatic Tunnel Addressing Protocol (ISATAP)",
+ RFC 5214, March 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 13]
+\f
+RFC 5952 IPv6 Text Representation August 2010
+
+
+Appendix A. For Developers
+
+ We recommend that developers use display routines that conform to
+ these rules. For example, the usage of getnameinfo() with flags
+ argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
+ except for the special addresses notes in Section 5. The function
+ inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+ be called directly. See [RFC4038] for details.
+
+Authors' Addresses
+
+ Seiichi Kawamura
+ NEC BIGLOBE, Ltd.
+ 14-22, Shibaura 4-chome
+ Minatoku, Tokyo 108-8558
+ JAPAN
+
+ Phone: +81 3 3798 6085
+ EMail: kawamucho@mesh.ad.jp
+
+
+ Masanobu Kawashima
+ NEC AccessTechnica, Ltd.
+ 800, Shimomata
+ Kakegawa-shi, Shizuoka 436-8501
+ JAPAN
+
+ Phone: +81 537 23 9655
+ EMail: kawashimam@necat.nec.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Standards Track [Page 14]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Bao
+Request for Comments: 6052 CERNET Center/Tsinghua University
+Updates: 4291 C. Huitema
+Category: Standards Track Microsoft Corporation
+ISSN: 2070-1721 M. Bagnulo
+ UC3M
+ M. Boucadair
+ France Telecom
+ X. Li
+ CERNET Center/Tsinghua University
+ October 2010
+
+
+ IPv6 Addressing of IPv4/IPv6 Translators
+
+Abstract
+
+ This document discusses the algorithmic translation of an IPv6
+ address to a corresponding IPv4 address, and vice versa, using only
+ statically configured information. It defines a well-known prefix
+ for use in algorithmic translations, while allowing organizations to
+ also use network-specific prefixes when appropriate. Algorithmic
+ translation is used in IPv4/IPv6 translators, as well as other types
+ of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
+
+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/rfc6052.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 1]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5
+ 2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
+ 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7
+ 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
+ 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8
+ 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
+ 3.3. Choice of Prefix for Stateless Translation Deployments . . 9
+ 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
+ 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
+ 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14
+ 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15
+ 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 2]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+1. Introduction
+
+ This document is part of a series of IPv4/IPv6 translation documents.
+ A framework for IPv4/IPv6 translation is discussed in
+ [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used
+ in this document. Other documents specify the behavior of various
+ types of translators and gateways, including mechanisms for
+ translating between IP headers and other types of messages that
+ include IP addresses. This document specifies how an individual IPv6
+ address is translated to a corresponding IPv4 address, and vice
+ versa, in cases where an algorithmic mapping is used. While specific
+ types of devices are used herein as examples, it is the
+ responsibility of the specification of such devices to reference this
+ document for algorithmic mapping of the addresses themselves.
+
+ Section 2 describes the prefixes and the format of "IPv4-embedded
+ IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
+ IPv4 address. This format is common to both "IPv4-converted" and
+ "IPv4-translatable" IPv6 addresses. This section also defines the
+ algorithms for translating addresses, and the text representation of
+ IPv4-embedded IPv6 addresses.
+
+ Section 3 discusses the choice of prefixes, the conditions in which
+ they can be used, and the use of IPv4-embedded IPv6 addresses with
+ stateless and stateful translation.
+
+ Section 4 provides a summary of the discussions behind two specific
+ design decisions, the choice of a null suffix and the specific value
+ of the selected prefix.
+
+ Section 5 discusses security concerns.
+
+ In some scenarios, a dual-stack host will unnecessarily send its
+ traffic through an IPv6/IPv4 translator. This can be caused by the
+ host's default address selection algorithm [RFC3484], referrals, or
+ other reasons. Optimizing these scenarios for dual-stack hosts is
+ for future study.
+
+1.1. Applicability Scope
+
+ This document is part of a series defining address translation
+ services. We understand that the address format could also be used
+ by other interconnection methods between IPv6 and IPv4, e.g., methods
+ based on encapsulation. If encapsulation methods are developed by
+ the IETF, we expect that their descriptions will document their
+ specific use of IPv4-embedded IPv6 addresses.
+
+
+
+
+
+Bao, et al. Standards Track [Page 3]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+1.2. Conventions
+
+ 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].
+
+1.3. Terminology
+
+ This document makes use of the following terms:
+
+ Address translator: any entity that has to derive an IPv4 address
+ from an IPv6 address or vice versa. This applies not only to
+ devices that do IPv4/IPv6 packet translation, but also to other
+ entities that manipulate addresses, such as name resolution
+ proxies (e.g., DNS64 [DNS64]) and possibly other types of
+ Application Layer Gateways (ALGs).
+
+ IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4
+ nodes in an IPv6 network. They are a variant of IPv4-embedded
+ IPv6 addresses and follow the format described in Section 2.2.
+
+ IPv4-embedded IPv6 addresses: IPv6 addresses in which 32 bits
+ contain an IPv4 address. Their format is described in
+ Section 2.2.
+
+ IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
+ packets, and vice versa. It may do "stateless" translation,
+ meaning that there is no per-flow state required, or "stateful"
+ translation, meaning that per-flow state is created when the first
+ packet in a flow is received.
+
+ IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6
+ nodes for use with stateless translation. They are a variant of
+ IPv4-embedded IPv6 addresses and follow the format described in
+ Section 2.2.
+
+ Network-Specific Prefix: an IPv6 prefix assigned by an organization
+ for use in algorithmic mapping. Options for the Network-Specific
+ Prefix are discussed in Sections 3.3 and 3.4.
+
+ Well-Known Prefix: the IPv6 prefix defined in this document for use
+ in an algorithmic mapping.
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 4]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+2. IPv4-Embedded IPv6 Address Prefix and Format
+
+2.1. Well-Known Prefix
+
+ This document reserves a "Well-Known Prefix" for use in an
+ algorithmic mapping. The value of this IPv6 prefix is:
+
+ 64:ff9b::/96
+
+2.2. IPv4-Embedded IPv6 Address Format
+
+ IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses
+ follow the same format, described here as the IPv4-embedded IPv6
+ address Format. IPv4-embedded IPv6 addresses are composed of a
+ variable-length prefix, the embedded IPv4 address, and a variable-
+ length suffix, as presented in the following diagram, in which PL
+ designates the prefix length:
+
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |32| prefix |v4(32) | u | suffix |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |40| prefix |v4(24) | u |(8)| suffix |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |48| prefix |v4(16) | u | (16) | suffix |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |56| prefix |(8)| u | v4(24) | suffix |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |64| prefix | u | v4(32) | suffix |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |96| prefix | v4(32) |
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+ Figure 1
+
+ In these addresses, the prefix shall be either the "Well-Known
+ Prefix" or a "Network-Specific Prefix" unique to the organization
+ deploying the address translators. The prefixes can only have one of
+ the following lengths: 32, 40, 48, 56, 64, or 96. (The Well-Known
+ Prefix is 96 bits long, and can only be used in the last form of the
+ table.)
+
+ Various deployments justify different prefix lengths with Network-
+ Specific Prefixes. The trade-off between different prefix lengths
+ are discussed in Sections 3.3 and 3.4.
+
+
+
+
+
+Bao, et al. Standards Track [Page 5]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ Bits 64 to 71 of the address are reserved for compatibility with the
+ host identifier format defined in the IPv6 addressing architecture
+ [RFC4291]. These bits MUST be set to zero. When using a /96
+ Network-Specific Prefix, the administrators MUST ensure that the bits
+ 64 to 71 are set to zero. A simple way to achieve that is to
+ construct the /96 Network-Specific Prefix by picking a /64 prefix,
+ and then adding 4 octets set to zero.
+
+ The IPv4 address is encoded following the prefix, most significant
+ bits first. Depending of the prefix length, the 4 octets of the
+ address may be separated by the reserved octet "u", whose 8 bits MUST
+ be set to zero. In particular:
+
+ o When the prefix is 32 bits long, the IPv4 address is encoded in
+ positions 32 to 63.
+
+ o When the prefix is 40 bits long, 24 bits of the IPv4 address are
+ encoded in positions 40 to 63, with the remaining 8 bits in
+ position 72 to 79.
+
+ o When the prefix is 48 bits long, 16 bits of the IPv4 address are
+ encoded in positions 48 to 63, with the remaining 16 bits in
+ position 72 to 87.
+
+ o When the prefix is 56 bits long, 8 bits of the IPv4 address are
+ encoded in positions 56 to 63, with the remaining 24 bits in
+ position 72 to 95.
+
+ o When the prefix is 64 bits long, the IPv4 address is encoded in
+ positions 72 to 103.
+
+ o When the prefix is 96 bits long, the IPv4 address is encoded in
+ positions 96 to 127.
+
+ There are no remaining bits, and thus no suffix, if the prefix is 96
+ bits long. In the other cases, the remaining bits of the address
+ constitute the suffix. These bits are reserved for future extensions
+ and SHOULD be set to zero. Address translators who receive IPv4-
+ embedded IPv6 addresses where these bits are not zero SHOULD ignore
+ the bits' value and proceed as if the bits' value were zero. (Future
+ extensions may specify a different behavior.)
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 6]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+2.3. Address Translation Algorithms
+
+ IPv4-embedded IPv6 addresses are composed according to the following
+ algorithm:
+
+ o Concatenate the prefix, the 32 bits of the IPv4 address, and the
+ suffix (if needed) to obtain a 128-bit address.
+
+ o If the prefix length is less than 96 bits, insert the null octet
+ "u" at the appropriate position (bits 64 to 71), thus causing the
+ least significant octet to be excluded, as documented in Figure 1.
+
+ The IPv4 addresses are extracted from the IPv4-embedded IPv6
+ addresses according to the following algorithm:
+
+ o If the prefix is 96 bits long, extract the last 32 bits of the
+ IPv6 address;
+
+ o For the other prefix lengths, remove the "u" octet to obtain a
+ 120-bit sequence (effectively shifting bits 72-127 to positions
+ 64-119), then extract the 32 bits following the prefix.
+
+2.4. Text Representation
+
+ IPv4-embedded IPv6 addresses will be represented in text in
+ conformity with Section 2.2 of [RFC4291]. IPv4-embedded IPv6
+ addresses constructed using the Well-Known Prefix or a /96 Network-
+ Specific Prefix may be represented using the alternative form
+ presented in Section 2.2 of [RFC4291], with the embedded IPv4 address
+ represented in dotted decimal notation. Examples of such
+ representations are presented in Tables 1 and 2.
+
+ +-----------------------+------------+------------------------------+
+ | Network-Specific | IPv4 | IPv4-embedded IPv6 address |
+ | Prefix | address | |
+ +-----------------------+------------+------------------------------+
+ | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: |
+ | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: |
+ | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: |
+ | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: |
+ | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
+ | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+ +-----------------------+------------+------------------------------+
+
+ Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using
+ Network-Specific Prefixes
+
+
+
+
+
+Bao, et al. Standards Track [Page 7]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ +-------------------+--------------+----------------------------+
+ | Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+ +-------------------+--------------+----------------------------+
+ | 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 |
+ +-------------------+--------------+----------------------------+
+
+ Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using
+ the Well-Known Prefix
+
+ The Network-Specific Prefix examples in Table 1 are derived from the
+ IPv6 prefix reserved for documentation in [RFC3849]. The IPv4
+ address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
+ documentation in [RFC5735]. The representation of IPv6 addresses is
+ compatible with [RFC5952].
+
+3. Deployment Guidelines
+
+3.1. Restrictions on the Use of the Well-Known Prefix
+
+ The Well-Known Prefix MUST NOT be used to represent non-global IPv4
+ addresses, such as those defined in [RFC1918] or listed in Section 3
+ of [RFC5735]. Address translators MUST NOT translate packets in
+ which an address is composed of the Well-Known Prefix and a non-
+ global IPv4 address; they MUST drop these packets.
+
+ The Well-Known Prefix SHOULD NOT be used to construct IPv4-
+ translatable IPv6 addresses. The nodes served by IPv4-translatable
+ IPv6 addresses should be able to receive global IPv6 traffic bound to
+ their IPv4-translatable IPv6 address without incurring intermediate
+ protocol translation. This is only possible if the specific prefix
+ used to build the IPv4-translatable IPv6 addresses is advertised in
+ inter-domain routing, but the advertisement of more specific prefixes
+ derived from the Well-Known Prefix is not supported, as explained in
+ Section 3.2. Network-Specific Prefixes SHOULD be used in these
+ scenarios, as explained in Section 3.3.
+
+ The Well-Known Prefix MAY be used by organizations deploying
+ translation services, as explained in Section 3.4.
+
+3.2. Impact on Inter-Domain Routing
+
+ The Well-Known Prefix MAY appear in inter-domain routing tables, if
+ service providers decide to provide IPv6-IPv4 interconnection
+ services to peers. Advertisement of the Well-Known Prefix SHOULD be
+ controlled either by upstream and/or downstream service providers
+ according to inter-domain routing policies, e.g., through
+
+
+
+
+
+Bao, et al. Standards Track [Page 8]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ configuration of BGP [RFC4271]. Organizations that advertise the
+ Well-Known Prefix in inter-domain routing MUST be able to provide
+ IPv4/IPv6 translation service.
+
+ When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4-
+ embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
+ advertised in BGP (especially External BGP) [RFC4271] because this
+ leads to importing the IPv4 routing table into the IPv6 one and
+ therefore introduces scalability issues to the global IPv6 routing
+ table. Administrators of BGP nodes SHOULD configure filters that
+ discard advertisements of embedded IPv6 prefixes longer than the
+ Well-Known Prefix.
+
+ When the IPv4/IPv6 translation service relies on Network-Specific
+ Prefixes, the IPv4-translatable IPv6 prefixes used in stateless
+ translation MUST be advertised with proper aggregation to the IPv6
+ Internet. Similarly, if translators are configured with multiple
+ Network-Specific Prefixes, these prefixes MUST be advertised to the
+ IPv6 Internet with proper aggregation.
+
+3.3. Choice of Prefix for Stateless Translation Deployments
+
+ Organizations may deploy translation services using stateless
+ translation. In these deployments, internal IPv6 nodes are addressed
+ using IPv4-translatable IPv6 addresses, which enable them to be
+ accessed by IPv4 nodes. The addresses of these external IPv4 nodes
+ are then represented in IPv4-converted IPv6 addresses.
+
+ Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
+ a Network-Specific Prefix to their IPv4/IPv6 translation service.
+ IPv4-translatable and IPv4-converted IPv6 addresses MUST be
+ constructed as specified in Section 2.2. IPv4-translatable IPv6
+ addresses MUST use the selected Network-Specific Prefix. Both IPv4-
+ translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD
+ use the same prefix.
+
+ Using the same prefix ensures that IPv6 nodes internal to the
+ organization will use the most efficient paths to reach the nodes
+ served by IPv4-translatable IPv6 addresses. Specifically, if a node
+ learns the IPv4 address of a target internal node without knowing
+ that this target is in fact located behind the same translator that
+ the node also uses, translation rules will ensure that the IPv6
+ address constructed with the Network-Specific Prefix is the same as
+ the IPv4-translatable IPv6 address assigned to the target. Standard
+ routing preference (i.e., "most specific match wins") will then
+ ensure that the IPv6 packets are delivered directly, without
+ requiring that translators receive the packets and then return them
+ in the direction from which they came.
+
+
+
+Bao, et al. Standards Track [Page 9]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ The intra-domain routing protocol must be able to deliver packets to
+ the nodes served by IPv4-translatable IPv6 addresses. This may
+ require routing on some or all of the embedded IPv4 address bits.
+ Security considerations detailed in Section 5 require that routers
+ check the validity of the IPv4-translatable IPv6 source addresses,
+ using some form of reverse path check.
+
+ The management of stateless address translation can be illustrated
+ with a small example:
+
+ We will consider an IPv6 network with the prefix 2001:db8:
+ 122::/48. The network administrator has selected the Network-
+ Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/
+ IPv6 translation. The IPv4-translatable address block for IPv4
+ subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this
+ network, the host A is assigned the IPv4-translatable IPv6 address
+ 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4
+ address 192.0.2.33. Host A's address is configured either
+ manually or through DHCPv6.
+
+ In this example, host A is not directly connected to the
+ translator, but instead to a link managed by a router R. The
+ router R is configured to forward to A the packets bound to 2001:
+ db8:122:344:c0:2:2100::. To receive these packets, R will
+ advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/
+ 104 in the intra-domain routing protocol -- or perhaps a shorter
+ prefix if many hosts on link have IPv4-translatable IPv6 addresses
+ derived from the same IPv4 subnet. If a packet bound to
+ 192.0.2.33 reaches the translator, the destination address will be
+ translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
+ routed towards R and then to A.
+
+ Let's suppose now that a host B of the same domain learns the IPv4
+ address of A, maybe through an application-specific referral. If
+ B has translation-aware software, B can compose a destination
+ address by combining the Network-Specific Prefix 2001:db8:122:
+ 344::/64 and the IPv4 address 192.0.2.33, resulting in the address
+ 2001:db8:122:344:c0:2:2100::. The packet sent by B will be
+ forwarded towards R, and then to A, avoiding protocol translation.
+
+ Forwarding, and reverse path checks, are more efficient when
+ performed on the combination of the prefix and the IPv4 address. In
+ theory, routers are able to route on prefixes of any length, but in
+ practice there may be routers for which routing on prefixes larger
+ than 64 bits is slower. However, routing efficiency is not the only
+ consideration in the choice of a prefix length. Organizations also
+ need to consider the availability of prefixes, and the potential
+ impact of all-zero identifiers.
+
+
+
+Bao, et al. Standards Track [Page 10]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ If a /32 prefix is used, all the routing bits are contained in the
+ top 64 bits of the IPv6 address, leading to excellent routing
+ properties. These prefixes may however be hard to obtain, and
+ allocation of a /32 to a small set of IPv4-translatable IPv6
+ addresses may be seen as wasteful. In addition, the /32 prefix and a
+ zero suffix lead to an all-zero interface identifier, which is an
+ issue that we discuss in Section 4.1.
+
+ Intermediate prefix lengths such as /40, /48, or /56 appear as
+ compromises. Only some of the IPv4 bits are part of the /64
+ prefixes. Reverse path checks, in particular, may have a limited
+ efficiency. Reverse path checks limited to the most significant bits
+ of the IPv4 address will reduce the possibility of spoofing external
+ IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
+ translatable IPv6 addresses.
+
+ We propose a compromise, based on using no more than 1/256th of an
+ organization's allocation of IPv6 addresses for the IPv4/IPv6
+ translation service. For example, if the organization is an Internet
+ Service Provider with an allocated IPv6 prefix /32 or shorter, the
+ ISP could dedicate a /40 prefix to the translation service. An end
+ site with a /48 allocation could dedicate a /56 prefix to the
+ translation service, or possibly a /96 prefix if all IPv4-
+ translatable IPv6 addresses are located on the same link.
+
+ The recommended prefix length is also a function of the deployment
+ scenario. The stateless translation can be used for Scenario 1,
+ Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK].
+ For different scenarios, the prefix length recommendations are:
+
+ o For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario
+ 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32
+ allocation SHOULD use a /40 prefix, and a site holding a /48
+ allocation SHOULD use a /56 prefix.
+
+ o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6
+ (an IPv4 network to an IPv6 network), the deployment SHOULD use a
+ /64 or a /96 prefix.
+
+3.4. Choice of Prefix for Stateful Translation Deployments
+
+ Organizations may deploy translation services based on stateful
+ translation technology. An organization may decide to use either a
+ Network-Specific Prefix or the Well-Known Prefix for its stateful
+ IPv4/IPv6 translation service.
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 11]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ When these services are used, IPv6 nodes are addressed through
+ standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
+ converted IPv6 addresses, as specified in Section 2.2.
+
+ The stateful nature of the translation creates a potential stability
+ issue when the organization deploys multiple translators. If several
+ translators use the same prefix, there is a risk that packets
+ belonging to the same connection may be routed to different
+ translators as the internal routing state changes. This issue can be
+ avoided either by assigning different prefixes to different
+ translators or by ensuring that all translators using the same prefix
+ coordinate their state.
+
+ Stateful translation can be used in scenarios defined in
+ [v4v6-FRAMEWORK]. The Well-Known Prefix SHOULD be used in these
+ scenarios, with two exceptions:
+
+ o In all scenarios, the translation MAY use a Network-Specific
+ Prefix, if deemed appropriate for management reasons.
+
+ o The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6
+ Internet to an IPv4 network), as this would lead to using the
+ Well-Known Prefix with non-global IPv4 addresses. That means a
+ Network-Specific Prefix (for example, a /96 prefix) MUST be used
+ in that scenario.
+
+4. Design Choices
+
+ The prefix that we have chosen reflects two design choices, the null
+ suffix and the specific value of the Well-Known Prefix. We provide
+ here a summary of the discussions leading to those two choices.
+
+4.1. Choice of Suffix
+
+ The address format described in Section 2.2 recommends a zero suffix.
+ Before making this recommendation, we considered different options:
+ checksum neutrality, the encoding of a port range, and a value
+ different than 0.
+
+ In the case of stateless translation, there would be no need for the
+ translator to recompute a one's complement checksum if both the IPv4-
+ translatable and the IPv4-converted IPv6 addresses were constructed
+ in a "checksum-neutral" manner, that is, if the IPv6 addresses would
+ have the same one's complement checksum as the embedded IPv4 address.
+ In the case of stateful translation, checksum neutrality does not
+ eliminate checksum computation during translation, as only one of the
+ two addresses would be checksum neutral. We considered reserving 16
+ bits in the suffix to guarantee checksum neutrality, but declined
+
+
+
+Bao, et al. Standards Track [Page 12]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ because it would not help with stateful translation and because
+ checksum neutrality can also be achieved by an appropriate choice of
+ the Network-Specific Prefix, i.e., selecting a prefix whose one's
+ complement checksum equals either 0 or 0xffff.
+
+ There have been proposals to complement stateless translation with a
+ port-range feature. Instead of mapping an IPv4 address to exactly
+ one IPv6 prefix, the options would allow several IPv6 nodes to share
+ an IPv4 address, with each node managing a different range of ports.
+ If a port range extension is needed, it could be defined later, using
+ bits currently reserved as null in the suffix.
+
+ When a /32 prefix is used, an all-zero suffix results in an all-zero
+ interface identifier. We understand the conflict with Section 2.6.1
+ of RFC4291, which specifies that all zeroes are used for the subnet-
+ router anycast address. However, in our specification, there is only
+ one node with an IPv4-translatable IPv6 address in the /64 subnet, so
+ the anycast semantic does not create confusion. We thus decided to
+ keep the null suffix for now. This issue does not exist for prefixes
+ larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that
+ we recommend in Section 3.3.
+
+4.2. Choice of the Well-Known Prefix
+
+ Before making our recommendation of the Well-Known Prefix, we were
+ faced with three choices:
+
+ o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC
+ 2765, Section 2.1;
+
+ o request IANA to allocate a /32 prefix, or
+
+ o request allocation of a new /96 prefix.
+
+ We weighted the pros and cons of these choices before settling on the
+ recommended /96 Well-Known Prefix.
+
+ The main advantage of the existing IPv4-mapped prefix is that it is
+ already defined. Reusing that prefix would require minimal
+ standardization efforts. However, being already defined is not just
+ an advantage, as there may be side effects of current
+ implementations. When presented with the IPv4-mapped prefix, current
+ versions of Windows and Mac OS generate IPv4 packets, but will not
+ send IPv6 packets. If we used the IPv4-mapped prefix, these nodes
+ would not be able to support translation without modification. This
+ will defeat the main purpose of the translation techniques. We thus
+ eliminated the first choice, i.e., decided to not reuse the IPv4-
+ mapped prefix, ::ffff:0:0/96.
+
+
+
+Bao, et al. Standards Track [Page 13]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ A /32 prefix would have allowed the embedded IPv4 address to fit
+ within the top 64 bits of the IPv6 address. This would have
+ facilitated routing and load balancing when an organization deploys
+ several translators. However, such destination-address-based load
+ balancing may not be desirable. It is not compatible with Session
+ Traversal Utilities for NAT (STUN) [RFC5389] in the deployments
+ involving multiple stateful translators, each one having a different
+ pool of IPv4 addresses. STUN compatibility would only be achieved if
+ the translators managed the same pool of IPv4 addresses and were able
+ to coordinate their translation state, in which case there is no big
+ advantage to using a /32 prefix rather than a /96 prefix.
+
+ According to Section 2.2 of [RFC4291], in the legal textual
+ representations of IPv6 addresses, dotted decimal can only appear at
+ the end. The /96 prefix is compatible with that requirement. It
+ enables the dotted decimal notation without requiring an update to
+ [RFC4291]. This representation makes the address format easier to
+ use and the log files easier to read.
+
+ The prefix that we recommend has the particularity of being "checksum
+ neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is
+ "ffff", i.e., a value equal to zero in one's complement arithmetic.
+ An IPv4-embedded IPv6 address constructed with this prefix will have
+ the same one's complement checksum as the embedded IPv4 address.
+
+5. Security Considerations
+
+5.1. Protection against Spoofing
+
+ IPv4/IPv6 translators can be modeled as special routers, are subject
+ to the same risks, and can implement the same mitigations. (The
+ discussion of generic threats to routers and their mitigations is
+ beyond the scope of this document.) There is, however, a particular
+ risk that directly derives from the practice of embedding IPv4
+ addresses in IPv6: address spoofing.
+
+ An attacker could use an IPv4-embedded IPv6 address as the source
+ address of malicious packets. After translation, the packets will
+ appear as IPv4 packets from the specified source, and the attacker
+ may be hard to track. If left without mitigation, the attack would
+ allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
+
+ The mitigation is to implement reverse path checks and to verify
+ throughout the network that packets are coming from an authorized
+ location.
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 14]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+5.2. Secure Configuration
+
+ The prefixes used for address translation are used by IPv6 nodes to
+ send packets to IPv6/IPv4 translators. Attackers could attempt to
+ fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
+ values for these parameters, resulting in network disruption, denial
+ of service, and possible information disclosure. To mitigate such
+ attacks, network administrators need to ensure that prefixes are
+ configured in a secure way.
+
+ The mechanisms for achieving secure configuration of prefixes are
+ beyond the scope of this document.
+
+5.3. Firewall Configuration
+
+ Many firewalls and other security devices filter traffic based on
+ IPv4 addresses. Attackers could attempt to fool these firewalls by
+ sending IPv6 packets to or from IPv6 addresses that translate to the
+ filtered IPv4 addresses. If the attack is successful, traffic that
+ was previously blocked might be able to pass through the firewalls
+ disguised as IPv6 packets. In all such scenarios, administrators
+ should assure that packets that send to or from IPv4-embedded IPv6
+ addresses are subject to the same filtering as those directly sent to
+ or from the embedded IPv4 addresses.
+
+ The mechanisms for configuring firewalls and security devices to
+ achieve this filtering are beyond the scope of this document.
+
+6. IANA Considerations
+
+ IANA has made the following changes in the "Internet Protocol Version
+ 6 Address Space" registry located at http://www.iana.org.
+
+ OLD:
+
+ IPv6 Prefix Allocation Reference Note
+ ----------- ---------------- ------------ ----------------
+ 0000::/8 Reserved by IETF [RFC4291] [1][5]
+
+ NEW:
+
+ IPv6 Prefix Allocation Reference Note
+ ----------- ---------------- ------------ ----------------
+ 0000::/8 Reserved by IETF [RFC4291] [1][5][6]
+
+ [6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic
+ mapping between IPv4 to IPv6 addresses is defined out of the
+ 0000::/8 address block, per RFC 6052.
+
+
+
+Bao, et al. Standards Track [Page 15]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+7. Acknowledgements
+
+ Many people in the BEHAVE WG have contributed to the discussion that
+ led to this document, including Andrew Sullivan, Andrew Yourtchenko,
+ Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler,
+ David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch
+ van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
+ Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
+ Matthews, Remi Denis-Courmont, Remi Despres, and William Waites.
+
+ Marcelo Bagnulo is partly funded by Trilogy, a research project
+ supported by the European Commission under its Seventh Framework
+ Program.
+
+8. Contributors
+
+ The following individuals co-authored documents from which text has
+ been incorporated, and are listed in alphabetical order.
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ USA
+ Phone: +1 425 703 8835
+ EMail: dthaler@microsoft.com
+
+ Fred Baker
+ Cisco Systems
+ Santa Barbara, California 93117
+ USA
+ Phone: +1-408-526-4257
+ Fax: +1-413-473-2403
+ EMail: fred@cisco.com
+
+ Hiroshi Miyata
+ Yokogawa Electric Corporation
+ 2-9-32 Nakacho
+ Musashino-shi, Tokyo 180-8750
+ JAPAN
+ EMail: h.miyata@jp.yokogawa.com
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 16]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+9.2. Informative References
+
+ [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
+ "DNS64: DNS extensions for Network Address Translation
+ from IPv6 Clients to IPv4 Servers", Work in Progress,
+ October 2010.
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+ E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+ Reserved for Documentation", RFC 3849, July 2004.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+ Address Text Representation", RFC 5952, August 2010.
+
+ [v4v6-FRAMEWORK]
+ Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", Work in Progress, August 2010.
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 17]
+\f
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+Authors' Addresses
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+ Phone: +86 10-62785983
+ EMail: congxiao@cernet.edu.cn
+
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ U.S.A.
+ EMail: huitema@microsoft.com
+
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+ Phone: +34-91-6249500
+ EMail: marcelo@it.uc3m.es
+ URI: http://www.it.uc3m.es/marcelo
+
+
+ Mohamed Boucadair
+ France Telecom
+ 3, Av Francois Chateaux
+ Rennes 350000
+ France
+ EMail: mohamed.boucadair@orange-ftgroup.com
+
+
+ Xing Li
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+ Phone: +86 10-62785983
+ EMail: xing@cernet.edu.cn
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 18]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Bagnulo
+Request for Comments: 6147 UC3M
+Category: Standards Track A. Sullivan
+ISSN: 2070-1721 Shinkuro
+ P. Matthews
+ Alcatel-Lucent
+ I. van Beijnum
+ IMDEA Networks
+ April 2011
+
+
+ DNS64: DNS Extensions for Network Address Translation
+ from IPv6 Clients to IPv4 Servers
+
+Abstract
+
+ DNS64 is a mechanism for synthesizing AAAA records from A records.
+ DNS64 is used with an IPv6/IPv4 translator to enable client-server
+ communication between an IPv6-only client and an IPv4-only server,
+ without requiring any changes to either the IPv6 or the IPv4 node,
+ for the class of applications that work through NATs. This document
+ specifies DNS64, and provides suggestions on how it should be
+ deployed in conjunction with IPv6/IPv4 translators.
+
+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/rfc6147.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 1]
+\f
+RFC 6147 DNS64 April 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 2]
+\f
+RFC 6147 DNS64 April 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Overview ........................................................5
+ 3. Background to DNS64-DNSSEC Interaction ..........................7
+ 4. Terminology .....................................................9
+ 5. DNS64 Normative Specification ..................................10
+ 5.1. Resolving AAAA Queries and the Answer Section .............11
+ 5.1.1. The Answer when There is AAAA Data Available .......11
+ 5.1.2. The Answer when There is an Error ..................11
+ 5.1.3. Dealing with Timeouts ..............................12
+ 5.1.4. Special Exclusion Set for AAAA Records .............12
+ 5.1.5. Dealing with CNAME and DNAME .......................12
+ 5.1.6. Data for the Answer when Performing Synthesis ......13
+ 5.1.7. Performing the Synthesis ...........................13
+ 5.1.8. Querying in Parallel ...............................14
+ 5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
+ 5.3. Handling Other Resource Records and the Additional
+ Section ...................................................15
+ 5.3.1. PTR Resource Record ................................15
+ 5.3.2. Handling the Additional Section ....................16
+ 5.3.3. Other Resource Records .............................17
+ 5.4. Assembling a Synthesized Response to a AAAA Query .........17
+ 5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
+ 6. Deployment Notes ...............................................19
+ 6.1. DNS Resolvers and DNS64 ...................................19
+ 6.2. DNSSEC Validators and DNS64 ...............................19
+ 6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19
+ 6.3.1. IPv6 Multihomed Hosts ..............................19
+ 6.3.2. Accidental Dual-Stack DNS64 Use ....................20
+ 6.3.3. Intentional Dual-Stack DNS64 Use ...................21
+ 7. Deployment Scenarios and Examples ..............................21
+ 7.1. Example of "an IPv6 Network to the IPv4 Internet"
+ Setup with DNS64 in DNS Server Mode .......................22
+ 7.2. Example of "an IPv6 Network to the IPv4 Internet"
+ Setup with DNS64 in Stub-Resolver Mode ....................23
+ 7.3. Example of "the IPv6 Internet to an IPv4 Network"
+ Setup with DNS64 in DNS Server Mode .......................24
+ 8. Security Considerations ........................................27
+ 9. Contributors ...................................................27
+ 10. Acknowledgements ..............................................27
+ 11. References ....................................................28
+ 11.1. Normative References .....................................28
+ 11.2. Informative References ...................................28
+ Appendix A. Motivations and Implications of Synthesizing AAAA
+ Resource Records when Real AAAA Resource Records
+ Exist ................................................30
+
+
+
+
+Bagnulo, et al. Standards Track [Page 3]
+\f
+RFC 6147 DNS64 April 2011
+
+
+1. Introduction
+
+ This document specifies DNS64, a mechanism that is part of the
+ toolbox for IPv4-IPv6 transition and coexistence. DNS64, used
+ together with an IPv6/IPv4 translator such as stateful NAT64
+ [RFC6146], allows an IPv6-only client to initiate communications by
+ name to an IPv4-only server.
+
+ DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+ from A RRs. A synthetic AAAA RR created by the DNS64 from an
+ original A RR contains the same owner name of the original A RR, but
+ it contains an IPv6 address instead of an IPv4 address. The IPv6
+ address is an IPv6 representation of the IPv4 address contained in
+ the original A RR. The IPv6 representation of the IPv4 address is
+ algorithmically generated from the IPv4 address returned in the A RR
+ and a set of parameters configured in the DNS64 (typically, an IPv6
+ prefix used by IPv6 representations of IPv4 addresses and,
+ optionally, other parameters).
+
+ Together with an IPv6/IPv4 translator, these two mechanisms allow an
+ IPv6-only client to initiate communications to an IPv4-only server
+ using the Fully Qualified Domain Name (FQDN) of the server.
+
+ These mechanisms are expected to play a critical role in the IPv4-
+ IPv6 transition and coexistence. Due to IPv4 address depletion, it
+ is likely that in the future, many IPv6-only clients will want to
+ connect to IPv4-only servers. In the typical case, the approach only
+ requires the deployment of IPv6/IPv4 translators that connect an
+ IPv6-only network to an IPv4-only network, along with the deployment
+ of one or more DNS64-enabled name servers. However, some features
+ require performing the DNS64 function directly in the end hosts
+ themselves.
+
+ This document is structured as follows: Section 2 provides a
+ non-normative overview of the behavior of DNS64. Section 3 provides
+ a non-normative background required to understand the interaction
+ between DNS64 and DNS Security Extensions (DNSSEC). The normative
+ specification of DNS64 is provided in Sections 4, 5, and 6.
+ Section 4 defines the terminology, Section 5 is the actual DNS64
+ specification, and Section 6 covers deployment issues. Section 7 is
+ non-normative and provides a set of examples and typical deployment
+ scenarios.
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 4]
+\f
+RFC 6147 DNS64 April 2011
+
+
+2. Overview
+
+ This section provides an introduction to the DNS64 mechanism.
+
+ We assume that we have one or more IPv6/IPv4 translator boxes
+ connecting an IPv4 network and an IPv6 network. The IPv6/IPv4
+ translator device provides translation services between the two
+ networks, enabling communication between IPv4-only hosts and
+ IPv6-only hosts. (NOTE: By "IPv6-only hosts", we mean hosts running
+ IPv6-only applications and hosts that can only use IPv6, as well as
+ cases where only IPv6 connectivity is available to the client. By
+ "IPv4-only servers", we mean servers running IPv4-only applications
+ and servers that can only use IPv4, as well as cases where only IPv4
+ connectivity is available to the server). Each IPv6/IPv4 translator
+ used in conjunction with DNS64 must allow communications initiated
+ from the IPv6-only host to the IPv4-only host.
+
+ To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+ learn the address of the responder, DNS64 is used to synthesize a
+ AAAA record from an A record containing a real IPv4 address of the
+ responder, whenever the DNS64 cannot retrieve a AAAA record for the
+ queried name. The DNS64 service appears as a regular DNS server or
+ resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query
+ generated by the IPv6 initiator. It first attempts a resolution for
+ the requested AAAA records. If there are no AAAA records available
+ for the target node (which is the normal case when the target node is
+ an IPv4-only node), DNS64 performs a query for A records. For each A
+ record discovered, DNS64 creates a synthetic AAAA RR from the
+ information retrieved in the A RR.
+
+ The owner name of a synthetic AAAA RR is the same as that of the
+ original A RR, but an IPv6 representation of the IPv4 address
+ contained in the original A RR is included in the AAAA RR. The IPv6
+ representation of the IPv4 address is algorithmically generated from
+ the IPv4 address and additional parameters configured in the DNS64.
+ Among those parameters configured in the DNS64, there is at least one
+ IPv6 prefix. If not explicitly mentioned, all prefixes are treated
+ equally, and the operations described in this document are performed
+ using the prefixes available. So as to be general, we will call any
+ of these prefixes Pref64::/n, and describe the operations made with
+ the generic prefix Pref64::/n. The IPv6 addresses representing IPv4
+ addresses included in the AAAA RR synthesized by the DNS64 contain
+ Pref64::/n, and they also embed the original IPv4 address.
+
+ The same algorithm and the same Pref64::/n prefix(es) must be
+ configured both in the DNS64 device and the IPv6/IPv4 translator(s),
+ so that both can algorithmically generate the same IPv6
+ representation for a given IPv4 address. In addition, it is required
+
+
+
+Bagnulo, et al. Standards Track [Page 5]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ that IPv6 packets addressed to an IPv6 destination address that
+ contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
+ has that particular Pref64::/n configured, so they can be translated
+ into IPv4 packets.
+
+ Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
+ are passed back to the IPv6 initiator, which will initiate an IPv6
+ communication with the IPv6 address associated with the IPv4
+ receiver. The packet will be routed to an IPv6/IPv4 translator,
+ which will forward it to the IPv4 network.
+
+ In general, the only shared state between the DNS64 and the IPv6/IPv4
+ translator is the Pref64::/n and an optional set of static
+ parameters. The Pref64::/n and the set of static parameters must be
+ configured to be the same on both; there is no communication between
+ the DNS64 device and IPv6/IPv4 translator functions. The mechanism
+ to be used for configuring the parameters of the DNS64 is beyond the
+ scope of this memo.
+
+ The prefixes to be used as Pref64::/n and their applicability are
+ discussed in [RFC6052]. There are two types of prefixes that can be
+ used as Pref64::/n.
+
+ o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved
+ by [RFC6052] for the purpose of representing IPv4 addresses in
+ IPv6 address space.
+
+ o The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is
+ an IPv6 prefix assigned by an organization to create IPv6
+ representations of IPv4 addresses.
+
+ The main difference in the nature of the two types of prefixes is
+ that the NSP is a locally assigned prefix that is under control of
+ the organization that is providing the translation services, while
+ the Well-Known Prefix is a prefix that has a global meaning since it
+ has been assigned for the specific purpose of representing IPv4
+ addresses in IPv6 address space.
+
+ The DNS64 function can be performed in any of three places. The
+ terms below are more formally defined in Section 4.
+
+ The first option is to locate the DNS64 function in authoritative
+ servers for a zone. In this case, the authoritative server provides
+ synthetic AAAA RRs for an IPv4-only host in its zone. This is one
+ type of DNS64 server.
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 6]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ Another option is to locate the DNS64 function in recursive name
+ servers serving end hosts. In this case, when an IPv6-only host
+ queries the name server for AAAA RRs for an IPv4-only host, the name
+ server can perform the synthesis of AAAA RRs and pass them back to
+ the IPv6-only initiator. The main advantage of this mode is that
+ current IPv6 nodes can use this mechanism without requiring any
+ modification. This mode is called "DNS64 in DNS recursive-resolver
+ mode". This is a second type of DNS64 server, and it is also one
+ type of DNS64 resolver.
+
+ The last option is to place the DNS64 function in the end hosts,
+ coupled to the local (stub) resolver. In this case, the stub
+ resolver will try to obtain (real) AAAA RRs, and in case they are not
+ available, the DNS64 function will synthesize AAAA RRs for internal
+ usage. This mode is compatible with some functions like DNSSEC
+ validation in the end host. The main drawback of this mode is its
+ deployability, since it requires changes in the end hosts. This mode
+ is called "DNS64 in stub-resolver mode". This is the second type of
+ DNS64 resolver.
+
+3. Background to DNS64-DNSSEC Interaction
+
+ DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge
+ for DNS64, because DNSSEC is designed to detect changes to DNS
+ answers, and DNS64 may alter answers coming from an authoritative
+ server.
+
+ A recursive resolver can be security-aware or security-oblivious.
+ Moreover, a security-aware recursive resolver can be validating or
+ non-validating, according to operator policy. In the cases below,
+ the recursive resolver is also performing DNS64, and has a local
+ policy to validate. We call this general case vDNS64, but in all the
+ cases below, the DNS64 functionality should be assumed to be needed.
+
+ DNSSEC includes some signaling bits that offer some indicators of
+ what the query originator understands.
+
+ If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
+ set, the query originator is signaling that it understands DNSSEC.
+ The DO bit does not indicate that the query originator will validate
+ the response. It only means that the query originator can understand
+ responses containing DNSSEC data. Conversely, if the DO bit is
+ clear, that is evidence that the querying agent is not aware of
+ DNSSEC.
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 7]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ If a query arrives at a vDNS64 device with the "Checking Disabled"
+ (CD) bit set, it is an indication that the querying agent wants all
+ the validation data so it can do checking itself. By local policy,
+ vDNS64 could still validate, but it must return all data to the
+ querying agent anyway.
+
+ Here are the possible cases:
+
+ 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
+ the DO bit clear. In this case, DNSSEC is not a concern, because
+ the querying agent does not understand DNSSEC responses. The
+ DNS64 can do validation of the response, if dictated by its local
+ policy.
+
+ 2. A security-oblivious DNS64 receives a query with the DO bit set,
+ and the CD bit clear or set. This is just like the case of a
+ non-DNS64 case: the server doesn't support it, so the querying
+ agent is out of luck.
+
+ 3. A security-aware and non-validating DNS64 receives a query with
+ the DO bit set and the CD bit clear. Such a resolver is not
+ validating responses, likely due to local policy (see [RFC4035],
+ Section 4.2). For that reason, this case amounts to the same as
+ the previous case, and no validation happens.
+
+ 4. A security-aware and non-validating DNS64 receives a query with
+ the DO bit set and the CD bit set. In this case, the DNS64 is
+ supposed to pass on all the data it gets to the query initiator
+ (see Section 3.2.2 of [RFC4035]). This case will not work with
+ DNS64, unless the validating resolver is prepared to do DNS64
+ itself. If the DNS64 modifies the record, the client will get
+ the data back and try to validate it, and the data will be
+ invalid as far as the client is concerned.
+
+ 5. A security-aware and validating DNS64 resolver receives a query
+ with the DO bit clear and the CD bit clear. In this case, the
+ resolver validates the data. If it fails, it returns RCODE 2
+ (Server failure); otherwise, it returns the answer. This is the
+ ideal case for vDNS64. The resolver validates the data, and then
+ synthesizes the new record and passes that to the client. The
+ client, which is presumably not validating (else it should have
+ set DO and CD), cannot tell that DNS64 is involved.
+
+ 6. A security-aware and validating DNS64 resolver receives a query
+ with the DO bit set and the CD bit clear. This works like the
+ previous case, except that the resolver should also set the
+ "Authentic Data" (AD) bit on the response.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 8]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ 7. A security-aware and validating DNS64 resolver receives a query
+ with the DO bit set and the CD bit set. This is effectively the
+ same as the case where a security-aware and non-validating
+ recursive resolver receives a similar query, and the same thing
+ will happen: the downstream validator will mark the data as
+ invalid if DNS64 has performed synthesis. The node needs to do
+ DNS64 itself, or else communication will fail.
+
+4. Terminology
+
+ This section provides definitions for the special terms used in the
+ 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 RFC 2119 [RFC2119].
+
+ Authoritative server: A DNS server that can answer authoritatively a
+ given DNS request.
+
+ DNS64: A logical function that synthesizes DNS resource records
+ (e.g., AAAA records containing IPv6 addresses) from DNS resource
+ records actually contained in the DNS (e.g., A records containing
+ IPv4 addresses).
+
+ DNS64 recursive resolver: A recursive resolver that provides the
+ DNS64 functionality as part of its operation. This is the same
+ thing as "DNS64 in recursive-resolver mode".
+
+ DNS64 resolver: Any resolver (stub resolver or recursive resolver)
+ that provides the DNS64 function.
+
+ DNS64 server: Any server providing the DNS64 function. This
+ includes the server portion of a recursive resolver when it is
+ providing the DNS64 function.
+
+ IPv4-only server: Servers running IPv4-only applications and servers
+ that can only use IPv4, as well as cases where only IPv4
+ connectivity is available to the server.
+
+ IPv6-only hosts: Hosts running IPv6-only applications and hosts that
+ can only use IPv6, as well as cases where only IPv6 connectivity
+ is available to the client.
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 9]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ Recursive resolver: A DNS server that accepts requests from one
+ resolver, and asks another server (of some description) for the
+ answer on behalf of the first resolver. Full discussion of DNS
+ recursion is beyond the scope of this document; see [RFC1034] and
+ [RFC1035] for full details.
+
+ Synthetic RR: A DNS resource record (RR) that is not contained in
+ the authoritative servers' zone data, but which is instead
+ synthesized from other RRs in the same zone. An example is a
+ synthetic AAAA record created from an A record.
+
+ IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
+ packets and vice versa. It is only required that the
+ communication initiated from the IPv6 side be supported.
+
+ For a detailed understanding of this document, the reader should also
+ be familiar with DNS terminology from [RFC1034] and [RFC1035] and
+ with current NAT terminology from [RFC4787]. Some parts of this
+ document assume familiarity with the terminology of the DNS security
+ extensions outlined in [RFC4035]. It is worth emphasizing that while
+ DNS64 is a logical function separate from the DNS, it is nevertheless
+ closely associated with that protocol. It depends on the DNS
+ protocol, and some behavior of DNS64 will interact with regular DNS
+ responses.
+
+5. DNS64 Normative Specification
+
+ DNS64 is a logical function that synthesizes AAAA records from A
+ records. The DNS64 function may be implemented in a stub resolver,
+ in a recursive resolver, or in an authoritative name server. It
+ works within those DNS functions, and appears on the network as
+ though it were a "plain" DNS resolver or name server conforming to
+ [RFC1034] and [RFC1035].
+
+ The implementation SHOULD support mapping of separate IPv4 address
+ ranges to separate IPv6 prefixes for AAAA record synthesis. This
+ allows handling of special use IPv4 addresses [RFC5735].
+
+ DNS messages contain several sections. The portion of a DNS message
+ that is altered by DNS64 is the answer section, which is discussed
+ below in Section 5.1. The resulting synthetic answer is put together
+ with other sections, and that creates the message that is actually
+ returned as the response to the DNS query. Assembling that response
+ is covered below in Section 5.4.
+
+ DNS64 also responds to PTR queries involving addresses containing any
+ of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 10]
+\f
+RFC 6147 DNS64 April 2011
+
+
+5.1. Resolving AAAA Queries and the Answer Section
+
+ When the DNS64 receives a query for RRs of type AAAA and class IN, it
+ first attempts to retrieve non-synthetic RRs of this type and class,
+ either by performing a query or, in the case of an authoritative
+ server, by examining its own results. The query may be answered from
+ a local cache, if one is available. DNS64 operation for classes
+ other than IN is undefined, and a DNS64 MUST behave as though no
+ DNS64 function is configured.
+
+5.1.1. The Answer when There is AAAA Data Available
+
+ If the query results in one or more AAAA records in the answer
+ section, the result is returned to the requesting client as per
+ normal DNS semantics, except in the case where any of the AAAA
+ records match a special exclusion set of prefixes, as considered in
+ Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64
+ SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
+ for an analysis of the motivations for and the implications of not
+ complying with this recommendation). By default, DNS64
+ implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+ exist.
+
+5.1.2. The Answer when There is an Error
+
+ If the query results in a response with an RCODE other than 0 (No
+ error condition), then there are two possibilities. A result with
+ RCODE=3 (Name Error) is handled according to normal DNS operation
+ (which is normally to return the error to the client). This stage is
+ still prior to any synthesis having happened, so a response to be
+ returned to the client does not need any special assembly other than
+ what would usually happen in DNS operation.
+
+ Any other RCODE is treated as though the RCODE were 0 (see
+ Sections 5.1.6 and 5.1.7) and the answer section were empty. This is
+ because of the large number of different responses from deployed name
+ servers when they receive AAAA queries without a AAAA record being
+ available (see [RFC4074]). Note that this means, for practical
+ purposes, that several different classes of error in the DNS are all
+ treated as though a AAAA record is not available for that owner name.
+
+ It is important to note that, as of this writing, some servers
+ respond with RCODE=3 to a AAAA query even if there is an A record
+ available for that owner name. Those servers are in clear violation
+ of the meaning of RCODE 3, and it is expected that they will decline
+ in use as IPv6 deployment increases.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 11]
+\f
+RFC 6147 DNS64 April 2011
+
+
+5.1.3. Dealing with Timeouts
+
+ If the query receives no answer before the timeout (which might be
+ the timeout from every authoritative server, depending on whether the
+ DNS64 is in recursive-resolver mode), it is treated as RCODE=2
+ (Server failure).
+
+5.1.4. Special Exclusion Set for AAAA Records
+
+ Some IPv6 addresses are not actually usable by IPv6-only hosts. If
+ they are returned to IPv6-only querying agents as AAAA records,
+ therefore, the goal of decreasing the number of failure modes will
+ not be attained. Examples include AAAA records with addresses in the
+ ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
+ records with the site's Pref64::/n or the Well-Known Prefix (see
+ below for more about the Well-Known Prefix). A DNS64 implementation
+ SHOULD provide a mechanism to specify IPv6 prefix ranges to be
+ treated as though the AAAA containing them were an empty answer. An
+ implementation SHOULD include the ::ffff/96 network in that range by
+ default. Failure to provide this facility will mean that clients
+ querying the DNS64 function may not be able to communicate with hosts
+ that would be reachable from a dual-stack host.
+
+ When the DNS64 performs its initial AAAA query, if it receives an
+ answer with only AAAA records containing addresses in the excluded
+ range(s), then it MUST treat the answer as though it were an empty
+ answer, and proceed accordingly. If it receives an answer with at
+ least one AAAA record containing an address outside any of the
+ excluded range(s), then it by default SHOULD build an answer section
+ for a response including only the AAAA record(s) that do not contain
+ any of the addresses inside the excluded ranges. That answer section
+ is used in the assembly of a response as detailed in Section 5.4.
+ Alternatively, it MAY treat the answer as though it were an empty
+ answer, and proceed accordingly. It MUST NOT return the offending
+ AAAA records as part of a response.
+
+5.1.5. Dealing with CNAME and DNAME
+
+ If the response contains a CNAME or a DNAME, then the CNAME or DNAME
+ chain is followed until the first terminating A or AAAA record is
+ reached. This may require the DNS64 to ask for an A record, in case
+ the response to the original AAAA query is a CNAME or DNAME without a
+ AAAA record to follow. The resulting AAAA or A record is treated
+ like any other AAAA or A case, as appropriate.
+
+ When assembling the answer section, any chains of CNAME or DNAME RRs
+ are included as part of the answer along with the synthetic AAAA (if
+ appropriate).
+
+
+
+Bagnulo, et al. Standards Track [Page 12]
+\f
+RFC 6147 DNS64 April 2011
+
+
+5.1.6. Data for the Answer when Performing Synthesis
+
+ If the query results in no error but an empty answer section in the
+ response, the DNS64 attempts to retrieve A records for the name in
+ question, either by performing another query or, in the case of an
+ authoritative server, by examining its own results. If this new A RR
+ query results in an empty answer or in an error, then the empty
+ result or error is used as the basis for the answer returned to the
+ querying client. If instead the query results in one or more A RRs,
+ the DNS64 synthesizes AAAA RRs based on the A RRs according to the
+ procedure outlined in Section 5.1.7. The DNS64 returns the
+ synthesized AAAA records in the answer section, removing the A
+ records that form the basis of the synthesis.
+
+5.1.7. Performing the Synthesis
+
+ A synthetic AAAA record is created from an A record as follows:
+
+ o The NAME field is set to the NAME field from the A record.
+
+ o The TYPE field is set to 28 (AAAA).
+
+ o The CLASS field is set to the original CLASS field, 1. Under this
+ specification, DNS64 for any CLASS other than 1 is undefined.
+
+ o The Time to Live (TTL) field is set to the minimum of the TTL of
+ the original A RR and the SOA RR for the queried domain. (Note
+ that in order to obtain the TTL of the SOA RR, the DNS64 does not
+ need to perform a new query, but it can remember the TTL from the
+ SOA RR in the negative response to the AAAA query. If the SOA RR
+ was not delivered with the negative response to the AAAA query,
+ then the DNS64 SHOULD use the TTL of the original A RR or
+ 600 seconds, whichever is shorter. It is possible instead to
+ query explicitly for the SOA RR and use the result of that query,
+ but this will increase query load and time to resolution for
+ little additional benefit.) This is in keeping with the approach
+ used in negative caching [RFC2308].
+
+ o The RDLENGTH field is set to 16.
+
+ o The RDATA field is set to the IPv6 representation of the IPv4
+ address from the RDATA field of the A record. The DNS64 MUST
+ check each A RR against configured IPv4 address ranges and select
+ the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
+ See Section 5.2 for discussion of the algorithms to be used in
+ effecting the transformation.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 13]
+\f
+RFC 6147 DNS64 April 2011
+
+
+5.1.8. Querying in Parallel
+
+ The DNS64 MAY perform the query for the AAAA RR and for the A RR in
+ parallel, in order to minimize the delay.
+
+ NOTE: Querying in parallel will result in performing unnecessary A
+ RR queries in the case where no AAAA RR synthesis is required. A
+ possible trade-off would be to perform them sequentially but with
+ a very short interval between them, so if we obtain a fast reply,
+ we avoid doing the additional query. (Note that this discussion
+ is relevant only if the DNS64 function needs to perform external
+ queries to fetch the RR. If the needed RR information is
+ available locally, as in the case of an authoritative server, the
+ issue is no longer relevant.)
+
+5.2. Generation of the IPv6 Representations of IPv4 Addresses
+
+ DNS64 supports multiple algorithms for the generation of the IPv6
+ representation of an IPv4 address. The constraints imposed on the
+ generation algorithms are the following:
+
+ o The same algorithm to create an IPv6 address from an IPv4 address
+ MUST be used by both a DNS64 to create the IPv6 address to be
+ returned in the synthetic AAAA RR from the IPv4 address contained
+ in an original A RR, and by an IPv6/IPv4 translator to create the
+ IPv6 address to be included in the source address field of the
+ outgoing IPv6 packets from the IPv4 address included in the source
+ address field of the incoming IPv4 packet.
+
+ o The algorithm MUST be reversible; i.e., it MUST be possible to
+ derive the original IPv4 address from the IPv6 representation.
+
+ o The input for the algorithm MUST be limited to the IPv4 address;
+ the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+ representations; and, optionally, a set of stable parameters that
+ are configured in the DNS64 and in the NAT64 (such as a fixed
+ string to be used as a suffix).
+
+ * For each prefix Pref64::/n, n MUST be less than or equal to 96.
+ If one or more Pref64::/n are configured in the DNS64 through
+ any means (such as manual configuration, or other automatic
+ means not specified in this document), the default algorithm
+ MUST use these prefixes (and not use the Well-Known Prefix).
+ If no prefix is available, the algorithm MUST use the
+ Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to
+ represent the IPv4 unicast address range.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 14]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ A DNS64 MUST support the algorithm for generating IPv6
+ representations of IPv4 addresses defined in Section 2 of [RFC6052].
+ Moreover, the aforementioned algorithm MUST be the default algorithm
+ used by the DNS64. While the normative description of the algorithm
+ is provided in [RFC6052], a sample description of the algorithm and
+ its application to different scenarios are provided in Section 7 for
+ illustration purposes.
+
+5.3. Handling Other Resource Records and the Additional Section
+
+5.3.1. PTR Resource Record
+
+ If a DNS64 server receives a PTR query for a record in the IP6.ARPA
+ domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
+ address portion of the QNAME according to the encoding scheme
+ outlined in Section 2.5 of [RFC3596], and examine the resulting
+ address to see whether its prefix matches any of the locally
+ configured Pref64::/n or the default Well-Known Prefix. There are
+ two alternatives for a DNS64 server to respond to such PTR queries.
+ A DNS64 server MUST provide one of these, and SHOULD NOT provide both
+ at the same time unless different IP6.ARPA zones require answers of
+ different sorts:
+
+ 1. The first option is for the DNS64 server to respond
+ authoritatively for its prefixes. If the address prefix matches
+ any Pref64::/n used in the site, either a NSP or the Well-Known
+ Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the
+ query using locally appropriate RDATA. The DNS64 server MAY use
+ the same RDATA for all answers. Note that the requirement is to
+ match any Pref64::/n used at the site, and not merely the locally
+ configured Pref64::/n. This is because end clients could ask for
+ a PTR record matching an address received through a different
+ (site-provided) DNS64, and if this strategy is in effect, those
+ queries should never be sent to the global DNS. The advantage of
+ this strategy is that it makes plain to the querying client that
+ the prefix is one operated by the (DNS64) site, and that the
+ answers the client is getting are generated by DNS64. The
+ disadvantage is that any useful reverse-tree information that
+ might be in the global DNS is unavailable to the clients querying
+ the DNS64.
+
+ 2. The second option is for the DNS64 name server to synthesize a
+ CNAME mapping the IP6.ARPA namespace to the corresponding
+ IN-ADDR.ARPA name. In this case, the DNS64 name server SHOULD
+ ensure that there is RDATA at the PTR of the corresponding
+ IN-ADDR.ARPA name, and that there is not an existing CNAME at
+ that name. This is in order to avoid synthesizing a CNAME that
+ makes a CNAME chain longer or that does not actually point to
+
+
+
+Bagnulo, et al. Standards Track [Page 15]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ anything. The rest of the response would be the normal DNS
+ processing. The CNAME can be signed on the fly if need be. The
+ advantage of this approach is that any useful information in the
+ reverse tree is available to the querying client. The
+ disadvantages are that it adds additional load to the DNS64
+ (because CNAMEs have to be synthesized for each PTR query that
+ matches the Pref64::/n), and that it may require signing on
+ the fly.
+
+ If the address prefix does not match any Pref64::/n, then the DNS64
+ server MUST process the query as though it were any other query;
+ i.e., a recursive name server MUST attempt to resolve the query as
+ though it were any other (non-A/AAAA) query, and an authoritative
+ server MUST respond authoritatively or with a referral, as
+ appropriate.
+
+5.3.2. Handling the Additional Section
+
+ DNS64 synthesis MUST NOT be performed on any records in the
+ additional section of synthesized answers. The DNS64 MUST pass the
+ additional section unchanged.
+
+ NOTE: It may appear that adding synthetic records to the
+ additional section is desirable, because clients sometimes use the
+ data in the additional section to proceed without having to
+ re-query. There is in general no promise, however, that the
+ additional section will contain all the relevant records, so any
+ client that depends on the additional section being able to
+ satisfy its needs (i.e., without additional queries) is
+ necessarily broken. An IPv6-only client that needs a AAAA record,
+ therefore, will send a query for the necessary AAAA record if it
+ is unable to find such a record in the additional section of an
+ answer it is consuming. For a correctly functioning client, the
+ effect would be no different if the additional section were empty.
+ The alternative of removing the A records in the additional
+ section and replacing them with synthetic AAAA records may cause a
+ host behind a NAT64 to query directly a name server that is
+ unaware of the NAT64 in question. The result in this case will be
+ resolution failure anyway, but later in the resolution operation.
+ The prohibition on synthetic data in the additional section
+ reduces, but does not eliminate, the possibility of resolution
+ failures due to cached DNS data from behind the DNS64. See
+ Section 6.
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 16]
+\f
+RFC 6147 DNS64 April 2011
+
+
+5.3.3. Other Resource Records
+
+ If the DNS64 is in recursive-resolver mode, then considerations
+ outlined in [DEFAULT-LOCAL-ZONES] may be relevant.
+
+ All other RRs MUST be returned unchanged. This includes responses to
+ queries for A RRs.
+
+5.4. Assembling a Synthesized Response to a AAAA Query
+
+ A DNS64 uses different pieces of data to build the response returned
+ to the querying client.
+
+ The query that is used as the basis for synthesis results either in
+ an error, an answer that can be used as a basis for synthesis, or an
+ empty (authoritative) answer. If there is an empty answer, then the
+ DNS64 responds to the original querying client with the answer the
+ DNS64 received to the original (initiator's) query. Otherwise, the
+ response is assembled as follows.
+
+ The header fields are set according to the usual rules for recursive
+ or authoritative servers, depending on the role that the DNS64 is
+ serving. The question section is copied from the original
+ (initiator's) query. The answer section is populated according to
+ the rules in Section 5.1.7. The authority and additional sections
+ are copied from the response to the final query that the DNS64
+ performed, and used as the basis for synthesis.
+
+ The final response from the DNS64 is subject to all the standard DNS
+ rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
+
+5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode
+
+ We consider the case where a recursive resolver that is performing
+ DNS64 also has a local policy to validate the answers according to
+ the procedures outlined in [RFC4035], Section 5. We call this
+ general case vDNS64.
+
+ The vDNS64 uses the presence of the DO and CD bits to make some
+ decisions about what the query originator needs, and can react
+ accordingly:
+
+ 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
+ validation and do synthesis as needed. See the next item for
+ rules about how to do validation and synthesis. In this case,
+ however, vDNS64 MUST NOT set the AD bit in any response.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 17]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
+ validation. Whenever vDNS64 performs validation, it MUST
+ validate the negative answer for AAAA queries before proceeding
+ to query for A records for the same name, in order to be sure
+ that there is not a legitimate AAAA record on the Internet.
+ Failing to observe this step would allow an attacker to use DNS64
+ as a mechanism to circumvent DNSSEC. If the negative response
+ validates, and the response to the A query validates, then the
+ vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+ answer to the client. This is acceptable, because [RFC4035],
+ Section 3.2.3 says that the AD bit is set by the name server side
+ of a security-aware recursive name server if and only if it
+ considers all the RRSets in the answer and authority sections to
+ be authentic. In this case, the name server has reason to
+ believe the RRSets are all authentic, so it SHOULD set the AD
+ bit. If the data does not validate, the vDNS64 MUST respond with
+ RCODE=2 (Server failure).
+
+ A security-aware end point might take the presence of the AD bit
+ as an indication that the data is valid, and may pass the DNS
+ (and DNSSEC) data to an application. If the application attempts
+ to validate the synthesized data, of course, the validation will
+ fail. One could argue therefore that this approach is not
+ desirable, but security-aware stub resolvers must not place any
+ reliance on data received from resolvers and validated on their
+ behalf without certain criteria established by [RFC4035],
+ Section 4.9.3. An application that wants to perform validation
+ on its own should use the CD bit.
+
+ 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
+ validation, but MUST NOT perform synthesis. It MUST return the
+ data to the query initiator, just like a regular recursive
+ resolver, and depend on the client to do the validation and the
+ synthesis itself.
+
+ The disadvantage to this approach is that an end point that is
+ translation-oblivious but security-aware and validating will not
+ be able to use the DNS64 functionality. In this case, the end
+ point will not have the desired benefit of NAT64. In effect,
+ this strategy means that any end point that wishes to do
+ validation in a NAT64 context must be upgraded to be
+ translation-aware as well.
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 18]
+\f
+RFC 6147 DNS64 April 2011
+
+
+6. Deployment Notes
+
+ While DNS64 is intended to be part of a strategy for aiding IPv6
+ deployment in an internetworking environment with some IPv4-only and
+ IPv6-only networks, it is important to realize that it is
+ incompatible with some things that may be deployed in an IPv4-only or
+ dual-stack context.
+
+6.1. DNS Resolvers and DNS64
+
+ Full-service resolvers that are unaware of the DNS64 function can be
+ (mis)configured to act as mixed-mode iterative and forwarding
+ resolvers. In a native IPv4 context, this sort of configuration may
+ appear to work. It is impossible to make it work properly without it
+ being aware of the DNS64 function, because it will likely at some
+ point obtain IPv4-only glue records and attempt to use them for
+ resolution. The result that is returned will contain only A records,
+ and without the ability to perform the DNS64 function the resolver
+ will be unable to answer the necessary AAAA queries.
+
+6.2. DNSSEC Validators and DNS64
+
+ An existing DNSSEC validator (i.e., one that is unaware of DNS64)
+ might reject all the data that comes from DNS64 as having been
+ tampered with (even if it did not set CD when querying). If it is
+ necessary to have validation behind the DNS64, then the validator
+ must know how to perform the DNS64 function itself. Alternatively,
+ the validating host may establish a trusted connection with a DNS64,
+ and allow the DNS64 recursive resolver to do all validation on its
+ behalf.
+
+6.3. DNS64 and Multihomed and Dual-Stack Hosts
+
+6.3.1. IPv6 Multihomed Hosts
+
+ Synthetic AAAA records may be constructed on the basis of the network
+ context in which they were constructed. If a host sends DNS queries
+ to resolvers in multiple networks, it is possible that some of them
+ will receive answers from a DNS64 without all of them being connected
+ via a NAT64. For instance, suppose a system has two interfaces, i1
+ and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2
+ has native IPv6 connectivity only. I1 might receive a AAAA answer
+ from a DNS64 that is configured for a particular NAT64; the IPv6
+ address contained in that AAAA answer will not connect with anything
+ via i2.
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 19]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | | +-------------+
+ | i2 (IPv6)+-----------------+IPv6 Internet|
+ +---------------+ +-------------+
+
+ Figure 1: IPv6 Multihomed Hosts
+
+ This example illustrates why it is generally preferable that hosts
+ treat DNS answers from one interface as local to that interface. The
+ answer received on one interface will not work on the other
+ interface. Hosts that attempt to use DNS answers globally may
+ encounter surprising failures in these cases.
+
+ Note that the issue is not that there are two interfaces, but that
+ there are two networks involved. The same results could be achieved
+ with a single interface routed to two different networks.
+
+6.3.2. Accidental Dual-Stack DNS64 Use
+
+ Similarly, suppose that i1 has IPv6 connectivity and can connect to
+ the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
+ In this case, i1 could receive an IPv6 address from a synthetic AAAA
+ that would better be reached via native IPv4. Again, it is worth
+ emphasizing that this arises because there are two networks involved.
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | | +-------------+
+ | i2 (IPv4)+-----------------+IPv4 Internet|
+ +---------------+ +-------------+
+
+ Figure 2: Accidental Dual-Stack DNS64 Use
+
+ The default configuration of dual-stack hosts is that IPv6 is
+ preferred over IPv4 ([RFC3484]). In that arrangement, the host will
+ often use the NAT64 when native IPv4 would be more desirable. For
+ this reason, hosts with IPv4 connectivity to the Internet should
+ avoid using DNS64. This can be partly resolved by ISPs when
+ providing DNS resolvers to clients, but that is not a guarantee that
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 20]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ the NAT64 will never be used when a native IPv4 connection should be
+ used. There is no general-purpose mechanism to ensure that native
+ IPv4 transit will always be preferred, because to a DNS64-oblivious
+ host, the DNS64 looks just like an ordinary DNS server. Operators of
+ a NAT64 should expect traffic to pass through the NAT64 even when it
+ is not necessary.
+
+6.3.3. Intentional Dual-Stack DNS64 Use
+
+ Finally, consider the case where the IPv4 connectivity on i2 is only
+ with a LAN, and not with the IPv4 Internet. The IPv4 Internet is
+ only accessible using the NAT64. In this case, it is critical that
+ the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
+ that the DNS64 be aware of hosts in the LAN and provide context-
+ sensitive answers ("split view" DNS answers) for hosts inside the
+ LAN. As with any split view DNS arrangement, operators must be
+ prepared for data to leak from one context to another, and for
+ failures to occur because nodes accessible from one context are not
+ accessible from the other.
+
+ +---------------+ +-------------+
+ | i1 (IPv6)+----NAT64--------+IPv4 Internet|
+ | | +-------------+
+ | host |
+ | |
+ | i2 (IPv4)+---(local LAN only)
+ +---------------+
+
+ Figure 3: Intentional Dual-Stack DNS64 Use
+
+ It is important for deployers of DNS64 to realize that, in some
+ circumstances, making the DNS64 available to a dual-stack host will
+ cause the host to prefer to send packets via NAT64 instead of via
+ native IPv4, with the associated loss of performance or functionality
+ (or both) entailed by the NAT. At the same time, some hosts are not
+ able to learn about DNS servers provisioned on IPv6 addresses, or
+ simply cannot send DNS packets over IPv6.
+
+7. Deployment Scenarios and Examples
+
+ In this section, we illustrate how the DNS64 behaves in different
+ scenarios that are expected to be common. In particular, we will
+ consider the following scenarios defined in [RFC6144]: the "an IPv6
+ network to the IPv4 Internet" scenario (both with DNS64 in DNS server
+ mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4
+ network" setup (with DNS64 in DNS server mode only).
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 21]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ In all the examples below, there is an IPv6/IPv4 translator
+ connecting the IPv6 domain to the IPv4 one. Also, there is a name
+ server that is a dual-stack node, so it can communicate with IPv6
+ hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we
+ assume that in the examples, the DNS64 function learns which IPv6
+ prefix it needs to use to map the IPv4 address space through manual
+ configuration.
+
+7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64
+ in DNS Server Mode
+
+ In this example, we consider an IPv6 node located in an IPv6-only
+ site that initiates a communication to an IPv4 node located in the
+ IPv4 Internet.
+
+ The scenario for this case is depicted in the following figure:
+
+ +---------------------+ +---------------+
+ |IPv6 network | | IPv4 |
+ | | +-------------+ | Internet |
+ | |--| Name server |--| |
+ | | | with DNS64 | | +----+ |
+ | +----+ | +-------------+ | | H2 | |
+ | | H1 |---| | | +----+ |
+ | +----+ | +------------+ | 192.0.2.1 |
+ | |---| IPv6/IPv4 |--| |
+ | | | Translator | | |
+ | | +------------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+ Figure 4: "An IPv6 Network to the IPv4 Internet" Setup
+ with DNS64 in DNS Server Mode
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+ address 192.0.2.1 and FQDN h2.example.com.
+
+ The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+ to its IPv4 interface, and it is using the Well-Known Prefix
+ 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The
+ same prefix is configured in the DNS64 function in the local name
+ server.
+
+ For this example, assume the typical DNS situation where IPv6 hosts
+ have only stub resolvers, and they are configured with the IP address
+ of a name server that they always have to query and that performs
+ recursive lookups (henceforth called "the recursive name server").
+
+
+
+
+Bagnulo, et al. Standards Track [Page 22]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
+ a DNS query for a AAAA record for H2 to the recursive name
+ server. The recursive name server implements DNS64
+ functionality.
+
+ 2. The recursive name server resolves the query, and discovers that
+ there are no AAAA records for H2.
+
+ 3. The recursive name server performs an A-record query for H2 and
+ gets back an RRSet containing a single A record with the IPv4
+ address 192.0.2.1. The name server then synthesizes a AAAA
+ record. The IPv6 address in the AAAA record contains the prefix
+ assigned to the IPv6/IPv4 translator in the upper 96 bits and the
+ received IPv4 address in the lower 32 bits; i.e., the resulting
+ IPv6 address is 64:ff9b::192.0.2.1.
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent to the destination address 64:ff9b::
+ 192.0.2.1.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ translator, and the subsequent communication flows by means of
+ the IPv6/IPv4 translator mechanisms.
+
+7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64
+ in Stub-Resolver Mode
+
+ This case is depicted in the following figure:
+
+ +---------------------+ +---------------+
+ |IPv6 network | | IPv4 |
+ | | +--------+ | Internet |
+ | |-----| Name |----| |
+ | +-----+ | | server | | +----+ |
+ | | H1 | | +--------+ | | H2 | |
+ | |with |---| | | +----+ |
+ | |DNS64| | +------------+ | 192.0.2.1 |
+ | +----+ |---| IPv6/IPv4 |--| |
+ | | | Translator | | |
+ | | +------------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+ Figure 5: "An IPv6 Network to the IPv4 Internet" Setup
+ with DNS64 in Stub-Resolver Mode
+
+
+
+
+Bagnulo, et al. Standards Track [Page 23]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ The figure shows an IPv6 node H1 implementing the DNS64 function and
+ an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN
+ h2.example.com.
+
+ The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned
+ to its IPv4 interface, and it is using the Well-Known Prefix
+ 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The
+ same prefix is configured in the DNS64 function in H1.
+
+ For this example, assume the typical DNS situation where IPv6 hosts
+ have only stub resolvers, and they are configured with the IP address
+ of a name server that they always have to query and that performs
+ recursive lookups (henceforth called "the recursive name server").
+ The recursive name server does not perform the DNS64 function.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
+ a DNS query for a AAAA record for H2 to the recursive name
+ server.
+
+ 2. The recursive DNS server resolves the query, and returns the
+ answer to H1. Because there are no AAAA records in the global
+ DNS for H2, the answer is empty.
+
+ 3. The stub resolver at H1 then queries for an A record for H2 and
+ gets back an A record containing the IPv4 address 192.0.2.1. The
+ DNS64 function within H1 then synthesizes a AAAA record. The
+ IPv6 address in the AAAA record contains the prefix assigned to
+ the IPv6/IPv4 translator in the upper 96 bits, then the received
+ IPv4 address in the lower 32 bits; the resulting IPv6 address is
+ 64:ff9b::192.0.2.1.
+
+ 4. H1 sends a packet towards H2. The packet is sent to the
+ destination address 64:ff9b::192.0.2.1.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ translator and the subsequent communication flows using the IPv6/
+ IPv4 translator mechanisms.
+
+7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64
+ in DNS Server Mode
+
+ In this example, we consider an IPv6 node located in the IPv6
+ Internet that initiates a communication to an IPv4 node located in
+ the IPv4 site.
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 24]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ In some cases, this scenario can be addressed without using any form
+ of DNS64 function. This is because it is possible to assign a fixed
+ IPv6 address to each of the IPv4 nodes. Such an IPv6 address would
+ be constructed using the address transformation algorithm defined in
+ [RFC6052] that takes as input the Pref64::/96 and the IPv4 address of
+ the IPv4 node. Note that the IPv4 address can be a public or a
+ private address; the latter does not present any additional
+ difficulty, since an NSP must be used as Pref64::/96 (in this
+ scenario, the usage of the Well-Known Prefix is not supported as
+ discussed in [RFC6052]). Once these IPv6 addresses have been
+ assigned to represent the IPv4 nodes in the IPv6 Internet, real AAAA
+ RRs containing these addresses can be published in the DNS under the
+ site's domain. This is the recommended approach to handle this
+ scenario, because it does not involve synthesizing AAAA records at
+ the time of query.
+
+ However, there are some more dynamic scenarios, where synthesizing
+ AAAA RRs in this setup may be needed. In particular, when DNS Update
+ [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+ nodes, there are two options. One option is to modify the DNS server
+ that receives the dynamic DNS updates. That would normally be the
+ authoritative server for the zone. So the authoritative zone would
+ have normal AAAA RRs that are synthesized as dynamic updates occur.
+ The other option is to modify all of the authoritative servers to
+ generate synthetic AAAA records for a zone, possibly based on
+ additional constraints, upon the receipt of a DNS query for the AAAA
+ RR. The first option -- in which the AAAA is synthesized when the
+ DNS update message is received, and the data published in the
+ relevant zone -- is recommended over the second option (i.e., the
+ synthesis upon receipt of the AAAA DNS query). This is because it is
+ usually easier to solve problems of misconfiguration when the DNS
+ responses are not being generated dynamically. However, it may be
+ the case where the primary server (that receives all the updates)
+ cannot be upgraded for whatever reason, but where a secondary can be
+ upgraded in order to handle the (comparatively small amount of) AAAA
+ queries. In such a case, it is possible to use the DNS64 as
+ described next. The DNS64 behavior that we describe in this section
+ covers the case of synthesizing the AAAA RR when the DNS query
+ arrives.
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 25]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ The scenario for this case is depicted in the following figure:
+
+ +-----------+ +----------------------+
+ | | | IPv4 site |
+ | IPv6 | +------------+ | +----+ |
+ | Internet |----| IPv6/IPv4 |--|---| H2 | |
+ | | | Translator | | +----+ |
+ | | +------------+ | |
+ | | | | 192.0.2.1 |
+ | | +------------+ | |
+ | |----| Name server|--| |
+ | | | with DNS64 | | |
+ +-----------+ +------------+ | |
+ | | | |
+ +----+ | |
+ | H1 | +----------------------+
+ +----+
+
+ Figure 6: "The IPv6 Internet to an IPv4 Network" Setup
+ with DNS64 in DNS Server Mode
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4
+ address 192.0.2.1 and FQDN h2.example.com.
+
+ The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6
+ representations of IPv4 addresses. The same prefix is configured in
+ the DNS64 function in the local name server. The name server that
+ implements the DNS64 function is the authoritative name server for
+ the local domain.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
+ a DNS query for a AAAA record for H2. The query is eventually
+ forwarded to the server in the IPv4 site.
+
+ 2. The local DNS server resolves the query (locally), and discovers
+ that there are no AAAA records for H2.
+
+ 3. The name server verifies that h2.example.com and its A RR are
+ among those that the local policy defines as allowed to generate
+ a AAAA RR. If that is the case, the name server synthesizes a
+ AAAA record from the A RR and the prefix 2001:db8::/96. The IPv6
+ address in the AAAA record is 2001:db8::192.0.2.1.
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent to the destination address 2001:db8::
+ 192.0.2.1.
+
+
+
+Bagnulo, et al. Standards Track [Page 26]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ 5. The packet is routed through the IPv6 Internet to the IPv6
+ interface of the IPv6/IPv4 translator and the communication flows
+ using the IPv6/IPv4 translator mechanisms.
+
+8. Security Considerations
+
+ DNS64 operates in combination with the DNS, and is therefore subject
+ to whatever security considerations are appropriate to the DNS mode
+ in which the DNS64 is operating (i.e., authoritative, recursive, or
+ stub-resolver mode).
+
+ DNS64 has the potential to interfere with the functioning of DNSSEC,
+ because DNS64 modifies DNS answers, and DNSSEC is designed to detect
+ such modifications and to treat modified answers as bogus. See the
+ discussion above in Sections 3, 5.5, and 6.2.
+
+ Additionally, for the correct functioning of the translation
+ services, the DNS64 and the NAT64 need to use the same Pref64. If an
+ attacker manages to change the Pref64 used by the DNS64, the traffic
+ generated by the host that receives the synthetic reply will be
+ delivered to the altered Pref64. This can result in either a denial-
+ of-service (DoS) attack (if the resulting IPv6 addresses are not
+ assigned to any device), a flooding attack (if the resulting IPv6
+ addresses are assigned to devices that do not wish to receive the
+ traffic), or an eavesdropping attack (in case the Pref64 is routed
+ through the attacker).
+
+9. Contributors
+
+ Dave Thaler
+ Microsoft
+ dthaler@windows.microsoft.com
+
+10. Acknowledgements
+
+ This document contains the result of discussions involving many
+ people, including the participants of the IETF BEHAVE Working Group.
+ The following IETF participants made specific contributions to parts
+ of the text, and their help is gratefully acknowledged: Jaap
+ Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin,
+ Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian
+ Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom,
+ David Harrington, Ed Jankiewicz, Peter Koch, Suresh Krishnan, Martti
+ Kuparinen, Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi
+ Miyata, Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler,
+ Mark Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff
+ Westhead, Florian Weimer, Dan Wing, Xu Xiaohu, and Xiangsong Cui.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 27]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+ Trilogy, a research project supported by the European Commission
+ under its Seventh Framework Program.
+
+11. References
+
+11.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.
+
+ [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.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ October 2010.
+
+11.2. Informative References
+
+ [DEFAULT-LOCAL-ZONES]
+ Andrews, M., "Locally-served DNS Zones", Work in Progress,
+ March 2011.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "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.
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+
+
+
+Bagnulo, et al. Standards Track [Page 28]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+ DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, April 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 29]
+\f
+RFC 6147 DNS64 April 2011
+
+
+Appendix A. Motivations and Implications of Synthesizing AAAA Resource
+ Records when Real AAAA Resource Records Exist
+
+ The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
+ to support the following scenario:
+
+ o An IPv4-only server application (e.g., web server software) is
+ running on a dual-stack host. There may also be dual-stack server
+ applications running on the same host. That host has fully
+ routable IPv4 and IPv6 addresses, and hence the authoritative DNS
+ server has an A record and a AAAA record.
+
+ o An IPv6-only client (regardless of whether the client application
+ is IPv6-only, the client stack is IPv6-only, or it only has an
+ IPv6 address) wants to access the above server.
+
+ o The client issues a DNS query to a DNS64 resolver.
+
+ If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+ then the communication will fail. Even though there's a real AAAA,
+ the only way for communication to succeed is with the translated
+ address. So, in order to support this scenario, the administrator of
+ a DNS64 service may want to enable the synthesis of AAAA RRs even
+ when real AAAA RRs exist.
+
+ The implication of including synthetic AAAA RRs when real AAAA RRs
+ exist is that translated connectivity may be preferred over native
+ connectivity in some cases where the DNS64 is operated in DNS server
+ mode.
+
+ RFC 3484 [RFC3484] rules use "longest matching prefix" to select the
+ preferred destination address to use. So, if the DNS64 resolver
+ returns both the synthetic AAAA RRs and the real AAAA RRs, then if
+ the DNS64 is operated by the same domain as the initiating host, and
+ a global unicast prefix (referred to as a Network-Specific Prefix
+ (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be
+ preferred.
+
+ This means that without further configuration:
+
+ o In the "an IPv6 network to the IPv4 Internet" scenario, the host
+ will prefer translated connectivity if an NSP is used. If the
+ Well-Known Prefix defined in [RFC6052] is used, it will probably
+ prefer native connectivity.
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 30]
+\f
+RFC 6147 DNS64 April 2011
+
+
+ o In the "IPv6 Internet to an IPv4 network" scenario, it is possible
+ to bias the selection towards the real AAAA RR if the DNS64
+ resolver returns the real AAAA first in the DNS reply, when an NSP
+ is used (the Well-Known Prefix usage is not supported in this
+ case).
+
+ o In the "an IPv6 network to an IPv4 network" scenario, for local
+ destinations (i.e., target hosts inside the local site), it is
+ likely that the NSP and the destination prefix are the same, so we
+ can use the order of RR in the DNS reply to bias the selection
+ through native connectivity. If the Well-Known Prefix is used,
+ the "longest matching prefix" rule will select native
+ connectivity.
+
+ The problem can be solved by properly configuring the RFC 3484
+ [RFC3484] policy table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 31]
+\f
+RFC 6147 DNS64 April 2011
+
+
+Authors' Addresses
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6249500
+ EMail: marcelo@it.uc3m.es
+ URI: http://www.it.uc3m.es/marcelo
+
+
+ Andrew Sullivan
+ Shinkuro
+ 4922 Fairmont Avenue, Suite 250
+ Bethesda, MD 20814
+ USA
+
+ Phone: +1 301 961 3131
+ EMail: ajs@shinkuro.com
+
+
+ Philip Matthews
+ Unaffiliated
+ 600 March Road
+ Ottawa, Ontario
+ Canada
+
+ Phone: +1 613-592-4343 x224
+ EMail: philip_matthews@magma.ca
+
+
+ Iljitsch van Beijnum
+ IMDEA Networks
+ Avda. del Mar Mediterraneo, 22
+ Leganes, Madrid 28918
+ Spain
+
+ Phone: +34-91-6246245
+ EMail: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Standards Track [Page 32]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) W. Hardaker
+Request for Comments: 6168 Sparta, Inc.
+Category: Informational May 2011
+ISSN: 2070-1721
+
+
+ Requirements for Management of Name Servers for the DNS
+
+Abstract
+
+ Management of name servers for the Domain Name System (DNS) has
+ traditionally been done using vendor-specific monitoring,
+ configuration, and control methods. Although some service monitoring
+ platforms can test the functionality of the DNS itself, there is not
+ an interoperable way to manage (monitor, control, and configure) the
+ internal aspects of a name server itself.
+
+ This document discusses the requirements of a management system for
+ name servers and can be used as a shopping list of needed features
+ for such a system.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6168.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Informational [Page 1]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Informational [Page 2]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
+ 2. Management Architecture Requirements . . . . . . . . . . . . . 5
+ 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
+ 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
+ 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
+ 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
+ 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
+ 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
+ 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
+ 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
+ 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
+ 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
+ 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
+ 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
+ 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
+ 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
+ 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
+ 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
+ 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
+ 3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
+ 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
+ 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
+ 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
+ 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
+ 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
+ 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
+ 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
+ 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
+ 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
+ Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
+ A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
+ A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
+ A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Hardaker Informational [Page 3]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+1. Introduction
+
+ Management of name servers for the Domain Name System (DNS) [RFC1034]
+ [RFC1035] has traditionally been done using vendor-specific
+ monitoring, configuration, and control methods. Although some
+ service monitoring platforms can test the functionality of the DNS
+ itself, there is not an interoperable way to manage (monitor,
+ control, and configure) the internal aspects of a name server itself.
+
+ Previous standardization work within the IETF resulted in the
+ creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed
+ to achieve significant implementation and deployment. The perceived
+ reasons behind the failure for the two MIB modules are documented in
+ [RFC3197].
+
+ This document discusses the requirements of a management system for
+ name servers and can be used as a shopping list of needed features
+ for such a system. This document only discusses requirements for
+ managing the name server component of a system -- not other elements
+ of the system itself.
+
+ Specifically out of scope for this document are requirements
+ associated with the management of stub resolvers. It is not the
+ intent of this document to document stub resolver requirements,
+ although some of the requirements listed are applicable to stub
+ resolvers as well.
+
+ The task of creating a management system for managing DNS servers is
+ not expected to be a small one. It is likely that components of the
+ solution will need to be designed in parts over time; these
+ requirements take this into consideration. In particular,
+ Section 5.1 discusses the need for future extensibility of the base
+ management solution. This document is intended to be a roadmap
+ towards a desired outcome and is not intended to define an "all-or-
+ nothing" system. Successful interoperable management of name
+ servers, even in part, is expected to be beneficial to network
+ operators compared to the entirely custom solutions that are used at
+ the time of this writing.
+
+1.1. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Hardaker Informational [Page 4]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+1.2. Terminology
+
+ This document is consistent with the terminology defined in Section 2
+ of [RFC4033]. Additional terminology needed for this document is
+ described below:
+
+ Name Server: When we are discussing servers that don't fall into a
+ more specific type of server category defined in other documents,
+ this document will refer to them generically as "name servers".
+ In particular, "name servers" can be considered to be any valid
+ combination of authoritative, recursive, validating, or security-
+ aware. The more specific name server labels will be used when
+ this document refers only to a specific type of server. However,
+ the term "name server", in this document, will not include stub
+ resolvers.
+
+1.3. Document Layout and Requirements
+
+ This document is written so that each numbered section will contain
+ only a single requirement if it contains one at all. Each
+ requirement will contain needed wording from the terminology
+ described in Section 1.1. Subsections, however, might exist with
+ additional related requirements. The document is laid out in this
+ way so that a specific requirement can be uniquely referred to using
+ the section number itself and the document version from which it
+ came.
+
+2. Management Architecture Requirements
+
+ This section discusses requirements that reflect the needs of the
+ expected deployment environments.
+
+2.1. Expected Deployment Scenarios
+
+ DNS zones vary greatly in the type of content published within them.
+ Name servers, too, are deployed with a wide variety of configurations
+ to support the diversity of the deployed content. It is important
+ that a management solution trying to meet the criteria specified in
+ this document consider supporting the largest number of potential
+ deployment cases as possible. Further deployment scenarios that are
+ not used as direct examples of specific requirements are listed in
+ Appendix A.
+
+
+
+
+
+
+
+
+
+Hardaker Informational [Page 5]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+2.1.1. Zone Size Constraints
+
+ The management solution MUST support both name servers that are
+ serving a small number of potentially very large zones (e.g., Top
+ Level Domains (TLDs)) as well as name servers that are serving a very
+ large number of small zones. Both deployment scenarios are common.
+
+2.1.2. Name Server Discovery
+
+ Large enterprise network deployments may contain multiple name
+ servers operating within the boundaries of the enterprise network.
+ These name servers may each be serving multiple zones both in and out
+ of the parent enterprise's zone. Finding and managing large numbers
+ of name servers would be a useful feature of the resulting management
+ solution. The management solution MAY support the ability to
+ discover previously unknown instances of name servers operating
+ within a deployed network.
+
+2.1.3. Configuration Data Volatility
+
+ Configuration data is defined as data that relates only to the
+ configuration of a server and the zones it serves. It specifically
+ does not include data from the zone contents that is served through
+ DNS itself. The solution MUST support servers that remain statically
+ configured over time as well as servers that have numerous zones
+ being added and removed within an hour. Both deployment scenarios
+ are common.
+
+2.1.4. Protocol Selection
+
+ There are many requirements in this document for many different types
+ of management operations (see Section 3 for further details). It is
+ possible that no one protocol will ideally fill all the needs of the
+ requirements listed in this document, and thus multiple protocols
+ might be needed to produce a completely functional management system.
+ Multiple protocols might be used to create the complete management
+ solution, but the solution SHOULD require only one.
+
+2.1.5. Common Data Model
+
+ Defining a standardized protocol (or set of protocols) to use for
+ managing name servers would be a step forward in achieving an
+ interoperable management solution. However, just defining a protocol
+ to use by itself would not achieve the entire end goal of a complete
+ interoperable management solution. Devices also need to represent
+ their internal management interface using a common management data
+ model. The solution MUST create a common data model that management
+ stations can make use of when sending or collecting data from a
+
+
+
+Hardaker Informational [Page 6]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+ managed device so it can successfully manage equipment from vendors
+ as if they were generic DNS servers. This common data model is
+ needed for the operations discussion in Section 3. Note that this
+ does not preclude the fact that name server vendors might provide
+ additional management infrastructure beyond a base management
+ specification, as discussed further in Section 5.1.
+
+2.1.6. Operational Impact
+
+ It is impossible to add new features to an existing server (such as
+ the inclusion of a management infrastructure) and not impact the
+ existing service and/or server in some fashion. At a minimum, for
+ example, more memory, disk, and/or CPU resources will be required to
+ implement a new management system. However, the impact to the
+ existing DNS service MUST be minimized since the DNS service itself
+ is still the primary service to be offered by the modified name
+ server. The management solution MUST NOT result in an increase of
+ the number of unhandled DNS requests.
+
+2.2. Name Server Types
+
+ There are multiple ways in which name servers can be deployed. Name
+ servers can take on any of the following roles:
+
+ o Master Servers
+
+ o Slave Servers
+
+ o Recursive Servers
+
+ The management solution SHOULD support all of these types of name
+ servers as they are all equally important. Note that "Recursive
+ Servers" can be further broken down by the security sub-roles they
+ might implement, as defined in section 2 of [RFC4033]. These sub-
+ roles are also important to support within any management solution.
+
+ As stated earlier, the management of stub resolvers is considered out
+ of scope for this document.
+
+3. Management Operation Types
+
+ Management operations can traditionally be broken into four
+ categories:
+
+ o Control
+
+ o Configuration
+
+
+
+
+Hardaker Informational [Page 7]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+ o Health and Monitoring
+
+ o Alarms and Events
+
+ This section discusses detailed requirements for each of these four
+ management categories.
+
+3.1. Control Requirements
+
+ The management solution MUST be capable of performing basic service
+ control operations.
+
+3.1.1. Needed Control Operations
+
+ These operations SHOULD include, at a minimum, the following
+ operations:
+
+ o Starting the name server
+
+ o Reloading the service configuration
+
+ o Reloading all of the zone data
+
+ o Reloading individual zone data sets
+
+ o Restarting the name server
+
+ o Stopping the name server
+
+ Note that no restriction is placed on how the management system
+ implements these operations. In particular, at least "starting the
+ name server" will require a minimal management system component to
+ exist independently of the name server itself.
+
+3.1.2. Asynchronous Status Notifications
+
+ Some control operations might take a long time to complete. As an
+ example, some name servers take a long time to perform reloads of
+ large zones. Because of these timing issues, the management solution
+ SHOULD take this into consideration and offer a mechanism to ease the
+ burden associated with awaiting the status of a long-running command.
+ This could, for example, result in the use of asynchronous
+ notifications for returning the status of a long-running task, or it
+ might require the management station to poll for the status of a
+ given task using monitoring commands. These and other potential
+ solutions need to be evaluated carefully to select one that balances
+ the result delivery needs with the perceived implementation costs.
+
+
+
+
+Hardaker Informational [Page 8]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+ Also, see the related discussion in Section 3.4 on notification
+ messages for supporting delivery of alarm and event messages.
+
+3.2. Configuration Requirements
+
+ Many features of name servers need to be configured before the server
+ can be considered functional. The management solution MUST be able
+ to provide name servers with configuration data. The most important
+ data to be configured, for example, is the served zone data itself.
+
+3.2.1. Served Zone Modification
+
+ The ability to add, modify, and delete zones being served by name
+ servers is needed. Although there are already solutions for zone
+ content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
+ full zone transfer (AXFR) [RFC5936], and incremental zone transfer
+ (IXFR) [RFC1995]) that might be used as part of the final management
+ solution, the management system SHOULD still be able to create a new
+ zone (with enough minimal data to allow the other mechanisms to
+ function as well) and to delete a zone. This might be, for example,
+ a management operation that allows for the creation of at least the
+ initial SOA (Start of Authority) record for a new zone, since that is
+ the minimum amount of zone data needed for the other operations to
+ function.
+
+3.2.2. Trust Anchor Management
+
+ The solution SHOULD support the ability to add, modify, and delete
+ trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
+ [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
+ anchors might be configured using the data from the DNSKEY Resource
+ Records (RRs) themselves or by using Delegation Signer (DS)
+ fingerprints.
+
+3.2.3. Security Expectations
+
+ DNSSEC validating resolvers need to make policy decisions about the
+ requests being processed. For example, they need to be configured
+ with a list of zones expected to be secured by DNSSEC. The
+ management solution SHOULD be able to add, modify, and delete
+ attributes of DNSSEC security policies.
+
+3.2.4. TSIG Key Management
+
+ TSIG [RFC2845] allows transaction-level authentication of DNS
+ traffic. The management solution SHOULD be able to add, modify, and
+ delete TSIG keys known to the name server.
+
+
+
+
+Hardaker Informational [Page 9]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+3.2.5. DNS Protocol Authorization Management
+
+ The management solution SHOULD have the ability to add, modify, and
+ delete authorization settings for the DNS protocols itself. Do not
+ confuse this with the ability to manage the authorization associated
+ with the management protocol itself, which is discussed later in
+ Section 4.4. There are a number of authorization settings that are
+ used by a name server. Example authorization settings that the
+ solution might need to cover are:
+
+ o Access to operations on zone data (e.g., DDNS)
+
+ o Access to certain zone data from certain sources (e.g., from
+ particular network subnets)
+
+ o Access to specific DNS protocol services (e.g., recursive service)
+
+ Note: the above list is expected to be used as a collection of
+ examples and is not a complete list of needed authorization
+ protections.
+
+3.3. Monitoring Requirements
+
+ Monitoring is the process of collecting aspects of the internal state
+ of a name server at a given moment in time. The solution MUST be
+ able to monitor the health of a name server to determine its
+ operational status, load, and other internal attributes. Example
+ parameters that the solution might need to collect and analyze are:
+
+ o Number of requests sent, responses sent, number of errors, average
+ response latency, and other performance counters
+
+ o Server status (e.g., "serving data", "starting up", "shutting
+ down", etc.)
+
+ o Access control violations
+
+ o List of zones being served
+
+ o Detailed statistics about clients interacting with the name server
+ (e.g., top 10 clients requesting data).
+
+ Note: the above list is expected to be used as a collection of
+ examples and is not a complete list of needed monitoring operations.
+ In particular, some monitoring statistics are expected to be
+ computationally or resource expensive and are considered to be "nice
+ to have" as opposed to "necessary to have".
+
+
+
+
+Hardaker Informational [Page 10]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+3.4. Alarm and Event Requirements
+
+ Events occurring at the name server that trigger alarm notifications
+ can quickly inform a management station about critical issues. A
+ management solution SHOULD include support for delivery of alarm
+ conditions.
+
+ Example alarm conditions might include:
+
+ o The server's status is changing (e.g., it is starting up,
+ reloading configuration, restarting or shutting down).
+
+ o A needed resource (e.g., memory or disk space) is exhausted or
+ nearing exhaustion.
+
+ o An authorization violation was detected.
+
+ o The server has not received any data traffic (e.g., DNS requests
+ or NOTIFYs) recently (aka the "lonely warning"). This condition
+ might indicate a problem with the server's deployment.
+
+ o The number of errors has exceeded a configured threshold.
+
+4. Security Requirements
+
+ The management solution will need to be appropriately secured against
+ attacks on the management infrastructure.
+
+4.1. Authentication
+
+ The solution MUST support mutual authentication. The management
+ client needs to be assured that the management operations are being
+ transferred to and from the correct name server. The managed name
+ server needs to authenticate the system that is accessing the
+ management infrastructure within itself.
+
+4.2. Integrity Protection
+
+ Management operations MUST be protected from modification while in
+ transit from the management client to the server.
+
+4.3. Confidentiality
+
+ The management solution MUST support message confidentiality. The
+ potential transfer of sensitive configuration is expected (such as
+ TSIG keys or security policies). The solution does not, however,
+ necessarily need to provide confidentiality to data that would
+ normally be carried without confidentiality by the DNS system itself.
+
+
+
+Hardaker Informational [Page 11]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+4.4. Authorization
+
+ The solution SHOULD provide an authorization model capable of
+ selectively authorizing individual management requests for any
+ management protocols it introduces to the completed system. This
+ authorization differs from the authorization previously discussed in
+ Section 3.2.5 in that this requirement is concerned solely with
+ authorization of the management system itself.
+
+ There are a number of authorization settings that might be used by a
+ managed system to determine whether the managing entity has
+ authorization to perform the given management task. Example
+ authorization settings that the solution might need to cover are:
+
+ o Access to the configuration that specifies which zones are to be
+ served
+
+ o Access to the management system infrastructure
+
+ o Access to other control operations
+
+ o Access to other configuration operations
+
+ o Access to monitoring operations
+
+ Note: the above list is expected to be used as a collection of
+ examples and is not a complete list of needed authorization
+ protections.
+
+4.5. Solution Impacts on Security
+
+ The solution MUST minimize the security risks introduced to the
+ complete name server system. It is impossible to add new
+ infrastructure to a server and not impact the security in some
+ fashion as the introduction of a management protocol alone will
+ provide a new avenue for potential attack. Although the added
+ management benefits will be worth the increased risks, the solution
+ still needs to minimize this impact as much as possible.
+
+5. Other Requirements
+
+5.1. Extensibility
+
+ The management solution is expected to change and expand over time as
+ lessons are learned and new DNS features are deployed. Thus, the
+ solution MUST be flexible and able to accommodate new future
+ management operations. The solution might, for example, make use of
+ protocol versioning or capability description exchanges to ensure
+
+
+
+Hardaker Informational [Page 12]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+ that management stations and name servers that weren't written to the
+ same specification version can still interoperate to the best of
+ their combined ability.
+
+5.1.1. Vendor Extensions
+
+ It MUST be possible for vendors to extend the standardized management
+ model with vendor-specific extensions to support additional features
+ offered by their products.
+
+5.1.2. Extension Identification
+
+ It MUST be possible for a management station to understand which
+ parts of returned data are specific to a given vendor or other
+ standardized extension. The data returned needs to be appropriately
+ marked, through the use of name spaces or similar mechanisms, to
+ ensure that the base management model data can be logically separated
+ from the extension data without needing to understand the extension
+ data itself.
+
+5.1.3. Name-Space Collision Protection
+
+ It MUST be possible to protect against multiple extensions
+ conflicting with each other. The use of name-space protection
+ mechanisms for communicated management variables is common practice
+ to protect against such problems. Name-space identification
+ techniques also frequently solve the "Extension Identification"
+ requirement discussed in Section 5.1.2.
+
+6. Security Considerations
+
+ Any management protocol for which conformance to this document is
+ claimed needs to fully support the criteria discussed in Section 4 in
+ order to protect the management infrastructure itself. The DNS is a
+ core Internet service, and management traffic that protects it could
+ be the target of attacks designed to subvert that service. Because
+ the management infrastructure will be adding additional interfaces to
+ that service, it is critical that the management infrastructure
+ support adequate protections against network attacks.
+
+7. Document History
+
+ A requirement-gathering discussion was held at the December 2007 IETF
+ meeting in Vancouver, BC, Canada, and a follow-up meeting was held at
+ the March 2008 IETF meeting in Philadelphia. This document is a
+ compilation of the results of those discussions as well as
+ discussions on the DCOMA mailing list.
+
+
+
+
+Hardaker Informational [Page 13]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+8. Acknowledgments
+
+ This document is the result of discussions within the DCOMA design
+ team chaired by Jaap Akkerhuis. This team consisted of a large
+ number of people, all of whom provided valuable insight and input
+ into the discussions surrounding name server management. The text of
+ this document was written from notes taken during meetings as well as
+ from contributions sent to the DCOMA mailing list. This work
+ documents the consensus of the DCOMA design team.
+
+ In particular, the following team members contributed significantly
+ to the text in the document:
+
+ Stephane Bortzmeyer
+ Stephen Morris
+ Phil Regnauld
+
+ Further editing contributions and wording suggestions were made by
+ Alfred Hoenes and Doug Barton.
+
+9. References
+
+9.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+
+
+
+
+Hardaker Informational [Page 14]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+ (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+ Trust Anchors", RFC 5011, September 2007.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008.
+
+ [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+ (AXFR)", RFC 5936, June 2010.
+
+9.2. Informative References
+
+ [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
+ RFC 1611, May 1994.
+
+ [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
+ RFC 1612, May 1994.
+
+ [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+ and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+ July 1997.
+
+ [RFC3197] Austein, R., "Applicability Statement for DNS MIB
+ Extensions", RFC 3197, November 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Informational [Page 15]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+Appendix A. Deployment Scenarios
+
+ This appendix documents some additional deployment scenarios that
+ have been traditionally difficult to manage. They are provided as
+ guidance to protocol developers as data points of real-world name
+ server management problems.
+
+A.1. Non-Standard Zones
+
+ If an organization uses non-standard zones (for example a purely
+ local TLD), synchronizing all the name servers for these zones is
+ usually a time-consuming task. It is made worse when two
+ organizations with conflicting zones merge. This situation is not a
+ recommended deployment scenario (and is even heavily discouraged),
+ but it is, unfortunately, seen in the wild.
+
+ It is typically implemented using "forwarding" zones. But there is
+ no way to ensure automatically that all the resolvers have the same
+ set of zones to forward at any given time. New zones might be added
+ to a local forwarding recursive server, for example, without
+ modifying the rest of the deployed forwarding servers. It is hoped
+ that a management solution that could handle the configuration of
+ zone forwarding would finally allow management of servers deployed in
+ this fashion.
+
+A.2. Redundancy Sharing
+
+ For reliability reasons, it is recommended that zone operators follow
+ the guidelines documented in [RFC2182], which recommends that
+ multiple name servers be configured for each zone and that the name
+ servers be separated both physically and via connectivity routes. A
+ common solution is to establish DNS-serving partnerships: "I'll host
+ your zones and you'll host mine". Both entities benefit from
+ increased DNS reliability via the wider service distribution. This
+ frequently occurs between cooperating but otherwise unrelated
+ entities (such as between two distinct companies) as well as between
+ affiliated organizations (such as between branch offices within a
+ single company).
+
+ The configuration of these relationships are currently required to be
+ manually configured and maintained. Changes to the list of zones
+ that are cross-hosted are manually negotiated between the cooperating
+ network administrators and configured by hand. A management protocol
+ with the ability to provide selective authorization, as discussed in
+ Section 4.4, would solve many of the management difficulties between
+ cooperating organizations.
+
+
+
+
+
+Hardaker Informational [Page 16]
+\f
+RFC 6168 Name Server Management Requirements May 2011
+
+
+A.3. DNSSEC Management
+
+ There are many different DNSSEC deployment strategies that may be
+ used for mission-critical zones. The following list describes some
+ example deployment scenarios that might warrant different management
+ strategies.
+
+ All contents and DNSSEC keying information controlled and operated
+ by a single organization
+
+ Zone contents controlled and operated by one organization, all
+ DNSSEC keying information controlled and operated by a second
+ organization.
+
+ Zone contents controlled and operated by one organization, zone
+ signing keys (ZSKs) controlled and operated by a second
+ organization, and key signing keys (KSKs) controlled and operated
+ by a third organization.
+
+ Although this list is not exhaustive in the potential ways that zone
+ data can be divided up, it should be sufficient to illustrate the
+ potential ways in which zone data can be controlled by multiple
+ entities.
+
+ The end result of all of these strategies, however, will be the same:
+ a live zone containing DNSSEC-related resource records. Many of the
+ above strategies are merely different ways of preparing a zone for
+ serving. A management solution that includes support for managing
+ DNSSEC zone data may wish to take into account these potential
+ management scenarios.
+
+Author's Address
+
+ Wes Hardaker
+ Sparta, Inc.
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Phone: +1 530 792 1913
+ EMail: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+Hardaker Informational [Page 17]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Rose
+Request for Comments: 6672 NIST
+Obsoletes: 2672 W. Wijngaards
+Updates: 3363 NLnet Labs
+Category: Standards Track June 2012
+ISSN: 2070-1721
+
+
+ DNAME Redirection in the DNS
+
+Abstract
+
+ The DNAME record provides redirection for a subtree of the domain
+ name tree in the DNS. That is, all names that end with a particular
+ suffix are redirected to another part of the DNS. This document
+ obsoletes the original specification in RFC 2672 as well as updates
+ the document on representing IPv6 addresses in DNS (RFC 3363).
+
+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/rfc6672.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 1]
+\f
+RFC 6672 DNAME Redirection June 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 2]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
+ 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 5
+ 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
+ 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 6
+ 2.4. Names next to and below a DNAME Record . . . . . . . . . . 7
+ 2.5. Compression of the DNAME Record . . . . . . . . . . . . . 7
+ 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. CNAME Synthesis . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. Server Algorithm . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
+ 3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11
+ 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
+ 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13
+ 5.1. Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13
+ 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
+ 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14
+ 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
+ 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
+ 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14
+ 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14
+ 5.3.4.1. Invalid Name Error Response Caused by DNAME in
+ Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.3.4.2. Valid Name Error Response Involving DNAME in
+ Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.3.4.3. Response with Synthesized CNAME . . . . . . . . . 16
+ 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16
+ 6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16
+ 6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17
+ 6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
+ Appendix A. Changes from RFC 2672 . . . . . . . . . . . . . . . . 21
+ A.1. Changes to Server Behavior . . . . . . . . . . . . . . . . 21
+ A.2. Changes to Client Behavior . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 3]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+1. Introduction
+
+ DNAME is a DNS resource record type originally defined in RFC 2672
+ [RFC2672]. DNAME provides redirection from a part of the DNS name
+ tree to another part of the DNS name tree.
+
+ The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
+ (potentially) return data corresponding to a domain name different
+ from the queried domain name. The difference between the two
+ resource records is that the CNAME RR directs the lookup of data at
+ its owner to another single name, whereas a DNAME RR directs lookups
+ for data at descendants of its owner's name to corresponding names
+ under a different (single) node of the tree.
+
+ For example, take looking through a zone (see RFC 1034 [RFC1034],
+ Section 4.3.2, step 3) for the domain name "foo.example.com", and a
+ DNAME resource record is found at "example.com" indicating that all
+ queries under "example.com" be directed to "example.net". The lookup
+ process will return to step 1 with the new query name of
+ "foo.example.net". Had the query name been "www.foo.example.com",
+ the new query name would be "www.foo.example.net".
+
+ This document is a revision of the original specification of DNAME in
+ RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
+ maintaining address-to-name mappings in a context of network
+ renumbering. With a careful setup, a renumbering event in the
+ network causes no change to the authoritative server that has the
+ address-to-name mappings. Examples in practice are classless reverse
+ address space delegations.
+
+ Another usage of DNAME lies in aliasing of name spaces. For example,
+ a zone administrator may want subtrees of the DNS to contain the same
+ information. Examples include punycode [RFC3492] alternates for
+ domain spaces.
+
+ This revision of the DNAME specification does not change the wire
+ format or the handling of DNAME resource records. Discussion is
+ added on problems that may be encountered when using DNAME.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in RFC
+ 2119 [RFC2119].
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 4]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+2. The DNAME Resource Record
+
+2.1. Format
+
+ The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
+ CLASS-insensitive.
+
+ Its RDATA is comprised of a single field, <target>, which contains a
+ fully qualified domain name that MUST be sent in uncompressed form
+ [RFC1035] [RFC3597]. The <target> field MUST be present. The
+ presentation format of <target> is that of a domain name [RFC1035].
+ The presentation format of the RR is as follows:
+
+ <owner> <ttl> <class> DNAME <target>
+
+ The effect of the DNAME RR is the substitution of the record's
+ <target> for its owner name, as a suffix of a domain name. This
+ substitution is to be applied for all names below the owner name of
+ the DNAME RR. This substitution has to be applied for every DNAME RR
+ found in the resolution process, which allows fairly lengthy valid
+ chains of DNAME RRs.
+
+ Details of the substitution process, methods to avoid conflicting
+ resource records, and rules for specific corner cases are given in
+ the following subsections.
+
+2.2. The DNAME Substitution
+
+ When following step 3 of the algorithm in RFC 1034 [RFC1034], Section
+ 4.3.2, "start matching down, label by label, in the zone" and a node
+ is found to own a DNAME resource record, a DNAME substitution occurs.
+ The name being sought may be the original query name or a name that
+ is the result of a CNAME resource record being followed or a
+ previously encountered DNAME. As in the case when finding a CNAME
+ resource record or NS resource record set, the processing of a DNAME
+ will happen prior to finding the desired domain name.
+
+ A DNAME substitution is performed by replacing the suffix labels of
+ the name being sought matching the owner name of the DNAME resource
+ record with the string of labels in the RDATA field. The matching
+ labels end with the root label in all cases. Only whole labels are
+ replaced. See the table of examples for common cases and corner
+ cases.
+
+ In the table below, the QNAME refers to the query name. The owner is
+ the DNAME owner domain name, and the target refers to the target of
+ the DNAME record. The result is the resulting name after performing
+ the DNAME substitution on the query name. "no match" means that the
+
+
+
+Rose & Wijngaards Standards Track [Page 5]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ query did not match the DNAME, and thus no substitution is performed
+ and a possible error message is returned (if no other result is
+ possible). Thus, every line contains one example substitution. In
+ the examples below, 'cyc' and 'shortloop' contain loops.
+
+ QNAME owner DNAME target result
+ ---------------- -------------- -------------- -----------------
+ com. example.com. example.net. <no match>
+ example.com. example.com. example.net. [0]
+ 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>
+ foo.example.com. example.com. example.net. foo.example.net.
+ a.x.example.com. x.example.com. example.net. a.example.net.
+ a.example.com. example.com. y.example.net. a.y.example.net.
+ cyc.example.com. example.com. example.com. cyc.example.com.
+ cyc.example.com. example.com. c.example.com. cyc.c.example.com.
+ shortloop.x.x. x. . shortloop.x.
+ shortloop.x. x. . shortloop.
+
+ [0] The result depends on the QTYPE. If the QTYPE = DNAME, then
+ the result is "example.com.", else "<no match>".
+
+ Table 1. DNAME Substitution Examples
+
+ It is possible for DNAMEs to form loops, just as CNAMEs can form
+ loops. DNAMEs and CNAMEs can chain together to form loops. A single
+ corner case DNAME can form a loop. Resolvers and servers should be
+ cautious in devoting resources to a query, but be aware that fairly
+ long chains of DNAMEs may be valid. Zone content administrators
+ should take care to ensure that there are no loops that could occur
+ when using DNAME or DNAME/CNAME redirection.
+
+ The domain name can get too long during substitution. For example,
+ suppose the target name of the DNAME RR is 250 octets in length
+ (multiple labels), if an incoming QNAME that has a first label over 5
+ octets in length, the result would be a name over 255 octets. If
+ this occurs, the server returns an RCODE of YXDOMAIN [RFC2136]. The
+ DNAME record and its signature (if the zone is signed) are included
+ in the answer as proof for the YXDOMAIN (value 6) RCODE.
+
+2.3. DNAME Owner Name Matching the QNAME
+
+ Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
+ owner name; the owner name of a DNAME is not redirected itself. The
+ domain name that owns a DNAME record is allowed to have other
+ resource record types at that domain name, except DNAMEs, CNAMEs, or
+ other types that have restrictions on what they can coexist with.
+
+
+
+Rose & Wijngaards Standards Track [Page 6]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ When there is a match of the QTYPE to a type (or types) also owned by
+ the owner name, the response is sourced from the owner name. For
+ example, a QTYPE of ANY would return the (available) types at the
+ owner name, not the target name.
+
+ DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
+ the owner name is the zone apex; if it is not the zone apex, then the
+ NS RR signifies a delegation point, and the DNAME RR must in that
+ case appear below the zone cut at the zone apex of the child zone.
+
+ If a DNAME record is present at the zone apex, there is still a need
+ to have the customary SOA and NS resource records there as well.
+ Such a DNAME cannot be used to mirror a zone completely, as it does
+ not mirror the zone apex.
+
+ These rules also allow DNAME records to be queried through caches
+ that are RFC 1034 [RFC1034] compliant and are DNAME unaware.
+
+2.4. Names next to and below a DNAME Record
+
+ Resource records MUST NOT exist at any subdomain of the owner of a
+ DNAME RR. To get the contents for names subordinate to that owner
+ name, the DNAME redirection must be invoked and the resulting target
+ queried. A server MAY refuse to load a zone that has data at a
+ subdomain of a domain name owning a DNAME RR. If the server does
+ load the zone, those names below the DNAME RR will be occluded as
+ described in RFC 2136 [RFC2136], Section 7.18. Also, a server ought
+ to refuse to load a zone subordinate to the owner of a DNAME record
+ in the ancestor zone. See Section 5.2 for further discussion related
+ to dynamic update.
+
+ DNAME is a singleton type, meaning only one DNAME is allowed per
+ name. The owner name of a DNAME can only have one DNAME RR, and no
+ CNAME RRs can exist at that name. These rules make sure that for a
+ single domain name, only one redirection exists; thus, there's no
+ confusion about which one to follow. A server ought to refuse to
+ load a zone that violates these rules.
+
+2.5. Compression of the DNAME Record
+
+ The DNAME owner name can be compressed like any other owner name.
+ The DNAME RDATA target name MUST NOT be sent out in compressed form
+ and MUST be downcased for DNS Security Extensions (DNSSEC)
+ validation.
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 7]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ Although the previous DNAME specification [RFC2672] (that is
+ obsoleted by this specification) talked about signaling to allow
+ compression of the target name, such signaling has never been
+ specified, nor is it specified in this document.
+
+ RFC 2672 (obsoleted by this document) states that the Extended DNS
+ (EDNS) version has a means for understanding DNAME and DNAME target
+ name compression. This document revises RFC 2672, in that there is
+ no EDNS version signaling for DNAME.
+
+3. Processing
+
+3.1. CNAME Synthesis
+
+ When preparing a response, a server performing a DNAME substitution
+ will, in all cases, include the relevant DNAME RR in the answer
+ section. Relevant cases includes the following:
+
+ 1. The DNAME is being employed as a substitution instruction.
+
+ 2. The DNAME itself matches the QTYPE, and the owner name matches
+ QNAME.
+
+ When the owner name matches the QNAME and the QTYPE matches another
+ type owned there, the DNAME is not included in the answer.
+
+ A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
+ RR is synthesized and included in the answer section when the DNAME
+ is employed as a substitution instruction. The owner name of the
+ CNAME is the QNAME of the query. The DNSSEC specification ([RFC4033]
+ [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to
+ be signed. The signed DNAME has an RRSIG, and a validating resolver
+ can check the CNAME against the DNAME record and validate the
+ signature over the DNAME RR.
+
+ Servers MUST be able to answer a query for a synthesized CNAME. Like
+ other query types, this invokes the DNAME, and then the server
+ synthesizes the CNAME and places it into the answer section. If the
+ server in question is a cache, the synthesized CNAME's TTL SHOULD be
+ equal to the decremented TTL of the cached DNAME.
+
+ Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a
+ value equal to the TTL of the corresponding DNAME record (as some
+ older, authoritative server implementations set the TTL of
+ synthesized CNAMEs to zero). A TTL of zero means that the CNAME can
+ be discarded immediately after processing the answer.
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 8]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+3.2. Server Algorithm
+
+ Below is the revised version of the server algorithm, which appears
+ in RFC 2672, Section 4.1.
+
+ 1. Set or clear the value of recursion available in the response
+ depending on whether the name server is willing to provide
+ recursive service. If recursive service is available and
+ requested via the RD bit in the query, go to step 5; otherwise,
+ step 2.
+
+ 2. Search the available zones for the zone which is the nearest
+ ancestor to QNAME. If such a zone is found, go to step 3;
+ otherwise, step 4.
+
+ 3. Start matching down, label by label, in the zone. The matching
+ process can terminate several ways:
+
+ A. If the whole of QNAME is matched, we have found the node.
+
+ If the data at the node is a CNAME, and QTYPE does not match
+ CNAME, copy the CNAME RR into the answer section of the
+ response, change QNAME to the canonical name in the CNAME RR,
+ and go back to step 1.
+
+ Otherwise, copy all RRs which match QTYPE into the answer
+ section and go to step 6.
+
+ B. If a match would take us out of the authoritative data, we
+ have a referral. This happens when we encounter a node with
+ NS RRs marking cuts along the bottom of a zone.
+
+ Copy the NS RRs for the sub-zone into the authority section
+ of the reply. Put whatever addresses are available into the
+ additional section, using glue RRs if the addresses are not
+ available from authoritative data or the cache. Go to step
+ 4.
+
+ C. If at some label, a match is impossible (i.e., the
+ corresponding label does not exist), look to see whether the
+ last label matched has a DNAME record.
+
+ If a DNAME record exists at that point, copy that record into
+ the answer section. If substitution of its <target> for its
+ <owner> in QNAME would overflow the legal size for a <domain-
+ name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise,
+ perform the substitution and continue. The server MUST
+
+
+
+
+Rose & Wijngaards Standards Track [Page 9]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ synthesize a CNAME record as described above and include it
+ in the answer section. Go back to step 1.
+
+ If there was no DNAME record, look to see if the "*" label
+ exists.
+
+ If the "*" label does not exist, check whether the name we
+ are looking for is the original QNAME in the query or a name
+ we have followed due to a CNAME or DNAME. If the name is
+ original, set an authoritative name error in the response and
+ exit. Otherwise, just exit.
+
+ If the "*" label does exist, match RRs at that node against
+ QTYPE. If any match, copy them into the answer section, but
+ set the owner of the RR to be QNAME, and not the node with
+ the "*" label. If the data at the node with the "*" label is
+ a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
+ into the answer section of the response changing the owner
+ name to the QNAME, change QNAME to the canonical name in the
+ CNAME RR, and go back to step 1. Otherwise, go to step 6.
+
+ 4. Start matching down in the cache. If QNAME is found in the
+ cache, copy all RRs attached to it that match QTYPE into the
+ answer section. If QNAME is not found in the cache but a DNAME
+ record is present at an ancestor of QNAME, copy that DNAME record
+ into the answer section. If there was no delegation from
+ authoritative data, look for the best one from the cache, and put
+ it in the authority section. Go to step 6.
+
+ 5. Use the local resolver or a copy of its algorithm to answer the
+ query. Store the results, including any intermediate CNAMEs and
+ DNAMEs, in the answer section of the response.
+
+ 6. Using local data only, attempt to add other RRs that may be
+ useful to the additional section of the query. Exit.
+
+ Note that there will be at most one ancestor with a DNAME as
+ described in step 4 unless some zone's data is in violation of the
+ no-descendants limitation in Section 3. An implementation might take
+ advantage of this limitation by stopping the search of step 3c or
+ step 4 when a DNAME record is encountered.
+
+3.3. Wildcards
+
+ The use of DNAME in conjunction with wildcards is discouraged
+ [RFC4592]. Thus, records of the form "*.example.com DNAME
+ example.net" SHOULD NOT be used.
+
+
+
+
+Rose & Wijngaards Standards Track [Page 10]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ The interaction between the expansion of the wildcard and the
+ redirection of the DNAME is non-deterministic. Due to the fact that
+ the processing is non-deterministic, DNSSEC validating resolvers may
+ not be able to validate a wildcarded DNAME.
+
+ A server MAY give a warning that the behavior is unspecified if such
+ a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
+ load the zone, or refuse dynamic updates.
+
+3.4. Acceptance and Intermediate Storage
+
+ Recursive caching name servers can encounter data at names below the
+ owner name of a DNAME RR, due to a change at the authoritative server
+ where data from before and after the change resides in the cache.
+ This conflict situation is a transitional phase that ends when the
+ old data times out. The caching name server can opt to store both
+ old and new data and treat each as if the other did not exist, or
+ drop the old data, or drop the longer domain name. In any approach,
+ consistency returns after the older data TTL times out.
+
+ Recursive caching name servers MUST perform CNAME synthesis on behalf
+ of clients.
+
+ If a recursive caching name server encounters a DNSSEC validated
+ DNAME RR that contradicts information already in the cache (excluding
+ CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the
+ CNAME record received along with it, subject to the rules for CNAME.
+ If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but
+ not able to validate), the recursive caching server SHOULD NOT cache
+ the DNAME RR but MAY cache the CNAME record received along with it,
+ subject to the rules for CNAME.
+
+3.4.1. Resolver Algorithm
+
+ Below is the revised version of the resolver algorithm, which appears
+ in RFC 2672, Section 4.2.
+
+ 1. See if the answer is in local information or can be synthesized
+ from a cached DNAME; if so, return it to the client.
+
+ 2. Find the best servers to ask.
+
+ 3. Send queries until one returns a response.
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 11]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ 4. Analyze the response, either:
+
+ A. If the response answers the question or contains a name
+ error, cache the data as well as return it back to the
+ client.
+
+ B. If the response contains a better delegation to other
+ servers, cache the delegation information, and go to step 2.
+
+ C. If the response shows a CNAME and that is not the answer
+ itself, cache the CNAME, change the SNAME to the canonical
+ name in the CNAME RR, and go to step 1.
+
+ D. If the response shows a DNAME and that is not the answer
+ itself, cache the DNAME (upon successful DNSSEC validation if
+ the client is a validating resolver). If substitution of the
+ DNAME's target name for its owner name in the SNAME would
+ overflow the legal size for a domain name, return an
+ implementation-dependent error to the application; otherwise,
+ perform the substitution and go to step 1.
+
+ E. If the response shows a server failure or other bizarre
+ contents, delete the server from the SLIST and go back to
+ step 3.
+
+4. DNAME Discussions in Other Documents
+
+ In Section 10.3 of [RFC2181], the discussion on MX and NS records
+ touches on redirection by CNAMEs, but this also holds for DNAMEs.
+
+ Section 10.3 ("MX and NS records") of [RFC2181] states:
+
+ The domain name used as the value of a NS resource record,
+ or part of the value of a MX resource record must not be
+ an alias. Not only is the specification clear on this
+ point, but using an alias in either of these positions
+ neither works as well as might be hoped, nor well fulfills
+ the ambition that may have led to this approach. This
+ domain name must have as its value one or more address
+ records. Currently those will be A records, however in
+ the future other record types giving addressing
+ information may be acceptable. It can also have other
+ RRs, but never a CNAME RR.
+
+ The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME.
+ The opening premise of this section is demonstrably wrong, and so the
+ conclusion based on that premise is wrong. In particular, [RFC3363]
+ deprecates the use of DNAME in the IPv6 reverse tree. Based on the
+
+
+
+Rose & Wijngaards Standards Track [Page 12]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ experience gained in the meantime, [RFC3363] is revised, dropping all
+ constraints on having DNAME RRs in these zones [RFC6434]. This would
+ greatly improve the manageability of the IPv6 reverse tree. These
+ changes are made explicit below.
+
+ In [RFC3363], the following paragraph is updated by this document,
+ and the use of DNAME RRs in the reverse tree is no longer deprecated.
+
+ The issues for DNAME in the reverse mapping tree appears to be
+ closely tied to the need to use fragmented A6 in the main tree: if
+ one is necessary, so is the other, and if one isn't necessary, the
+ other isn't either. Therefore, in moving RFC 2874 to experimental,
+ the intent of this document is that use of DNAME RRs in the reverse
+ tree be deprecated.
+
+5. Other Issues with DNAME
+
+ There are several issues to be aware of about the use of DNAME.
+
+5.1. Canonical Hostnames Cannot Be below DNAME Owners
+
+ The names listed as target names of MX, NS, PTR, and SRV [RFC2782]
+ records must be canonical hostnames. This means no CNAME or DNAME
+ redirection may be present during DNS lookup of the address records
+ for the host. This is discussed in RFC 2181 [RFC2181], Section 10.3,
+ and RFC 1912 [RFC1912], Section 2.4. For SRV, see RFC 2782
+ [RFC2782], page 4.
+
+ The upshot of this is that although the lookup of a PTR record can
+ involve DNAMEs, the name listed in the PTR record cannot fall under a
+ DNAME. The same holds for NS, SRV, and MX records. For example,
+ when punycode [RFC3492] alternates for a zone use DNAME, then the NS,
+ MX, SRV, and PTR records that point to that zone must use names that
+ are not aliases in their RDATA. Then, what must be done is to have
+ the domain names with DNAME substitution already applied to it as the
+ MX, NS, PTR, and SRV data. These are valid canonical hostnames.
+
+5.2. Dynamic Update and DNAME
+
+ DNAME records can be added, changed, and removed in a zone using
+ dynamic update transactions. Adding a DNAME RR to a zone occludes
+ any domain names that may exist under the added DNAME.
+
+ If a dynamic update message attempts to add a DNAME with a given
+ owner name, but a CNAME is associated with that name, then the server
+ MUST ignore the DNAME. If a DNAME is already associated with that
+ name, then it is replaced with the new DNAME. Otherwise, add the
+ DNAME. If a CNAME is added with a given owner name, but a DNAME is
+
+
+
+Rose & Wijngaards Standards Track [Page 13]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ associated with that name, then the CNAME MUST be ignored. Similar
+ behavior occurs for dynamic updates to an owner name of a CNAME RR
+ [RFC2136].
+
+5.3. DNSSEC and DNAME
+
+ The following subsections specify the behavior of implementations
+ that understand both DNSSEC and DNAME (synthesis).
+
+5.3.1. Signed DNAME, Unsigned Synthesized CNAME
+
+ In any response, a signed DNAME RR indicates a non-terminal
+ redirection of the query. There might or might not be a server-
+ synthesized CNAME in the answer section; if there is, the CNAME will
+ never be signed. For a DNSSEC validator, verification of the DNAME
+ RR and then that the CNAME was properly synthesized is sufficient
+ proof.
+
+5.3.2. DNAME Bit in NSEC Type Map
+
+ In any negative response, the NSEC or NSEC3 [RFC5155] record type
+ bitmap SHOULD be checked to see that there was no DNAME that could
+ have been applied. If the DNAME bit in the type bitmap is set and
+ the query name is a subdomain of the closest encloser that is
+ asserted, then DNAME substitution should have been done, but the
+ substitution has not been done as specified.
+
+5.3.3. DNAME Chains as Strong as the Weakest Link
+
+ A response can contain a chain of DNAME and CNAME redirections. That
+ chain can end in a positive answer or a negative reply (no name error
+ or no data error). Each step in that chain results in resource
+ records being added to the answer or authority section of the
+ response. Only if all steps are secure can the AD (Authentic Data)
+ bit be set for the response. If one of the steps is bogus, the
+ result is bogus.
+
+5.3.4. Validators Must Understand DNAME
+
+ Below are examples of why DNSSEC validators MUST understand DNAME.
+ In the examples, SOA records, wildcard denial NSECs, and other
+ material not under discussion have been omitted or shortened.
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 14]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+5.3.4.1. Invalid Name Error Response Caused by DNAME in Bitmap
+
+ ;; Header: QR AA RCODE=3(NXDOMAIN)
+ ;; OPT PSEUDOSECTION:
+ ; EDNS: version: 0, flags: do; udp: 4096
+
+ ;; Question
+ foo.bar.example.com. IN A
+ ;; Authority
+ bar.example.com. NSEC dub.example.com. A DNAME
+ bar.example.com. RRSIG NSEC [valid signature]
+
+ If this is the received response, then only by understanding that the
+ DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
+ have been redirected by the DNAME, the validator can see that it is a
+ BOGUS reply from an attacker that collated existing records from the
+ DNS to create a confusing reply.
+
+ If the DNAME bit had not been set in the NSEC record above, then the
+ answer would have validated as a correct name error response.
+
+5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
+
+ ;; Header: QR AA RCODE=3(NXDOMAIN)
+ ;; OPT PSEUDOSECTION:
+ ; EDNS: version: 0, flags: do; udp: 4096
+
+ ;; Question
+ cee.example.com. IN A
+ ;; Authority
+ bar.example.com. NSEC dub.example.com. A DNAME
+ bar.example.com. RRSIG NSEC [valid signature]
+
+ This response has the same NSEC records as the example above, but
+ with this query name (cee.example.com), the answer is validated,
+ because 'cee' does not get redirected by the DNAME at 'bar'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 15]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+5.3.4.3. Response with Synthesized CNAME
+
+ ;; Header: QR AA RCODE=0(NOERROR)
+ ;; OPT PSEUDOSECTION:
+ ; EDNS: version: 0, flags: do; udp: 4096
+
+ ;; Question
+ foo.bar.example.com. IN A
+ ;; Answer
+ bar.example.com. DNAME bar.example.net.
+ bar.example.com. RRSIG DNAME [valid signature]
+ foo.bar.example.com. CNAME foo.bar.example.net.
+
+ The response shown above has the synthesized CNAME included.
+ However, the CNAME has no signature, since the server does not sign
+ online. So this response cannot be trusted. It could be altered by
+ an attacker to be foo.bar.example.com CNAME bla.bla.example. The
+ DNAME record does have its signature included, since it does not
+ change. The validator must verify the DNAME signature and then
+ recursively resolve further in order to query for the
+ foo.bar.example.net A record.
+
+6. Examples of DNAME Use in a Zone
+
+ Below are some examples of the use of DNAME in a zone. These
+ examples are by no means exhaustive.
+
+6.1. Organizational Renaming
+
+ If an organization with domain name FROBOZZ.EXAMPLE.NET became part
+ of an organization with domain name ACME.EXAMPLE.COM, it might ease
+ transition by placing information such as this in its old zone.
+
+ frobozz.example.net. DNAME frobozz-division.acme.example.com.
+ MX 10 mailhub.acme.example.com.
+
+ The response to an extended recursive query for
+ www.frobozz.example.net would contain, in the answer section, the
+ DNAME record shown above and the relevant RRs for www.frobozz-
+ division.acme.example.com.
+
+ If an organization wants to have aliases for names, for a different
+ spelling or language, the same example applies. Note that the MX RR
+ at the zone apex is not redirected and has to be repeated in the
+ target zone. Also note that the services at mailhub or www.frobozz-
+ division.acme.example.com. have to recognize and handle the aliases.
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 16]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+6.2. Classless Delegation of Shorter Prefixes
+
+ The classless scheme for in-addr.arpa delegation [RFC2317] can be
+ extended to prefixes shorter than 24 bits by use of the DNAME record.
+ For example, the prefix 192.0.8.0/22 can be delegated by the
+ following records.
+
+ $ORIGIN 0.192.in-addr.arpa.
+ 8/22 NS ns.slash-22-holder.example.com.
+ 8 DNAME 8.8/22
+ 9 DNAME 9.8/22
+ 10 DNAME 10.8/22
+ 11 DNAME 11.8/22
+
+ A typical entry in the resulting reverse zone for some host with
+ address 192.0.9.33 might be as follows:
+
+ $ORIGIN 8/22.0.192.in-addr.arpa.
+ 33.9 PTR somehost.slash-22-holder.example.com.
+
+ The advisory remarks in [RFC2317] concerning the choice of the "/"
+ character apply here as well.
+
+6.3. Network Renumbering Support
+
+ If IPv4 network renumbering were common, maintenance of address space
+ delegation could be simplified by using DNAME records instead of NS
+ records to delegate.
+
+ $ORIGIN new-style.in-addr.arpa.
+ 189.190 DNAME in-addr.example.net.
+
+ $ORIGIN in-addr.example.net.
+ 188 DNAME in-addr.customer.example.com.
+
+ $ORIGIN in-addr.customer.example.
+ 1 PTR www.customer.example.com
+ 2 PTR mailhub.customer.example.com.
+ ; etc ...
+
+ This would allow the address space 190.189.0.0/16 assigned to the ISP
+ "example.net" to be changed without having to alter the zone data
+ describing the use of that space by the ISP and its customers.
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 17]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+ Renumbering IPv4 networks is currently so arduous a task that
+ updating the DNS is only a small part of the labor, so this scheme
+ may have a low value. But it is hoped that in IPv6 the renumbering
+ task will be quite different, and the DNAME mechanism may play a
+ useful part.
+
+7. IANA Considerations
+
+ The DNAME resource record type code 39 (decimal) originally was
+ registered by [RFC2672] in the DNS Resource Record (RR) Types
+ registry table at http://www.iana.org/assignments/dns-parameters.
+ IANA has updated the DNS resource record registry to point to this
+ document for RR type 39.
+
+8. Security Considerations
+
+ DNAME redirects queries elsewhere, which may impact security based on
+ policy and the security status of the zone with the DNAME and the
+ redirection zone's security status. For validating resolvers, the
+ lowest security status of the links in the chain of CNAME and DNAME
+ redirections is applied to the result.
+
+ If a validating resolver accepts wildcarded DNAMEs, this creates
+ security issues. Since the processing of a wildcarded DNAME is non-
+ deterministic and the CNAME that was substituted by the server has no
+ signature, the resolver may choose a different result than what the
+ server meant, and consequently end up at the wrong destination. Use
+ of wildcarded DNAMEs is discouraged in any case [RFC4592].
+
+ A validating resolver MUST understand DNAME, according to [RFC4034].
+ The examples in Section 5.3.4 illustrate this need.
+
+9. Acknowledgments
+
+ The authors of this document would like to acknowledge Matt Larson
+ for beginning this effort to address the issues related to the DNAME
+ RR type. The authors would also like to acknowledge Paul Vixie, Ed
+ Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
+ Hoenes, and Kevin Darcy for their reviews and comments on this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 18]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+10. References
+
+10.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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
+ ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [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.
+
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
+ System", RFC 4592, July 2006.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008.
+
+
+
+Rose & Wijngaards Standards Track [Page 19]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+10.2. Informative References
+
+ [RFC1912] Barr, D., "Common DNS Operational and Configuration
+ Errors", RFC 1912, February 1996.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
+ RFC 2672, 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.
+
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications
+ (IDNA)", RFC 3492, March 2003.
+
+ [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
+ Requirements", RFC 6434, December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 20]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+Appendix A. Changes from RFC 2672
+
+A.1. Changes to Server Behavior
+
+ Major changes to server behavior from the original DNAME
+ specification are summarized below:
+
+ o The rules for DNAME substitution have been clarified in
+ Section 2.2.
+
+ o The EDNS option to signal DNAME understanding and compression has
+ never been specified, and this document clarifies that there is no
+ signaling method (Section 2.5).
+
+ o The TTL for synthesized CNAME RRs is now set to the TTL of the
+ DNAME, not zero (Section 3.1).
+
+ o Recursive caching servers MUST perform CNAME synthesis on behalf
+ of clients (Section 3.4).
+
+ o The revised server algorithm is detailed in Section 3.2.
+
+ o Rules for dynamic update messages adding a DNAME or CNAME RR to a
+ zone where a CNAME or DNAME already exists are detailed in
+ Section 5.2.
+
+A.2. Changes to Client Behavior
+
+ Major changes to client behavior from the original DNAME
+ specification are summarized below:
+
+ o Clients MUST be able to accept synthesized CNAME RR's with a TTL
+ of either zero or the TTL of the DNAME RR that accompanies the
+ CNAME RR.
+
+ o DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache
+ synthesized CNAME RRs they receive in the same response. DNSSEC-
+ aware clients SHOULD also check the NSEC/NSEC3 type bitmap to
+ verify that DNAME redirection is to be done. DNSSEC validators
+ MUST understand DNAME (Section 5.3).
+
+ o The revised client algorithm is detailed in Section 3.4.1.
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 21]
+\f
+RFC 6672 DNAME Redirection June 2012
+
+
+Authors' Addresses
+
+ Scott Rose
+ NIST
+ 100 Bureau Dr.
+ Gaithersburg, MD 20899
+ USA
+
+ Phone: +1-301-975-8439
+ Fax: +1-301-975-6238
+ EMail: scott.rose@nist.gov
+
+
+ Wouter Wijngaards
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XH
+ The Netherlands
+
+ Phone: +31-20-888-4551
+ EMail: wouter@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards Standards Track [Page 22]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hoffman
+Request for Comments: 6698 VPN Consortium
+Category: Standards Track J. Schlyter
+ISSN: 2070-1721 Kirei AB
+ August 2012
+
+
+ The DNS-Based Authentication of Named Entities (DANE)
+ Transport Layer Security (TLS) Protocol: TLSA
+
+Abstract
+
+ Encrypted communication on the Internet often uses Transport Layer
+ Security (TLS), which depends on third parties to certify the keys
+ used. This document improves on that situation by enabling the
+ administrators of domain names to specify the keys used in that
+ domain's TLS servers. This requires matching improvements in TLS
+ client software, but no change in TLS server software.
+
+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/rfc6698.
+
+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
+ 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.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 1]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Background and Motivation ..................................3
+ 1.2. Securing the Association of a Domain Name with a
+ Server's Certificate .......................................4
+ 1.3. Method for Securing Certificate Associations ...............5
+ 1.4. Terminology ................................................6
+ 2. The TLSA Resource Record ........................................7
+ 2.1. TLSA RDATA Wire Format .....................................7
+ 2.1.1. The Certificate Usage Field .........................7
+ 2.1.2. The Selector Field ..................................8
+ 2.1.3. The Matching Type Field .............................9
+ 2.1.4. The Certificate Association Data Field ..............9
+ 2.2. TLSA RR Presentation Format ................................9
+ 2.3. TLSA RR Examples ..........................................10
+ 3. Domain Names for TLSA Certificate Associations .................10
+ 4. Use of TLSA Records in TLS .....................................11
+ 4.1. Usable Certificate Associations ...........................11
+ 5. TLSA and DANE Use Cases and Requirements .......................13
+ 6. Mandatory-to-Implement Features ................................15
+ 7. IANA Considerations ............................................15
+ 7.1. TLSA RRtype ...............................................15
+ 7.2. TLSA Certificate Usages ...................................15
+ 7.3. TLSA Selectors ............................................16
+ 7.4. TLSA Matching Types .......................................16
+ 8. Security Considerations ........................................16
+ 8.1. Comparing DANE to Public CAs ..............................18
+ 8.1.1. Risk of Key Compromise .............................19
+ 8.1.2. Impact of Key Compromise ...........................20
+ 8.1.3. Detection of Key Compromise ........................20
+ 8.1.4. Spoofing Hostnames .................................20
+ 8.2. DNS Caching ...............................................21
+ 8.3. External DNSSEC Validators ................................21
+ 9. Acknowledgements ...............................................22
+ 10. References ....................................................22
+ 10.1. Normative References .....................................22
+ 10.2. Informative References ...................................23
+ Appendix A. Operational Considerations for Deploying TLSA
+ Records ...............................................25
+ A.1. Creating TLSA Records ......................................25
+ A.1.1. Ambiguities and Corner Cases When TLS Clients
+ Build Trust Chains .....................................26
+ A.1.2. Choosing a Selector Type ...............................26
+ A.2. Provisioning TLSA Records in DNS ...........................28
+ A.2.1. Provisioning TLSA Records with Aliases .................28
+ A.3. Securing the Last Hop ......................................30
+ A.4. Handling Certificate Rollover ..............................31
+
+
+
+Hoffman & Schlyter Standards Track [Page 2]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Appendix B. Pseudocode for Using TLSA .............................32
+ B.1. Helper Functions ...........................................32
+ B.2. Main TLSA Pseudocode .......................................33
+ Appendix C. Examples ..............................................35
+
+1. Introduction
+
+1.1. Background and Motivation
+
+ Applications that communicate over the Internet often need to prevent
+ eavesdropping, tampering, or forgery of their communications. The
+ Transport Layer Security (TLS) protocol provides this kind of
+ communications security over the Internet, using channel encryption.
+
+ The security properties of encryption systems depend strongly on the
+ keys that they use. If secret keys are revealed, or if public keys
+ can be replaced by fake keys (that is, a key not corresponding to the
+ entity identified in the certificate), these systems provide little
+ or no security.
+
+ TLS uses certificates to bind keys and names. A certificate combines
+ a published key with other information such as the name of the
+ service that uses the key, and this combination is digitally signed
+ by another key. Having a key in a certificate is only helpful if one
+ trusts the other key that signed the certificate. If that other key
+ was itself revealed or substituted, then its signature is worthless
+ in proving anything about the first key.
+
+ On the Internet, this problem has been solved for years by entities
+ called "Certification Authorities" (CAs). CAs protect their secret
+ key vigorously, while supplying their public key to the software
+ vendors who build TLS clients. They then sign certificates, and
+ supply those to TLS servers. TLS client software uses a set of these
+ CA keys as "trust anchors" to validate the signatures on certificates
+ that the client receives from TLS servers. Client software typically
+ allows any CA to usefully sign any other certificate.
+
+ The public CA model upon which TLS has depended is fundamentally
+ vulnerable because it allows any of these CAs to issue a certificate
+ for any domain name. A single trusted CA that betrays its trust,
+ either voluntarily or by providing less-than-vigorous protection for
+ its secrets and capabilities, can undermine the security offered by
+ any certificates employed with TLS. This problem arises because a
+ compromised CA can issue a replacement certificate that contains a
+ fake key. Recent experiences with compromises of CAs or their
+ trusted partners have led to very serious security problems, such as
+ the governments of multiple countries attempting to wiretap and/or
+ subvert major TLS-protected web sites trusted by millions of users.
+
+
+
+Hoffman & Schlyter Standards Track [Page 3]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ The DNS Security Extensions (DNSSEC) provide a similar model that
+ involves trusted keys signing the information for untrusted keys.
+ However, DNSSEC provides three significant improvements. Keys are
+ tied to names in the Domain Name System (DNS), rather than to
+ arbitrary identifying strings; this is more convenient for Internet
+ protocols. Signed keys for any domain are accessible online through
+ a straightforward query using the standard DNSSEC protocol, so there
+ is no problem distributing the signed keys. Most significantly, the
+ keys associated with a domain name can only be signed by a key
+ associated with the parent of that domain name; for example, the keys
+ for "example.com" can only be signed by the keys for "com", and the
+ keys for "com" can only be signed by the DNS root. This prevents an
+ untrustworthy signer from compromising anyone's keys except those in
+ their own subdomains. Like TLS, DNSSEC relies on public keys that
+ come built into the DNSSEC client software, but these keys come only
+ from a single root domain rather than from a multiplicity of CAs.
+
+ DNS-Based Authentication of Named Entities (DANE) offers the option
+ to use the DNSSEC infrastructure to store and sign keys and
+ certificates that are used by TLS. DANE is envisioned as a
+ preferable basis for binding public keys to DNS names, because the
+ entities that vouch for the binding of public key data to DNS names
+ are the same entities responsible for managing the DNS names in
+ question. While the resulting system still has residual security
+ vulnerabilities, it restricts the scope of assertions that can be
+ made by any entity, consistent with the naming scope imposed by the
+ DNS hierarchy. As a result, DANE embodies the security "principle of
+ least privilege" that is lacking in the current public CA model.
+
+1.2. Securing the Association of a Domain Name with a Server's
+ Certificate
+
+ A TLS client begins a connection by exchanging messages with a TLS
+ server. For many application protocols, it looks up the server's
+ name using the DNS to get an Internet Protocol (IP) address
+ associated with the name. It then begins a connection to a
+ particular port at that address, and sends an initial message there.
+ However, the client does not yet know whether an adversary is
+ intercepting and/or altering its communication before it reaches the
+ TLS server. It does not even know whether the real TLS server
+ associated with that domain name has ever received its initial
+ messages.
+
+ The first response from the server in TLS may contain a certificate.
+ In order for the TLS client to authenticate that it is talking to the
+ expected TLS server, the client must validate that this certificate
+ is associated with the domain name used by the client to get to the
+ server. Currently, the client must extract the domain name from the
+
+
+
+Hoffman & Schlyter Standards Track [Page 4]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ certificate and must successfully validate the certificate, including
+ chaining to a trust anchor.
+
+ There is a different way to authenticate the association of the
+ server's certificate with the intended domain name without trusting
+ an external CA. Given that the DNS administrator for a domain name
+ is authorized to give identifying information about the zone, it
+ makes sense to allow that administrator to also make an authoritative
+ binding between the domain name and a certificate that might be used
+ by a host at that domain name. The easiest way to do this is to use
+ the DNS, securing the binding with DNSSEC.
+
+ There are many use cases for such functionality. [RFC6394] lists the
+ ones to which the DNS RRtype in this document apply. [RFC6394] also
+ lists many requirements, most of which this document is believed to
+ meet. Section 5 covers the applicability of this document to the use
+ cases in detail. The protocol in this document can generally be
+ referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for
+ anything; it is just the name of the RRtype.)
+
+ This document applies to both TLS [RFC5246] and Datagram TLS (DTLS)
+ [RFC6347]. In order to make the document more readable, it mostly
+ only talks about "TLS", but in all cases, it means "TLS or DTLS".
+ Although the references in this paragraph are to TLS and DTLS
+ version 1.2, the DANE TLSA protocol can also be used with earlier
+ versions of TLS and DTLS.
+
+ This document only relates to securely associating certificates for
+ TLS and DTLS with host names; retrieving certificates from DNS for
+ other protocols is handled in other documents. For example, keys for
+ IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are
+ covered in [RFC4255].
+
+1.3. Method for Securing Certificate Associations
+
+ A certificate association is formed from a piece of information
+ identifying a certificate and the domain name where the server
+ application runs. The combination of a trust anchor and a domain
+ name can also be a certificate association.
+
+ A DNS query can return multiple certificate associations, such as in
+ the case of a server that is changing from one certificate to another
+ (described in more detail in Appendix A.4).
+
+ This document only applies to PKIX [RFC5280] certificates, not
+ certificates of other formats.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 5]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ This document defines a secure method to associate the certificate
+ that is obtained from the TLS server with a domain name using DNS;
+ the DNS information needs to be protected by DNSSEC. Because the
+ certificate association was retrieved based on a DNS query, the
+ domain name in the query is by definition associated with the
+ certificate. Note that this document does not cover how to associate
+ certificates with domain names for application protocols that depend
+ on SRV, NAPTR, and similar DNS resource records. It is expected that
+ future documents will cover methods for making those associations,
+ and those documents may or may not need to update this one.
+
+ DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
+ cryptographic keys and digital signatures to provide authentication
+ of DNS data. Information that is retrieved from the DNS and that is
+ validated using DNSSEC is thereby proved to be the authoritative
+ data. The DNSSEC signature needs to be validated on all responses
+ that use DNSSEC in order to assure the proof of origin of the data.
+
+ This document does not specify how DNSSEC validation occurs because
+ there are many different proposals for how a client might get
+ validated DNSSEC results, such as from a DNSSEC-aware resolver that
+ is coded in the application, from a trusted DNSSEC resolver on the
+ machine on which the application is running, or from a trusted DNSSEC
+ resolver with which the application is communicating over an
+ authenticated and integrity-protected channel or network. This is
+ described in more detail in Section 7 of [RFC4033].
+
+ This document only relates to getting the DNS information for the
+ certificate association securely using DNSSEC; other secure DNS
+ mechanisms are out of scope.
+
+1.4. Terminology
+
+ 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].
+
+ This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
+ terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13
+ [RFC1034] [RFC1035], respectively, for these terms. In addition,
+ terms related to TLS-protected application services and DNS names are
+ taken from [RFC6125].
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 6]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+2. The TLSA Resource Record
+
+ The TLSA DNS resource record (RR) is used to associate a TLS server
+ certificate or public key with the domain name where the record is
+ found, thus forming a "TLSA certificate association". The semantics
+ of how the TLSA RR is interpreted are given later in this document.
+
+ The type value for the TLSA RR type is defined in Section 7.1.
+
+ The TLSA RR is class independent.
+
+ The TLSA RR has no special Time to Live (TTL) requirements.
+
+2.1. TLSA RDATA Wire Format
+
+ The RDATA for a TLSA RR consists of a one-octet certificate usage
+ field, a one-octet selector field, a one-octet matching type field,
+ and the certificate association data field.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cert. Usage | Selector | Matching Type | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
+ / /
+ / Certificate Association Data /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1. The Certificate Usage Field
+
+ A one-octet value, called "certificate usage", specifies the provided
+ association that will be used to match the certificate presented in
+ the TLS handshake. This value is defined in a new IANA registry (see
+ Section 7.2) in order to make it easier to add additional certificate
+ usages in the future. The certificate usages defined in this
+ document are:
+
+ 0 -- Certificate usage 0 is used to specify a CA certificate, or
+ the public key of such a certificate, that MUST be found in any of
+ the PKIX certification paths for the end entity certificate given
+ by the server in TLS. This certificate usage is sometimes
+ referred to as "CA constraint" because it limits which CA can be
+ used to issue certificates for a given service on a host. The
+ presented certificate MUST pass PKIX certification path
+ validation, and a CA certificate that matches the TLSA record MUST
+ be included as part of a valid certification path. Because this
+ certificate usage allows both trust anchors and CA certificates,
+
+
+
+Hoffman & Schlyter Standards Track [Page 7]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ the certificate might or might not have the basicConstraints
+ extension present.
+
+ 1 -- Certificate usage 1 is used to specify an end entity
+ certificate, or the public key of such a certificate, that MUST be
+ matched with the end entity certificate given by the server in
+ TLS. This certificate usage is sometimes referred to as "service
+ certificate constraint" because it limits which end entity
+ certificate can be used by a given service on a host. The target
+ certificate MUST pass PKIX certification path validation and MUST
+ match the TLSA record.
+
+ 2 -- Certificate usage 2 is used to specify a certificate, or the
+ public key of such a certificate, that MUST be used as the trust
+ anchor when validating the end entity certificate given by the
+ server in TLS. This certificate usage is sometimes referred to as
+ "trust anchor assertion" and allows a domain name administrator to
+ specify a new trust anchor -- for example, if the domain issues
+ its own certificates under its own CA that is not expected to be
+ in the end users' collection of trust anchors. The target
+ certificate MUST pass PKIX certification path validation, with any
+ certificate matching the TLSA record considered to be a trust
+ anchor for this certification path validation.
+
+ 3 -- Certificate usage 3 is used to specify a certificate, or the
+ public key of such a certificate, that MUST match the end entity
+ certificate given by the server in TLS. This certificate usage is
+ sometimes referred to as "domain-issued certificate" because it
+ allows for a domain name administrator to issue certificates for a
+ domain without involving a third-party CA. The target certificate
+ MUST match the TLSA record. The difference between certificate
+ usage 1 and certificate usage 3 is that certificate usage 1
+ requires that the certificate pass PKIX validation, but PKIX
+ validation is not tested for certificate usage 3.
+
+ The certificate usages defined in this document explicitly only apply
+ to PKIX-formatted certificates in DER encoding [X.690]. If TLS
+ allows other formats later, or if extensions to this RRtype are made
+ that accept other formats for certificates, those certificates will
+ need their own certificate usage values.
+
+2.1.2. The Selector Field
+
+ A one-octet value, called "selector", specifies which part of the TLS
+ certificate presented by the server will be matched against the
+ association data. This value is defined in a new IANA registry (see
+ Section 7.3). The selectors defined in this document are:
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 8]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 0 -- Full certificate: the Certificate binary structure as defined
+ in [RFC5280]
+
+ 1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined
+ in [RFC5280]
+
+ (Note that the use of "selector" in this document is completely
+ unrelated to the use of "selector" in DomainKeys Identified Mail
+ (DKIM) [RFC6376].)
+
+2.1.3. The Matching Type Field
+
+ A one-octet value, called "matching type", specifies how the
+ certificate association is presented. This value is defined in a new
+ IANA registry (see Section 7.4). The types defined in this document
+ are:
+
+ 0 -- Exact match on selected content
+
+ 1 -- SHA-256 hash of selected content [RFC6234]
+
+ 2 -- SHA-512 hash of selected content [RFC6234]
+
+ If the TLSA record's matching type is a hash, having the record use
+ the same hash algorithm that was used in the signature in the
+ certificate (if possible) will assist clients that support a small
+ number of hash algorithms.
+
+2.1.4. The Certificate Association Data Field
+
+ This field specifies the "certificate association data" to be
+ matched. These bytes are either raw data (that is, the full
+ certificate or its SubjectPublicKeyInfo, depending on the selector)
+ for matching type 0, or the hash of the raw data for matching types 1
+ and 2. The data refers to the certificate in the association, not to
+ the TLS ASN.1 Certificate object.
+
+2.2. TLSA RR Presentation Format
+
+ The presentation format of the RDATA portion (as defined in
+ [RFC1035]) is as follows:
+
+ o The certificate usage field MUST be represented as an 8-bit
+ unsigned integer.
+
+ o The selector field MUST be represented as an 8-bit unsigned
+ integer.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 9]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ o The matching type field MUST be represented as an 8-bit unsigned
+ integer.
+
+ o The certificate association data field MUST be represented as a
+ string of hexadecimal characters. Whitespace is allowed within
+ the string of hexadecimal characters, as described in [RFC1035].
+
+2.3. TLSA RR Examples
+
+ In the following examples, the domain name is formed using the rules
+ in Section 3.
+
+ An example of a hashed (SHA-256) association of a PKIX CA
+ certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
+ 7983a1d16e8a410e4561cb106618e971 )
+
+ An example of a hashed (SHA-512) subject public key association of a
+ PKIX end entity certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 1 1 2 92003ba34942dc74152e2f2c408d29ec
+ a5a520e7f2e06bb944f4dca346baf63c
+ 1b177615d466f6c4b71c216a50292bd5
+ 8c9ebdd2f74e38fe51ffd48c43326cbc )
+
+ An example of a full certificate association of a PKIX end entity
+ certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 3 0 0 30820307308201efa003020102020... )
+
+3. Domain Names for TLSA Certificate Associations
+
+ Unless there is a protocol-specific specification that is different
+ than this one, TLSA resource records are stored at a prefixed DNS
+ domain name. The prefix is prepared in the following manner:
+
+ 1. The decimal representation of the port number on which a TLS-
+ based service is assumed to exist is prepended with an underscore
+ character ("_") to become the left-most label in the prepared
+ domain name. This number has no leading zeros.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 10]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 2. The protocol name of the transport on which a TLS-based service
+ is assumed to exist is prepended with an underscore character
+ ("_") to become the second left-most label in the prepared domain
+ name. The transport names defined for this protocol are "tcp",
+ "udp", and "sctp".
+
+ 3. The base domain name is appended to the result of step 2 to
+ complete the prepared domain name. The base domain name is the
+ fully qualified DNS domain name [RFC1035] of the TLS server, with
+ the additional restriction that every label MUST meet the rules
+ of [RFC0952]. The latter restriction means that, if the query is
+ for an internationalized domain name, it MUST use the A-label
+ form as defined in [RFC5890].
+
+ For example, to request a TLSA resource record for an HTTP server
+ running TLS on port 443 at "www.example.com",
+ "_443._tcp.www.example.com" is used in the request. To request a
+ TLSA resource record for an SMTP server running the STARTTLS protocol
+ on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
+ used.
+
+4. Use of TLSA Records in TLS
+
+ Section 2.1 of this document defines the mandatory matching rules for
+ the data from the TLSA certificate associations and the certificates
+ received from the TLS server.
+
+ The TLS session that is to be set up MUST be for the specific port
+ number and transport name that was given in the TLSA query.
+
+ Some specifications for applications that run over TLS, such as
+ [RFC2818] for HTTP, require that the server's certificate have a
+ domain name that matches the host name expected by the client. Some
+ specifications, such as [RFC6125], detail how to match the identity
+ given in a PKIX certificate with those expected by the user.
+
+ If a TLSA record has certificate usage 2, the corresponding TLS
+ server SHOULD send the certificate that is referenced just like it
+ currently sends intermediate certificates.
+
+4.1. Usable Certificate Associations
+
+ An implementation of this protocol makes a DNS query for TLSA
+ records, validates these records using DNSSEC, and uses the resulting
+ TLSA records and validation status to modify its responses to the TLS
+ server.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 11]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Determining whether a TLSA RRSet can be used MUST be based on the
+ DNSSEC validation state (as defined in [RFC4033]).
+
+ o A TLSA RRSet whose DNSSEC validation state is secure MUST be used
+ as a certificate association for TLS unless a local policy would
+ prohibit the use of the specific certificate association in the
+ secure TLSA RRSet.
+
+ o If the DNSSEC validation state on the response to the request for
+ the TLSA RRSet is bogus, this MUST cause TLS not to be started or,
+ if the TLS negotiation is already in progress, MUST cause the
+ connection to be aborted.
+
+ o A TLSA RRSet whose DNSSEC validation state is indeterminate or
+ insecure cannot be used for TLS and MUST be considered unusable.
+
+ Clients that validate the DNSSEC signatures themselves MUST use
+ standard DNSSEC validation procedures. Clients that rely on another
+ entity to perform the DNSSEC signature validation MUST use a secure
+ mechanism between themselves and the validator. Examples of secure
+ transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
+ and IPsec [RFC6071]. Note that it is not sufficient to use secure
+ transport to a DNS resolver that does not do DNSSEC signature
+ validation. See Section 8.3 for more security considerations related
+ to external validators.
+
+ If a certificate association contains a certificate usage, selector,
+ or matching type that is not understood by the TLS client, that
+ certificate association MUST be considered unusable. If the
+ comparison data for a certificate is malformed, the certificate
+ association MUST be considered unusable.
+
+ If a certificate association contains a matching type or certificate
+ association data that uses a cryptographic algorithm that is
+ considered too weak for the TLS client's policy, the certificate
+ association MUST be considered unusable.
+
+ If an application receives zero usable certificate associations from
+ a DNS request or from its cache, it processes TLS in the normal
+ fashion without any input from the TLSA records. If an application
+ receives one or more usable certificate associations, it attempts to
+ match each certificate association with the TLS server's end entity
+ certificate until a successful match is found. During the TLS
+ handshake, if none of the certificate associations matches the
+ certificate given by the TLS server, the TLS client MUST abort the
+ handshake.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 12]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ An attacker who is able to divert a user to a server under his
+ control is also likely to be able to block DNS requests from the user
+ or DNS responses being sent to the user. Thus, in order to achieve
+ any security benefit from certificate usage 0 or 1, an application
+ that sends a request for TLSA records needs to get either a valid
+ signed response containing TLSA records or verification that the
+ domain is insecure or indeterminate. If a request for a TLSA record
+ does not meet one of those two criteria but the application continues
+ with the TLS handshake anyway, the application has gotten no benefit
+ from TLSA and SHOULD NOT make any internal or external indication
+ that TLSA was applied. If an application has a configuration setting
+ that has turned on TLSA use, or has any indication that TLSA is in
+ use (regardless of whether or not this is configurable), that
+ application either MUST NOT start a TLS connection or it MUST abort a
+ TLS handshake if both of the two criteria above are not met.
+
+ The application can perform the TLSA lookup before initiating the TLS
+ handshake, or do it during the TLS handshake: the choice is up to the
+ client.
+
+5. TLSA and DANE Use Cases and Requirements
+
+ The different types of certificate associations defined in TLSA are
+ matched with various sections of [RFC6394]. The use cases from
+ Section 3 of [RFC6394] are covered in this document as follows:
+
+ 3.1 CA Constraints -- Implemented using certificate usage 0.
+
+ 3.2 Certificate Constraints -- Implemented using certificate usage 1.
+
+ 3.3 Trust Anchor Assertion and Domain-Issued Certificates --
+ Implemented using certificate usages 2 and 3, respectively.
+
+ The requirements from Section 4 of [RFC6394] are covered in this
+ document as follows:
+
+ Multiple Ports -- The TLSA records for different application services
+ running on a single host can be distinguished through the service
+ name and port number prefixed to the host name (see Section 3).
+
+ No Downgrade -- Section 4 specifies the conditions under which a
+ client can process and act upon TLSA records. Specifically, if
+ the DNSSEC status for the TLSA resource record set is determined
+ to be bogus, the TLS connection (if started) will fail.
+
+ Encapsulation -- Encapsulation is covered in the TLSA response
+ semantics.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 13]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Predictability -- The appendices of this specification provide
+ operational considerations and implementation guidance in order to
+ enable application developers to form a consistent interpretation
+ of the recommended client behavior.
+
+ Opportunistic Security -- If a client conformant to this
+ specification can reliably determine the presence of a TLSA
+ record, it will attempt to use this information. Conversely, if a
+ client can reliably determine the absence of any TLSA record, it
+ will fall back to processing TLS in the normal fashion. This is
+ discussed in Section 4.
+
+ Combination -- Multiple TLSA records can be published for a given
+ host name, thus enabling the client to construct multiple TLSA
+ certificate associations that reflect different assertions. No
+ support is provided to combine two TLSA certificate associations
+ in a single operation.
+
+ Roll-over -- TLSA records are processed in the normal manner within
+ the scope of the DNS protocol, including the TTL expiration of the
+ records. This ensures that clients will not latch onto assertions
+ made by expired TLSA records, and will be able to transition from
+ using one public key or certificate usage to another.
+
+ Simple Key Management -- The SubjectPublicKeyInfo selector in the
+ TLSA record provides a mode that enables a domain holder to only
+ have to maintain a single long-lived public/private key pair
+ without the need to manage certificates. Appendix A outlines the
+ usefulness and the potential downsides to using this mode.
+
+ Minimal Dependencies -- This specification relies on DNSSEC to
+ protect the origin authenticity and integrity of the TLSA resource
+ record set. Additionally, if DNSSEC validation is not performed
+ on the system that wishes to use TLSA certificate bindings, this
+ specification requires that the "last mile" be over a secure
+ transport. There are no other deployment dependencies for this
+ approach.
+
+ Minimal Options -- The operating modes map precisely to the DANE use
+ cases and requirements. DNSSEC use is mandatory in that this
+ specification encourages applications to use only those TLSA
+ records that are shown to be validated.
+
+ Wildcards -- Wildcards are covered in a limited manner in the TLSA
+ request syntax; see Appendix A.
+
+ Redirection -- Redirection is covered in the TLSA request syntax; see
+ Appendix A.
+
+
+
+Hoffman & Schlyter Standards Track [Page 14]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+6. Mandatory-to-Implement Features
+
+ TLS clients conforming to this specification MUST be able to
+ correctly interpret TLSA records with certificate usages 0, 1, 2,
+ and 3. TLS clients conforming to this specification MUST be able to
+ compare a certificate association with a certificate from the TLS
+ handshake using selector types 0 and 1, and matching type 0 (no hash
+ used) and matching type 1 (SHA-256), and SHOULD be able to make such
+ comparisons with matching type 2 (SHA-512).
+
+7. IANA Considerations
+
+ IANA has made the assignments in this section.
+
+ In the following sections, "RFC Required" was chosen for TLSA
+ certificate usages and "Specification Required" for selectors and
+ matching types because of the amount of detail that is likely to be
+ needed for implementers to correctly implement new certificate usages
+ as compared to new selectors and matching types.
+
+7.1. TLSA RRtype
+
+ This document uses a new DNS RR type, TLSA, whose value (52) was
+ allocated by IANA from the Resource Record (RR) TYPEs subregistry of
+ the Domain Name System (DNS) Parameters registry.
+
+7.2. TLSA Certificate Usages
+
+ This document creates a new registry, "TLSA Certificate Usages". The
+ registry policy is "RFC Required". The initial entries in the
+ registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 CA constraint RFC 6698
+ 1 Service certificate constraint RFC 6698
+ 2 Trust anchor assertion RFC 6698
+ 3 Domain-issued certificate RFC 6698
+ 4-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 15]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+7.3. TLSA Selectors
+
+ This document creates a new registry, "TLSA Selectors". The registry
+ policy is "Specification Required". The initial entries in the
+ registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 Full certificate RFC 6698
+ 1 SubjectPublicKeyInfo RFC 6698
+ 2-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+7.4. TLSA Matching Types
+
+ This document creates a new registry, "TLSA Matching Types". The
+ registry policy is "Specification Required". The initial entries in
+ the registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 No hash used RFC 6698
+ 1 SHA-256 RFC 6234
+ 2 SHA-512 RFC 6234
+ 3-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+8. Security Considerations
+
+ The security of the DNS RRtype described in this document relies on
+ the security of DNSSEC to verify that the TLSA record has not been
+ altered.
+
+ A rogue DNS administrator who changes the A, AAAA, and/or TLSA
+ records for a domain name can cause the client to go to an
+ unauthorized server that will appear authorized, unless the client
+ performs PKIX certification path validation and rejects the
+ certificate. That administrator could probably get a certificate
+ issued by some CA anyway, so this is not an additional threat.
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 16]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ If the authentication mechanism for adding or changing TLSA data in a
+ zone is weaker than the authentication mechanism for changing the A
+ and/or AAAA records, a man-in-the-middle who can redirect traffic to
+ his site may be able to impersonate the attacked host in TLS if he
+ can use the weaker authentication mechanism. A better design for
+ authenticating DNS would be to have the same level of authentication
+ used for all DNS additions and changes for a particular domain name.
+
+ Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-
+ middle for TLS clients. In these scenarios, the clients add a new
+ trust anchor whose private key is kept on the SSL proxy; the proxy
+ intercepts TLS requests, creates a new TLS session with the intended
+ host, and sets up a TLS session with the client using a certificate
+ that chains to the trust anchor installed in the client by the proxy.
+ In such environments, using TLSA records will prevent the SSL proxy
+ from functioning as expected because the TLS client will get a
+ certificate association from the DNS that will not match the
+ certificate that the SSL proxy uses with the client. The client,
+ seeing the proxy's new certificate for the supposed destination, will
+ not set up a TLS session.
+
+ Client treatment of any information included in the trust anchor is a
+ matter of local policy. This specification does not mandate that
+ such information be inspected or validated by the server's domain
+ name administrator.
+
+ If a server's certificate is revoked, or if an intermediate CA in a
+ chain between the server and a trust anchor has its certificate
+ revoked, a TLSA record with a certificate usage of 2 that matches the
+ revoked certificate would in essence override the revocation because
+ the client would treat that revoked certificate as a trust anchor and
+ thus not check its revocation status. Because of this, domain
+ administrators need to be responsible for being sure that the keys or
+ certificates used in TLSA records with a certificate usage of 2 are
+ in fact able to be used as reliable trust anchors.
+
+ Certificates that are delivered in TLSA with certificate usage 2
+ fundamentally change the way the TLS server's end entity certificate
+ is evaluated. For example, the server's certificate might chain to
+ an existing CA through an intermediate CA that has certain policy
+ restrictions, and the certificate would not pass those restrictions
+ and thus normally be rejected. That intermediate CA could issue
+ itself a new certificate without the policy restrictions and tell its
+ customers to use that certificate with certificate usage 2. This in
+ essence allows an intermediate CA to become a trust anchor for
+ certificates that the end user might have expected to chain to an
+ existing trust anchor.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 17]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ If an administrator wishes to stop using a TLSA record, the
+ administrator can simply remove it from the DNS. Normal clients will
+ stop using the TLSA record after the TTL has expired. Replay attacks
+ against the TLSA record are not possible after the expiration date on
+ the RRsig of the TLSA record that was removed.
+
+ Generators of TLSA records should be aware that the client's full
+ trust of a certificate association retrieved from a TLSA record may
+ be a matter of local policy. While such trust is limited to the
+ specific domain name, protocol, and port for which the TLSA query was
+ made, local policy may decline to accept the certificate (for reasons
+ such as weak cryptography), as is also the case with PKIX trust
+ anchors.
+
+8.1. Comparing DANE to Public CAs
+
+ As stated above, the security of the DNS RRtype described in this
+ document relies on the security of DNSSEC to verify that the TLSA
+ record has not been altered. This section describes where the
+ security of public CAs and the security of TLSA are similar and
+ different. This section applies equally to other security-related
+ DNS RRtypes such as keys for IPsec and SSH.
+
+ DNSSEC forms certificates (the binding of an identity to a key) by
+ combining a DNSKEY, DS, or DLV resource record with an associated
+ RRSIG record. These records then form a signing chain extending from
+ the client's trust anchors to the RR of interest.
+
+ Although the DNSSEC protocol does not enforce it, DNSKEYs are often
+ marked with a SEP flag indicating whether the key is a Zone Signing
+ Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the
+ zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
+ records. This allows KSKs to be stored offline.
+
+ The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
+ authenticate keys wrapped in PKIX certificates for a particular host
+ name, protocol, and port.
+
+ With the exception of the DLV RRtype, all of these certificates
+ constrain the keys they identify to names that are within the zone
+ signing the certificate. In order for a domain's DLV resource
+ records to be honored, the domain must be configured as a DLV domain,
+ and the domain's DNSKEYs must be configured as trust anchors or be
+ authentic [RFC5074].
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 18]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.1.1. Risk of Key Compromise
+
+ The risk that a given certificate that has a valid signing chain is
+ fake is related to the number of keys that can contribute to the
+ validation of the certificate, the quality of protection each private
+ key receives, the value of each key to an attacker, and the value of
+ falsifying the certificate.
+
+ DNSSEC allows any set of domains to be configured as trust anchors
+ and/or DLVs, but most clients are likely to use the root zone as
+ their only trust anchor. Also, because a given DNSKEY can only sign
+ resource records for that zone, the number of private keys capable of
+ compromising a given TLSA resource record is limited to the number of
+ zones between the TLSA resource record and the nearest trust anchor,
+ plus any configured DLV domains. Typically, this will be six keys,
+ half of which will be KSKs.
+
+ PKIX only describes how to validate a certificate based on a client-
+ chosen set of trust anchors, but says nothing about how many trust
+ anchors to use or how they should be constrained. As currently
+ deployed, most PKIX clients use a large number of trust anchors
+ provided with the client or operating system software. These trust
+ anchors are selected carefully, but with a desire for broad
+ interoperability. The trust anchors and CA certificates for public
+ CAs rarely have name constraints applied.
+
+ A combination of technical protections, process controls, and
+ personnel experience contribute to the quality of security that keys
+ receive.
+
+ o The security surrounding DNSSEC DNSKEYs varies significantly. The
+ KSK/ZSK split allows the KSK to be stored offline and protected
+ more carefully than the ZSK, but not all domains do so. The
+ security applied to a zone's DNSKEYs should be proportional to the
+ value of the domain, but that is difficult to estimate. For
+ example, the root DNSKEY has protections and controls comparable
+ to or exceeding those of public CAs. On the other end of the
+ spectrum, small domains might provide no more protection to their
+ keys than they do to their other data.
+
+ o The security surrounding public CAs also varies. However, due to
+ financial incentives and standards imposed by clients for
+ acceptance into their trust anchor stores, CAs generally employ
+ security experts and protect their keys carefully, though highly
+ public compromises have occurred.
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 19]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.1.2. Impact of Key Compromise
+
+ The impact of a key compromise differs significantly between the two
+ models.
+
+ o DNSKEYs are inherently limited in what they can sign, so a
+ compromise of the DNSKEY for "example.com" provides no avenue of
+ attack against "example.org". Even the impact of a compromise of
+ .com's DNSKEY, while considerable, would be limited to .com
+ domains. Only the compromise of the root DNSKEY would have the
+ equivalent impact of an unconstrained public CA.
+
+ o Public CAs are not typically constrained in what names they can
+ sign, and therefore a compromise of even one CA allows the
+ attacker to generate a certificate for any name in the DNS. A
+ domain holder can get a certificate from any willing CA, or even
+ multiple CAs simultaneously, making it impossible for a client to
+ determine whether the certificate it is validating is legitimate
+ or fraudulent.
+
+ Because a TLSA certificate association is constrained to its
+ associated name, protocol, and port, the PKIX certificate is
+ similarly constrained, even if its public CAs signing the certificate
+ (if any) are not.
+
+8.1.3. Detection of Key Compromise
+
+ If a key is compromised, rapid and reliable detection is important in
+ order to limit the impact of the compromise. In this regard, neither
+ model prevents an attacker from near-invisibly attacking their
+ victim, provided that the necessary keys are compromised.
+
+ If a public CA is compromised, only the victim will see the
+ fraudulent certificate, as there is typically no publicly accessible
+ directory of all the certificates issued by a CA that can be
+ inspected. DNS resource records are typically published publicly.
+ However, the attacker could also allow the uncompromised records to
+ be published to the Internet as usual but provide a compromised DNS
+ view to the victim to achieve the same effect.
+
+8.1.4. Spoofing Hostnames
+
+ Some CAs implement technical controls to ensure that certificates are
+ not issued to domains with names similar to domains that are popular
+ and prone to attack. Of course, an attacker can attempt to
+ circumvent this restriction by finding a CA willing to issue the
+ certificate anyway. However, by using DNSSEC and TLSA, the attacker
+ can circumvent this check completely.
+
+
+
+Hoffman & Schlyter Standards Track [Page 20]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.2. DNS Caching
+
+ Implementations of this protocol rely heavily on the DNS, and are
+ thus prone to security attacks based on the deliberate
+ mis-association of TLSA records and DNS names. Implementations need
+ to be cautious in assuming the continuing validity of an association
+ between a TLSA record and a DNS name.
+
+ In particular, implementations SHOULD rely on their DNS resolver for
+ confirmation of an association between a TLSA record and a DNS name,
+ rather than caching the result of previous domain name lookups. Many
+ platforms already can cache domain name lookups locally when
+ appropriate, and they SHOULD be configured to do so. It is proper
+ for these lookups to be cached, however, only when the TTL (Time To
+ Live) information reported by the DNS makes it likely that the cached
+ information will remain useful.
+
+ If implementations cache the results of domain name lookups in order
+ to achieve a performance improvement, they MUST observe the TTL
+ information reported by DNS. Implementations that fail to follow
+ this rule could be spoofed or have access denied when a previously
+ accessed server's TLSA record changes, such as during a certificate
+ rollover.
+
+8.3. External DNSSEC Validators
+
+ Due to a lack of DNSSEC support in the most commonly deployed stub
+ resolvers today, some ISPs have begun checking DNSSEC in the
+ recursive resolvers they provide to their customers, setting the
+ Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could
+ use that data, ignoring the fact that the DNSSEC data has been
+ validated externally. Because there is typically no authentication
+ of the recursive resolver or integrity protection of the data and AD
+ flag between the client and the recursive resolver, this can be
+ trivially spoofed by an attacker.
+
+ However, even with secure communications between a host and the
+ external validating resolver, there is a risk that the external
+ validator could become compromised. Nothing prevents a compromised
+ external DNSSEC validator from claiming that all the records it
+ provides are secure, even if the data is falsified, unless the client
+ checks the DNSSEC data itself (rendering the external validator
+ unnecessary).
+
+ For this reason, DNSSEC validation is best performed on-host, even
+ when a secure path to an external validator is available.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 21]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+9. Acknowledgements
+
+ Many of the ideas in this document have been discussed over many
+ years. More recently, the ideas have been discussed by the authors
+ and others in a more focused fashion. In particular, some of the
+ ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
+ Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
+ Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
+ Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
+ Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
+ Gilmore, and Murray Kucherawy.
+
+ This document has also been greatly helped by many active
+ participants of the DANE Working Group.
+
+10. References
+
+10.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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, May 2008.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 22]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, March 2011.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+10.2. Informative References
+
+ [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+ host table specification", RFC 952, October 1985.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
+ ( SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
+ Material in DNS", RFC 4025, March 2005.
+
+ [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
+ Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
+ January 2006.
+
+ [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ RFC 4641, September 2006.
+
+ [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+ November 2007.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, August 2010.
+
+ [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
+ Extensions: Extension Definitions", RFC 6066,
+ January 2011.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 23]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
+ Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
+ February 2011.
+
+ [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
+
+ [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+ "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+ September 2011.
+
+ [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
+ Authentication of Named Entities (DANE)", RFC 6394,
+ October 2011.
+
+ [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 24]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Appendix A. Operational Considerations for Deploying TLSA Records
+
+A.1. Creating TLSA Records
+
+ When creating TLSA records, care must be taken to avoid
+ misconfigurations. Section 4 of this document states that a TLSA
+ RRSet whose validation state is secure MUST be used. This means that
+ the existence of such a RRSet effectively disables other forms of
+ name and path validation. A misconfigured TLSA RRSet will
+ effectively disable access to the TLS server for all conforming
+ clients, and this document does not provide any means of making a
+ gradual transition to using TLSA.
+
+ When creating TLSA records with certificate usage 0 (CA certificate)
+ or usage 2 (trust anchor), one needs to understand the implications
+ when choosing between selector type 0 (Full certificate) and 1
+ (SubjectPublicKeyInfo). A careful choice is required because
+ different methods for building trust chains are used by different TLS
+ clients. The following outlines the cases that one ought to be aware
+ of and discusses the implications of the choice of selector type.
+
+ Certificate usage 2 is not affected by the different types of chain
+ building when the end entity certificate is the same as the trust
+ anchor certificate.
+
+A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains
+
+ TLS clients can implement their own chain-building code rather than
+ rely on the chain presented by the TLS server. This means that,
+ except for the end entity certificate, any certificate presented in
+ the suggested chain might or might not be present in the final chain
+ built by the client.
+
+ Certificates that the client can use to replace certificates from the
+ original chain include:
+
+ o Client's trust anchors
+
+ o Certificates cached locally
+
+ o Certificates retrieved from a URI listed in an Authority
+ Information Access X.509v3 extension
+
+ CAs frequently reissue certificates with different validity periods,
+ signature algorithms (such as a different hash algorithm in the
+ signature algorithm), CA key pairs (such as for a cross-certificate),
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 25]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ or PKIX extensions where the public key and subject remain the same.
+ These reissued certificates are the certificates that the TLS client
+ can use in place of an original certificate.
+
+ Clients are known to exchange or remove certificates that could cause
+ TLSA certificate associations that rely on the full certificate to
+ fail. For example:
+
+ o The client considers the signature algorithm of a certificate to
+ no longer be sufficiently secure.
+
+ o The client might not have an associated root certificate in its
+ trust store and instead uses a cross-certificate with an identical
+ subject and public key.
+
+A.1.2. Choosing a Selector Type
+
+ In this section, "false-negative failure" means that a client will
+ not accept the TLSA certificate association for a certificate
+ designated by the DNS administrator. Also, "false-positive
+ acceptance" means that the client accepts a TLSA association for a
+ certificate that is not designated by the DNS administrator.
+
+A.1.2.1. Selector Type 0 (Full Certificate)
+
+ The "Full certificate" selector provides the most precise
+ specification of a TLSA certificate association, capturing all
+ fields of the PKIX certificate. For a DNS administrator, the best
+ course to avoid false-negative failures in the client when using this
+ selector is:
+
+ 1. If a CA issued a replacement certificate, don't associate to CA
+ certificates that have a signature algorithm with a hash that is
+ considered weak by local policy.
+
+ 2. Determine how common client applications process the TLSA
+ certificate association using a fresh client installation -- that
+ is, with the local certificate cache empty.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 26]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo)
+
+ A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
+ some false-negative failures caused by trust-chain-building
+ algorithms used in clients.
+
+ One specific use case ought to be noted: creating a TLSA certificate
+ association to CA certificate I1 that directly signed end entity
+ certificate S1 of the server. The case can be illustrated by the
+ following graph:
+
+ +----+ +----+
+ | I1 | | I2 |
+ +----+ +----+
+ | |
+ v v
+ +----+ +----+
+ | S1 | | S1 |
+ +----+ +----+
+ Certificate chain sent by A different validation path
+ server in TLS handshake built by the TLS client
+
+ I2 is a reissued version of CA certificate I1 (that is, it has a
+ different hash in its signature algorithm).
+
+ In the above scenario, both certificates I1 and I2 that sign S1 need
+ to have identical SubjectPublicKeyInfo fields because the key used to
+ sign S1 is fixed. An association to SubjectPublicKeyInfo (selector
+ type 1) will always succeed in such a case, but an association with a
+ full certificate (selector type 0) might not work due to a false-
+ negative failure.
+
+ The attack surface is a bit broader compared to the "Full
+ certificate" selector: the DNS administrator might unintentionally
+ specify an association that would lead to false-positive acceptance.
+
+ o The administrator must know or trust that the CA does not engage
+ in bad practices, such as not sharing the key of I1 for unrelated
+ CA certificates (which would lead to trust-chain redirection). If
+ possible, the administrator ought to review all CA certificates
+ that have the same SubjectPublicKeyInfo field.
+
+ o The administrator ought to understand whether some PKIX extension
+ may adversely affect security of the association. If possible,
+ administrators ought to review all CA certificates that share the
+ SubjectPublicKeyInfo.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 27]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ o The administrator ought to understand that any CA could, in the
+ future, issue a certificate that contains the same
+ SubjectPublicKeyInfo. Therefore, new chains can crop up in the
+ future without any warning.
+
+ Using the SubjectPublicKeyInfo selector for association with a
+ certificate in a chain above I1 needs to be decided on a case-by-case
+ basis: there are too many possibilities based on the issuing CA's
+ practices. Unless the full implications of such an association are
+ understood by the administrator, using selector type 0 is a better
+ option from a security perspective.
+
+A.2. Provisioning TLSA Records in DNS
+
+A.2.1. Provisioning TLSA Records with Aliases
+
+ The TLSA resource record is not special in the DNS; it acts exactly
+ like any other RRtype where the queried name has one or more labels
+ prefixed to the base name, such as the SRV RRtype [RFC2782]. This
+ affects the way that the TLSA resource record is used when aliasing
+ in the DNS.
+
+ Note that the IETF sometimes adds new types of aliasing in the DNS.
+ If that happens in the future, those aliases might affect TLSA
+ records, hopefully in a good way.
+
+A.2.1.1. Provisioning TLSA Records with CNAME Records
+
+ Using CNAME to alias in DNS only aliases from the exact name given,
+ not any zones below the given name. For example, assume that a zone
+ file has only the following:
+
+ sub1.example.com. IN CNAME sub2.example.com.
+
+ In this case, a request for the A record at "bottom.sub1.example.com"
+ would not return any records because the CNAME given only aliases the
+ name given. Assume, instead, the zone file has the following:
+
+ sub3.example.com. IN CNAME sub4.example.com.
+ bottom.sub3.example.com. IN CNAME bottom.sub4.example.com.
+
+ In this case, a request for the A record at bottom.sub3.example.com
+ would in fact return whatever value for the A record exists at
+ bottom.sub4.example.com.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 28]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Application implementations and full-service resolvers request DNS
+ records using libraries that automatically follow CNAME (and DNAME)
+ aliasing. This allows hosts to put TLSA records in their own zones
+ or to use CNAME to do redirection.
+
+ If the owner of the original domain wants a TLSA record for the same,
+ they simply enter it under the defined prefix:
+
+ ; No TLSA record in target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+
+ If the owner of the original domain wants to have the target domain
+ host the TLSA record, the original domain uses a CNAME record:
+
+ ; TLSA record for original domain has CNAME to target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com.
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
+
+ Note that it is acceptable for both the original domain and the
+ target domain to have TLSA records, but the two records are
+ unrelated. Consider the following:
+
+ ; TLSA record in both the original and target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
+
+ In this example, someone looking for the TLSA record for
+ sub5.example.com would always get the record whose value starts with
+ "308202c5308201ab"; the TLSA record whose value starts with
+ "ac49d9ba4570ac49" would only be sought by someone who is looking for
+ the TLSA record for sub6.example.com, and never for sub5.example.com.
+ Note that deploying different certificates for multiple services
+ located at a shared TLS listener often requires the use of TLS SNI
+ (Server Name Indication) [RFC6066].
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 29]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Note that these methods use the normal method for DNS aliasing using
+ CNAME: the DNS client requests the record type that they actually
+ want.
+
+A.2.1.2. Provisioning TLSA Records with DNAME Records
+
+ Using DNAME records allows a zone owner to alias an entire subtree of
+ names below the name that has the DNAME. This allows the wholesale
+ aliasing of prefixed records such as those used by TLSA, SRV, and so
+ on without aliasing the name itself. However, because DNAME can only
+ be used for subtrees of a base name, it is rarely used to alias
+ individual hosts that might also be running TLS.
+
+ ; TLSA record in target domain, visible in original domain via DNAME
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
+
+A.2.1.3. Provisioning TLSA Records with Wildcards
+
+ Wildcards are generally not terribly useful for RRtypes that require
+ prefixing because one can only wildcard at a layer below the host
+ name. For example, if one wants to have the same TLSA record for
+ every TCP port for www.example.com, the result might be:
+
+ *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
+
+ This is possibly useful in some scenarios where the same service is
+ offered on many ports or the same certificate and/or key is used for
+ all services on a host. Note that the domain being searched for is
+ not necessarily related to the domain name found in the certificate,
+ so a certificate with a wildcard in it is not searched for using a
+ wildcard in the search request.
+
+A.3. Securing the Last Hop
+
+ As described in Section 4, an application processing TLSA records
+ must know the DNSSEC validity of those records. There are many ways
+ for the application to determine this securely, and this
+ specification does not mandate any single method.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 30]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Some common methods for an application to know the DNSSEC validity of
+ TLSA records include:
+
+ o The application can have its own DNS resolver and DNSSEC
+ validation stack.
+
+ o The application can communicate through a trusted channel (such as
+ requests to the operating system under which the application is
+ running) to a local DNS resolver that does DNSSEC validation.
+
+ o The application can communicate through a secured channel (such as
+ requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+ DNS resolver that does DNSSEC validation.
+
+ o The application can communicate through a secured channel (such as
+ requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+ DNS resolver that does not do DNSSEC validation, but gets
+ responses through a secured channel from a different DNS resolver
+ that does DNSSEC validation.
+
+A.4. Handling Certificate Rollover
+
+ Certificate rollover is handled in much the same way as for rolling
+ DNSSEC zone signing keys using the pre-publish key rollover method
+ [RFC4641]. Suppose example.com has a single TLSA record for a TLS
+ service on TCP port 990:
+
+ _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+
+ To start the rollover process, obtain or generate the new certificate
+ or SubjectPublicKeyInfo to be used after the rollover and generate
+ the new TLSA record. Add that record alongside the old one:
+
+ _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+ _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+ After the new records have propagated to the authoritative
+ nameservers and the TTL of the old record has expired, switch to the
+ new certificate on the TLS server. Once this has occurred, the old
+ TLSA record can be removed:
+
+ _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+ This completes the certificate rollover.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 31]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Appendix B. Pseudocode for Using TLSA
+
+ This appendix describes, in pseudocode format, the interactions given
+ earlier in this specification. If the steps below disagree with the
+ text earlier in the document, the steps earlier in the document ought
+ to be considered correct and this text incorrect.
+
+ Note that this pseudocode is more strict than the normative text.
+ For instance, it forces an order on the evaluation of criteria, which
+ is not mandatory from the normative text.
+
+B.1. Helper Functions
+
+ // implement the function for exiting
+ function Finish (F) = {
+ if (F == ABORT_TLS) {
+ abort the TLS handshake or prevent TLS from starting
+ exit
+ }
+
+ if (F == NO_TLSA) {
+ fall back to non-TLSA certificate validation
+ exit
+ }
+
+ if (F == ACCEPT) {
+ accept the TLS connection
+ exit
+ }
+
+ // unreachable
+ }
+
+ // implement the selector function
+ function Select (S, X) = {
+ // Full certificate
+ if (S == 0) {
+ return X in DER encoding
+ }
+
+ // SubjectPublicKeyInfo
+ if (S == 1) {
+ return X.SubjectPublicKeyInfo in DER encoding
+ }
+
+ // unreachable
+ }
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 32]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ // implement the matching function
+ function Match (M, X, Y) {
+ // Exact match on selected content
+ if (M == 0) {
+ return (X == Y)
+ }
+
+ // SHA-256 hash of selected content
+ if (M == 1) {
+ return (SHA-256(X) == Y)
+ }
+
+ // SHA-512 hash of selected content
+ if (M == 2) {
+ return (SHA-512(X) == Y)
+ }
+
+ // unreachable
+ }
+
+B.2. Main TLSA Pseudocode
+
+ TLS connect using [transport] to [name] on [port] and receiving end
+ entity cert C for the TLS server:
+
+ (TLSArecords, ValState) = DNSSECValidatedLookup(
+ domainname=_[port]._[transport].[name], RRtype=TLSA)
+
+ // check for states that would change processing
+ if (ValState == BOGUS) {
+ Finish(ABORT_TLS)
+ }
+ if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
+ Finish(NO_TLSA)
+ }
+ // if here, ValState must be SECURE
+
+ for each R in TLSArecords {
+ // unusable records include unknown certUsage, unknown
+ // selectorType, unknown matchingType, erroneous RDATA, and
+ // prohibited by local policy
+ if (R is unusable) {
+ remove R from TLSArecords
+ }
+ }
+ if (length(TLSArecords) == 0) {
+ Finish(NO_TLSA)
+ }
+
+
+
+Hoffman & Schlyter Standards Track [Page 33]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ // A TLS client might have multiple trust anchors that it might use
+ // when validating the TLS server's end entity (EE) certificate.
+ // Also, there can be multiple PKIX certification paths for the
+ // certificates given by the server in TLS. Thus, there are
+ // possibly many chains that might need to be tested during
+ // PKIX path validation.
+
+ for each R in TLSArecords {
+
+ // pass PKIX certificate validation and chain through a CA cert
+ // that comes from TLSA
+ if (R.certUsage == 0) {
+ for each PKIX certification path H {
+ if (C passes PKIX certification path validation in H) {
+ for each D in H {
+ if ((D is a CA certificate) and
+ Match(R.matchingType, Select(R.selectorType, D),
+ R.cert)) {
+ Finish(ACCEPT)
+ }
+ }
+ }
+ }
+ }
+
+ // pass PKIX certificate validation and match EE cert from TLSA
+ if (R.certUsage == 1) {
+ for each PKIX certification path H {
+ if ((C passes PKIX certificate validation in H) and
+ Match(R.matchingType, Select(R.selectorType, C),
+ R.cert)) {
+ Finish(ACCEPT)
+ }
+ }
+ }
+
+ // pass PKIX certification validation using TLSA record as the
+ // trust anchor
+ if (R.certUsage == 2) {
+ // the following assert() is merely a formalization of the
+ // "trust anchor" condition for a certificate D matching R
+ assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 34]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ for each PKIX certification path H that has certificate D
+ matching R as the trust anchor {
+ if (C passes PKIX validation in H) {
+ Finish(ACCEPT);
+ }
+ }
+ }
+
+ // match the TLSA record and the TLS certificate
+ if (R.certUsage == 3) {
+ if Match(R.matchingType, Select(R.selectorType, C), R.cert)
+ Finish(ACCEPT)
+ }
+ }
+
+ }
+
+ // if here, then none of the TLSA records ended in "Finish(ACCEPT)"
+ // so abort TLS
+ Finish(ABORT_TLS)
+
+Appendix C. Examples
+
+ The following are examples of self-signed certificates that have been
+ generated with various selectors and matching types. They were
+ generated with one piece of software, and validated by an individual
+ using other tools.
+
+ S = Selector
+ M = Matching Type
+
+ S M Association Data
+ 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
+ 4886F70D0101050500306C310B3009060355040613024E4C31163014
+ 0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
+ 071309416D7374657264616D310C300A060355040A13034F53333123
+ 30210603550403131A64616E652E6B6965762E70726163746963756D
+ 2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
+ 303131333136353730335A306C310B3009060355040613024E4C3116
+ 30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
+ 5504071309416D7374657264616D310C300A060355040A13034F5333
+ 312330210603550403131A64616E652E6B6965762E70726163746963
+ 756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
+ 0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
+ 7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
+ 6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
+ 281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
+ C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
+
+
+
+Hoffman & Schlyter Standards Track [Page 35]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
+ 2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
+ 37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
+ FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
+ 4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
+ 4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
+ 6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
+ 962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
+ 9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
+ DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
+ 0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
+ 64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
+ D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
+ E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
+ 495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
+ 48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
+ A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
+ DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
+ B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
+ E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
+ 9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
+ DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
+ 591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
+ 2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
+
+ 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
+ 82D9364338D955
+
+ 0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
+ 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
+ 883503E5B024CF7A8F6A94
+
+ 1 0 308201A2300D06092A864886F70D01010105000382018F0030
+ 82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
+ 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
+ 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
+ B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
+ C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
+ C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
+ 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
+ A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
+ 9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
+ 5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
+ FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
+ 1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
+ 2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
+ 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
+ 0203010001
+
+
+
+Hoffman & Schlyter Standards Track [Page 36]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
+ D9E30A924138C4
+
+ 1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
+ C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
+ 33A934B3A2D7E232C94AB4
+
+Authors' Addresses
+
+ Paul Hoffman
+ VPN Consortium
+
+ EMail: paul.hoffman@vpnc.org
+
+
+ Jakob Schlyter
+ Kirei AB
+
+ EMail: jakob@kirei.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 37]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Weiler, Ed.
+Request for Comments: 6840 SPARTA, Inc.
+Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed.
+Category: Standards Track Verisign, Inc.
+ISSN: 2070-1721 February 2013
+
+
+ Clarifications and Implementation Notes for DNS Security (DNSSEC)
+
+Abstract
+
+ This document is a collection of technical clarifications to the DNS
+ Security (DNSSEC) document set. It is meant to serve as a resource
+ to implementors as well as a collection of DNSSEC errata that existed
+ at the time of writing.
+
+ This document updates the core DNSSEC documents (RFC 4033, RFC 4034,
+ and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also
+ defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the
+ DNSSEC specification.
+
+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/rfc6840.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 1]
+\f
+RFC 6840 DNSSEC Implementation Notes February 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 2]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+Table of Contents
+
+ 1. Introduction and Terminology ....................................4
+ 1.1. Structure of This Document .................................4
+ 1.2. Terminology ................................................4
+ 2. Important Additions to DNSSEC ...................................4
+ 2.1. NSEC3 Support ..............................................4
+ 2.2. SHA-2 Support ..............................................5
+ 3. Scaling Concerns ................................................5
+ 3.1. Implement a BAD Cache ......................................5
+ 4. Security Concerns ...............................................5
+ 4.1. Clarifications on Nonexistence Proofs ......................5
+ 4.2. Validating Responses to an ANY Query .......................6
+ 4.3. Check for CNAME ............................................6
+ 4.4. Insecure Delegation Proofs .................................7
+ 5. Interoperability Concerns .......................................7
+ 5.1. Errors in Canonical Form Type Code List ....................7
+ 5.2. Unknown DS Message Digest Algorithms .......................7
+ 5.3. Private Algorithms .........................................8
+ 5.4. Caution about Local Policy and Multiple RRSIGs .............9
+ 5.5. Key Tag Calculation ........................................9
+ 5.6. Setting the DO Bit on Replies ..............................9
+ 5.7. Setting the AD Bit on Queries .............................10
+ 5.8. Setting the AD Bit on Replies .............................10
+ 5.9. Always Set the CD Bit on Queries ..........................10
+ 5.10. Nested Trust Anchors .....................................11
+ 5.11. Mandatory Algorithm Rules ................................11
+ 5.12. Ignore Extra Signatures from Unknown Keys ................12
+ 6. Minor Corrections and Clarifications ...........................12
+ 6.1. Finding Zone Cuts .........................................12
+ 6.2. Clarifications on DNSKEY Usage ............................12
+ 6.3. Errors in Examples ........................................13
+ 6.4. Errors in RFC 5155 ........................................13
+ 7. Security Considerations ........................................13
+ 8. References .....................................................14
+ 8.1. Normative References ......................................14
+ 8.2. Informative References ....................................15
+ Appendix A. Acknowledgments .......................................16
+ Appendix B. Discussion of Setting the CD Bit ......................16
+ Appendix C. Discussion of Trust Anchor Preference Options .........19
+ C.1. Closest Encloser ..........................................19
+ C.2. Accept Any Success ........................................20
+ C.3. Preference Based on Source ................................20
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 3]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+1. Introduction and Terminology
+
+ This document lists some additions, clarifications, and corrections
+ to the core DNSSEC specification, as originally described in
+ [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+ (See Section 2 for more recent additions to that core document set.)
+
+ It is intended to serve as a resource for implementors and as a
+ repository of items existing at the time of writing that need to be
+ addressed when advancing the DNSSEC documents along the Standards
+ Track.
+
+1.1. Structure of This Document
+
+ The clarifications and changes to DNSSEC are sorted according to
+ their importance, starting with ones which could, if ignored, lead to
+ security problems and progressing down to clarifications that are
+ expected to have little operational impact.
+
+1.2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+2. Important Additions to DNSSEC
+
+ This section lists some documents that are now considered core DNSSEC
+ protocol documents in addition to those originally specified in
+ Section 10 of [RFC4033].
+
+2.1. NSEC3 Support
+
+ [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
+ records for hashed denial of existence. Validator implementations
+ are strongly encouraged to include support for NSEC3 because a number
+ of highly visible zones use it. Validators that do not support
+ validation of responses using NSEC3 will be hampered in validating
+ large portions of the DNS space.
+
+ [RFC5155] is now considered part of the DNS Security Document Family
+ as described by Section 10 of [RFC4033].
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 4]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3-
+ SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512)
+ signal that a zone might be using NSEC3, rather than NSEC. The zone
+ may be using either, and validators supporting these algorithms MUST
+ support both NSEC3 and NSEC responses.
+
+2.2. SHA-2 Support
+
+ [RFC4509] describes the use of SHA-256 as a digest algorithm in
+ Delegation Signer (DS) RRs. [RFC5702] describes the use of the
+ RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+ Validator implementations are strongly encouraged to include support
+ for these algorithms for DS, DNSKEY, and RRSIG records.
+
+ Both [RFC4509] and [RFC5702] are now considered part of the DNS
+ Security Document Family as described by Section 10 of [RFC4033].
+
+3. Scaling Concerns
+
+3.1. Implement a BAD Cache
+
+ Section 4.7 of [RFC4035] permits security-aware resolvers to
+ implement a BAD cache. That guidance has changed: security-aware
+ resolvers SHOULD implement a BAD cache as described in [RFC4035].
+
+ This change in guidance is based on operational experience with
+ DNSSEC administrative errors leading to significant increases in DNS
+ traffic, with an accompanying realization that such events are more
+ likely and more damaging than originally supposed. An example of one
+ such event is documented in "Rolling Over DNSSEC Keys" [Huston].
+
+4. Security Concerns
+
+ This section provides clarifications that, if overlooked, could lead
+ to security issues.
+
+4.1. Clarifications on Nonexistence Proofs
+
+ Section 5.4 of [RFC4035] under-specifies the algorithm for checking
+ nonexistence proofs. In particular, the algorithm as presented would
+ allow a validator to interpret an NSEC or NSEC3 RR from an ancestor
+ zone as proving the nonexistence of an RR in a child zone.
+
+ An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
+
+ o the NS bit set,
+
+ o the Start of Authority (SOA) bit clear, and
+
+
+
+Weiler & Blacka Standards Track [Page 5]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ o a signer field that is shorter than the owner name of the NSEC RR,
+ or the original owner name for the NSEC3 RR.
+
+ Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume
+ nonexistence of any RRs below that zone cut, which include all RRs at
+ that (original) owner name other than DS RRs, and all RRs below that
+ owner name regardless of type.
+
+ Similarly, the algorithm would also allow an NSEC RR at the same
+ owner name as a DNAME RR, or an NSEC3 RR at the same original owner
+ name as a DNAME, to prove the nonexistence of names beneath that
+ DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
+ to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's
+ (original) owner name.
+
+4.2. Validating Responses to an ANY Query
+
+ [RFC4035] does not address how to validate responses when QTYPE=*.
+ As described in Section 6.2.2 of [RFC1034], a proper response to
+ QTYPE=* may include a subset of the RRsets at a given name. That is,
+ it is not necessary to include all RRsets at the QNAME in the
+ response.
+
+ When validating a response to QTYPE=*, all received RRsets that match
+ QNAME and QCLASS MUST be validated. If any of those RRsets fail
+ validation, the answer is considered Bogus. If there are no RRsets
+ matching QNAME and QCLASS, that fact MUST be validated according to
+ the rules in Section 5.4 of [RFC4035] (as clarified in this
+ document). To be clear, a validator must not expect to receive all
+ records at the QNAME in response to QTYPE=*.
+
+4.3. Check for CNAME
+
+ Section 5 of [RFC4035] says nothing explicit about validating
+ responses based on (or that should be based on) CNAMEs. When
+ validating a NOERROR/NODATA response, validators MUST check the CNAME
+ bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
+ bit for the query type.
+
+ Without this check, an attacker could successfully transform a
+ positive CNAME response into a NOERROR/NODATA response by (for
+ example) simply stripping the CNAME RRset from the response. A naive
+ validator would then note that the QTYPE was not present in the
+ matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
+ set; thus, the response should have been a positive CNAME response.
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 6]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+4.4. Insecure Delegation Proofs
+
+ Section 5.2 of [RFC4035] specifies that a validator, when proving a
+ delegation is not secure, needs to check for the absence of the DS
+ and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also
+ MUST check for the presence of the NS bit in the matching NSEC (or
+ NSEC3) RR (proving that there is, indeed, a delegation), or
+ alternately make sure that the delegation is covered by an NSEC3 RR
+ with the Opt-Out flag set.
+
+ Without this check, an attacker could reuse an NSEC or NSEC3 RR
+ matching a non-delegation name to spoof an unsigned delegation at
+ that name. This would claim that an existing signed RRset (or set of
+ signed RRsets) is below an unsigned delegation, thus not signed and
+ vulnerable to further attack.
+
+5. Interoperability Concerns
+
+5.1. Errors in Canonical Form Type Code List
+
+ When canonicalizing DNS names (for both ordering and signing), DNS
+ names in the RDATA section of NSEC resource records are not converted
+ to lowercase. DNS names in the RDATA section of RRSIG resource
+ records are converted to lowercase.
+
+ The guidance in the above paragraph differs from what has been
+ published before but is consistent with current common practice.
+ Item 3 of Section 6.2 of [RFC4034] says that names in both of these
+ RR types should be converted to lowercase. The earlier [RFC3755]
+ says that they should not. Current practice follows neither document
+ fully.
+
+ Section 6.2 of [RFC4034] also erroneously lists HINFO as a record
+ that needs conversion to lowercase, and twice at that. Since HINFO
+ records contain no domain names, they are not subject to case
+ conversion.
+
+5.2. Unknown DS Message Digest Algorithms
+
+ Section 5.2 of [RFC4035] includes rules for how to handle delegations
+ to zones that are signed with entirely unsupported public key
+ algorithms, as indicated by the key algorithms shown in those zones'
+ DS RRsets. It does not explicitly address how to handle DS records
+ that use unsupported message digest algorithms. In brief, DS records
+ using unknown or unsupported message digest algorithms MUST be
+ treated the same way as DS records referring to DNSKEY RRs of unknown
+ or unsupported public key algorithms.
+
+
+
+
+Weiler & Blacka Standards Track [Page 7]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ The existing text says:
+
+ If the validator does not support any of the algorithms listed in
+ an authenticated DS RRset, then the resolver has no supported
+ authentication path leading from the parent to the child. The
+ resolver should treat this case as it would the case of an
+ authenticated NSEC RRset proving that no DS RRset exists, as
+ described above.
+
+ In other words, when determining the security status of a zone, a
+ validator disregards any authenticated DS records that specify
+ unknown or unsupported DNSKEY algorithms. If none are left, the zone
+ is treated as if it were unsigned.
+
+ This document modifies the above text to additionally disregard
+ authenticated DS records using unknown or unsupported message digest
+ algorithms.
+
+5.3. Private Algorithms
+
+ As discussed above, Section 5.2 of [RFC4035] requires that validators
+ make decisions about the security status of zones based on the public
+ key algorithms shown in the DS records for those zones. In the case
+ of private algorithms, as described in Appendix A.1.1 of [RFC4034],
+ the eight-bit algorithm field in the DS RR is not conclusive about
+ what algorithm(s) is actually in use.
+
+ If no private algorithms appear in the DS RRset, or if any supported
+ algorithm appears in the DS RRset, no special processing is needed.
+ Furthermore, if the validator implementation does not support any
+ private algorithms, or only supports private algorithms using an
+ algorithm number not present in the DS RRset, no special processing
+ is needed.
+
+ In the remaining cases, the security status of the zone depends on
+ whether or not the resolver supports any of the private algorithms in
+ use (provided that these DS records use supported message digest
+ algorithms, as discussed in Section 5.2 of this document). In these
+ cases, the resolver MUST retrieve the corresponding DNSKEY for each
+ private algorithm DS record and examine the public key field to
+ determine the algorithm in use. The security-aware resolver MUST
+ ensure that the hash of the DNSKEY RR's owner name and RDATA matches
+ the digest in the DS RR as described in Section 5.2 of [RFC4035],
+ authenticating the DNSKEY. If all of the retrieved and authenticated
+ DNSKEY RRs use unknown or unsupported private algorithms, then the
+ zone is treated as if it were unsigned.
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 8]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ Note that if none of the private algorithm DS RRs can be securely
+ matched to DNSKEY RRs and no other DS establishes that the zone is
+ secure, the referral should be considered Bogus data as discussed in
+ [RFC4035].
+
+ This clarification facilitates the broader use of private algorithms,
+ as suggested by [RFC4955].
+
+5.4. Caution about Local Policy and Multiple RRSIGs
+
+ When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035]
+ suggests that "the local resolver security policy determines whether
+ the resolver also has to test these RRSIG RRs and how to resolve
+ conflicts if these RRSIG RRs lead to differing results".
+
+ This document specifies that a resolver SHOULD accept any valid RRSIG
+ as sufficient, and only determine that an RRset is Bogus if all
+ RRSIGs fail validation.
+
+ If a resolver adopts a more restrictive policy, there's a danger that
+ properly signed data might unnecessarily fail validation due to cache
+ timing issues. Furthermore, certain zone management techniques, like
+ the Double Signature Zone Signing Key Rollover method described in
+ Section 4.2.1.2 of [RFC6781], will not work reliably. Such a
+ resolver is also vulnerable to malicious insertion of gibberish
+ signatures.
+
+5.5. Key Tag Calculation
+
+ Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field
+ calculation for algorithm 1. It correctly says that the Key Tag is
+ the most significant 16 of the least significant 24 bits of the
+ public key modulus. However, [RFC4034] then goes on to incorrectly
+ say that this is fourth-to-last and third-to-last octets of the
+ public key modulus. It is, in fact, the third-to-last and second-to-
+ last octets.
+
+5.6. Setting the DO Bit on Replies
+
+ As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the
+ query MUST be copied in the response. However, in order to
+ interoperate with implementations that ignore this rule on sending,
+ resolvers MUST ignore the DO bit in responses.
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 9]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+5.7. Setting the AD Bit on Queries
+
+ The semantics of the Authentic Data (AD) bit in the query were
+ previously undefined. Section 4.6 of [RFC4035] instructed resolvers
+ to always clear the AD bit when composing queries.
+
+ This document defines setting the AD bit in a query as a signal
+ indicating that the requester understands and is interested in the
+ value of the AD bit in the response. This allows a requester to
+ indicate that it understands the AD bit without also requesting
+ DNSSEC data via the DO bit.
+
+5.8. Setting the AD Bit on Replies
+
+ Section 3.2.3 of [RFC4035] describes under which conditions a
+ validating resolver should set or clear the AD bit in a response. In
+ order to interoperate with legacy stub resolvers and middleboxes that
+ neither understand nor ignore the AD bit, validating resolvers SHOULD
+ only set the AD bit when a response both meets the conditions listed
+ in Section 3.2.3 of [RFC4035], and the request contained either a set
+ DO bit or a set AD bit.
+
+5.9. Always Set the CD Bit on Queries
+
+ When processing a request with the Checking Disabled (CD) bit set, a
+ resolver SHOULD attempt to return all response data, even data that
+ has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a
+ resolver processing a request with the CD bit set to set the CD bit
+ on its upstream queries.
+
+ This document further specifies that validating resolvers SHOULD set
+ the CD bit on every upstream query. This is regardless of whether
+ the CD bit was set on the incoming query or whether it has a trust
+ anchor at or above the QNAME.
+
+ [RFC4035] is ambiguous about what to do when a cached response was
+ obtained with the CD bit unset, a case that only arises when the
+ resolver chooses not to set the CD bit on all upstream queries, as
+ specified above. In the typical case, no new query is required, nor
+ does the cache need to track the state of the CD bit used to make a
+ given query. The problem arises when the cached response is a server
+ failure (RCODE 2), which may indicate that the requested data failed
+ DNSSEC validation at an upstream validating resolver. ([RFC2308]
+ permits caching of server failures for up to five minutes.) In these
+ cases, a new query with the CD bit set is required.
+
+ Appendix B discusses more of the logic behind the recommendation
+ presented in this section.
+
+
+
+Weiler & Blacka Standards Track [Page 10]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+5.10. Nested Trust Anchors
+
+ A DNSSEC validator may be configured such that, for a given response,
+ more than one trust anchor could be used to validate the chain of
+ trust to the response zone. For example, imagine a validator
+ configured with trust anchors for "example." and "zone.example."
+ When the validator is asked to validate a response to
+ "www.sub.zone.example.", either trust anchor could apply.
+
+ When presented with this situation, DNSSEC validators have a choice
+ of which trust anchor(s) to use. Which to use is a matter of
+ implementation choice. Appendix C discusses several possible
+ algorithms.
+
+ It is possible and advisable to expose the choice of policy as a
+ configuration option. As a default, it is suggested that validators
+ implement the "Accept Any Success" policy described in Appendix C.2
+ while exposing other policies as configuration options.
+
+ The "Accept Any Success" policy is to try all applicable trust
+ anchors until one gives a validation result of Secure, in which case
+ the final validation result is Secure. If and only if all applicable
+ trust anchors give a result of Insecure, the final validation result
+ is Insecure. If one or more trust anchors lead to a Bogus result and
+ there is no Secure result, then the final validation result is Bogus.
+
+5.11. Mandatory Algorithm Rules
+
+ The last paragraph of Section 2.2 of [RFC4035] includes rules
+ describing which algorithms must be used to sign a zone. Since these
+ rules have been confusing, they are restated using different language
+ here:
+
+ The DS RRset and DNSKEY RRset are used to signal which algorithms
+ are used to sign a zone. The presence of an algorithm in either a
+ zone's DS or DNSKEY RRset signals that that algorithm is used to
+ sign the entire zone.
+
+ A signed zone MUST include a DNSKEY for each algorithm present in
+ the zone's DS RRset and expected trust anchors for the zone. The
+ zone MUST also be signed with each algorithm (though not each key)
+ present in the DNSKEY RRset. It is possible to add algorithms at
+ the DNSKEY that aren't in the DS record, but not vice versa. If
+ more than one key of the same algorithm is in the DNSKEY RRset, it
+ is sufficient to sign each RRset with any subset of these DNSKEYs.
+ It is acceptable to sign some RRsets with one subset of keys (or
+ key) and other RRsets with a different subset, so long as at least
+
+
+
+
+Weiler & Blacka Standards Track [Page 11]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ one DNSKEY of each algorithm is used to sign each RRset.
+ Likewise, if there are DS records for multiple keys of the same
+ algorithm, any subset of those may appear in the DNSKEY RRset.
+
+ This requirement applies to servers, not validators. Validators
+ SHOULD accept any single valid path. They SHOULD NOT insist that all
+ algorithms signaled in the DS RRset work, and they MUST NOT insist
+ that all algorithms signaled in the DNSKEY RRset work. A validator
+ MAY have a configuration option to perform a signature completeness
+ test to support troubleshooting.
+
+5.12. Ignore Extra Signatures from Unknown Keys
+
+ Validating resolvers MUST disregard RRSIGs in a zone that do not
+ (currently) have a corresponding DNSKEY in the zone. Similarly, a
+ validating resolver MUST disregard RRSIGs with algorithm types that
+ don't exist in the DNSKEY RRset.
+
+ Good key rollover and algorithm rollover practices, as discussed in
+ RFC 6781 and its successor documents and as suggested by the rules in
+ the previous section, may require that such RRSIGs be present in a
+ zone.
+
+6. Minor Corrections and Clarifications
+
+6.1. Finding Zone Cuts
+
+ Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
+ for a parent zone but does not state how to find those servers.
+ Specific instructions can be found in Section 4.2 of [RFC4035].
+
+6.2. Clarifications on DNSKEY Usage
+
+ It is possible to use different DNSKEYs to sign different subsets of
+ a zone, constrained only by the rules in Section 5.11. It is even
+ possible to use a different DNSKEY for each RRset in a zone, subject
+ only to practical limits on the size of the DNSKEY RRset and the
+ above rules. However, be aware that there is no way to tell
+ resolvers what a particular DNSKEY is supposed to be used for -- any
+ DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
+ any RRset in the zone. For example, if a weaker or less trusted
+ DNSKEY is being used to authenticate NSEC RRsets or all dynamically
+ updated records, that same DNSKEY can also be used to sign any other
+ RRsets from the zone.
+
+ Furthermore, note that the SEP bit setting has no effect on how a
+ DNSKEY may be used -- the validation process is specifically
+ prohibited from using that bit by Section 2.1.2 of [RFC4034]. It is
+
+
+
+Weiler & Blacka Standards Track [Page 12]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ possible to use a DNSKEY without the SEP bit set as the sole secure
+ entry point to the zone, yet use a DNSKEY with the SEP bit set to
+ sign all RRsets in the zone (other than the DNSKEY RRset). It is
+ also possible to use a single DNSKEY, with or without the SEP bit
+ set, to sign the entire zone, including the DNSKEY RRset itself.
+
+6.3. Errors in Examples
+
+ The text in Appendix C.1 of [RFC4035] refers to the examples in
+ Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This
+ is painfully obvious in the second paragraph where it states that the
+ RRSIG labels field value of 3 indicates that the answer was not the
+ result of wildcard expansion. This is true for "x.w.example" but not
+ for "x.w.example.com", which of course has a label count of 4
+ (antithetically, a label count of 3 would imply the answer was the
+ result of a wildcard expansion).
+
+ The first paragraph of Appendix C.6 of [RFC4035] also has a minor
+ error: the reference to "a.z.w.w.example" should instead be
+ "a.z.w.example", as in the previous line.
+
+6.4. Errors in RFC 5155
+
+ An NSEC3 record that matches an Empty Non-Terminal effectively has no
+ type associated with it. This NSEC3 record has an empty type bit
+ map. Section 3.2.1 of [RFC5155] contains the statement:
+
+ Blocks with no types present MUST NOT be included.
+
+ However, the same section contains a regular expression:
+
+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+ The plus sign in the regular expression indicates that there is one
+ or more of the preceding element. This means that there must be at
+ least one window block. If this window block has no types, it
+ contradicts with the first statement. Therefore, the correct text in
+ Section 3.2.1 of [RFC5155] should be:
+
+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
+
+7. Security Considerations
+
+ This document adds SHA-2 and NSEC3 support to the core DNSSEC
+ protocol. Security considerations for those features are discussed
+ in the documents defining them. Additionally, this document
+ addresses some ambiguities and omissions in the core DNSSEC documents
+ that, if not recognized and addressed in implementations, could lead
+
+
+
+Weiler & Blacka Standards Track [Page 13]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ to security failures. In particular, the validation algorithm
+ clarifications in Section 4 are critical for preserving the security
+ properties DNSSEC offers. Furthermore, failure to address some of
+ the interoperability concerns in Section 5 could limit the ability to
+ later change or expand DNSSEC, including adding new algorithms.
+
+ The recommendation in Section 5.9 to always set the CD bit has
+ security implications. By setting the CD bit, a resolver will not
+ benefit from more stringent validation rules or a more complete set
+ of trust anchors at an upstream validator.
+
+8. References
+
+8.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
+ RFC 3225, December 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.
+
+ [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.
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 14]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+8.2. Informative References
+
+ [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
+ "Rolling Over DNSSEC Keys", Internet Protocol
+ Journal, Vol. 13, No.1, pp. 2-16, March 2010.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer (DS)", RFC 3755, May 2004.
+
+ [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
+ July 2007.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+ Trust Anchors", STD 74, RFC 5011, September 2007.
+
+ [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+ November 2007.
+
+ [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+ Operational Practices, Version 2", RFC 6781,
+ December 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 15]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+Appendix A. Acknowledgments
+
+ The editors would like the thank Rob Austein for his previous work as
+ an editor of this document.
+
+ The editors are extremely grateful to those who, in addition to
+ finding errors and omissions in the DNSSEC document set, have
+ provided text suitable for inclusion in this document.
+
+ The lack of specificity about handling private algorithms, as
+ described in Section 5.3, and the lack of specificity in handling ANY
+ queries, as described in Section 4.2, were discovered by David
+ Blacka.
+
+ The error in algorithm 1 key tag calculation, as described in
+ Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
+ contributed text for Section 5.5.
+
+ The bug relating to delegation NSEC RR's in Section 4.1 was found by
+ Roy Badami. Roy Arends found the related problem with DNAME.
+
+ The errors in the [RFC4035] examples were found by Roy Arends, who
+ also contributed text for Section 6.3 of this document.
+
+ Text on the mandatory algorithm rules was derived from suggestions by
+ Matthijs Mekking and Ed Lewis.
+
+ The CD bit logic was analyzed in depth by David Blacka, Olafur
+ Gudmundsson, Mike St. Johns, and Andrew Sullivan.
+
+ The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+ Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+ Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
+ Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
+ Warren Kumari and Scott Rose for their contributions to this
+ document.
+
+Appendix B. Discussion of Setting the CD Bit
+
+ [RFC4035] may be read as relying on the implicit assumption that
+ there is at most one validating system between the stub resolver and
+ the authoritative server for a given zone. It is entirely possible,
+ however, for more than one validator to exist between a stub resolver
+ and an authoritative server. If these different validators have
+ disjoint trust anchors configured, then it is possible that each
+ would be able to validate some portion of the DNS tree, but neither
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 16]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ is able to validate all of it. Accordingly, it might be argued that
+ it is desirable not to set the CD bit on upstream queries, because
+ that allows for maximal validation.
+
+ In Section 5.9 of this document, it is recommended to set the CD bit
+ on an upstream query even when the incoming query arrives with CD=0.
+ This is for two reasons: it encourages a more predictable validation
+ experience as only one validator is always doing the validation, and
+ it ensures that all DNSSEC data that exists may be available from the
+ local cache should a query with CD=1 arrive.
+
+ As a matter of policy, it is possible to set the CD bit differently
+ than suggested in Section 5.9. A different choice will, of course,
+ not always yield the benefits listed above. It is beyond the scope
+ of this document to outline all of the considerations and counter
+ considerations for all possible policies. Nevertheless, it is
+ possible to describe three approaches and their underlying philosophy
+ of operation. These are laid out in the tables below.
+
+ The table that describes each model has five columns. The first
+ column indicates the value of the CD bit that the resolver receives
+ (for instance, on the name server side in an iterative resolver, or
+ as local policy or from the API in the case of a stub). The second
+ column indicates whether the query needs to be forwarded for
+ resolution (F) or can be satisfied from a local cache (C). The third
+ column is a line number, so that it can be referred to later in the
+ table. The fourth column indicates any relevant conditions at the
+ resolver, for example, whether the resolver has a covering trust
+ anchor, and so on. If there are no parameters here, the column is
+ empty. The fifth and final column indicates what action the resolver
+ takes.
+
+ The tables differentiate between "cached data" and "cached RCODE=2".
+ This is a shorthand; the point is that one has to treat RCODE=2
+ (server failure) as special, because it might indicate a validation
+ failure somewhere upstream. The distinction is really between
+ "cached RCODE=2" and "cached everything else".
+
+ The tables are probably easiest to think of in terms of describing
+ what happens when a stub resolver sends a query to an intermediate
+ resolver, but they are perfectly general and can be applied to any
+ validating resolver.
+
+ Model 1: "always set"
+
+ This model is so named because the validating resolver sets the CD
+ bit on queries it makes regardless of whether it has a covering trust
+ anchor for the query. The general philosophy represented by this
+
+
+
+Weiler & Blacka Standards Track [Page 17]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ table is that only one resolver should be responsible for validation
+ irrespective of the possibility that an upstream resolver may be
+ present with trust anchors that cover different or additional QNAMEs.
+ It is the model recommended in Section 5.9 of this document.
+
+ CD F/C line conditions action
+ ====================================================================
+ 1 F A1 Set CD=1 on upstream query
+ 0 F A2 Set CD=1 on upstream query
+ 1 C A3 Return the cache contents
+ (data or RCODE=2)
+ 0 C A4 no covering TA Return cache contents
+ (data or RCODE=2)
+ 0 C A5 covering TA Validate cached result and
+ return it
+
+ Model 2: "never set when receiving CD=0"
+
+ This model is so named because it sets CD=0 on upstream queries for
+ all received CD=0 queries, even if it has a covering trust anchor.
+ The general philosophy represented by this table is that more than
+ one resolver may take responsibility for validating a QNAME and that
+ a validation failure for a QNAME by any resolver in the chain is a
+ validation failure for the query. Using this model is NOT
+ RECOMMENDED.
+
+ CD F/C line conditions action
+ ====================================================================
+ 1 F N1 Set CD=1 on upstream query
+ 0 F N2 Set CD=0 on upstream query
+ 1 C N3 cached data Return cached data
+ 1 C N4 cached RCODE=2 Treat as line N1
+ 0 C N5 no covering TA Return cache contents
+ (data or RCODE=2)
+ 0 C N6 covering TA & Treat as line N2
+ cached data was
+ generated with CD=1
+ 0 C N7 covering TA & Validate and return
+ cached data was
+ generated with CD=0
+
+
+ Model 3: "sometimes set"
+
+ This model is so named because it sets the CD bit on upstream queries
+ triggered by received CD=0 queries, based on whether the validator
+ has a trust anchor configured that covers the query. If there is no
+ covering trust anchor, the resolver clears the CD bit in the upstream
+
+
+
+Weiler & Blacka Standards Track [Page 18]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ query. If there is a covering trust anchor, the resolver sets CD=1
+ and performs validation itself. The general philosophy represented
+ by this table is that a resolver should try and validate QNAMEs for
+ which it has trust anchors and should not preclude validation by
+ other resolvers for QNAMEs for which it does not have covering trust
+ anchors. Using this model is NOT RECOMMENDED.
+
+ CD F/C line conditions action
+ ====================================================================
+ 1 F S1 Set CD=1 on upstream query
+ 0 F S2 covering TA Set CD=1 on upstream query
+ 0 F S3 no covering TA Set CD=0 on upstream query
+ 1 C S4 cached data Return cached data
+ 1 C S5 cached RCODE=2 Treat as line S1
+ 0 C S6 cached data was Return cache contents
+ generated with
+ CD=0
+ 0 C S7 cached data was Validate & return cache
+ generated with contents
+ CD=1 &
+ covering TA
+ 0 C S8 cached RCODE=2 Return cache contents
+ 0 C S9 cached data Treat as line S3
+ was generated
+ with CD=1 &
+ no covering
+ TA
+
+
+Appendix C. Discussion of Trust Anchor Preference Options
+
+ This section presents several different policies for validating
+ resolvers to use when they have a choice of trust anchors available
+ for validating a given answer.
+
+C.1. Closest Encloser
+
+ One policy is to choose the trust anchor closest to the QNAME of the
+ response. For example, consider a validator configured with trust
+ anchors for "example." and "zone.example." When asked to validate a
+ response for "www.sub.zone.example.", a validator using the "Closest
+ Encloser" policy would choose the "zone.example." trust anchor.
+
+ This policy has the advantage of allowing the operator to trivially
+ override a parent zone's trust anchor with one that the operator can
+ validate in a stronger way, perhaps because the resolver operator is
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 19]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ affiliated with the zone in question. This policy also minimizes the
+ number of public key operations needed, which is of benefit in
+ resource-constrained environments.
+
+ This policy has the disadvantage of giving the user some unexpected
+ and unnecessary validation failures when sub-zone trust anchors are
+ neglected. As a concrete example, consider a validator that
+ configured a trust anchor for "zone.example." in 2009 and one for
+ "example." in 2011. In 2012, "zone.example." rolls its Key Signing
+ Key (KSK) and updates its DS records, but the validator operator
+ doesn't update its trust anchor. With the "Closest Encloser" policy,
+ the validator gets validation failures.
+
+C.2. Accept Any Success
+
+ Another policy is to try all applicable trust anchors until one gives
+ a validation result of Secure, in which case the final validation
+ result is Secure. If and only if all applicable trust anchors give a
+ result of Insecure, the final validation result is Insecure. If one
+ or more trust anchors lead to a Bogus result and there is no Secure
+ result, then the final validation result is Bogus.
+
+ This has the advantage of causing the fewest validation failures,
+ which may deliver a better user experience. If one trust anchor is
+ out of date (as in our above example), the user may still be able to
+ get a Secure validation result (and see DNS responses).
+
+ This policy has the disadvantage of making the validator subject to
+ the compromise of the weakest of these trust anchors, while making it
+ relatively painless to keep old trust anchors configured in
+ perpetuity.
+
+C.3. Preference Based on Source
+
+ When the trust anchors have come from different sources (e.g.,
+ automated updates ([RFC5011]), one or more DNSSEC Lookaside
+ Validation (DLV) registries ([RFC5074]), and manual configuration), a
+ validator may wish to choose between them based on the perceived
+ reliability of those sources. The order of precedence might be
+ exposed as a configuration option.
+
+ For example, a validator might choose to prefer trust anchors found
+ in a DLV registry over those manually configured on the theory that
+ the manually configured ones will not be as aggressively maintained.
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 20]
+\f
+RFC 6840 DNSSEC Implementation Notes February 2013
+
+
+ Conversely, a validator might choose to prefer manually configured
+ trust anchors over those obtained from a DLV registry on the theory
+ that the manually configured ones have been more carefully
+ authenticated.
+
+ Or the validator might do something more complex: prefer a sub-set of
+ manually configured trust anchors (based on a configuration option),
+ then trust anchors that have been updated using the mechanism in
+ [RFC5011], then trust anchors from one DLV registry, then trust
+ anchors from a different DLV registry, then the rest of the manually
+ configured trust anchors.
+
+Authors' Addresses
+
+ Samuel Weiler (editor)
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+ US
+
+ EMail: weiler@tislabs.com
+
+
+ David Blacka (editor)
+ Verisign, Inc.
+ 12061 Bluemont Way
+ Reston, VA 20190
+ US
+
+ EMail: davidb@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Standards Track [Page 21]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / bind9.git / commitdiff
