From 2d4143b7b132c64f8720d6608219ccfa89a7d9ec Mon Sep 17 00:00:00 2001 From: "Internet Software Consortium, Inc" <@isc.org> Date: Fri, 4 Feb 2011 20:43:53 -0700 Subject: 9.7.3b1 --- doc/draft/draft-ietf-behave-dns64-10.txt | 1736 ------------------- doc/draft/draft-ietf-behave-dns64-11.txt | 1792 ++++++++++++++++++++ .../draft-ietf-dnsext-dnssec-bis-updates-10.txt | 785 --------- .../draft-ietf-dnsext-dnssec-bis-updates-12.txt | 785 +++++++++ 4 files changed, 2577 insertions(+), 2521 deletions(-) delete mode 100644 doc/draft/draft-ietf-behave-dns64-10.txt create mode 100644 doc/draft/draft-ietf-behave-dns64-11.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt (limited to 'doc') diff --git a/doc/draft/draft-ietf-behave-dns64-10.txt b/doc/draft/draft-ietf-behave-dns64-10.txt deleted file mode 100644 index 3d8200f9..00000000 --- a/doc/draft/draft-ietf-behave-dns64-10.txt +++ /dev/null @@ -1,1736 +0,0 @@ - - - -BEHAVE WG M. Bagnulo -Internet-Draft UC3M -Intended status: Standards Track A. Sullivan -Expires: January 6, 2011 Shinkuro - P. Matthews - Alcatel-Lucent - I. van Beijnum - IMDEA Networks - July 5, 2010 - - -DNS64: DNS extensions for Network Address Translation from IPv6 Clients - to IPv4 Servers - draft-ietf-behave-dns64-10 - -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 Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 6, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - - - -Bagnulo, et al. Expires January 6, 2011 [Page 1] - -Internet-Draft DNS64 July 2010 - - - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - 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. Expires January 6, 2011 [Page 2] - -Internet-Draft DNS64 July 2010 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 - 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 recursive resolver mode . . . 17 - 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 18 - 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 . . . . . . . . . . . 20 - 7. Deployment scenarios and examples . . . . . . . . . . . . . . 21 - 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 - 7.2. An example of an-IPv6-network-to-IPv4-Internet setup - with DNS64 in stub-resolver mode . . . . . . . . . . . . . 23 - 7.3. Example of IPv6-Internet-to-an-IPv4-network setup - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 - Appendix A. Motivations and Implications of synthesizing AAAA - Resource Records when real AAAA Resource Records - - - -Bagnulo, et al. Expires January 6, 2011 [Page 3] - -Internet-Draft DNS64 July 2010 - - - exist . . . . . . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 4] - -Internet-Draft DNS64 July 2010 - - -1. Introduction - - This document specifies DNS64, a mechanism that is part of the - toolbox for IPv6-IPv4 transition and co-existence. DNS64, used - together with an IPv6/IPv4 translator such as stateful NAT64 - [I-D.ietf-behave-v6v4-xlate-stateful], 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 FQDN of the server. - - These mechanisms are expected to play a critical role in the IPv4- - IPv6 transition and co-existence. 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 advanced - features require performing the DNS64 function directly in the end- - hosts themselves. - - -2. Overview - - This section provides a non-normative 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, 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, servers that - can only use IPv4, as well as cases where only IPv4 connectivity is - - - -Bagnulo, et al. Expires January 6, 2011 [Page 5] - -Internet-Draft DNS64 July 2010 - - - 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 address 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 - 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 - - - -Bagnulo, et al. Expires January 6, 2011 [Page 6] - -Internet-Draft DNS64 July 2010 - - - 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 [I-D.ietf-behave-address-format]. There are two types - of prefixes that can be used as Pref64::/n. - - The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved - by [I-D.ietf-behave-address-format] for the purpose of - representing IPv4 addresses in IPv6 address space. - - 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. - - 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 advanced functions like - - - -Bagnulo, et al. Expires January 6, 2011 [Page 7] - -Internet-Draft DNS64 July 2010 - - - 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 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. - - 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. - - 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. - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 8] - -Internet-Draft DNS64 July 2010 - - - 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 resolver 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 server 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 node receives a query with - the DO bit clear and CD 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 node receives a query with - the DO bit set and CD clear. This works like the previous case, - except that the resolver should also set the "Authentic Data" - (AD) bit on the response. - - 7. A security-aware and validating DNS64 node receives a query with - the DO bit set and CD 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]. - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 9] - -Internet-Draft DNS64 July 2010 - - - Authoritative server: A DNS server that can answer authoritatively a - given DNS question. - - 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 recursor: 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. - - 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. - - Synthetic RR: A DNS resource record (RR) that is not contained in - any zone data file, but has been synthesized from other RRs. 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], [RFC1035] and - 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]. - - - -Bagnulo, et al. Expires January 6, 2011 [Page 10] - -Internet-Draft DNS64 July 2010 - - - 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]. - - DNS64 also responds to PTR queries involving addresses containing any - of the IPv6 prefixes it uses for synthesis of AAAA RRs. - -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, 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 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 than would usually - happen in DNS operation. - - Any other RCODE is treated as though the RCODE were 0 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. - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 11] - -Internet-Draft DNS64 July 2010 - - - 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. - -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 Pref::64/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 MAY 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 - - - -Bagnulo, et al. Expires January 6, 2011 [Page 12] - -Internet-Draft DNS64 July 2010 - - - 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). - -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 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 a default value of 600 seconds. 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 SHOULD - - - -Bagnulo, et al. Expires January 6, 2011 [Page 13] - -Internet-Draft DNS64 July 2010 - - - 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. - -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. However, this would 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: - - 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 a 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. - - The algorithm MUST be reversible; i.e., it MUST be possible to - derive the original IPv4 address from the IPv6 representation. - - 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 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 manually configured, 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 - - - -Bagnulo, et al. Expires January 6, 2011 [Page 14] - -Internet-Draft DNS64 July 2010 - - - [I-D.ietf-behave-address-format] to represent the IPv4 unicast - address range - - [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as - the value for the Well-Known prefix and needs to be confirmed - whenis published as RFC.]][I-D.ietf-behave-address-format] - - A DNS64 MUST support the algorithm for generating IPv6 - representations of IPv4 addresses defined in Section 2 of - [I-D.ietf-behave-address-format]. Moreover, the aforementioned - algorithm MUST be the default algorithm used by the DNS64. While the - normative description of the algorithm is provided in - [I-D.ietf-behave-address-format], a sample description of the - algorithm and its application to different scenarios is 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. 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. - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 15] - -Internet-Draft DNS64 July 2010 - - - 2. The second option is for the DNS64 nameserver to synthesize a - CNAME mapping the IP6.ARPA namespace to the corresponding IN- - ADDR.ARPA name. 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 - disadvantage is 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. In addition, the generated CNAME could correspond to an - unpopulated in-addr.arpa zone, so the CNAME would provide a - reference to a non-existent record. - - 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 nameserver 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. - - 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 nameserver that is unaware of the - NAT64 in question. The result in this case will be resolution - failure anyway, only 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. Expires January 6, 2011 [Page 16] - -Internet-Draft DNS64 July 2010 - - -5.3.3. Other Resource Records - - If the DNS64 is in recursive resolver mode, then considerations - outlined in [I-D.ietf-dnsop-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 recursive 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. Expires January 6, 2011 [Page 17] - -Internet-Draft DNS64 July 2010 - - - 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. - - -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 realise that it is - incompatible with some things that may be deployed in an IPv4-only or - - - -Bagnulo, et al. Expires January 6, 2011 [Page 18] - -Internet-Draft DNS64 July 2010 - - - 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. 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 recursor 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. - - +---------------+ +-------------+ - | i1 (IPv6)+----NAT64--------+IPv4 Internet| - | | +-------------+ - | host | - | | +-------------+ - | i2 (IPv6)+-----------------+IPv6 Internet| - +---------------+ +-------------+ - - Figure 1: IPv6 multihomed hosts - - - -Bagnulo, et al. Expires January 6, 2011 [Page 19] - -Internet-Draft DNS64 July 2010 - - - 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 - emphasising 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 - 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- - - - -Bagnulo, et al. Expires January 6, 2011 [Page 20] - -Internet-Draft DNS64 July 2010 - - - 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 realise 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 walk through some sample scenarios that are - expected to be common deployment cases. It should be noted that this - is provided for illustrative purposes and this section is not - normative. The normative definition of DNS64 is provided in - Section 5 and the normative definition of the address transformation - algorithm is provided in [I-D.ietf-behave-address-format]. - - 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 - [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-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). - - In all the examples below, there is a 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. - - - -Bagnulo, et al. Expires January 6, 2011 [Page 21] - -Internet-Draft DNS64 July 2010 - - -7.1. Example of An-IPv6-network-to-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-IPv4-Internet setup with DNS64 in DNS - server mode - - The figure shows an IPv6 node H1 and an IPv4 node H2 with 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 WKP 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 nameserver"). - - 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. - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 22] - -Internet-Draft DNS64 July 2010 - - - 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. An example of an-IPv6-network-to-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-IPv4-Internet setup with DNS64 in stub- - resolver mode - - The figure shows an IPv6 node H1 implementing the DNS64 function and - an IPv4 node H2 with 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 WKP 64:FF9B::/96 to create - - - -Bagnulo, et al. Expires January 6, 2011 [Page 23] - -Internet-Draft DNS64 July 2010 - - - 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 nameserver"). - 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 i.e. 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 IPv6-Internet-to-an-IPv4-network setup 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. - - In some cases, this scenario can be addressed without using any form - of DNS64 function. This is so 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 [I-D.ietf-behave-address-format] 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 - - - -Bagnulo, et al. Expires January 6, 2011 [Page 24] - -Internet-Draft DNS64 July 2010 - - - 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 [I-D.ietf-behave-address-format]). - 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 modify all 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 - 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. - - The scenario for this case is depicted in the following figure: - - - - - - - - - - - - - - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 25] - -Internet-Draft DNS64 July 2010 - - - +-----------+ +----------------------+ - | | | IPv4 site | - | IPv6 | +------------+ | +----+ | - | Internet |----| IPv6/IPv4 |--|---| H2 | | - | | | Translator | | +----+ | - | | +------------+ | | - | | | | 192.0.2.1 | - | | +------------+ | | - | |----| Name server|--| | - | | | with DNS64 | | | - +-----------+ +------------+ | | - | | | | - +----+ | | - | H1 | +----------------------+ - +----+ - - Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server - mode - - The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 - address 192.0.2.1 and FQDN h2.example.com. - - The IPv6/IPv4 Translator is using a 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 from. 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. Expires January 6, 2011 [Page 26] - -Internet-Draft DNS64 July 2010 - - - 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 modification and to treat modified answers as bogus. See the - discussion above in Section 3, Section 5.5, and Section 6.2. - - -9. IANA Considerations - - This memo makes no request of IANA. - - -10. Contributors - - Dave Thaler - - Microsoft - - dthaler@windows.microsoft.com - - -11. Acknowledgements - - This draft 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, Xiangsong Cui. - - Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by - - - -Bagnulo, et al. Expires January 6, 2011 [Page 27] - -Internet-Draft DNS64 July 2010 - - - Trilogy, a research project supported by the European Commission - under its Seventh Framework Program. - - -12. References - -12.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [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. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [I-D.ietf-behave-address-format] - Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. - Li, "IPv6 Addressing of IPv4/IPv6 Translators", - draft-ietf-behave-address-format-08 (work in progress), - May 2010. - -12.2. Informative References - - [I-D.ietf-behave-v6v4-xlate-stateful] - Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful - NAT64: Network Address and Protocol Translation from IPv6 - Clients to IPv4 Servers", - draft-ietf-behave-v6v4-xlate-stateful-11 (work in - progress), March 2010. - - [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. - - - -Bagnulo, et al. Expires January 6, 2011 [Page 28] - -Internet-Draft DNS64 July 2010 - - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 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. - - [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. - - [I-D.ietf-behave-v6v4-framework] - Baker, F., Li, X., Bao, C., and K. Yin, "Framework for - IPv4/IPv6 Translation", - draft-ietf-behave-v6v4-framework-09 (work in progress), - May 2010. - - [I-D.ietf-dnsop-default-local-zones] - Andrews, M., "Locally-served DNS Zones", - draft-ietf-dnsop-default-local-zones-13 (work in - progress), April 2010. - - -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: - - 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 and a AAAA record. - - An IPv6-only client (regardless of whether the client application - is IPv6-only, the client stack is IPv6-only, or it only has an - - - -Bagnulo, et al. Expires January 6, 2011 [Page 29] - -Internet-Draft DNS64 July 2010 - - - IPv6 address) wants to access the above server. - - 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. - - RFC3484 [RFC3484] rules use longest prefix match 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 (called an NSP in - [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR - is likely to be preferred. - - This means that without further configuration: - - 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 [I-D.ietf-behave-address-format] is - used, it will probably prefer native connectivity. - - 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) - - In the "An IPv6 network to 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 prefix match rule will select native connectivity. - - The problem can be solved by properly configuring the RFC3484 - [RFC3484] policy table. - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 30] - -Internet-Draft DNS64 July 2010 - - -Authors' Addresses - - Marcelo Bagnulo - UC3M - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6249500 - Fax: - 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 - Fax: - Email: philip_matthews@magma.ca - URI: - - - Iljitsch van Beijnum - IMDEA Networks - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6246245 - Email: iljitsch@muada.com - - - - - - - -Bagnulo, et al. Expires January 6, 2011 [Page 31] - diff --git a/doc/draft/draft-ietf-behave-dns64-11.txt b/doc/draft/draft-ietf-behave-dns64-11.txt new file mode 100644 index 00000000..3c5ac813 --- /dev/null +++ b/doc/draft/draft-ietf-behave-dns64-11.txt @@ -0,0 +1,1792 @@ + + + +BEHAVE WG M. Bagnulo +Internet-Draft UC3M +Intended status: Standards Track A. Sullivan +Expires: April 4, 2011 Shinkuro + P. Matthews + Alcatel-Lucent + I. van Beijnum + IMDEA Networks + October 1, 2010 + + +DNS64: DNS extensions for Network Address Translation from IPv6 Clients + to IPv4 Servers + draft-ietf-behave-dns64-11 + +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 Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on April 4, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + + + +Bagnulo, et al. Expires April 4, 2011 [Page 1] + +Internet-Draft DNS64 October 2010 + + + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + 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. Expires April 4, 2011 [Page 2] + +Internet-Draft DNS64 October 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 11 + 5.1. Resolving AAAA queries and the answer section . . . . . . 11 + 5.1.1. The answer when there is AAAA data available . . . . . 12 + 5.1.2. The answer when there is an error . . . . . . . . . . 12 + 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 + 5.1.4. Special exclusion set for AAAA records . . . . . . . . 13 + 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 13 + 5.1.6. Data for the answer when performing synthesis . . . . 13 + 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 14 + 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 + 5.2. Generation of the IPv6 representations of IPv4 + addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Handling other Resource Records and the Additional + Section . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 16 + 5.3.2. Handling the additional section . . . . . . . . . . . 17 + 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 17 + 5.4. Assembling a synthesized response to a AAAA query . . . . 18 + 5.5. DNSSEC processing: DNS64 in validating resolver mode . . . 18 + 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 19 + 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 20 + 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 20 + 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 20 + 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 21 + 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 21 + 7. Deployment scenarios and examples . . . . . . . . . . . . . . 22 + 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 + 7.2. An example of an-IPv6-network-to-IPv4-Internet setup + with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24 + 7.3. Example of IPv6-Internet-to-an-IPv4-network setup + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 + Appendix A. Motivations and Implications of synthesizing AAAA + Resource Records when real AAAA Resource Records + + + +Bagnulo, et al. Expires April 4, 2011 [Page 3] + +Internet-Draft DNS64 October 2010 + + + exist . . . . . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 4] + +Internet-Draft DNS64 October 2010 + + +1. Introduction + + This document specifies DNS64, a mechanism that is part of the + toolbox for IPv6-IPv4 transition and co-existence. DNS64, used + together with an IPv6/IPv4 translator such as stateful NAT64 + [I-D.ietf-behave-v6v4-xlate-stateful], 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 FQDN of the server. + + These mechanisms are expected to play a critical role in the IPv4- + IPv6 transition and co-existence. 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 behaviour of DNS64. Section 3 provides a + non-normative background required to understand the interaction + between DNS64 and 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 + deployments issues. Section 7 is non-normative and provides a set of + examples and typical deployment scenarios. + + +2. Overview + + This section provides an introduction to the DNS64 mechanism. + + We assume that we have one or more IPv6/IPv4 translator boxes + + + +Bagnulo, et al. Expires April 4, 2011 [Page 5] + +Internet-Draft DNS64 October 2010 + + + 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, 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, 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 address 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 + 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. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 6] + +Internet-Draft DNS64 October 2010 + + + 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 [I-D.ietf-behave-address-format]. There are two types + of prefixes that can be used as Pref64::/n. + + The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved + by [I-D.ietf-behave-address-format] for the purpose of + representing IPv4 addresses in IPv6 address space. + + 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. + + 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 7] + +Internet-Draft DNS64 October 2010 + + + 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 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. + + 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: + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 8] + +Internet-Draft DNS64 October 2010 + + + 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 CD 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 CD clear. This works like the previous + case, except that the resolver should also set the "Authentic + Data" (AD) bit on the response. + + 7. A security-aware and validating DNS64 resolver receives a query + with the DO bit set and CD 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. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 9] + +Internet-Draft DNS64 October 2010 + + +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, 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, hosts that + can only use IPv6, as well as cases where only IPv6 connectivity + is available to the client. + + 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. + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 10] + +Internet-Draft DNS64 October 2010 + + + 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], [RFC1035] and + 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 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 Section 5.4. + + DNS64 also responds to PTR queries involving addresses containing any + of the IPv6 prefixes it uses for synthesis of AAAA RRs. + +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. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 11] + +Internet-Draft DNS64 October 2010 + + +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, 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 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 than would usually + happen in DNS operation. + + Any other RCODE is treated as though the RCODE were 0 (see sections + Section 5.1.6 and Section 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. + +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). + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 12] + +Internet-Draft DNS64 October 2010 + + +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 Pref::64/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 MAY 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). + +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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 13] + +Internet-Draft DNS64 October 2010 + + + 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 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 a the minimum of the TTL of the original A RR and + 600 seconds. 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. + +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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 14] + +Internet-Draft DNS64 October 2010 + + + 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 + t 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: + + 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 a 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. + + The algorithm MUST be reversible; i.e., it MUST be possible to + derive the original IPv4 address from the IPv6 representation. + + 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 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 manually configured, 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 + [I-D.ietf-behave-address-format] to represent the IPv4 unicast + address range + + [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as + the value for the Well-Known prefix and needs to be confirmed + whenis published as RFC.]][I-D.ietf-behave-address-format] + + A DNS64 MUST support the algorithm for generating IPv6 + representations of IPv4 addresses defined in Section 2 of + [I-D.ietf-behave-address-format]. Moreover, the aforementioned + + + +Bagnulo, et al. Expires April 4, 2011 [Page 15] + +Internet-Draft DNS64 October 2010 + + + algorithm MUST be the default algorithm used by the DNS64. While the + normative description of the algorithm is provided in + [I-D.ietf-behave-address-format], a sample description of the + algorithm and its application to different scenarios is 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 nameserver to synthesize a + CNAME mapping the IP6.ARPA namespace to the corresponding IN- + ADDR.ARPA name. In this case, the DNS64 nameserver 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 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 16] + +Internet-Draft DNS64 October 2010 + + + approach is that any useful information in the reverse tree is + available to the querying client. The disadvantage is 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 nameserver 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 nameserver that is unaware of + the NAT64 in question. The result in this case will be resolution + failure anyway, only 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. + +5.3.3. Other Resource Records + + If the DNS64 is in recursive resolver mode, then considerations + outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. + + All other RRs MUST be returned unchanged. This includes responses to + queries for A RRs. + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 17] + +Internet-Draft DNS64 October 2010 + + +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. + + 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 18] + +Internet-Draft DNS64 October 2010 + + + 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. + + +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 realise 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 19] + +Internet-Draft DNS64 October 2010 + + + 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. 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. + + +---------------+ +-------------+ + | 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 20] + +Internet-Draft DNS64 October 2010 + + + 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 + emphasising 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 + 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. + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 21] + +Internet-Draft DNS64 October 2010 + + + +---------------+ +-------------+ + | 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 realise 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 + [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-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). + + In all the examples below, there is a 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-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: + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 22] + +Internet-Draft DNS64 October 2010 + + + +---------------------+ +---------------+ + |IPv6 network | | IPv4 | + | | +-------------+ | Internet | + | |--| Name server |--| | + | | | with DNS64 | | +----+ | + | +----+ | +-------------+ | | H2 | | + | | H1 |---| | | +----+ | + | +----+ | +------------+ | 192.0.2.1 | + | |---| IPv6/IPv4 |--| | + | | | Translator | | | + | | +------------+ | | + | | | | | + +---------------------+ +---------------+ + + Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS + server mode + + The figure shows an IPv6 node H1 and an IPv4 node H2 with 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 WKP 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 nameserver"). + + 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. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 23] + +Internet-Draft DNS64 October 2010 + + + 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. An example of an-IPv6-network-to-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-IPv4-Internet setup with DNS64 in stub- + resolver mode + + The figure shows an IPv6 node H1 implementing the DNS64 function and + an IPv4 node H2 with 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 WKP 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 nameserver"). + The recursive name server does not perform the DNS64 function. + + The steps by which H1 establishes communication with H2 are: + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 24] + +Internet-Draft DNS64 October 2010 + + + 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 i.e. 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 IPv6-Internet-to-an-IPv4-network setup 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. + + In some cases, this scenario can be addressed without using any form + of DNS64 function. This is so 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 [I-D.ietf-behave-address-format] 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 [I-D.ietf-behave-address-format]). + 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 25] + +Internet-Draft DNS64 October 2010 + + + [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 modify all 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 + 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. + + 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: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server + mode + + The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4 + address 192.0.2.1 and FQDN h2.example.com. + + The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6 + representations of IPv4 addresses. The same prefix is configured in + + + +Bagnulo, et al. Expires April 4, 2011 [Page 26] + +Internet-Draft DNS64 October 2010 + + + 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 from. 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. + + 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 modification and to treat modified answers as bogus. See the + discussion above in Section 3, Section 5.5, and Section 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 DoS + attack (if resulting IPv6 addresses are not assigned to any device) + or in a flooding attack (if the resulting IPv6 addresses are assigned + to devices that do not wish to receive the traffic) or in + + + +Bagnulo, et al. Expires April 4, 2011 [Page 27] + +Internet-Draft DNS64 October 2010 + + + eavesdropping attack (in case the Pref64 is routed through the + attacker). + + +9. IANA Considerations + + This memo makes no request of IANA. + + +10. Contributors + + Dave Thaler + + Microsoft + + dthaler@windows.microsoft.com + + +11. Acknowledgements + + This draft 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, Xiangsong Cui. + + Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by + Trilogy, a research project supported by the European Commission + under its Seventh Framework Program. + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 28] + +Internet-Draft DNS64 October 2010 + + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [I-D.ietf-behave-address-format] + Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", + draft-ietf-behave-address-format-10 (work in progress), + August 2010. + +12.2. Informative References + + [I-D.ietf-behave-v6v4-xlate-stateful] + Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", + draft-ietf-behave-v6v4-xlate-stateful-12 (work in + progress), July 2010. + + [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. + + [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. + + + +Bagnulo, et al. Expires April 4, 2011 [Page 29] + +Internet-Draft DNS64 October 2010 + + + 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. + + [I-D.ietf-behave-v6v4-framework] + Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", + draft-ietf-behave-v6v4-framework-10 (work in progress), + August 2010. + + [I-D.ietf-dnsop-default-local-zones] + Andrews, M., "Locally-served DNS Zones", + draft-ietf-dnsop-default-local-zones-14 (work in + progress), September 2010. + + +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: + + 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 and a AAAA record. + + 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. + + 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 + + + +Bagnulo, et al. Expires April 4, 2011 [Page 30] + +Internet-Draft DNS64 October 2010 + + + connectivity in some cases where the DNS64 is operated in DNS server + mode. + + RFC3484 [RFC3484] rules use longest prefix match 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 (called an NSP in + [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR + is likely to be preferred. + + This means that without further configuration: + + 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 [I-D.ietf-behave-address-format] is + used, it will probably prefer native connectivity. + + 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) + + In the "An IPv6 network to 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 prefix match rule will select native connectivity. + + The problem can be solved by properly configuring the RFC3484 + [RFC3484] policy table. + + +Authors' Addresses + + Marcelo Bagnulo + UC3M + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + + Phone: +34-91-6249500 + Fax: + Email: marcelo@it.uc3m.es + URI: http://www.it.uc3m.es/marcelo + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 31] + +Internet-Draft DNS64 October 2010 + + + 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 + Fax: + Email: philip_matthews@magma.ca + URI: + + + Iljitsch van Beijnum + IMDEA Networks + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + + Phone: +34-91-6246245 + Email: iljitsch@muada.com + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires April 4, 2011 [Page 32] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt deleted file mode 100644 index eef3308e..00000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt +++ /dev/null @@ -1,785 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc. -Updates: 4033, 4034, 4035, 5155 D. Blacka -(if approved) VeriSign, Inc. -Intended status: Standards Track March 8, 2010 -Expires: September 9, 2010 - - - Clarifications and Implementation Notes for DNSSECbis - draft-ietf-dnsext-dnssec-bis-updates-10 - -Abstract - - This document is a collection of technical clarifications to the - DNSSECbis document set. It is meant to serve as a resource to - implementors as well as a repository of DNSSECbis errata. - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 9, 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 - - - -Weiler & Blacka Expires September 9, 2010 [Page 1] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 - 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 - 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 4 - 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 - 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 5 - 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 - 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 - 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5 - 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 - 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 - 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 - 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 - 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 - 4.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 - 4.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 - 4.9. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 - 4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 - 4.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 - 4.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9 - 4.10.3. Preference Based on Source . . . . . . . . . . . . . 10 - 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 - 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10 - 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10 - 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 - 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 - - - - -Weiler & Blacka Expires September 9, 2010 [Page 2] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - -1. Introduction and Terminology - - This document lists some additions, clarifications and corrections to - the core DNSSECbis specification, as originally described in - [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. - (See section 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 that need to be addressed when advancing the - DNSSECbis documents from Proposed Standard to Draft Standard. - -1.1. Structure of this Document - - The clarifications to DNSSECbis 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", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Important Additions to DNSSSECbis - - This section lists some documents that should be 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 are expected to use it. Validators that do - not support validation of responses using NSEC3 will likely be - hampered in validating large portions of the DNS space. - - [RFC5155] should be considered part of the DNS Security Document - Family as described by [RFC4033], Section 10. - - Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- - SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3, - rather than NSEC. The zone MAY indeed be using either and validators - supporting these algorithms MUST support both NSEC3 and NSEC - - - -Weiler & Blacka Expires September 9, 2010 [Page 3] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - responses. - -2.2. SHA-256 Support - - [RFC4509] describes the use of SHA-256 as a digest algorithm in - Delegation Signer (DS) RRs. [RFC5702] describes the use of the - RSASHA256 algorithm in DNSKEY and RRSIG RRs. Validator - implementations are strongly encouraged to include support for this - algorithm for DS, DNSKEY, and RRSIG records. - - Both [RFC4509] and [RFC5702] should also be considered part of the - DNS Security Document Family as described by [RFC4033], Section 10. - - -3. Security Concerns - - This section provides clarifications that, if overlooked, could lead - to security issues. - -3.1. Clarifications on Non-Existence Proofs - - [RFC4035] Section 5.4 under-specifies the algorithm for checking non- - existence proofs. In particular, the algorithm as presented would - incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove - the non-existence of RRs in the child zone. - - An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: - - o the NS bit set, - o the SOA bit clear, and - 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 non- - existence 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 non-existence of names beneath that - DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used - to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's - (original) owner name. - - - - - - - -Weiler & Blacka Expires September 9, 2010 [Page 4] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - -3.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 [RFC4035] Section 5.4 (as clarified in this document). - To be clear, a validator must not expect to receive all records at - the QNAME in response to QTYPE=*. - -3.3. Check for CNAME - - Section 5 of [RFC4035] says little 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. - -3.4. Insecure Delegation Proofs - - [RFC4035] Section 5.2 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 - needs to 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. If this is not checked, spoofed unsigned - delegations might be used to claim that an existing signed record is - not signed. - - -4. Interoperability Concerns - -4.1. Errors in Canonical Form Type Code List - - When canonicalizing DNS names, DNS names in the RDATA section of NSEC - and RRSIG resource records are not downcased. - - [RFC4034] Section 6.2 item 3 has a list of resource record types for - which DNS names in the RDATA are downcased for purposes of DNSSEC - canonical form (for both ordering and signing). That list - - - -Weiler & Blacka Expires September 9, 2010 [Page 5] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - erroneously contains NSEC and RRSIG. According to [RFC3755], DNS - names in the RDATA of NSEC and RRSIG should not be downcased. - - The same section also erroneously lists HINFO, and twice at that. - Since HINFO records contain no domain names, they are not subject to - downcasing. - -4.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 zone's - 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. - - 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. - - To paraphrase the above, when determining the security status of a - zone, a validator disregards any DS records listing unknown or - unsupported algorithms. If none are left, the zone is treated as if - it were unsigned. - - Modified to consider DS message digest algorithms, a validator also - disregards any DS records using unknown or unsupported message digest - algorithms. - -4.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 [RFC4034] Appendix A.1.1, 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 set or if any supported - algorithm appears in the DS set, no special processing will be - needed. In the remaining cases, the security status of the zone - - - -Weiler & Blacka Expires September 9, 2010 [Page 6] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - depends on whether or not the resolver supports any of the private - algorithms in use (provided that these DS records use supported hash - functions, as discussed in Section 4.2). 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. If they do not match, 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]. - -4.4. Caution About Local Policy and Multiple RRSIGs - - When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 - 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." In most - cases, a resolver would be well advised to accept any valid RRSIG as - sufficient. If the first RRSIG tested fails validation, a resolver - would be well advised to try others, giving a successful validation - result if any can be validated and giving a failure only 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, perhaps - because of 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 [RFC4641] might not work - reliably. - -4.5. Key Tag Calculation - - [RFC4034] Appendix B.1 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 4th to last and 3rd to last octets of the public key - modulus. It is, in fact, the 3rd to last and 2nd to last octets. - -4.6. Setting the DO Bit on Replies - - As stated in [RFC3225], the DO bit of the query MUST be copied in the - response. At least one implementation has done something different, - so it may be wise for resolvers to be liberal in what they accept. - - - - -Weiler & Blacka Expires September 9, 2010 [Page 7] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - -4.7. Setting the AD Bit on Queries - - The use of the AD bit in the query was previously undefined. This - document defines it as a signal indicating that the requester - understands and is interested in the value of the AD bit in the - response. This allows a requestor to indicate that it understands - the AD bit without also requesting DNSSEC data via the DO bit. - -4.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 protect legacy stub resolvers and middleboxes, validating - resolvers SHOULD only set the AD bit when a response both meets the - conditions listed in RFC 4035, section 3.2.3, and the request - contained either a set DO bit or a set AD bit. - -4.9. Setting the CD bit on Requests - - When processing a request with the CD bit set, a resolver SHOULD - attempt to return all responsive data, even data that has failed - DNSSEC validation. RFC4035 section 3.2.2 requires a resolver - processing a request with the CD bit set to set the CD bit on its - upstream queries. - - The guidance in RFC4035 is ambiguous about what to do when a cached - response was obtained with the CD bit not set. 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. - - For efficiency, a validator may wish to set the CD bit on all - upstream queries when it has a trust anchor at or above the QNAME - (and thus can reasonably expect to be able to validate the response). - -4.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. - - - - -Weiler & Blacka Expires September 9, 2010 [Page 8] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - 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. It is possible and perhaps advisable to - expose the choice of policy as a configuration option. The rest of - this section discusses some possible policies. As a default, we - suggest that validators implement the "Accept Any Success" policy - described below in Section 4.10.2 while exposing other policies as - configuration options. - -4.10.1. Closest Encloser - - One policy is to choose the trust anchor closest to the QNAME of the - response. In our example, that would be 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 - affiliated with the zone in question. This policy also minimizes the - number of public key operations needed, which may be of benefit in - resource-constrained environments. - - This policy has the disadvantage of possibly 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 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. - -4.10.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 fewer 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 - compromise of the weakest of these trust anchors while making its - relatively painless to keep old trust anchors configured in - - - -Weiler & Blacka Expires September 9, 2010 [Page 9] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - perpetuity. - -4.10.3. Preference Based on Source - - When the trust anchors have come from different sources (e.g. - automated updates ([RFC5011]), one or more DLV registries - ([RFC5074]), and manually configured), 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. - - 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 complicated: prefer a sub- - set of manually configured trust anchors (based on a configuration - option), then trust anchors that have been updated using the RFC5011 - mechanism, then trust anchors from one DLV registry, then trust - anchors from a different DLV registry, then the rest of the manually - configured trust anchors. - - -5. Minor Corrections and Clarifications - -5.1. Finding Zone Cuts - - Appendix C.8 of [RFC4035] discusses sending DS queries to the servers - for a parent zone. To do that, a resolver may first need to apply - special rules to discover what those servers are. - - As explained in Section 3.1.4.1 of [RFC4035], security-aware name - servers need to apply special processing rules to handle the DS RR, - and in some situations the resolver may also need to apply special - rules to locate the name servers for the parent zone if the resolver - does not already have the parent's NS RRset. Section 4.2 of - [RFC4035] specifies a mechanism for doing that. - -5.2. Clarifications on DNSKEY Usage - - Questions of the form "can I use a different DNSKEY for signing this - RRset" have occasionally arisen. - - The short answer is "yes, absolutely". You can even use a different - - - -Weiler & Blacka Expires September 9, 2010 [Page 10] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - DNSKEY for each RRset in a zone, subject only to practical limits on - the size of the DNSKEY RRset. However, be aware that there is no way - to tell resolvers what a particularly 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 [RFC4034] section 2.1.2. It is - 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's also - possible to use a single DNSKEY, with or without the SEP bit set, to - sign the entire zone, including the DNSKEY RRset itself. - -5.3. Errors in Examples - - The text in [RFC4035] Section C.1 refers to the examples in 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 [RFC4035] Section C.6 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. - -5.4. Errors in RFC 5155 - - A 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 - - - -Weiler & Blacka Expires September 9, 2010 [Page 11] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - contradicts with the first statement. Therefore, the correct text in - RFC 5155 3.2.1 should be: - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* - - -6. IANA Considerations - - This document specifies no IANA Actions. - - -7. Security Considerations - - This document adds two cryptographic features to the core DNSSEC - protocol. Additionally, it addresses some ambiguities and omissions - in the core DNSSEC documents that, if not recognized and addressed in - implementations, could lead to security failures. In particular, the - validation algorithm clarifications in Section 3 are critical for - preserving the security properties DNSSEC offers. Furthermore, - failure to address some of the interoperability concerns in Section 4 - could limit the ability to later change or expand DNSSEC, including - adding new algorithms. - - -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. - - - -Weiler & Blacka Expires September 9, 2010 [Page 12] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - [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. - -8.2. Informative References - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - RFC 4641, September 2006. - - [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, - July 2007. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - - [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, - November 2007. - - -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 DNSSECbis document set, have - provided text suitable for inclusion in this document. - - The lack of specificity about handling private algorithms, as - described in Section 4.3, and the lack of specificity in handling ANY - queries, as described in Section 3.2, were discovered by David - Blacka. - - The error in algorithm 1 key tag calculation, as described in - Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake - contributed text for Section 4.5. - - The bug relating to delegation NSEC RR's in Section 3.1 was found by - - - -Weiler & Blacka Expires September 9, 2010 [Page 13] - -Internet-Draft DNSSECbis Implementation Notes March 2010 - - - 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 5.3 of this document. - - The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, - Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their - substantive comments on the text of this document. - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc. - 7110 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - David Blacka - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166 - US - - Email: davidb@verisign.com - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Blacka Expires September 9, 2010 [Page 14] - - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt new file mode 100644 index 00000000..7228ad1b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt @@ -0,0 +1,785 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc. +Updates: 4033, 4034, 4035, 5155 D. Blacka +(if approved) VeriSign, Inc. +Intended status: Standards Track November 10, 2010 +Expires: May 14, 2011 + + + Clarifications and Implementation Notes for DNSSECbis + draft-ietf-dnsext-dnssec-bis-updates-12 + +Abstract + + This document is a collection of technical clarifications to the + DNSSECbis document set. It is meant to serve as a resource to + implementors as well as a repository of DNSSECbis errata. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on May 14, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Weiler & Blacka Expires May 14, 2011 [Page 1] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 + 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 + 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4 + 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 + 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5 + 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 + 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 + 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 + 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6 + 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 + 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 + 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 + 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 + 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8 + 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 + 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 + 5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8 + 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9 + 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 + 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9 + 5.10.3. Preference Based on Source . . . . . . . . . . . . . 10 + 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 + 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11 + 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 + 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + +Weiler & Blacka Expires May 14, 2011 [Page 2] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + +1. Introduction and Terminology + + This document lists some additions, clarifications and corrections to + the core DNSSECbis specification, as originally described in + [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. + (See section 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 that need to be addressed when advancing the + DNSSECbis documents from Proposed Standard to Draft Standard. + +1.1. Structure of this Document + + The clarifications to DNSSECbis 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", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + +2. Important Additions to DNSSSECbis + + This section lists some documents that should be 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 are expected to use it. Validators that do + not support validation of responses using NSEC3 will likely be + hampered in validating large portions of the DNS space. + + [RFC5155] should be considered part of the DNS Security Document + Family as described by [RFC4033], Section 10. + + Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- + SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) + signal that a zone MAY be using NSEC3, rather than NSEC. The zone + MAY indeed be using either and validators supporting these algorithms + + + +Weiler & Blacka Expires May 14, 2011 [Page 3] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + 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] should also be considered part of the + DNS Security Document Family as described by [RFC4033], Section 10. + + +3. Scaling Concerns + +3.1. Implement a BAD cache + + Section 4.7 of RFC4035 permits security-aware resolvers to implement + a BAD cache. Because of scaling concerns not discussed in this + document, that guidance has changed: security-aware resolvers SHOULD + implement a BAD cache, as described in RFC4035. + + +4. Security Concerns + + This section provides clarifications that, if overlooked, could lead + to security issues. + +4.1. Clarifications on Non-Existence Proofs + + [RFC4035] Section 5.4 under-specifies the algorithm for checking non- + existence proofs. In particular, the algorithm as presented would + incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove + the non-existence of RRs in the child zone. + + An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: + + o the NS bit set, + o the SOA bit clear, and + 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 non- + existence 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. + + + + +Weiler & Blacka Expires May 14, 2011 [Page 4] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + 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 non-existence of names beneath that + DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used + to assume the non-existence 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 [RFC4035] Section 5.4 (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 little 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. + +4.4. Insecure Delegation Proofs + + [RFC4035] Section 5.2 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 + needs to 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. If this is not checked, spoofed unsigned + delegations might be used to claim that an existing signed record is + not signed. + + +5. Interoperability Concerns + + + + + +Weiler & Blacka Expires May 14, 2011 [Page 5] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + +5.1. Errors in Canonical Form Type Code List + + When canonicalizing DNS names, DNS names in the RDATA section of NSEC + and RRSIG resource records are not downcased. + + [RFC4034] Section 6.2 item 3 has a list of resource record types for + which DNS names in the RDATA are downcased for purposes of DNSSEC + canonical form (for both ordering and signing). That list + erroneously contains NSEC and RRSIG. According to [RFC3755], DNS + names in the RDATA of NSEC and RRSIG should not be downcased. + + The same section also erroneously lists HINFO, and twice at that. + Since HINFO records contain no domain names, they are not subject to + downcasing. + +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 zone's + 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. + + 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. + + To paraphrase the above, when determining the security status of a + zone, a validator disregards any DS records listing unknown or + unsupported algorithms. If none are left, the zone is treated as if + it were unsigned. + + Modified to consider DS message digest algorithms, a validator also + disregards any 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 + + + +Weiler & Blacka Expires May 14, 2011 [Page 6] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + key algorithms shown in the DS records for those zones. In the case + of private algorithms, as described in [RFC4034] Appendix A.1.1, 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 set or if any supported + algorithm appears in the DS set, no special processing will be + 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 hash + functions, as discussed in Section 5.2). 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. If they do not match, 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, [RFC4035] Section 5.3.3 + 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." In most + cases, a resolver would be well advised to accept any valid RRSIG as + sufficient. If the first RRSIG tested fails validation, a resolver + would be well advised to try others, giving a successful validation + result if any can be validated and giving a failure only 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, perhaps + because of 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 [RFC4641] might not work + reliably. + +5.5. Key Tag Calculation + + [RFC4034] Appendix B.1 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 4th to last and 3rd to last octets of the public key + + + +Weiler & Blacka Expires May 14, 2011 [Page 7] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + modulus. It is, in fact, the 3rd to last and 2nd to last octets. + +5.6. Setting the DO Bit on Replies + + As stated in [RFC3225], the DO bit of the query MUST be copied in the + response. At least one implementation has done something different, + so it may be wise for resolvers to be liberal in what they accept. + +5.7. Setting the AD Bit on Queries + + The use of the AD bit in the query was previously undefined. This + document defines it as a signal indicating that the requester + understands and is interested in the value of the AD bit in the + response. This allows a requestor 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 protect legacy stub resolvers and middleboxes, validating + resolvers SHOULD only set the AD bit when a response both meets the + conditions listed in RFC 4035, section 3.2.3, and the request + contained either a set DO bit or a set AD bit. + +5.9. Handling Queries With the CD Bit Set + + When processing a request with the CD bit set, a resolver SHOULD + attempt to return all responsive data, even data that has failed + DNSSEC validation. RFC4035 section 3.2.2 requires a resolver + processing a request with the CD bit set to set the CD bit on its + upstream queries. + + The guidance in RFC4035 is ambiguous about what to do when a cached + response was obtained with the CD bit not set. 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. + + For efficiency, a validator SHOULD set the CD bit on upstream queries + when it has a trust anchor at or above the QNAME (and thus can + reasonably expect to be able to validate the response). + + + + + +Weiler & Blacka Expires May 14, 2011 [Page 8] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + +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. It is possible and perhaps advisable to + expose the choice of policy as a configuration option. The rest of + this section discusses some possible policies. As a default, we + suggest that validators implement the "Accept Any Success" policy + described below in Section 5.10.2 while exposing other policies as + configuration options. + +5.10.1. Closest Encloser + + One policy is to choose the trust anchor closest to the QNAME of the + response. In our example, that would be 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 + affiliated with the zone in question. This policy also minimizes the + number of public key operations needed, which may be of benefit in + resource-constrained environments. + + This policy has the disadvantage of possibly 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 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. + +5.10.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. + + + +Weiler & Blacka Expires May 14, 2011 [Page 9] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + This has the advantage of causing the fewer 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 + compromise of the weakest of these trust anchors while making its + relatively painless to keep old trust anchors configured in + perpetuity. + +5.10.3. Preference Based on Source + + When the trust anchors have come from different sources (e.g. + automated updates ([RFC5011]), one or more DLV registries + ([RFC5074]), and manually configured), 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. + + 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 complicated: prefer a sub- + set of manually configured trust anchors (based on a configuration + option), then trust anchors that have been updated using the RFC5011 + mechanism, then trust anchors from one DLV registry, then trust + anchors from a different DLV registry, then the rest of the manually + configured trust anchors. + + +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. To do that, a resolver may first need to apply + special rules to discover what those servers are. + + As explained in Section 3.1.4.1 of [RFC4035], security-aware name + servers need to apply special processing rules to handle the DS RR, + and in some situations the resolver may also need to apply special + rules to locate the name servers for the parent zone if the resolver + does not already have the parent's NS RRset. Section 4.2 of + + + +Weiler & Blacka Expires May 14, 2011 [Page 10] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + [RFC4035] specifies a mechanism for doing that. + +6.2. Clarifications on DNSKEY Usage + + Questions of the form "can I use a different DNSKEY for signing this + RRset" have occasionally arisen. + + The short answer is "yes, absolutely". You can even use a different + DNSKEY for each RRset in a zone, subject only to practical limits on + the size of the DNSKEY RRset. However, be aware that there is no way + to tell resolvers what a particularly 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 [RFC4034] section 2.1.2. It is + 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's 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 [RFC4035] Section C.1 refers to the examples in 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 [RFC4035] Section C.6 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 + + A 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: + + + + + +Weiler & Blacka Expires May 14, 2011 [Page 11] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + 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 + RFC 5155 3.2.1 should be: + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* + + +7. IANA Considerations + + This document specifies no IANA Actions. + + +8. Security Considerations + + This document adds two cryptographic features to the core DNSSEC + protocol. Additionally, it addresses some ambiguities and omissions + in the core DNSSEC documents that, if not recognized and addressed in + implementations, could lead 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. + + +9. References + +9.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", + + + +Weiler & Blacka Expires May 14, 2011 [Page 12] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + 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. + +9.2. Informative References + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + RFC 4641, September 2006. + + [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, + July 2007. + + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) + Trust Anchors", RFC 5011, September 2007. + + [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, + November 2007. + + +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 DNSSECbis document set, have + provided text suitable for inclusion in this document. + + + + +Weiler & Blacka Expires May 14, 2011 [Page 13] + +Internet-Draft DNSSECbis Implementation Notes November 2010 + + + 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. + + The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, + Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, + and Scott Rose for their substantive comments on the text of this + document. + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc. + 7110 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + + + David Blacka + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166 + US + + Email: davidb@verisign.com + + + + + + + + + + + + +Weiler & Blacka Expires May 14, 2011 [Page 14] + + -- cgit v1.2.3