svn commit: r216302 - in vendor/bind9/dist-9.4: . bin/named
doc/draft lib/dns lib/dns/include/dns lib/isc
Doug Barton
dougb at FreeBSD.org
Wed Dec 8 19:33:19 UTC 2010
Author: dougb
Date: Wed Dec 8 19:33:18 2010
New Revision: 216302
URL: http://svn.freebsd.org/changeset/base/216302
Log:
Vendor import of BIND 9.4-ESV-R4
Added:
vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html (contents, props changed)
vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf (contents, props changed)
vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt (contents, props changed)
vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt (contents, props changed)
vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt (contents, props changed)
vendor/bind9/dist-9.4/release-notes.css (contents, props changed)
Deleted:
vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-10.txt
vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
Modified:
vendor/bind9/dist-9.4/CHANGES
vendor/bind9/dist-9.4/bin/named/query.c
vendor/bind9/dist-9.4/lib/dns/api
vendor/bind9/dist-9.4/lib/dns/include/dns/db.h
vendor/bind9/dist-9.4/lib/dns/rbtdb.c
vendor/bind9/dist-9.4/lib/dns/validator.c
vendor/bind9/dist-9.4/lib/isc/api
vendor/bind9/dist-9.4/lib/isc/print.c
vendor/bind9/dist-9.4/version
Modified: vendor/bind9/dist-9.4/CHANGES
==============================================================================
--- vendor/bind9/dist-9.4/CHANGES Wed Dec 8 17:34:07 2010 (r216301)
+++ vendor/bind9/dist-9.4/CHANGES Wed Dec 8 19:33:18 2010 (r216302)
@@ -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
Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.html Wed Dec 8 19:33:18 2010 (r216302)
@@ -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>
Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.pdf
==============================================================================
Binary file. No diff available.
Added: vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ vendor/bind9/dist-9.4/RELEASE-NOTES-BIND-9.4-ESV.txt Wed Dec 8 19:33:18 2010 (r216302)
@@ -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: vendor/bind9/dist-9.4/bin/named/query.c
==============================================================================
--- vendor/bind9/dist-9.4/bin/named/query.c Wed Dec 8 17:34:07 2010 (r216301)
+++ vendor/bind9/dist-9.4/bin/named/query.c Wed Dec 8 19:33:18 2010 (r216302)
@@ -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;
Added: 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)
+++ vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-11.txt Wed Dec 8 19:33:18 2010 (r216302)
@@ -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 ***
More information about the svn-src-vendor
mailing list