Date: Thu, 9 Dec 2010 21:11:53 +0000 (UTC) From: Doug Barton <dougb@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org Subject: svn commit: r216336 - in stable/7/contrib/bind9: . bin/named doc/draft lib/dns lib/dns/include/dns lib/isc Message-ID: <201012092111.oB9LBrp0050900@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dougb Date: Thu Dec 9 21:11:53 2010 New Revision: 216336 URL: http://svn.freebsd.org/changeset/base/216336 Log: MFV: vendor/bind9/dist-9.4 Update to version 9.4-ESV-R4, the latest from ISC, which addresses the following security vulnerabilities. For more information regarding these issues please see: http://www.isc.org/announcement/guidance-regarding-dec-1st-2010-security-advisories 1. Cache incorrectly allows ncache and rrsig for the same type http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3613 Affects resolver operators whose servers are open to potential attackers. Triggering the bug will cause the server to crash. This bug applies even if you do not have DNSSEC enabled. 2. Key algorithm rollover http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3614 Affects resolver operators who are validating with DNSSEC, and querying zones which are in a key rollover period. The bug will cause answers to incorrectly be marked as insecure. Approved by: re (kib) Added: stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.html - copied unchanged from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.pdf - copied unchanged from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.txt - copied unchanged from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-11.txt - copied unchanged from r216303, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt - copied unchanged from r216303, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt stable/7/contrib/bind9/release-notes.css - copied unchanged from r216303, vendor/bind9/dist-9.4/release-notes.css Deleted: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-10.txt stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt Modified: stable/7/contrib/bind9/CHANGES stable/7/contrib/bind9/bin/named/query.c stable/7/contrib/bind9/lib/dns/api stable/7/contrib/bind9/lib/dns/include/dns/db.h stable/7/contrib/bind9/lib/dns/rbtdb.c stable/7/contrib/bind9/lib/dns/validator.c stable/7/contrib/bind9/lib/isc/api stable/7/contrib/bind9/lib/isc/print.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 Dec 9 21:02:22 2010 (r216335) +++ stable/7/contrib/bind9/CHANGES Thu Dec 9 21:11:53 2010 (r216336) @@ -1,3 +1,30 @@ + --- 9.4-ESV-R4 released --- + +2970. [security] Adding a NO DATA negative cache entry failed to clear + any matching RRSIG records. A subsequent lookup of + of NO DATA cache entry could trigger a INSIST when the + unexpected RRSIG was also returned with the NO DATA + cache entry. + + CVE-2010-3613, VU#706148. [RT #22288] + +2968. [security] Named could fail to prove a data set was insecure + before marking it as insecure. One set of conditions + that can trigger this occurs naturally when rolling + DNSKEY algorithms. + + CVE-2010-3614, VU#837744. [RT #22309] + +2966. [bug] isc_print_vsnprintf() failed to check if there was + space available in the buffer when adding a left + justified character with a non zero width, + (e.g. "%-1c"). [RT #22270] + +2962. [port] win32: add more dependancies to BINDBuild.dsw. + [RT #22062] + +2786. [bug] Additional could be promoted to answer. [RT #20663] + --- 9.4-ESV-R3 released --- 2925. [bug] Named failed to accept uncachable negative responses Copied: stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.html (from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.html Thu Dec 9 21:11:53 2010 (r216336, copy of r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html) @@ -0,0 +1,123 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">; +<!-- + - Copyright (C) 2010 Internet Systems Consortium, Inc. ("ISC") + - + - Permission to use, copy, modify, and/or distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: RELEASE-NOTES-BIND-9.4-ESV.html,v 1.1.2.2 2010/11/29 01:15:44 tbox Exp $ --> + +<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><link rel="stylesheet" type="text/css" href="release-notes.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article"><div class="titlepage"><hr /></div> + + <div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111797"></a>Introduction</h2></div></div></div> + + <p> + BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV. + </p> + <p> + This document summarizes changes from BIND 9.4-ESV-R3 to BIND 9.4-ESV-R4. + Please see the CHANGES file in the source code release for a + complete list of all changes. + </p> + </div> + + <div class="section" title="Download"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111880"></a>Download</h2></div></div></div> + + <p> + The latest release of BIND 9 software can always be found + on our web site at + <a class="ulink" href="http://www.isc.org/software/bind" target="_top">http://www.isc.org/software/bind</a>. + There you will find additional information about each release, + source code, and some pre-compiled versions for certain operating + systems. + </p> + </div> + + <div class="section" title="Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111815"></a>Support</h2></div></div></div> + + <p>Product support information is available on + <a class="ulink" href="http://www.isc.org/services/support" target="_top">http://www.isc.org/services/support</a>; + for paid support options. Free support is provided by our user + community via a mailing list. Information on all public email + lists is available at + <a class="ulink" href="https://lists.isc.org/mailman/listinfo" target="_top">https://lists.isc.org/mailman/listinfo</a>. + </p> + </div> + + <div class="section" title="New Features"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111957"></a>New Features</h2></div></div></div> + + <div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111972"></a>9.4-ESV-R4</h3></div></div></div> + + <p>None.</p> + </div> + </div> + + <div class="section" title="Feature Changes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111905"></a>Feature Changes</h2></div></div></div> + + <div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111988"></a>9.4-ESV-R4</h3></div></div></div> + + <p>None.</p> + </div> + </div> + + <div class="section" title="Security Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111999"></a>Security Fixes</h2></div></div></div> + + <div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112004"></a>9.4-ESV-R4</h3></div></div></div> + + <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> + Adding a NO DATA signed negative response to cache failed to clear + any matching RRSIG records already in cache. A subsequent lookup + of the cached NO DATA entry could crash named (INSIST) when the + unexpected RRSIG was also returned with the NO DATA cache entry. + [RT #22288] [CVE-2010-3613] [VU#706148] + </li><li class="listitem"> + BIND, acting as a DNSSEC validator, was determining if the NS RRset + is insecure based on a value that could mean either that the RRset + is actually insecure or that there wasn't a matching key for the RRSIG + in the DNSKEY RRset when resuming from validating the DNSKEY RRset. + This can happen when in the middle of a DNSKEY algorithm rollover, + when two different algorithms were used to sign a zone but only the + new set of keys are in the zone DNSKEY RRset. + [RT #22309] [CVE-2010-3614] [VU#837744] + </li></ul></div> + </div> + </div> + + <div class="section" title="Bug Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112029"></a>Bug Fixes</h2></div></div></div> + + <div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112035"></a>9.4-ESV-R4</h3></div></div></div> + + <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> + isc_print_vsnprintf() failed to check if there was + space available in the buffer when adding a left + justified character with a non zero width, + (e.g. "%-1c"). + [RT #22270] + </li><li class="listitem"> + win32: add more dependencies to BINDBuild.dsw. + [RT #22062] + </li></ul></div> + </div> + </div> + + <div class="section" title="Thank You"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112054"></a>Thank You</h2></div></div></div> + + <p> + Thank you to everyone who assisted us in making this release possible. + If you would like to contribute to ISC to assist us in continuing to make + quality open source software, please visit our donations page at + <a class="ulink" href="http://www.isc.org/supportisc" target="_top">http://www.isc.org/supportisc</a>. + </p> + </div> +</div></body></html> Copied: stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.pdf (from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf) ============================================================================== Binary file (source and/or target). No diff available. Copied: stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.txt (from r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ stable/7/contrib/bind9/RELEASE-NOTES-BIND-9.4-ESV.txt Thu Dec 9 21:11:53 2010 (r216336, copy of r216303, vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt) @@ -0,0 +1,70 @@ + __________________________________________________________________ + +Introduction + + BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV. + + This document summarizes changes from BIND 9.4-ESV-R3 to BIND + 9.4-ESV-R4. Please see the CHANGES file in the source code release for + a complete list of all changes. + +Download + + The latest release of BIND 9 software can always be found on our web + site at http://www.isc.org/software/bind. There you will find + additional information about each release, source code, and some + pre-compiled versions for certain operating systems. + +Support + + Product support information is available on + http://www.isc.org/services/support for paid support options. Free + support is provided by our user community via a mailing list. + Information on all public email lists is available at + https://lists.isc.org/mailman/listinfo. + +New Features + +9.4-ESV-R4 + + None. + +Feature Changes + +9.4-ESV-R4 + + None. + +Security Fixes + +9.4-ESV-R4 + + * Adding a NO DATA signed negative response to cache failed to clear + any matching RRSIG records already in cache. A subsequent lookup of + the cached NO DATA entry could crash named (INSIST) when the + unexpected RRSIG was also returned with the NO DATA cache entry. + [RT #22288] [CVE-2010-3613] [VU#706148] + * BIND, acting as a DNSSEC validator, was determining if the NS RRset + is insecure based on a value that could mean either that the RRset + is actually insecure or that there wasn't a matching key for the + RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY + RRset. This can happen when in the middle of a DNSKEY algorithm + rollover, when two different algorithms were used to sign a zone + but only the new set of keys are in the zone DNSKEY RRset. [RT + #22309] [CVE-2010-3614] [VU#837744] + +Bug Fixes + +9.4-ESV-R4 + + * isc_print_vsnprintf() failed to check if there was space available + in the buffer when adding a left justified character with a non + zero width, (e.g. "%-1c"). [RT #22270] + * win32: add more dependencies to BINDBuild.dsw. [RT #22062] + +Thank You + + Thank you to everyone who assisted us in making this release possible. + If you would like to contribute to ISC to assist us in continuing to + make quality open source software, please visit our donations page at + http://www.isc.org/supportisc. Modified: stable/7/contrib/bind9/bin/named/query.c ============================================================================== --- stable/7/contrib/bind9/bin/named/query.c Thu Dec 9 21:02:22 2010 (r216335) +++ stable/7/contrib/bind9/bin/named/query.c Thu Dec 9 21:11:53 2010 (r216336) @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.257.18.55 2010/07/03 23:45:26 tbox Exp $ */ +/* $Id: query.c,v 1.257.18.56 2010/11/17 10:21:01 marka Exp $ */ /*! \file */ @@ -1129,7 +1129,8 @@ query_addadditional(void *arg, dns_name_ goto cleanup; } result = dns_db_find(db, name, version, type, - client->query.dboptions | DNS_DBFIND_GLUEOK, + client->query.dboptions | + DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK, client->now, &node, fname, rdataset, sigrdataset); if (result == DNS_R_GLUE && @@ -1614,7 +1615,8 @@ query_addadditional2(void *arg, dns_name goto try_glue; result = dns_db_find(db, name, version, type, - client->query.dboptions | DNS_DBFIND_GLUEOK, + client->query.dboptions | + DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK, client->now, &node, fname, NULL, NULL); if (result == ISC_R_SUCCESS) goto found; Copied: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-11.txt (from r216303, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-11.txt Thu Dec 9 21:11:53 2010 (r216336, copy of r216303, vendor/bind9/dist-9.4/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, *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012092111.oB9LBrp0050900>