aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDoug Barton <dougb@FreeBSD.org>2010-12-08 19:33:18 +0000
committerDoug Barton <dougb@FreeBSD.org>2010-12-08 19:33:18 +0000
commit2b56ccf7fc71c6016d49509c1de6c06f3e632770 (patch)
treee6fce2d4180de8deda535ee26db4241c2126a483
parent0b3de9fd35baea98991ccb87ba9105c02d15a792 (diff)
downloadsrc-vendor/bind9/9.4-ESV-R4.tar.gz
src-vendor/bind9/9.4-ESV-R4.zip
Vendor import of BIND 9.4-ESV-R4vendor/bind9/9.4-ESV-R4
-rw-r--r--CHANGES27
-rw-r--r--RELEASE-NOTES-BIND-9.4-ESV.html123
-rw-r--r--RELEASE-NOTES-BIND-9.4-ESV.pdfbin0 -> 37550 bytes
-rw-r--r--RELEASE-NOTES-BIND-9.4-ESV.txt70
-rw-r--r--bin/named/query.c8
-rw-r--r--doc/draft/draft-ietf-behave-dns64-11.txt (renamed from doc/draft/draft-ietf-behave-dns64-10.txt)804
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt (renamed from doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt)398
-rw-r--r--lib/dns/api2
-rw-r--r--lib/dns/include/dns/db.h24
-rw-r--r--lib/dns/rbtdb.c40
-rw-r--r--lib/dns/validator.c58
-rw-r--r--lib/isc/api2
-rw-r--r--lib/isc/print.c6
-rw-r--r--release-notes.css60
-rw-r--r--version4
15 files changed, 1011 insertions, 615 deletions
diff --git a/CHANGES b/CHANGES
index 1fdd09756cd4..1e4c562f7788 100644
--- a/CHANGES
+++ b/CHANGES
@@ -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
diff --git a/RELEASE-NOTES-BIND-9.4-ESV.html b/RELEASE-NOTES-BIND-9.4-ESV.html
new file mode 100644
index 000000000000..724b3f9cd8d3
--- /dev/null
+++ b/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>
diff --git a/RELEASE-NOTES-BIND-9.4-ESV.pdf b/RELEASE-NOTES-BIND-9.4-ESV.pdf
new file mode 100644
index 000000000000..44b73c048036
--- /dev/null
+++ b/RELEASE-NOTES-BIND-9.4-ESV.pdf
Binary files differ
diff --git a/RELEASE-NOTES-BIND-9.4-ESV.txt b/RELEASE-NOTES-BIND-9.4-ESV.txt
new file mode 100644
index 000000000000..b6587741f745
--- /dev/null
+++ b/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.
diff --git a/bin/named/query.c b/bin/named/query.c
index 03f8c702be8c..5104558fdb8a 100644
--- a/bin/named/query.c
+++ b/bin/named/query.c
@@ -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_t *name, dns_rdatatype_t qtype) {
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_t *name, dns_rdatatype_t qtype) {
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;
diff --git a/doc/draft/draft-ietf-behave-dns64-10.txt b/doc/draft/draft-ietf-behave-dns64-11.txt
index 3d8200f961f3..3c5ac813f79a 100644
--- a/doc/draft/draft-ietf-behave-dns64-10.txt
+++ b/doc/draft/draft-ietf-behave-dns64-11.txt
@@ -4,17 +4,17 @@
BEHAVE WG M. Bagnulo
Internet-Draft UC3M
Intended status: Standards Track A. Sullivan
-Expires: January 6, 2011 Shinkuro
+Expires: April 4, 2011 Shinkuro
P. Matthews
Alcatel-Lucent
I. van Beijnum
IMDEA Networks
- July 5, 2010
+ October 1, 2010
DNS64: DNS extensions for Network Address Translation from IPv6 Clients
to IPv4 Servers
- draft-ietf-behave-dns64-10
+ draft-ietf-behave-dns64-11
Abstract
@@ -41,7 +41,7 @@ Status of this Memo
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.
+ This Internet-Draft will expire on April 4, 2011.
Copyright Notice
@@ -52,9 +52,9 @@ Copyright Notice
-Bagnulo, et al. Expires January 6, 2011 [Page 1]
+Bagnulo, et al. Expires April 4, 2011 [Page 1]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 2010
Provisions Relating to IETF Documents
@@ -108,9 +108,9 @@ Internet-Draft DNS64 July 2010
-Bagnulo, et al. Expires January 6, 2011 [Page 2]
+Bagnulo, et al. Expires April 4, 2011 [Page 2]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 2010
Table of Contents
@@ -118,58 +118,58 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8
- 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 10
+ 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 . . . . . 11
- 5.1.2. The answer when there is an error . . . . . . . . . . 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 . . . . . . . . 12
- 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 14
+ addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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
+ 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 . . . . 17
- 5.5. DNSSEC processing: DNS64 in recursive resolver mode . . . 17
- 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 18
+ 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 . . . . . . . . . . . . . . . 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
+ 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 . . . . . . . . . . . . . 23
+ with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24
7.3. Example of IPv6-Internet-to-an-IPv4-network setup
- DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 24
+ DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
- 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
- 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
+ 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
- 12.2. Informative 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 January 6, 2011 [Page 3]
+Bagnulo, et al. Expires April 4, 2011 [Page 3]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 2010
- exist . . . . . . . . . . . . . . . . . . . . . . . . 29
+ exist . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
@@ -220,9 +220,9 @@ Internet-Draft DNS64 July 2010
-Bagnulo, et al. Expires January 6, 2011 [Page 4]
+Bagnulo, et al. Expires April 4, 2011 [Page 4]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 2010
1. Introduction
@@ -254,17 +254,33 @@ Internet-Draft DNS64 July 2010
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.
+ 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 a non-normative introduction to the DNS64
- mechanism.
+ 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
@@ -273,14 +289,6 @@ Internet-Draft DNS64 July 2010
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.
@@ -321,6 +329,14 @@ Internet-Draft DNS64 July 2010
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
@@ -329,14 +345,6 @@ Internet-Draft DNS64 July 2010
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
@@ -377,27 +385,27 @@ Internet-Draft DNS64 July 2010
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]
+Bagnulo, et al. Expires April 4, 2011 [Page 7]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 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
+ 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
@@ -432,23 +440,26 @@ Internet-Draft DNS64 July 2010
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 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.
-
-
-
-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],
@@ -456,16 +467,16 @@ Internet-Draft DNS64 July 2010
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
+ 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 server modifies the record, the client will
- get the data back and try to validate it, and the data will be
+ 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 node receives a query with
- the DO bit clear and CD clear. In this case, the resolver
+ 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
@@ -473,18 +484,25 @@ Internet-Draft DNS64 July 2010
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.
+ 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.
- 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.
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 9]
+
+Internet-Draft DNS64 October 2010
4. Terminology
@@ -496,39 +514,52 @@ Internet-Draft DNS64 July 2010
"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.
+ 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 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 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.
+ 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.
+ 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
- any zone data file, but has been synthesized from other RRs. An
- example is a synthetic AAAA record created from an A record.
+ 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
@@ -554,17 +585,17 @@ Internet-Draft DNS64 July 2010
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].
+ 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.
@@ -578,6 +609,14 @@ Internet-Draft DNS64 July 2010
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
@@ -601,21 +640,14 @@ Internet-Draft DNS64 July 2010
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
-
+ 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
@@ -628,7 +660,18 @@ Internet-Draft DNS64 July 2010
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). .
+ (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
@@ -665,14 +708,6 @@ Internet-Draft DNS64 July 2010
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.
@@ -686,6 +721,14 @@ Internet-Draft DNS64 July 2010
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,
@@ -698,9 +741,9 @@ Internet-Draft DNS64 July 2010
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 NAME field is set to the NAME field from the A record.
- o The TYPE field is set to 28 (AAAA)
+ 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.
@@ -711,24 +754,17 @@ Internet-Draft DNS64 July 2010
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]
+ DNS64 SHOULD use a the minimum of the TTL of the original A RR and
+ 600 seconds. It is possible instead to query explicitly for the
+ SOA RR and use the result of that query, but this will increase
+ query load and time to resolution for little additional benefit.)
+ This is in keeping with the approach used in negative caching
+ ([RFC2308].
- o The RDLENGTH field is set to 16
+ o The 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
-
-
+ address from the RDATA field of the A record. The DNS64 MUST
check each A RR against configured IPv4 address ranges and select
the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
See Section 5.2 for discussion of the algorithms to be used in
@@ -737,15 +773,25 @@ Internet-Draft DNS64 July 2010
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.)
+ parallel, in order to minimize the delay.
+
+ Note: Querying in parallel will result in performing unnecessary A RR
+ queries in the case where no AAAA RR synthesis is required. A
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 14]
+
+Internet-Draft DNS64 October 2010
+
+
+ possible trade-off would be to perform them sequentially but with a
+ very short interval between them, so if we obtain a fast reply, we
+ avoid doing the additional query. (Note that this discussion is
+ relevant only if the DNS64 function needs to perform external queries
+ t fetch the RR. If the needed RR information is available locally,
+ as in the case of an authoritative server, the issue is no longer
+ relevant.)
5.2. Generation of the IPv6 representations of IPv4 addresses
@@ -777,24 +823,24 @@ Internet-Draft DNS64 July 2010
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
+ [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as
the value for the Well-Known prefix and needs to be confirmed
whenis published as RFC.]][I-D.ietf-behave-address-format]
A DNS64 MUST support the algorithm for generating IPv6
representations of IPv4 addresses defined in Section 2 of
[I-D.ietf-behave-address-format]. Moreover, the aforementioned
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 15]
+
+Internet-Draft DNS64 October 2010
+
+
algorithm MUST be the default algorithm used by the DNS64. While the
normative description of the algorithm is provided in
[I-D.ietf-behave-address-format], a sample description of the
@@ -810,10 +856,11 @@ Internet-Draft DNS64 July 2010
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:
+ configured Pref64::/n or the default Well-known prefix. There are
+ two alternatives for a DNS64 server to respond to such PTR queries.
+ A DNS64 server MUST provide one of these, and SHOULD NOT provide both
+ at the same time unless different IP6.ARPA zones require answers of
+ different sorts:
1. The first option is for the DNS64 server to respond
authoritatively for its prefixes. If the address prefix matches
@@ -833,26 +880,28 @@ Internet-Draft DNS64 July 2010
information that might be in the global DNS is unavailable to the
clients querying the DNS64.
+ 2. The second option is for the DNS64 nameserver to synthesize a
+ CNAME mapping the IP6.ARPA namespace to the corresponding IN-
+ ADDR.ARPA name. In this case, the DNS64 nameserver SHOULD ensure
+ that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA
+ name, and that there is not an existing CNAME at that name. This
+ is in order to avoid synthesizing a CNAME that makes a CNAME
+ chain longer or that does not actually point to anything. The
+ rest of the response would be the normal DNS processing. The
+ CNAME can be signed on the fly if need be. The advantage of this
-Bagnulo, et al. Expires January 6, 2011 [Page 15]
+Bagnulo, et al. Expires April 4, 2011 [Page 16]
-Internet-Draft DNS64 July 2010
+Internet-Draft DNS64 October 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.
+ approach is that any useful information in the reverse tree is
+ available to the querying client. The disadvantage is that it
+ adds additional load to the DNS64 (because CNAMEs have to be
+ synthesized for each PTR query that matches the Pref64::/n), and
+ that it may require signing on the fly.
If the address prefix does not match any Pref64::/n, then the DNS64
server MUST process the query as though it were any other query; i.e.
@@ -866,44 +915,43 @@ Internet-Draft DNS64 July 2010
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.
+ NOTE: It may appear that adding synthetic records to the
+ additional section is desirable, because clients sometimes use the
+ data in the additional section to proceed without having to re-
+ query. There is in general no promise, however, that the
+ additional section will contain all the relevant records, so any
+ client that depends on the additional section being able to
+ satisfy its needs (i.e. without additional queries) is necessarily
+ broken. An IPv6-only client that needs a AAAA record, therefore,
+ will send a query for the necessary AAAA record if it is unable to
+ find such a record in the additional section of an answer it is
+ consuming. For a correctly-functioning client, the effect would
+ be no different if the additional section were empty.The
+ alternative, of removing the A records in the additional section
+ and replacing them with synthetic AAAA records, may cause a host
+ behind a NAT64 to query directly a nameserver that is unaware of
+ the NAT64 in question. The result in this case will be resolution
+ failure anyway, only later in the resolution operation. The
+ prohibition on synthetic data in the additional section reduces,
+ but does not eliminate, the possibility of resolution failures due
+ to cached DNS data from behind the DNS64. See Section 6.
- The alternative, of removing the A records in the additional section
- and replacing them with synthetic AAAA records, may cause a host
- behind a NAT64 to query directly a nameserver that is unaware of the
- NAT64 in question. The result in this case will be resolution
- failure anyway, only later in the resolution operation.
-
- The prohibition on synthetic data in the additional section reduces,
- but does not eliminate, the possibility of resolution failures due to
- cached DNS data from behind the DNS64. See Section 6.
+5.3.3. Other Resource Records
+ If the DNS64 is in recursive resolver mode, then considerations
+ outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.
+ All other RRs MUST be returned unchanged. This includes responses to
+ queries for A RRs.
-Bagnulo, et al. Expires 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.
+Bagnulo, et al. Expires April 4, 2011 [Page 17]
+
+Internet-Draft DNS64 October 2010
- 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
@@ -928,7 +976,7 @@ Internet-Draft DNS64 July 2010
The final response from the DNS64 is subject to all the standard DNS
rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
-5.5. DNSSEC processing: DNS64 in recursive resolver mode
+5.5. DNSSEC processing: DNS64 in validating resolver mode
We consider the case where a recursive resolver that is performing
DNS64 also has a local policy to validate the answers according to
@@ -944,15 +992,6 @@ Internet-Draft DNS64 July 2010
rules about how to do validation and synthesis. In this case,
however, vDNS64 MUST NOT set the AD bit in any response.
-
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 17]
-
-Internet-Draft DNS64 July 2010
-
-
2. If CD is not set and DO is set, then vDNS64 SHOULD perform
validation. Whenever vDNS64 performs validation, it MUST
validate the negative answer for AAAA queries before proceeding
@@ -962,6 +1001,14 @@ Internet-Draft DNS64 July 2010
as a mechanism to circumvent DNSSEC. If the negative response
validates, and the response to the A query validates, then the
vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 18]
+
+Internet-Draft DNS64 October 2010
+
+
answer to the client. This is acceptable, because [RFC4035],
section 3.2.3 says that the AD bit is set by the name server side
of a security-aware recursive name server if and only if it
@@ -1001,14 +1048,6 @@ Internet-Draft DNS64 July 2010
deployment in an internetworking environment with some IPv4-only and
IPv6-only networks, it is important to realise that it is
incompatible with some things that may be deployed in an IPv4-only or
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 18]
-
-Internet-Draft DNS64 July 2010
-
-
dual-stack context.
6.1. DNS resolvers and DNS64
@@ -1018,6 +1057,14 @@ Internet-Draft DNS64 July 2010
resolvers. In a native IPv4 context, this sort of configuration may
appear to work. It is impossible to make it work properly without it
being aware of the DNS64 function, because it will likely at some
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 19]
+
+Internet-Draft DNS64 October 2010
+
+
point obtain IPv4-only glue records and attempt to use them for
resolution. The result that is returned will contain only A records,
and without the ability to perform the DNS64 function the resolver
@@ -1031,7 +1078,7 @@ Internet-Draft DNS64 July 2010
to have validation behind the DNS64, then the validator must know how
to perform the DNS64 function itself. Alternatively, the validating
host may establish a trusted connection with a DNS64, and allow the
- DNS64 recursor to do all validation on its behalf.
+ DNS64 recursive resolver to do all validation on its behalf.
6.3. DNS64 and multihomed and dual-stack hosts
@@ -1058,13 +1105,6 @@ Internet-Draft DNS64 July 2010
Figure 1: IPv6 multihomed hosts
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 19]
-
-Internet-Draft DNS64 July 2010
-
-
This example illustrates why it is generally preferable that hosts
treat DNS answers from one interface as local to that interface. The
answer received on one interface will not work on the other
@@ -1073,6 +1113,14 @@ Internet-Draft DNS64 July 2010
Note that the issue is not that there are two interfaces, but that
there are two networks involved. The same results could be achieved
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 20]
+
+Internet-Draft DNS64 October 2010
+
+
with a single interface routed to two different networks.
6.3.2. Accidental dual-stack DNS64 use
@@ -1113,20 +1161,22 @@ Internet-Draft DNS64 July 2010
only accessible using the NAT64. In this case, it is critical that
the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
that the DNS64 be aware of hosts in the LAN and provide context-
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 20]
-
-Internet-Draft DNS64 July 2010
-
-
sensitive answers ("split view" DNS answers) for hosts inside the
LAN. As with any split view DNS arrangement, operators must be
prepared for data to leak from one context to another, and for
failures to occur because nodes accessible from one context are not
accessible from the other.
+
+
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 21]
+
+Internet-Draft DNS64 October 2010
+
+
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
@@ -1148,13 +1198,6 @@ Internet-Draft DNS64 July 2010
7. Deployment scenarios and examples
- In this section, we walk through some sample scenarios that are
- expected to be common deployment cases. It should be noted that this
- is provided for illustrative purposes and this section is not
- normative. The normative definition of DNS64 is provided in
- Section 5 and the normative definition of the address transformation
- algorithm is provided in [I-D.ietf-behave-address-format].
-
In this section we illustrate how the DNS64 behaves in different
scenarios that are expected to be common. In particular we will
consider the following scenarios defined in
@@ -1170,13 +1213,6 @@ Internet-Draft DNS64 July 2010
examples, the DNS64 function learns which IPv6 prefix it needs to use
to map the IPv4 address space through manual configuration.
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 21]
-
-Internet-Draft DNS64 July 2010
-
-
7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
DNS server mode
@@ -1187,6 +1223,16 @@ Internet-Draft DNS64 July 2010
The scenario for this case is depicted in the following figure:
+
+
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 22]
+
+Internet-Draft DNS64 October 2010
+
+
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Internet |
@@ -1205,7 +1251,7 @@ Internet-Draft DNS64 July 2010
server mode
The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
- address 192.0.2.1 and FQDN h2.example.com
+ address 192.0.2.1 and FQDN h2.example.com.
The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
@@ -1224,15 +1270,6 @@ Internet-Draft DNS64 July 2010
server. The recursive name server implements DNS64
functionality.
-
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 22]
-
-Internet-Draft DNS64 July 2010
-
-
2. The recursive name server resolves the query, and discovers that
there are no AAAA records for H2.
@@ -1242,7 +1279,15 @@ Internet-Draft DNS64 July 2010
record. The IPv6 address in the AAAA record contains the prefix
assigned to the IPv6/IPv4 Translator in the upper 96 bits and the
received IPv4 address in the lower 32 bits i.e. the resulting
- IPv6 address is 64:FF9B::192.0.2.1
+ IPv6 address is 64:FF9B::192.0.2.1.
+
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 23]
+
+Internet-Draft DNS64 October 2010
+
4. H1 receives the synthetic AAAA record and sends a packet towards
H2. The packet is sent to the destination address 64:FF9B::
@@ -1277,18 +1322,10 @@ Internet-Draft DNS64 July 2010
resolver mode
The figure shows an IPv6 node H1 implementing the DNS64 function and
- an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com
+ an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com.
The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 23]
-
-Internet-Draft DNS64 July 2010
-
-
IPv6 representations of IPv4 addresses. The same prefix is
configured in the DNS64 function in H1.
@@ -1300,6 +1337,14 @@ Internet-Draft DNS64 July 2010
The steps by which H1 establishes communication with H2 are:
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 24]
+
+Internet-Draft DNS64 October 2010
+
+
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
a DNS query for a AAAA record for H2 to the recursive name
server.
@@ -1337,14 +1382,6 @@ Internet-Draft DNS64 July 2010
defined in [I-D.ietf-behave-address-format] that takes as input the
Pref64::/96 and the IPv4 address of the IPv4 node. Note that the
IPv4 address can be a public or a private address; the latter does
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 24]
-
-Internet-Draft DNS64 July 2010
-
-
not present any additional difficulty, since an NSP must be used as
Pref64::/96 (in this scenario the usage of the Well-Known prefix is
not supported as discussed in [I-D.ietf-behave-address-format]).
@@ -1356,6 +1393,14 @@ Internet-Draft DNS64 July 2010
However, there are some more dynamic scenarios, where synthesizing
AAAA RRs in this setup may be needed. In particular, when DNS Update
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 25]
+
+Internet-Draft DNS64 October 2010
+
+
[RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
nodes, there are two options: One option is to modify the DNS server
that receives the dynamic DNS updates. That would normally be the
@@ -1380,27 +1425,6 @@ Internet-Draft DNS64 July 2010
The scenario for this case is depicted in the following figure:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 25]
-
-Internet-Draft DNS64 July 2010
-
-
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +------------+ | +----+ |
@@ -1425,6 +1449,14 @@ Internet-Draft DNS64 July 2010
The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6
representations of IPv4 addresses. The same prefix is configured in
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 26]
+
+Internet-Draft DNS64 October 2010
+
+
the DNS64 function in the local name server. The name server that
implements the DNS64 function is the authoritative name server for
the local domain.
@@ -1448,15 +1480,6 @@ Internet-Draft DNS64 July 2010
H2. The packet is sent to the destination address 2001:DB8::
192.0.2.1.
-
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 26]
-
-Internet-Draft DNS64 July 2010
-
-
5. The packet is routed through the IPv6 Internet to the IPv6
interface of the IPv6/IPv4 translator and the communication flows
using the IPv6/IPv4 translator mechanisms.
@@ -1474,6 +1497,25 @@ Internet-Draft DNS64 July 2010
such modification and to treat modified answers as bogus. See the
discussion above in Section 3, Section 5.5, and Section 6.2.
+ Additionally, for the correct functioning of the translation
+ services, the DNS64 and the NAT64 need to use the same Pref64. If an
+ attacker manages to change the Pref64 used by the DNS64, the traffic
+ generated by the host that receives the synthetic reply will be
+ delivered to the altered Pref64. This can result in either a DoS
+ attack (if resulting IPv6 addresses are not assigned to any device)
+ or in a flooding attack (if the resulting IPv6 addresses are assigned
+ to devices that do not wish to receive the traffic) or in
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 27]
+
+Internet-Draft DNS64 October 2010
+
+
+ eavesdropping attack (in case the Pref64 is routed through the
+ attacker).
+
9. IANA Considerations
@@ -1505,14 +1547,6 @@ Internet-Draft DNS64 July 2010
Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 27]
-
-Internet-Draft DNS64 July 2010
-
-
Trilogy, a research project supported by the European Commission
under its Seventh Framework Program.
@@ -1527,6 +1561,14 @@ Internet-Draft DNS64 July 2010
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 28]
+
+Internet-Draft DNS64 October 2010
+
+
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
@@ -1540,8 +1582,8 @@ Internet-Draft DNS64 July 2010
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
- draft-ietf-behave-address-format-08 (work in progress),
- May 2010.
+ draft-ietf-behave-address-format-10 (work in progress),
+ August 2010.
12.2. Informative References
@@ -1549,8 +1591,8 @@ Internet-Draft DNS64 July 2010
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
- draft-ietf-behave-v6v4-xlate-stateful-11 (work in
- progress), March 2010.
+ draft-ietf-behave-v6v4-xlate-stateful-12 (work in
+ progress), July 2010.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
@@ -1562,13 +1604,6 @@ Internet-Draft DNS64 July 2010
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 28]
-
-Internet-Draft DNS64 July 2010
-
-
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
@@ -1582,6 +1617,14 @@ Internet-Draft DNS64 July 2010
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 29]
+
+Internet-Draft DNS64 October 2010
+
+
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
@@ -1594,13 +1637,13 @@ Internet-Draft DNS64 July 2010
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
- draft-ietf-behave-v6v4-framework-09 (work in progress),
- May 2010.
+ draft-ietf-behave-v6v4-framework-10 (work in progress),
+ August 2010.
[I-D.ietf-dnsop-default-local-zones]
Andrews, M., "Locally-served DNS Zones",
- draft-ietf-dnsop-default-local-zones-13 (work in
- progress), April 2010.
+ draft-ietf-dnsop-default-local-zones-14 (work in
+ progress), September 2010.
Appendix A. Motivations and Implications of synthesizing AAAA Resource
@@ -1617,14 +1660,6 @@ Appendix A. Motivations and Implications of synthesizing AAAA Resource
An IPv6-only client (regardless of whether the client application
is IPv6-only, the client stack is IPv6-only, or it only has an
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 29]
-
-Internet-Draft DNS64 July 2010
-
-
IPv6 address) wants to access the above server.
The client issues a DNS query to a DNS64 resolver.
@@ -1638,6 +1673,14 @@ Internet-Draft DNS64 July 2010
The implication of including synthetic AAAA RRs when real AAAA RRs
exist is that translated connectivity may be preferred over native
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 30]
+
+Internet-Draft DNS64 October 2010
+
+
connectivity in some cases where the DNS64 is operated in DNS server
mode.
@@ -1673,14 +1716,6 @@ Internet-Draft DNS64 July 2010
[RFC3484] policy table.
-
-
-
-Bagnulo, et al. Expires January 6, 2011 [Page 30]
-
-Internet-Draft DNS64 July 2010
-
-
Authors' Addresses
Marcelo Bagnulo
@@ -1695,6 +1730,13 @@ Authors' Addresses
URI: http://www.it.uc3m.es/marcelo
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 31]
+
+Internet-Draft DNS64 October 2010
+
+
Andrew Sullivan
Shinkuro
4922 Fairmont Avenue, Suite 250
@@ -1732,5 +1774,19 @@ Authors' Addresses
-Bagnulo, et al. Expires January 6, 2011 [Page 31]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires April 4, 2011 [Page 32]
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt
index eef3308e9270..7228ad1bd118 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt
@@ -5,12 +5,12 @@ Network Working Group S. Weiler
Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc.
-Intended status: Standards Track March 8, 2010
-Expires: September 9, 2010
+Intended status: Standards Track November 10, 2010
+Expires: May 14, 2011
Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-10
+ draft-ietf-dnsext-dnssec-bis-updates-12
Abstract
@@ -20,26 +20,20 @@ Abstract
Status of this Memo
- This Internet-Draft is submitted to IETF in full conformance with the
+ 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), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
+ 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."
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 9, 2010.
+ This Internet-Draft will expire on May 14, 2011.
Copyright Notice
@@ -49,20 +43,18 @@ Copyright Notice
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 1]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
- described in the BSD License.
+ described in the Simplified BSD License.
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 1]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
Table of Contents
@@ -72,45 +64,53 @@ Table of Contents
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 4
- 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
- 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 5
- 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
- 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
- 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
- 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5
- 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
- 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
- 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
- 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
- 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
- 4.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
- 4.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
- 4.9. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
- 4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
- 4.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
- 4.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
- 4.10.3. Preference Based on Source . . . . . . . . . . . . . 10
- 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 10
- 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10
- 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10
- 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
- 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4
+ 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
+ 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5
+ 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
+ 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
+ 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
+ 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6
+ 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
+ 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
+ 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
+ 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
+ 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8
+ 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
+ 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
+ 5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8
+ 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9
+ 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
+ 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
+ 5.10.3. Preference Based on Source . . . . . . . . . . . . . 10
+ 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10
+ 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10
+ 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
+ 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
+ 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
-Weiler & Blacka Expires September 9, 2010 [Page 2]
+
+
+
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 2]
-Internet-Draft DNSSECbis Implementation Notes March 2010
+Internet-Draft DNSSECbis Implementation Notes November 2010
1. Introduction and Terminology
@@ -158,37 +158,47 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
Family as described by [RFC4033], Section 10.
Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
- SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3,
- rather than NSEC. The zone MAY indeed be using either and validators
- supporting these algorithms MUST support both NSEC3 and NSEC
+ SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
+ signal that a zone MAY be using NSEC3, rather than NSEC. The zone
+ MAY indeed be using either and validators supporting these algorithms
-Weiler & Blacka Expires September 9, 2010 [Page 3]
+Weiler & Blacka Expires May 14, 2011 [Page 3]
-Internet-Draft DNSSECbis Implementation Notes March 2010
+Internet-Draft DNSSECbis Implementation Notes November 2010
- responses.
+ MUST support both NSEC3 and NSEC responses.
-2.2. SHA-256 Support
+2.2. SHA-2 Support
[RFC4509] describes the use of SHA-256 as a digest algorithm in
Delegation Signer (DS) RRs. [RFC5702] describes the use of the
- RSASHA256 algorithm in DNSKEY and RRSIG RRs. Validator
- implementations are strongly encouraged to include support for this
- algorithm for DS, DNSKEY, and RRSIG records.
+ RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+ Validator implementations are strongly encouraged to include support
+ for these algorithms for DS, DNSKEY, and RRSIG records.
Both [RFC4509] and [RFC5702] should also be considered part of the
DNS Security Document Family as described by [RFC4033], Section 10.
-3. Security Concerns
+3. Scaling Concerns
+
+3.1. Implement a BAD cache
+
+ Section 4.7 of RFC4035 permits security-aware resolvers to implement
+ a BAD cache. Because of scaling concerns not discussed in this
+ document, that guidance has changed: security-aware resolvers SHOULD
+ implement a BAD cache, as described in RFC4035.
+
+
+4. Security Concerns
This section provides clarifications that, if overlooked, could lead
to security issues.
-3.1. Clarifications on Non-Existence Proofs
+4.1. Clarifications on Non-Existence Proofs
[RFC4035] Section 5.4 under-specifies the algorithm for checking non-
existence proofs. In particular, the algorithm as presented would
@@ -207,6 +217,14 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
that (original) owner name other than DS RRs, and all RRs below that
owner name regardless of type.
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 4]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
Similarly, the algorithm would also allow an NSEC RR at the same
owner name as a DNAME RR, or an NSEC3 RR at the same original owner
name as a DNAME, to prove the non-existence of names beneath that
@@ -214,18 +232,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
(original) owner name.
-
-
-
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 4]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
-3.2. Validating Responses to an ANY Query
+4.2. Validating Responses to an ANY Query
[RFC4035] does not address how to validate responses when QTYPE=*.
As described in Section 6.2.2 of [RFC1034], a proper response to
@@ -241,7 +248,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
To be clear, a validator must not expect to receive all records at
the QNAME in response to QTYPE=*.
-3.3. Check for CNAME
+4.3. Check for CNAME
Section 5 of [RFC4035] says little about validating responses based
on (or that should be based on) CNAMEs. When validating a NOERROR/
@@ -250,7 +257,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
type. Without this check, an attacker could successfully transform a
positive CNAME response into a NOERROR/NODATA response.
-3.4. Insecure Delegation Proofs
+4.4. Insecure Delegation Proofs
[RFC4035] Section 5.2 specifies that a validator, when proving a
delegation is not secure, needs to check for the absence of the DS
@@ -263,24 +270,25 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
not signed.
-4. Interoperability Concerns
+5. Interoperability Concerns
-4.1. Errors in Canonical Form Type Code List
- When canonicalizing DNS names, DNS names in the RDATA section of NSEC
- and RRSIG resource records are not downcased.
-
- [RFC4034] Section 6.2 item 3 has a list of resource record types for
- which DNS names in the RDATA are downcased for purposes of DNSSEC
- canonical form (for both ordering and signing). That list
-Weiler & Blacka Expires September 9, 2010 [Page 5]
+Weiler & Blacka Expires May 14, 2011 [Page 5]
-Internet-Draft DNSSECbis Implementation Notes March 2010
+Internet-Draft DNSSECbis Implementation Notes November 2010
+5.1. Errors in Canonical Form Type Code List
+
+ When canonicalizing DNS names, DNS names in the RDATA section of NSEC
+ and RRSIG resource records are not downcased.
+
+ [RFC4034] Section 6.2 item 3 has a list of resource record types for
+ which DNS names in the RDATA are downcased for purposes of DNSSEC
+ canonical form (for both ordering and signing). That list
erroneously contains NSEC and RRSIG. According to [RFC3755], DNS
names in the RDATA of NSEC and RRSIG should not be downcased.
@@ -288,7 +296,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
Since HINFO records contain no domain names, they are not subject to
downcasing.
-4.2. Unknown DS Message Digest Algorithms
+5.2. Unknown DS Message Digest Algorithms
Section 5.2 of [RFC4035] includes rules for how to handle delegations
to zones that are signed with entirely unsupported public key
@@ -317,10 +325,18 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
disregards any DS records using unknown or unsupported message digest
algorithms.
-4.3. Private Algorithms
+5.3. Private Algorithms
As discussed above, section 5.2 of [RFC4035] requires that validators
make decisions about the security status of zones based on the public
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 6]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in [RFC4034] Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what
@@ -329,17 +345,9 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 6]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash
- functions, as discussed in Section 4.2). In these cases, the
+ functions, as discussed in Section 5.2). In these cases, the
resolver MUST retrieve the corresponding DNSKEY for each private
algorithm DS record and examine the public key field to determine the
algorithm in use. The security-aware resolver MUST ensure that the
@@ -351,7 +359,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
This clarification facilitates the broader use of private algorithms,
as suggested by [RFC4955].
-4.4. Caution About Local Policy and Multiple RRSIGs
+5.4. Caution About Local Policy and Multiple RRSIGs
When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
suggests that "the local resolver security policy determines whether
@@ -370,30 +378,30 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
method described in section 4.2.1.2 of [RFC4641] might not work
reliably.
-4.5. Key Tag Calculation
+5.5. Key Tag Calculation
[RFC4034] Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the
public key modulus. However, [RFC4034] then goes on to incorrectly
say that this is 4th to last and 3rd to last octets of the public key
- modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-4.6. Setting the DO Bit on Replies
- As stated in [RFC3225], the DO bit of the query MUST be copied in the
- response. At least one implementation has done something different,
- so it may be wise for resolvers to be liberal in what they accept.
+Weiler & Blacka Expires May 14, 2011 [Page 7]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+ modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-Weiler & Blacka Expires September 9, 2010 [Page 7]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
+5.6. Setting the DO Bit on Replies
+ As stated in [RFC3225], the DO bit of the query MUST be copied in the
+ response. At least one implementation has done something different,
+ so it may be wise for resolvers to be liberal in what they accept.
-4.7. Setting the AD Bit on Queries
+5.7. Setting the AD Bit on Queries
The use of the AD bit in the query was previously undefined. This
document defines it as a signal indicating that the requester
@@ -401,7 +409,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
response. This allows a requestor to indicate that it understands
the AD bit without also requesting DNSSEC data via the DO bit.
-4.8. Setting the AD Bit on Replies
+5.8. Setting the AD Bit on Replies
Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response. In
@@ -410,7 +418,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
conditions listed in RFC 4035, section 3.2.3, and the request
contained either a set DO bit or a set AD bit.
-4.9. Setting the CD bit on Requests
+5.9. Handling Queries With the CD Bit Set
When processing a request with the CD bit set, a resolver SHOULD
attempt to return all responsive data, even data that has failed
@@ -428,11 +436,20 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
up to five minutes.) In these cases, a new query with the CD bit set
is required.
- For efficiency, a validator may wish to set the CD bit on all
- upstream queries when it has a trust anchor at or above the QNAME
- (and thus can reasonably expect to be able to validate the response).
+ For efficiency, a validator SHOULD set the CD bit on upstream queries
+ when it has a trust anchor at or above the QNAME (and thus can
+ reasonably expect to be able to validate the response).
+
+
+
-4.10. Nested Trust Anchors
+
+Weiler & Blacka Expires May 14, 2011 [Page 8]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
+5.10. Nested Trust Anchors
A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of
@@ -441,24 +458,16 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply.
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 8]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. It is possible and perhaps advisable to
expose the choice of policy as a configuration option. The rest of
this section discusses some possible policies. As a default, we
suggest that validators implement the "Accept Any Success" policy
- described below in Section 4.10.2 while exposing other policies as
+ described below in Section 5.10.2 while exposing other policies as
configuration options.
-4.10.1. Closest Encloser
+5.10.1. Closest Encloser
One policy is to choose the trust anchor closest to the QNAME of the
response. In our example, that would be the "zone.example." trust
@@ -480,7 +489,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
trust anchor. With the "closest encloser" policy, the validator gets
validation failures.
-4.10.2. Accept Any Success
+5.10.2. Accept Any Success
Another policy is to try all applicable trust anchors until one gives
a validation result of Secure, in which case the final validation
@@ -489,6 +498,13 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
or more trust anchors lead to a Bogus result and there is no Secure
result, then the final validation result is Bogus.
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 9]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
This has the advantage of causing the fewer validation failures,
which may deliver a better user experience. If one trust anchor is
out of date (as in our above example), the user may still be able to
@@ -497,17 +513,9 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
This policy has the disadvantage of making the validator subject to
compromise of the weakest of these trust anchors while making its
relatively painless to keep old trust anchors configured in
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 9]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
perpetuity.
-4.10.3. Preference Based on Source
+5.10.3. Preference Based on Source
When the trust anchors have come from different sources (e.g.
automated updates ([RFC5011]), one or more DLV registries
@@ -532,9 +540,9 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
configured trust anchors.
-5. Minor Corrections and Clarifications
+6. Minor Corrections and Clarifications
-5.1. Finding Zone Cuts
+6.1. Finding Zone Cuts
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
for a parent zone. To do that, a resolver may first need to apply
@@ -545,22 +553,22 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
and in some situations the resolver may also need to apply special
rules to locate the name servers for the parent zone if the resolver
does not already have the parent's NS RRset. Section 4.2 of
- [RFC4035] specifies a mechanism for doing that.
-5.2. Clarifications on DNSKEY Usage
- Questions of the form "can I use a different DNSKEY for signing this
- RRset" have occasionally arisen.
- The short answer is "yes, absolutely". You can even use a different
+Weiler & Blacka Expires May 14, 2011 [Page 10]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+ [RFC4035] specifies a mechanism for doing that.
-Weiler & Blacka Expires September 9, 2010 [Page 10]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
+6.2. Clarifications on DNSKEY Usage
+ Questions of the form "can I use a different DNSKEY for signing this
+ RRset" have occasionally arisen.
+ The short answer is "yes, absolutely". You can even use a different
DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used
@@ -579,7 +587,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
possible to use a single DNSKEY, with or without the SEP bit set, to
sign the entire zone, including the DNSKEY RRset itself.
-5.3. Errors in Examples
+6.3. Errors in Examples
The text in [RFC4035] Section C.1 refers to the examples in B.1 as
"x.w.example.com" while B.1 uses "x.w.example". This is painfully
@@ -594,12 +602,21 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line.
-5.4. Errors in RFC 5155
+6.4. Errors in RFC 5155
A NSEC3 record that matches an Empty Non-Terminal effectively has no
type associated with it. This NSEC3 record has an empty type bit
map. Section 3.2.1 of [RFC5155] contains the statement:
+
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 11]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
Blocks with no types present MUST NOT be included.
However, the same section contains a regular expression:
@@ -609,41 +626,33 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
The plus sign in the regular expression indicates that there is one
or more of the preceding element. This means that there must be at
least one window block. If this window block has no types, it
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 11]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
contradicts with the first statement. Therefore, the correct text in
RFC 5155 3.2.1 should be:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
-6. IANA Considerations
+7. IANA Considerations
This document specifies no IANA Actions.
-7. Security Considerations
+8. Security Considerations
This document adds two cryptographic features to the core DNSSEC
protocol. Additionally, it addresses some ambiguities and omissions
in the core DNSSEC documents that, if not recognized and addressed in
implementations, could lead to security failures. In particular, the
- validation algorithm clarifications in Section 3 are critical for
+ validation algorithm clarifications in Section 4 are critical for
preserving the security properties DNSSEC offers. Furthermore,
- failure to address some of the interoperability concerns in Section 4
+ failure to address some of the interoperability concerns in Section 5
could limit the ability to later change or expand DNSSEC, including
adding new algorithms.
-8. References
+9. References
-8.1. Normative References
+9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
@@ -656,6 +665,14 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
+
+
+
+Weiler & Blacka Expires May 14, 2011 [Page 12]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
+
+
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -666,13 +683,6 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 12]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
-
-
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
@@ -684,7 +694,7 @@ Internet-Draft DNSSECbis Implementation Notes March 2010
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
-8.2. Informative References
+9.2. Informative References
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
@@ -711,32 +721,33 @@ Appendix A. Acknowledgments
finding errors and omissions in the DNSSECbis document set, have
provided text suitable for inclusion in this document.
- The lack of specificity about handling private algorithms, as
- described in Section 4.3, and the lack of specificity in handling ANY
- queries, as described in Section 3.2, were discovered by David
- Blacka.
- The error in algorithm 1 key tag calculation, as described in
- Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 4.5.
- The bug relating to delegation NSEC RR's in Section 3.1 was found by
+Weiler & Blacka Expires May 14, 2011 [Page 13]
+
+Internet-Draft DNSSECbis Implementation Notes November 2010
-Weiler & Blacka Expires September 9, 2010 [Page 13]
-
-Internet-Draft DNSSECbis Implementation Notes March 2010
+ The lack of specificity about handling private algorithms, as
+ described in Section 5.3, and the lack of specificity in handling ANY
+ queries, as described in Section 4.2, were discovered by David
+ Blacka.
+ The error in algorithm 1 key tag calculation, as described in
+ Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
+ contributed text for Section 5.5.
+ The bug relating to delegation NSEC RR's in Section 4.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the [RFC4035] examples were found by Roy Arends, who
- also contributed text for Section 5.3 of this document.
+ also contributed text for Section 6.3 of this document.
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
- Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their
- substantive comments on the text of this document.
+ Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+ and Scott Rose for their substantive comments on the text of this
+ document.
Authors' Addresses
@@ -769,17 +780,6 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires September 9, 2010 [Page 14]
+Weiler & Blacka Expires May 14, 2011 [Page 14]
diff --git a/lib/dns/api b/lib/dns/api
index 251eda6f4d41..02321262cded 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
LIBINTERFACE = 39
-LIBREVISION = 0
+LIBREVISION = 1
LIBAGE = 1
diff --git a/lib/dns/include/dns/db.h b/lib/dns/include/dns/db.h
index 6086bff5f703..32b4d3f75412 100644
--- a/lib/dns/include/dns/db.h
+++ b/lib/dns/include/dns/db.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004, 2005, 2007, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009, 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: db.h,v 1.76.18.14 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: db.h,v 1.76.18.16 2010/11/17 23:45:12 tbox Exp $ */
#ifndef DNS_DB_H
#define DNS_DB_H 1
@@ -184,13 +184,15 @@ struct dns_db {
/*%
* Options that can be specified for dns_db_find().
*/
-#define DNS_DBFIND_GLUEOK 0x01
-#define DNS_DBFIND_VALIDATEGLUE 0x02
-#define DNS_DBFIND_NOWILD 0x04
-#define DNS_DBFIND_PENDINGOK 0x08
-#define DNS_DBFIND_NOEXACT 0x10
-#define DNS_DBFIND_FORCENSEC 0x20
-#define DNS_DBFIND_COVERINGNSEC 0x40
+#define DNS_DBFIND_GLUEOK 0x0001
+#define DNS_DBFIND_VALIDATEGLUE 0x0002
+#define DNS_DBFIND_NOWILD 0x0004
+#define DNS_DBFIND_PENDINGOK 0x0008
+#define DNS_DBFIND_NOEXACT 0x0010
+#define DNS_DBFIND_FORCENSEC 0x0020
+#define DNS_DBFIND_COVERINGNSEC 0x0040
+#define DNS_DBFIND_FORCENSEC3 0x0080
+#define DNS_DBFIND_ADDITIONALOK 0x0100
/*@}*/
/*@{*/
@@ -649,6 +651,10 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
* For cache databases, glue is any rdataset with a trust of
* dns_trust_glue.
*
+ * \li If 'options' does not have #DNS_DBFIND_ADDITIONALOK set, then no
+ * additional records will be returned. Only caches can have
+ * rdataset with trust dns_trust_additional.
+ *
* \li If 'options' does not have #DNS_DBFIND_PENDINGOK set, then no
* pending data will be returned. This option is only meaningful for
* cache databases.
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index fb561db3cf9d..0aafb9ffb14f 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: rbtdb.c,v 1.196.18.61 2010/02/26 23:46:36 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.64 2010/11/17 10:21:01 marka Exp $ */
/*! \file */
@@ -3594,6 +3594,8 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
* If we didn't find what we were looking for...
*/
if (found == NULL ||
+ (found->trust == dns_trust_additional &&
+ ((options & DNS_DBFIND_ADDITIONALOK) == 0)) ||
(found->trust == dns_trust_glue &&
((options & DNS_DBFIND_GLUEOK) == 0)) ||
(DNS_TRUST_PENDING(found->trust) &&
@@ -4406,14 +4408,14 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
dns_rdataset_t *addedrdataset, isc_stdtime_t now)
{
rbtdb_changed_t *changed = NULL;
- rdatasetheader_t *topheader, *topheader_prev, *header;
+ rdatasetheader_t *topheader, *topheader_prev, *header, *sigheader;
unsigned char *merged;
isc_result_t result;
isc_boolean_t header_nx;
isc_boolean_t newheader_nx;
isc_boolean_t merge;
dns_rdatatype_t rdtype, covers;
- rbtdb_rdatatype_t negtype;
+ rbtdb_rdatatype_t negtype, sigtype;
dns_trust_t trust;
/*
@@ -4450,7 +4452,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
newheader_nx = NONEXISTENT(newheader) ? ISC_TRUE : ISC_FALSE;
topheader_prev = NULL;
-
+ sigheader = NULL;
negtype = 0;
if (rbtversion == NULL && !newheader_nx) {
rdtype = RBTDB_RDATATYPE_BASE(newheader->type);
@@ -4459,26 +4461,35 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
* We're adding a negative cache entry.
*/
covers = RBTDB_RDATATYPE_EXT(newheader->type);
- if (covers == dns_rdatatype_any) {
+ sigtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig,
+ covers);
+
+ for (topheader = rbtnode->data;
+ topheader != NULL;
+ topheader = topheader->next) {
/*
- * We're adding an negative cache entry
+ * If we're adding an negative cache entry
* which covers all types (NXDOMAIN,
* NODATA(QTYPE=ANY)).
*
* We make all other data stale so that the
* only rdataset that can be found at this
* node is the negative cache entry.
+ *
+ * Otherwise look for any RRSIGs of the
+ * given type so they can be marked stale
+ * later.
*/
- for (topheader = rbtnode->data;
- topheader != NULL;
- topheader = topheader->next) {
+ if (covers == dns_rdatatype_any) {
topheader->ttl = 0;
topheader->attributes |=
RDATASET_ATTR_STALE;
- }
- rbtnode->dirty = 1;
- goto find_header;
+ rbtnode->dirty = 1;
+ } else if (topheader->type == sigtype)
+ sigheader = topheader;
}
+ if (covers == dns_rdatatype_any)
+ goto find_header;
negtype = RBTDB_RDATATYPE_VALUE(covers, 0);
} else {
/*
@@ -4700,6 +4711,11 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
if (rbtversion == NULL) {
header->ttl = 0;
header->attributes |= RDATASET_ATTR_STALE;
+ if (sigheader != NULL) {
+ sigheader->ttl = 0;
+ sigheader->attributes |=
+ RDATASET_ATTR_STALE;
+ }
}
}
} else {
diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 6a1d0c9a04b4..bea5301773c2 100644
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: validator.c,v 1.119.18.59 2010/09/02 07:21:53 marka Exp $ */
+/* $Id: validator.c,v 1.119.18.60 2010/11/16 04:17:44 marka Exp $ */
/*! \file */
@@ -304,6 +304,7 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
isc_boolean_t want_destroy;
isc_result_t result;
isc_result_t eresult;
+ isc_result_t saved_result;
UNUSED(task);
INSIST(event->ev_type == DNS_EVENT_FETCHDONE);
@@ -340,6 +341,17 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
val->keyset = &val->frdataset;
}
result = validate(val, ISC_TRUE);
+ if (result == DNS_R_NOVALIDSIG &&
+ (val->attributes & VALATTR_TRIEDVERIFY) == 0)
+ {
+ saved_result = result;
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "falling back to insecurity proof");
+ val->attributes |= VALATTR_INSECURITY;
+ result = proveunsecure(val, ISC_FALSE, ISC_FALSE);
+ if (result == DNS_R_NOTINSECURE)
+ result = saved_result;
+ }
if (result != DNS_R_WAIT)
validator_done(val, result);
} else {
@@ -530,6 +542,7 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
isc_boolean_t want_destroy;
isc_result_t result;
isc_result_t eresult;
+ isc_result_t saved_result;
UNUSED(task);
INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
@@ -556,6 +569,17 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
if (val->frdataset.trust >= dns_trust_secure)
(void) get_dst_key(val, val->siginfo, &val->frdataset);
result = validate(val, ISC_TRUE);
+ if (result == DNS_R_NOVALIDSIG &&
+ (val->attributes & VALATTR_TRIEDVERIFY) == 0)
+ {
+ saved_result = result;
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "falling back to insecurity proof");
+ val->attributes |= VALATTR_INSECURITY;
+ result = proveunsecure(val, ISC_FALSE, ISC_FALSE);
+ if (result == DNS_R_NOTINSECURE)
+ result = saved_result;
+ }
if (result != DNS_R_WAIT)
validator_done(val, result);
} else {
@@ -1480,9 +1504,11 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
* was known and "sufficiently good".
*/
if (!dns_resolver_algorithm_supported(val->view->resolver,
- event->name,
- val->siginfo->algorithm))
+ event->name,
+ val->siginfo->algorithm)) {
+ resume = ISC_FALSE;
continue;
+ }
if (!resume) {
result = get_key(val, val->siginfo);
@@ -1493,16 +1519,12 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
}
/*
- * The key is insecure, so mark the data as insecure also.
+ * There isn't a secure DNSKEY for this signature so move
+ * onto the next RRSIG.
*/
if (val->key == NULL) {
- if (val->mustbesecure) {
- validator_log(val, ISC_LOG_WARNING,
- "must be secure failure");
- return (DNS_R_MUSTBESECURE);
- }
- markanswer(val, "validate");
- return (ISC_R_SUCCESS);
+ resume = ISC_FALSE;
+ continue;
}
do {
@@ -3123,6 +3145,20 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
*/
result = DNS_R_NOVALIDNSEC;
goto out;
+ } else if (DNS_TRUST_PENDING(val->frdataset.trust) ||
+ DNS_TRUST_ANSWER(val->frdataset.trust)) {
+ /*
+ * If we have "trust == answer" then this namespace
+ * has switched from insecure to should be secure.
+ */
+ result = create_validator(val, tname,
+ dns_rdatatype_ds,
+ &val->frdataset,
+ NULL, dsvalidated,
+ "proveunsecure");
+ if (result != ISC_R_SUCCESS)
+ goto out;
+ return (DNS_R_WAIT);
} else if (val->frdataset.trust < dns_trust_secure) {
/*
* This shouldn't happen, since the negative
diff --git a/lib/isc/api b/lib/isc/api
index 8216a30f0a2c..2caba4267223 100644
--- a/lib/isc/api
+++ b/lib/isc/api
@@ -1,3 +1,3 @@
LIBINTERFACE = 37
-LIBREVISION = 0
+LIBREVISION = 1
LIBAGE = 1
diff --git a/lib/isc/print.c b/lib/isc/print.c
index 191ad24a664f..d8e72417d7bf 100644
--- a/lib/isc/print.c
+++ b/lib/isc/print.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2006, 2008 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2001, 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: print.c,v 1.27.18.5 2008/02/18 23:46:01 tbox Exp $ */
+/* $Id: print.c,v 1.27.18.7 2010/10/18 23:45:45 tbox Exp $ */
/*! \file */
@@ -468,7 +468,7 @@ isc_print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
if (width > 0) {
count += width;
width--;
- if (left) {
+ if (left && size > 1) {
*str++ = c;
size--;
}
diff --git a/release-notes.css b/release-notes.css
new file mode 100644
index 000000000000..8cbbf61f98bc
--- /dev/null
+++ b/release-notes.css
@@ -0,0 +1,60 @@
+/*
+ * 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.css,v 1.1.2.2 2010/11/29 01:15:44 tbox Exp $ */
+
+body {
+ background-color: #ffffff;
+ color: #333333;
+ font-family: "Helvetica Neue", "ArialMT", "Verdana", "Arial", "Helvetica", sans-serif;
+ font-size: 14px;
+ line-height: 18px;
+ margin: 2em auto;
+ width: 700px;
+}
+
+.command {
+ font-family: "Courier New", "Courier", monospace;
+ font-weight: normal;
+}
+
+.note {
+ background-color: #ddeedd;
+ border: 1px solid #aaccaa;
+ margin: 1em 0 1em 0;
+ padding: 0.5em 1em 0.5em 1em;
+ -moz-border-radius: 10px;
+ -webkit-border-radius: 10px;
+}
+
+.screen {
+ background-color: #ffffee;
+ border: 1px solid #ddddaa;
+ padding: 0.25em 1em 0.25em 1em;
+ margin: 1em 0 1em 0;
+ -moz-border-radius: 10px;
+ -webkit-border-radius: 10px;
+}
+
+.section.title {
+ font-size: 150%;
+ font-weight: bold;
+}
+
+.section.section.title {
+ font-size: 130%;
+ font-weight: bold;
+}
diff --git a/version b/version
index e8ebbf9f4c83..714863943869 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.31 2010/09/02 07:23:32 marka Exp $
+# $Id: version,v 1.29.134.32 2010/11/18 01:34:50 marka Exp $
#
# This file must follow /bin/sh rules. It is imported directly via
# configure.
@@ -7,4 +7,4 @@ MAJORVER=9
MINORVER=4
PATCHVER=
RELEASETYPE=-ESV
-RELEASEVER=-R3
+RELEASEVER=-R4