From owner-svn-src-stable@FreeBSD.ORG Thu Nov 4 21:50:19 2010 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7CAB1065693; Thu, 4 Nov 2010 21:50:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 923548FC1B; Thu, 4 Nov 2010 21:50:19 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id oA4LoJVM074229; Thu, 4 Nov 2010 21:50:19 GMT (envelope-from dougb@svn.freebsd.org) Received: (from dougb@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id oA4LoJH8074225; Thu, 4 Nov 2010 21:50:19 GMT (envelope-from dougb@svn.freebsd.org) Message-Id: <201011042150.oA4LoJH8074225@svn.freebsd.org> From: Doug Barton Date: Thu, 4 Nov 2010 21:50:19 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org X-SVN-Group: stable-7 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r214812 - in stable/7/contrib/bind9: . bin/named doc/arm doc/draft doc/rfc lib/dns lib/dns/include/dns X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:50:19 -0000 Author: dougb Date: Thu Nov 4 21:50:19 2010 New Revision: 214812 URL: http://svn.freebsd.org/changeset/base/214812 Log: MFV version 9.4-ESV-R3 This version contains several fixes for DNSSEC and DLV, as well as fixes relevant to any resolving name server. Added: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-10.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-10.txt stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt stable/7/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt stable/7/contrib/bind9/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt stable/7/contrib/bind9/doc/draft/draft-yao-dnsext-bname-04.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/draft/draft-yao-dnsext-bname-04.txt stable/7/contrib/bind9/doc/rfc/rfc5933.txt - copied unchanged from r214805, vendor/bind9/dist-9.4/doc/rfc/rfc5933.txt Deleted: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-09.txt stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt Modified: stable/7/contrib/bind9/CHANGES stable/7/contrib/bind9/bin/named/query.c stable/7/contrib/bind9/doc/arm/isc-logo.eps stable/7/contrib/bind9/doc/arm/isc-logo.pdf stable/7/contrib/bind9/doc/rfc/index stable/7/contrib/bind9/lib/dns/api stable/7/contrib/bind9/lib/dns/include/dns/ncache.h stable/7/contrib/bind9/lib/dns/include/dns/types.h stable/7/contrib/bind9/lib/dns/ncache.c stable/7/contrib/bind9/lib/dns/resolver.c stable/7/contrib/bind9/lib/dns/validator.c stable/7/contrib/bind9/version Directory Properties: stable/7/contrib/bind9/ (props changed) Modified: stable/7/contrib/bind9/CHANGES ============================================================================== --- stable/7/contrib/bind9/CHANGES Thu Nov 4 21:48:39 2010 (r214811) +++ stable/7/contrib/bind9/CHANGES Thu Nov 4 21:50:19 2010 (r214812) @@ -1,3 +1,32 @@ + --- 9.4-ESV-R3 released --- + +2925. [bug] Named failed to accept uncachable negative responses + from insecure zones. [RT# 21555] + +2921. [bug] The resolver could attempt to destroy a fetch context + too soon. [RT #19878] + +2904. [bug] When using DLV, sub-zones of the zones in the DLV, + could be incorrectly marked as insecure instead of + secure leading to negative proofs failing. This was + a unintended outcome from change 2890. [RT# 21392] + +2900. [bug] The placeholder negative caching element was not + properly constructed triggering a INSIST in + dns_ncache_towire(). [RT #21346] + +2890. [bug] Handle the introduction of new trusted-keys and + DS, DLV RRsets better. [RT #21097] + +2869. [bug] Fix arguments to dns_keytable_findnextkeynode() call. + [RT #20877] + +2678. [func] Treat DS queries as if "minimal-response yes;" + was set. [RT #20258] + +2427. [func] Treat DNSKEY queries as if "minimal-response yes;" + was set. [RT #18528] + --- 9.4-ESV-R2 released --- 2876. [bug] Named could return SERVFAIL for negative responses Modified: stable/7/contrib/bind9/bin/named/query.c ============================================================================== --- stable/7/contrib/bind9/bin/named/query.c Thu Nov 4 21:48:39 2010 (r214811) +++ stable/7/contrib/bind9/bin/named/query.c Thu Nov 4 21:50:19 2010 (r214812) @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.257.18.53 2009/12/30 08:55:48 jinmei Exp $ */ +/* $Id: query.c,v 1.257.18.55 2010/07/03 23:45:26 tbox Exp $ */ /*! \file */ @@ -4654,6 +4654,13 @@ ns_query_start(ns_client_t *client) { } /* + * Turn on minimal response for DNSKEY and DS queries. + */ + if (qtype == dns_rdatatype_dnskey || qtype == dns_rdatatype_ds) + client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY | + NS_QUERYATTR_NOADDITIONAL); + + /* * If the client has requested that DNSSEC checking be disabled, * allow lookups to return pending data and instruct the resolver * to return data before validation has completed. Modified: stable/7/contrib/bind9/doc/arm/isc-logo.eps ============================================================================== Binary file (source and/or target). No diff available. Modified: stable/7/contrib/bind9/doc/arm/isc-logo.pdf ============================================================================== Binary file (source and/or target). No diff available. Copied: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-10.txt (from r214805, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-10.txt) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-10.txt Thu Nov 4 21:50:19 2010 (r214812, copy of r214805, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-10.txt) @@ -0,0 +1,1736 @@ + + + +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]. + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***