aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDoug Barton <dougb@FreeBSD.org>2010-03-29 20:15:32 +0000
committerDoug Barton <dougb@FreeBSD.org>2010-03-29 20:15:32 +0000
commitbbf1dfca0159346fbb573e7a4f4c150c5906d6ac (patch)
treed51b9c271ccfb336a7f7ff7785ad82ef4c7d80ff
parente6787144c0a7f2ccb1b75e05abbd390f0fd225cd (diff)
Vendor import of BIND 9.4-ESV-R1vendor/bind9/9.4-ESV-R1
Notes
Notes: svn path=/vendor/bind9/dist-9.4/; revision=205856 svn path=/vendor/bind9/9.4-ESV-R1/; revision=205857; tag=vendor/bind9/9.4-ESV-R1
-rw-r--r--CHANGES4
-rw-r--r--bin/named/server.c6
-rw-r--r--doc/arm/Bv9ARM-book.xml12
-rw-r--r--doc/arm/Bv9ARM.ch01.html52
-rw-r--r--doc/arm/Bv9ARM.ch02.html24
-rw-r--r--doc/arm/Bv9ARM.ch03.html28
-rw-r--r--doc/arm/Bv9ARM.ch04.html72
-rw-r--r--doc/arm/Bv9ARM.ch05.html8
-rw-r--r--doc/arm/Bv9ARM.ch06.html148
-rw-r--r--doc/arm/Bv9ARM.ch07.html16
-rw-r--r--doc/arm/Bv9ARM.ch08.html20
-rw-r--r--doc/arm/Bv9ARM.ch09.html182
-rw-r--r--doc/arm/Bv9ARM.ch10.html4
-rw-r--r--doc/arm/Bv9ARM.html148
-rw-r--r--doc/arm/Bv9ARM.pdf3943
-rw-r--r--doc/arm/man.dig.html22
-rw-r--r--doc/arm/man.dnssec-keygen.html16
-rw-r--r--doc/arm/man.dnssec-signzone.html14
-rw-r--r--doc/arm/man.host.html12
-rw-r--r--doc/arm/man.named-checkconf.html14
-rw-r--r--doc/arm/man.named-checkzone.html14
-rw-r--r--doc/arm/man.named.html18
-rw-r--r--doc/arm/man.rndc-confgen.html14
-rw-r--r--doc/arm/man.rndc.conf.html14
-rw-r--r--doc/arm/man.rndc.html14
-rw-r--r--doc/draft/draft-ietf-6man-text-addr-representation-07.txt (renamed from doc/draft/draft-ietf-6man-text-addr-representation-01.txt)578
-rw-r--r--doc/draft/draft-ietf-behave-dns64-01.txt1624
-rw-r--r--doc/draft/draft-ietf-behave-dns64-06.txt1680
-rw-r--r--doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt (renamed from doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt)600
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt (renamed from doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt)86
-rw-r--r--doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt (renamed from doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt)270
-rw-r--r--doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt504
-rw-r--r--doc/draft/draft-kerr-ixfr-only-01.txt336
-rw-r--r--lib/dns/include/dns/rdataset.h20
-rw-r--r--lib/dns/include/dns/resolver.h46
-rw-r--r--lib/dns/include/dns/result.h11
-rw-r--r--lib/dns/include/dns/validator.h6
-rw-r--r--lib/dns/ncache.c8
-rw-r--r--lib/dns/rbtdb.c40
-rw-r--r--lib/dns/rdatalist.c8
-rw-r--r--lib/dns/rdataset.c25
-rw-r--r--lib/dns/rdataslab.c6
-rw-r--r--lib/dns/resolver.c417
-rw-r--r--lib/dns/result.c12
-rw-r--r--lib/dns/sdb.c6
-rw-r--r--lib/dns/sdlz.c6
-rw-r--r--lib/dns/validator.c160
-rw-r--r--lib/dns/view.c11
-rw-r--r--version4
49 files changed, 6416 insertions, 4867 deletions
diff --git a/CHANGES b/CHANGES
index fbc9bfd7cd54..3b209d86e48b 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,7 @@
+ --- 9.4-ESV-R1 released ---
+
+2852. [bug] Handle broken DNSSEC trust chains better. [RT #15619]
+
--- 9.4-ESV released ---
2831. [security] Do not attempt to validate or cache
diff --git a/bin/named/server.c b/bin/named/server.c
index 7bb2a6e0e298..c3fc858ab92b 100644
--- a/bin/named/server.c
+++ b/bin/named/server.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: server.c,v 1.419.18.75 2009/07/11 04:30:49 marka Exp $ */
+/* $Id: server.c,v 1.419.18.77 2010/02/26 23:46:32 tbox Exp $ */
/*! \file */
@@ -4563,6 +4563,8 @@ dumpdone(void *arg, isc_result_t result) {
}
if (dctx->cache != NULL) {
dns_adb_dump(dctx->view->view->adb, dctx->fp);
+ dns_resolver_printbadcache(dctx->view->view->resolver,
+ dctx->fp);
dns_db_detach(&dctx->cache);
}
if (dctx->dumpzones) {
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index 9d05255eeaaa..f2dce2132046 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -2,7 +2,7 @@
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY mdash "&#8212;">]>
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.111 2009/09/24 21:38:50 jinmei Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.113 2010/02/26 23:46:35 tbox Exp $ -->
<book xmlns:xi="http://www.w3.org/2001/XInclude">
<title>BIND 9 Administrator Reference Manual</title>
@@ -30,6 +30,7 @@
<year>2007</year>
<year>2008</year>
<year>2009</year>
+ <year>2010</year>
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
</copyright>
<copyright>
@@ -7422,6 +7423,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
<literal>1800</literal> (30 minutes).
</para>
+ <para>
+ Lame-ttl also controls the amount of time DNSSEC
+ validation failures are cached. There is a minimum
+ of 30 seconds applied to bad cache entries if the
+ lame-ttl is set to less than 30 seconds.
+ </para>
+
</listitem>
</varlistentry>
diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html
index 40005894c068..ac8f0a9d6971 100644
--- a/doc/arm/Bv9ARM.ch01.html
+++ b/doc/arm/Bv9ARM.ch01.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.29 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.30 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,17 +45,17 @@
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">Name Servers in Multiple Roles</a></span></dt>
</dl></dd>
</dl>
</div>
@@ -71,7 +71,7 @@
</p>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2563409"></a>Scope of Document</h2></div></div></div>
+<a name="id2563412"></a>Scope of Document</h2></div></div></div>
<p>
The Berkeley Internet Name Domain
(<acronym class="acronym">BIND</acronym>) implements a
@@ -87,7 +87,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564388"></a>Organization of This Document</h2></div></div></div>
+<a name="id2564391"></a>Organization of This Document</h2></div></div></div>
<p>
In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces
the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span>
@@ -116,7 +116,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564528"></a>Conventions Used in This Document</h2></div></div></div>
+<a name="id2564531"></a>Conventions Used in This Document</h2></div></div></div>
<p>
In this document, we use the following general typographic
conventions:
@@ -243,7 +243,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564641"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<a name="id2564712"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
<p>
The purpose of this document is to explain the installation
and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
@@ -253,7 +253,7 @@
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564662"></a>DNS Fundamentals</h3></div></div></div>
+<a name="id2564733"></a>DNS Fundamentals</h3></div></div></div>
<p>
The Domain Name System (DNS) is a hierarchical, distributed
database. It stores information for mapping Internet host names to
@@ -273,7 +273,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564696"></a>Domains and Domain Names</h3></div></div></div>
+<a name="id2564768"></a>Domains and Domain Names</h3></div></div></div>
<p>
The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
organizational or administrative boundaries. Each node of the tree,
@@ -319,7 +319,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567170"></a>Zones</h3></div></div></div>
+<a name="id2567173"></a>Zones</h3></div></div></div>
<p>
To properly operate a name server, it is important to understand
the difference between a <span class="emphasis"><em>zone</em></span>
@@ -372,7 +372,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567246"></a>Authoritative Name Servers</h3></div></div></div>
+<a name="id2567250"></a>Authoritative Name Servers</h3></div></div></div>
<p>
Each zone is served by at least
one <span class="emphasis"><em>authoritative name server</em></span>,
@@ -389,7 +389,7 @@
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567270"></a>The Primary Master</h4></div></div></div>
+<a name="id2567273"></a>The Primary Master</h4></div></div></div>
<p>
The authoritative server where the master copy of the zone
data is maintained is called the
@@ -409,7 +409,7 @@
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567300"></a>Slave Servers</h4></div></div></div>
+<a name="id2567303"></a>Slave Servers</h4></div></div></div>
<p>
The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
@@ -425,7 +425,7 @@
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567389"></a>Stealth Servers</h4></div></div></div>
+<a name="id2567393"></a>Stealth Servers</h4></div></div></div>
<p>
Usually all of the zone's authoritative servers are listed in
NS records in the parent zone. These NS records constitute
@@ -460,7 +460,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567419"></a>Caching Name Servers</h3></div></div></div>
+<a name="id2567422"></a>Caching Name Servers</h3></div></div></div>
<p>
The resolver libraries provided by most operating systems are
<span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
@@ -487,7 +487,7 @@
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2567523"></a>Forwarding</h4></div></div></div>
+<a name="id2567526"></a>Forwarding</h4></div></div></div>
<p>
Even a caching name server does not necessarily perform
the complete recursive lookup itself. Instead, it can
@@ -514,7 +514,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567549"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<a name="id2567553"></a>Name Servers in Multiple Roles</h3></div></div></div>
<p>
The <acronym class="acronym">BIND</acronym> name server can
simultaneously act as
diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html
index 91bc2c525b7a..32149884cbf6 100644
--- a/doc/arm/Bv9ARM.ch02.html
+++ b/doc/arm/Bv9ARM.ch02.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.30 2009/07/11 01:31:47 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.31 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,16 +45,16 @@
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">Supported Operating Systems</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567584"></a>Hardware requirements</h2></div></div></div>
+<a name="id2567587"></a>Hardware requirements</h2></div></div></div>
<p>
<acronym class="acronym">DNS</acronym> hardware requirements have
traditionally been quite modest.
@@ -73,7 +73,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567610"></a>CPU Requirements</h2></div></div></div>
+<a name="id2567613"></a>CPU Requirements</h2></div></div></div>
<p>
CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
i486-class machines
@@ -84,7 +84,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567623"></a>Memory Requirements</h2></div></div></div>
+<a name="id2567626"></a>Memory Requirements</h2></div></div></div>
<p>
The memory of the server has to be large enough to fit the
cache and zones loaded off disk. The <span><strong class="command">max-cache-size</strong></span>
@@ -107,7 +107,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567854"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<a name="id2567721"></a>Name Server Intensive Environment Issues</h2></div></div></div>
<p>
For name server intensive environments, there are two alternative
configurations that may be used. The first is where clients and
@@ -124,7 +124,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567865"></a>Supported Operating Systems</h2></div></div></div>
+<a name="id2567732"></a>Supported Operating Systems</h2></div></div></div>
<p>
ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
number of Unix-like operating systems, and on some versions of
diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html
index 245ddad54cdb..6580262feb86 100644
--- a/doc/arm/Bv9ARM.ch03.html
+++ b/doc/arm/Bv9ARM.ch03.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.39 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.40 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,14 +47,14 @@
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">Signals</a></span></dt>
</dl></dd>
</dl>
</div>
@@ -68,7 +68,7 @@
<a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567897"></a>A Caching-only Name Server</h3></div></div></div>
+<a name="id2567764"></a>A Caching-only Name Server</h3></div></div></div>
<p>
The following sample configuration is appropriate for a caching-only
name server for use by clients internal to a corporation. All
@@ -95,7 +95,7 @@ zone "0.0.127.in-addr.arpa" {
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2567913"></a>An Authoritative-only Name Server</h3></div></div></div>
+<a name="id2567780"></a>An Authoritative-only Name Server</h3></div></div></div>
<p>
This sample configuration is for an authoritative-only server
that is the master server for "<code class="filename">example.com</code>"
@@ -137,7 +137,7 @@ zone "eng.example.com" {
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568004"></a>Load Balancing</h2></div></div></div>
+<a name="id2568007"></a>Load Balancing</h2></div></div></div>
<p>
A primitive form of load balancing can be achieved in
the <acronym class="acronym">DNS</acronym> by using multiple records
@@ -280,10 +280,10 @@ zone "eng.example.com" {
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568426"></a>Name Server Operations</h2></div></div></div>
+<a name="id2568429"></a>Name Server Operations</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2568432"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<a name="id2568435"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
<p>
This section describes several indispensable diagnostic,
administrative and monitoring tools available to the system
@@ -739,7 +739,7 @@ controls {
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570041"></a>Signals</h3></div></div></div>
+<a name="id2570044"></a>Signals</h3></div></div></div>
<p>
Certain UNIX signals cause the name server to take specific
actions, as described in the following table. These signals can
diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html
index 1aeecb4eab6c..6bd5242e4da9 100644
--- a/doc/arm/Bv9ARM.ch04.html
+++ b/doc/arm/Bv9ARM.ch04.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.50 2009/07/15 01:32:15 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.51 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -49,29 +49,29 @@
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">Example split DNS setup</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">SIG(0)</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">Address to Name Lookups Using Nibble Format</a></span></dt>
</dl></dd>
</dl>
</div>
@@ -205,7 +205,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2570437"></a>Split DNS</h2></div></div></div>
+<a name="id2570440"></a>Split DNS</h2></div></div></div>
<p>
Setting up different views, or visibility, of the DNS space to
internal and external resolvers is usually referred to as a
@@ -235,7 +235,7 @@
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570455"></a>Example split DNS setup</h3></div></div></div>
+<a name="id2570458"></a>Example split DNS setup</h3></div></div></div>
<p>
Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
(<code class="literal">example.com</code>)
@@ -481,7 +481,7 @@ nameserver 172.16.72.4
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2570958"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<a name="id2571098"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
<p>
A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
An arbitrary key name is chosen: "host1-host2.". The key name must
@@ -489,7 +489,7 @@ nameserver 172.16.72.4
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2570976"></a>Automatic Generation</h4></div></div></div>
+<a name="id2571115"></a>Automatic Generation</h4></div></div></div>
<p>
The following command will generate a 128-bit (16 byte) HMAC-MD5
key as described above. Longer keys are better, but shorter keys
@@ -514,7 +514,7 @@ nameserver 172.16.72.4
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2571014"></a>Manual Generation</h4></div></div></div>
+<a name="id2571154"></a>Manual Generation</h4></div></div></div>
<p>
The shared secret is simply a random sequence of bits, encoded
in base-64. Most ASCII strings are valid base-64 strings (assuming
@@ -529,7 +529,7 @@ nameserver 172.16.72.4
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571032"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<a name="id2571172"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
<p>
This is beyond the scope of DNS. A secure transport mechanism
should be used. This could be secure FTP, ssh, telephone, etc.
@@ -537,7 +537,7 @@ nameserver 172.16.72.4
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571043"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<a name="id2571182"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
<p>
Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
are
@@ -566,7 +566,7 @@ key host1-host2. {
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571085"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<a name="id2571225"></a>Instructing the Server to Use the Key</h3></div></div></div>
<p>
Since keys are shared between two hosts only, the server must
be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
@@ -598,7 +598,7 @@ server 10.1.2.3 {
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571280"></a>TSIG Key Based Access Control</h3></div></div></div>
+<a name="id2571419"></a>TSIG Key Based Access Control</h3></div></div></div>
<p>
<acronym class="acronym">BIND</acronym> allows IP addresses and ranges
to be specified in ACL
@@ -626,7 +626,7 @@ allow-update { key host1-host2. ;};
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571328"></a>Errors</h3></div></div></div>
+<a name="id2571467"></a>Errors</h3></div></div></div>
<p>
The processing of TSIG signed messages can result in
several errors. If a signed message is sent to a non-TSIG aware
@@ -652,7 +652,7 @@ allow-update { key host1-host2. ;};
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571410"></a>TKEY</h2></div></div></div>
+<a name="id2571549"></a>TKEY</h2></div></div></div>
<p><span><strong class="command">TKEY</strong></span>
is a mechanism for automatically generating a shared secret
between two hosts. There are several "modes" of
@@ -688,7 +688,7 @@ allow-update { key host1-host2. ;};
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571459"></a>SIG(0)</h2></div></div></div>
+<a name="id2571598"></a>SIG(0)</h2></div></div></div>
<p>
<acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
transaction signatures as specified in RFC 2535 and RFC 2931.
@@ -749,7 +749,7 @@ allow-update { key host1-host2. ;};
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564086"></a>Generating Keys</h3></div></div></div>
+<a name="id2571735"></a>Generating Keys</h3></div></div></div>
<p>
The <span><strong class="command">dnssec-keygen</strong></span> program is used to
generate keys.
@@ -800,7 +800,7 @@ allow-update { key host1-host2. ;};
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2564155"></a>Signing the Zone</h3></div></div></div>
+<a name="id2571804"></a>Signing the Zone</h3></div></div></div>
<p>
The <span><strong class="command">dnssec-signzone</strong></span> program is used
to
@@ -844,7 +844,7 @@ allow-update { key host1-host2. ;};
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2571880"></a>Configuring Servers</h3></div></div></div>
+<a name="id2571883"></a>Configuring Servers</h3></div></div></div>
<p>
To enable <span><strong class="command">named</strong></span> to respond appropriately
to DNS requests from DNSSEC aware clients,
@@ -932,7 +932,7 @@ options {
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572026"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<a name="id2572029"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
<p>
<acronym class="acronym">BIND</acronym> 9 fully supports all currently
defined forms of IPv6
@@ -971,7 +971,7 @@ options {
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2572156"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<a name="id2572160"></a>Address Lookups Using AAAA Records</h3></div></div></div>
<p>
The IPv6 AAAA record is a parallel to the IPv4 A record,
and, unlike the deprecated A6 record, specifies the entire
@@ -990,7 +990,7 @@ host 3600 IN AAAA 2001:db8::1
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2572178"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<a name="id2572181"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
<p>
When looking up an address in nibble format, the address
components are simply reversed, just as in IPv4, and
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index 20133328cc48..490d4ba613ec 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.41 2009/07/11 01:31:49 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.42 2010/02/27 01:33:44 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,13 +45,13 @@
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">The Lightweight Resolver Library</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572211"></a>The Lightweight Resolver Library</h2></div></div></div>
+<a name="id2572214"></a>The Lightweight Resolver Library</h2></div></div></div>
<p>
Traditionally applications have been linked with a stub resolver
library that sends recursive DNS queries to a local caching name
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index f2098b2205c3..ce78a7a8e2d9 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.98 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.100 2010/02/27 01:33:44 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,52 +48,52 @@
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">Comment Syntax</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><span><strong class="command">trusted-keys</strong></span> Statement Definition
and Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">Zone File</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">Discussion of MX Records</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
</dl></dd>
</dl>
@@ -455,7 +455,7 @@
<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573353"></a>Syntax</h4></div></div></div>
+<a name="id2573356"></a>Syntax</h4></div></div></div>
<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
[<span class="optional"> address_match_list_element; ... </span>]
<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
@@ -464,7 +464,7 @@
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573381"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573384"></a>Definition and Usage</h4></div></div></div>
<p>
Address match lists are primarily used to determine access
control for various server operations. They are also used in
@@ -542,7 +542,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2573560"></a>Comment Syntax</h3></div></div></div>
+<a name="id2573563"></a>Comment Syntax</h3></div></div></div>
<p>
The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
comments to appear
@@ -552,7 +552,7 @@
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573575"></a>Syntax</h4></div></div></div>
+<a name="id2573578"></a>Syntax</h4></div></div></div>
<p>
</p>
<pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
@@ -567,7 +567,7 @@
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2573605"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573608"></a>Definition and Usage</h4></div></div></div>
<p>
Comments may appear anywhere that whitespace may appear in
a <acronym class="acronym">BIND</acronym> configuration file.
@@ -797,7 +797,7 @@
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574164"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574167"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
address_match_list
};
@@ -880,7 +880,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574422"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574425"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">controls</strong></span> {
[ inet ( ip_addr | * ) [ port ip_port ] allow { <em class="replaceable"><code> address_match_list </code></em> }
keys { <em class="replaceable"><code>key_list</code></em> }; ]
@@ -1002,12 +1002,12 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574851"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574854"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">include</strong></span> <em class="replaceable"><code>filename</code></em>;</pre>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574868"></a><span><strong class="command">include</strong></span> Statement Definition and
+<a name="id2574871"></a><span><strong class="command">include</strong></span> Statement Definition and
Usage</h3></div></div></div>
<p>
The <span><strong class="command">include</strong></span> statement inserts the
@@ -1022,7 +1022,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574891"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574894"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">key</strong></span> <em class="replaceable"><code>key_id</code></em> {
algorithm <em class="replaceable"><code>string</code></em>;
secret <em class="replaceable"><code>string</code></em>;
@@ -1031,7 +1031,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2574915"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2574918"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
<p>
The <span><strong class="command">key</strong></span> statement defines a shared
secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
@@ -1078,7 +1078,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2575005"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575009"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">logging</strong></span> {
[ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path_name</code></em>
@@ -1102,7 +1102,7 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2575200"></a><span><strong class="command">logging</strong></span> Statement Definition and
+<a name="id2575203"></a><span><strong class="command">logging</strong></span> Statement Definition and
Usage</h3></div></div></div>
<p>
The <span><strong class="command">logging</strong></span> statement configures a
@@ -1136,7 +1136,7 @@
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2575252"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<a name="id2575255"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
<p>
All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
you can make as many of them as you want.
@@ -1665,7 +1665,7 @@ category notify { null; };
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2576508"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
+<a name="id2576512"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
<p>
The <span><strong class="command">query-errors</strong></span> category is
specifically intended for debugging purposes: To identify
@@ -1893,7 +1893,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2577096"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577099"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
<p>
This is the grammar of the <span><strong class="command">lwres</strong></span>
statement in the <code class="filename">named.conf</code> file:
@@ -1908,7 +1908,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2577238"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2577241"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
<p>
The <span><strong class="command">lwres</strong></span> statement configures the
name
@@ -1959,14 +1959,14 @@ badresp:1,adberr:0,findfail:0,valfail:0]
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2577302"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577305"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting">
<span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] };
</pre>
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2577346"></a><span><strong class="command">masters</strong></span> Statement Definition and
+<a name="id2577349"></a><span><strong class="command">masters</strong></span> Statement Definition and
Usage</h3></div></div></div>
<p><span><strong class="command">masters</strong></span>
lists allow for a common set of masters to be easily used by
@@ -1975,7 +1975,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2577361"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577364"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
<p>
This is the grammar of the <span><strong class="command">options</strong></span>
statement in the <code class="filename">named.conf</code> file:
@@ -3086,7 +3086,7 @@ options {
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581241"></a>Forwarding</h4></div></div></div>
+<a name="id2581244"></a>Forwarding</h4></div></div></div>
<p>
The forwarding facility can be used to create a large site-wide
cache on a few servers, reducing traffic over links to external
@@ -3130,7 +3130,7 @@ options {
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581368"></a>Dual-stack Servers</h4></div></div></div>
+<a name="id2581371"></a>Dual-stack Servers</h4></div></div></div>
<p>
Dual-stack servers are used as servers of last resort to work
around
@@ -3286,7 +3286,7 @@ options {
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2581867"></a>Interfaces</h4></div></div></div>
+<a name="id2581870"></a>Interfaces</h4></div></div></div>
<p>
The interfaces and ports that the server will answer queries
from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
@@ -3719,7 +3719,7 @@ avoid-v6-udp-ports {};
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2582869"></a>UDP Port Lists</h4></div></div></div>
+<a name="id2582872"></a>UDP Port Lists</h4></div></div></div>
<p>
<span><strong class="command">use-v4-udp-ports</strong></span>,
<span><strong class="command">avoid-v4-udp-ports</strong></span>,
@@ -3761,7 +3761,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2582929"></a>Operating System Resource Limits</h4></div></div></div>
+<a name="id2582932"></a>Operating System Resource Limits</h4></div></div></div>
<p>
The server's usage of many system resources can be limited.
Scaled values are allowed when specifying resource limits. For
@@ -3922,7 +3922,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2583488"></a>Periodic Task Intervals</h4></div></div></div>
+<a name="id2583422"></a>Periodic Task Intervals</h4></div></div></div>
<div class="variablelist"><dl>
<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
<dd><p>
@@ -4227,14 +4227,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
<a name="tuning"></a>Tuning</h4></div></div></div>
<div class="variablelist"><dl>
<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
-<dd><p>
+<dd>
+<p>
Sets the number of seconds to cache a
lame server indication. 0 disables caching. (This is
<span class="bold"><strong>NOT</strong></span> recommended.)
The default is <code class="literal">600</code> (10 minutes) and the
maximum value is
<code class="literal">1800</code> (30 minutes).
- </p></dd>
+ </p>
+<p>
+ Lame-ttl also controls the amount of time DNSSEC
+ validation failures are cached. There is a minimum
+ of 30 seconds applied to bad cache entries if the
+ lame-ttl is set to less than 30 seconds.
+ </p>
+</dd>
<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
<dd><p>
To reduce network traffic and increase performance,
@@ -4993,7 +5001,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2586451"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2586321"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
<pre class="programlisting"><span><strong class="command">trusted-keys</strong></span> {
<em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
[<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
@@ -5002,7 +5010,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2586502"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<a name="id2586372"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
and Usage</h3></div></div></div>
<p>
The <span><strong class="command">trusted-keys</strong></span> statement defines
@@ -5045,7 +5053,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2586652"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2586590"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
<p>
The <span><strong class="command">view</strong></span> statement is a powerful
feature
@@ -5301,10 +5309,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2587989"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2587995"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2587996"></a>Zone Types</h4></div></div></div>
+<a name="id2588003"></a>Zone Types</h4></div></div></div>
<div class="informaltable"><table border="1">
<colgroup>
<col>
@@ -5515,7 +5523,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2588424"></a>Class</h4></div></div></div>
+<a name="id2588362"></a>Class</h4></div></div></div>
<p>
The zone's name may optionally be followed by a class. If
a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
@@ -5537,7 +5545,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2588457"></a>Zone Options</h4></div></div></div>
+<a name="id2588395"></a>Zone Options</h4></div></div></div>
<div class="variablelist"><dl>
<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
<dd><p>
@@ -6038,7 +6046,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2590251"></a>Zone File</h2></div></div></div>
+<a name="id2590189"></a>Zone File</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
@@ -6051,7 +6059,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2590269"></a>Resource Records</h4></div></div></div>
+<a name="id2590208"></a>Resource Records</h4></div></div></div>
<p>
A domain name identifies a node. Each node has a set of
resource information, which may be empty. The set of resource
@@ -6741,7 +6749,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2591754"></a>Textual expression of RRs</h4></div></div></div>
+<a name="id2591761"></a>Textual expression of RRs</h4></div></div></div>
<p>
RRs are represented in binary form in the packets of the DNS
protocol, and are usually represented in highly encoded form
@@ -6944,7 +6952,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2592275"></a>Discussion of MX Records</h3></div></div></div>
+<a name="id2592281"></a>Discussion of MX Records</h3></div></div></div>
<p>
As described above, domain servers store information as a
series of resource records, each of which contains a particular
@@ -7200,7 +7208,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2592890"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<a name="id2592965"></a>Inverse Mapping in IPv4</h3></div></div></div>
<p>
Reverse name resolution (that is, translation from IP address
to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
@@ -7261,7 +7269,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2593085"></a>Other Zone File Directives</h3></div></div></div>
+<a name="id2593092"></a>Other Zone File Directives</h3></div></div></div>
<p>
The Master File Format was initially defined in RFC 1035 and
has subsequently been extended. While the Master File Format
@@ -7276,7 +7284,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
</p>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2593108"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<a name="id2593114"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
<p>
Syntax: <span><strong class="command">$ORIGIN</strong></span>
<em class="replaceable"><code>domain-name</code></em>
@@ -7304,7 +7312,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2593169"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<a name="id2593175"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
<p>
Syntax: <span><strong class="command">$INCLUDE</strong></span>
<em class="replaceable"><code>filename</code></em>
@@ -7340,7 +7348,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
</div>
<div class="sect3" lang="en">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2593238"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<a name="id2593244"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
<p>
Syntax: <span><strong class="command">$TTL</strong></span>
<em class="replaceable"><code>default-ttl</code></em>
@@ -7359,7 +7367,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2593342"></a><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<a name="id2593349"></a><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
<p>
Syntax: <span><strong class="command">$GENERATE</strong></span>
<em class="replaceable"><code>range</code></em>
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 58688d2165a5..8843c8652078 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.84 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.86 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -46,10 +46,10 @@
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593952"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593958"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
</dl>
@@ -118,7 +118,7 @@ zone "example.com" {
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593952"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+<a name="id2593958"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
</h2></div></div></div>
<p>
On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym>
@@ -144,7 +144,7 @@ zone "example.com" {
</p>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2594033"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<a name="id2594039"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
<p>
In order for a <span><strong class="command">chroot</strong></span> environment
to
@@ -172,7 +172,7 @@ zone "example.com" {
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2594092"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<a name="id2594099"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
<p>
Prior to running the <span><strong class="command">named</strong></span> daemon,
use
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
index 73c49412250d..d5b8fe1cd85f 100644
--- a/doc/arm/Bv9ARM.ch08.html
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.85 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.87 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,18 +45,18 @@
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">Where Can I Get Help?</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594241"></a>Common Problems</h2></div></div></div>
+<a name="id2594247"></a>Common Problems</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2594246"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<a name="id2594252"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
<p>
The best solution to solving installation and
configuration issues is to take preventative measures by setting
@@ -68,7 +68,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594258"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<a name="id2594264"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
<p>
Zone serial numbers are just numbers &#8212; they aren't
date related. A lot of people set them to a number that
@@ -95,7 +95,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594343"></a>Where Can I Get Help?</h2></div></div></div>
+<a name="id2594281"></a>Where Can I Get Help?</h2></div></div></div>
<p>
The Internet Systems Consortium
(<acronym class="acronym">ISC</acronym>) offers a wide range
diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html
index 24fbfe07d460..d12290d80a95 100644
--- a/doc/arm/Bv9ARM.ch09.html
+++ b/doc/arm/Bv9ARM.ch09.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.88 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.90 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,21 +45,21 @@
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">Acknowledgments</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
</dl></dd>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594405"></a>Acknowledgments</h2></div></div></div>
+<a name="id2594480"></a>Acknowledgments</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
@@ -162,7 +162,7 @@
</div>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594645"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<a name="id2594651"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
<a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
@@ -250,17 +250,17 @@
</p>
<div class="bibliography">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2594901"></a>Bibliography</h4></div></div></div>
+<a name="id2594907"></a>Bibliography</h4></div></div></div>
<div class="bibliodiv">
<h3 class="title">Standards</h3>
<div class="biblioentry">
-<a name="id2594912"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
+<a name="id2594918"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
</div>
<div class="biblioentry">
-<a name="id2594935"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2594941"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
</div>
<div class="biblioentry">
-<a name="id2594958"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+<a name="id2594965"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
Specification</i>. </span><span class="pubdate">November 1987. </span></p>
</div>
</div>
@@ -268,42 +268,42 @@
<h3 class="title">
<a name="proposed_standards"></a>Proposed Standards</h3>
<div class="biblioentry">
-<a name="id2594995"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
+<a name="id2595001"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
Specification</i>. </span><span class="pubdate">July 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595021"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
+<a name="id2595028"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
Queries</i>. </span><span class="pubdate">March 1998. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595047"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595053"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595072"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595078"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595095"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2595101"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595150"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
+<a name="id2595157"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595177"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2595184"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595204"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2595210"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595266"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2595272"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595296"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2595302"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595325"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
+<a name="id2595332"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595352"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
+<a name="id2595358"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
Key Transaction Authentication for DNS
(GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
</div>
@@ -312,19 +312,19 @@
<h3 class="title">
<acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
<div class="biblioentry">
-<a name="id2595434"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
+<a name="id2595441"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595461"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2595467"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595497"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2595504"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595562"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2595569"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595627"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
+<a name="id2595634"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
</div>
</div>
@@ -332,146 +332,146 @@
<h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
Implementation</h3>
<div class="biblioentry">
-<a name="id2595701"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
+<a name="id2595707"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595726"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
+<a name="id2595733"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595795"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2595801"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2595830"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
+<a name="id2595836"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
</div>
</div>
<div class="bibliodiv">
<h3 class="title">Resource Record Types</h3>
<div class="biblioentry">
-<a name="id2595876"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
+<a name="id2595882"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596002"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
+<a name="id2596008"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596039"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
+<a name="id2596045"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596074"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
+<a name="id2596081"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
Domain
Name System</i>. </span><span class="pubdate">January 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596129"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
+<a name="id2596135"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
Location of
Services.</i>. </span><span class="pubdate">October 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596167"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
+<a name="id2596173"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
Distribute MIXER
Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596193"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
+<a name="id2596199"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596218"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596225"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596245"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596251"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596272"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596278"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596311"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596317"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596341"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2596347"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596371"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
+<a name="id2596377"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596413"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2596420"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596446"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
+<a name="id2596453"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596473"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
+<a name="id2596480"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596497"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
+<a name="id2596503"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
version 6</i>. </span><span class="pubdate">October 2003. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596554"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
+<a name="id2596561"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
</div>
</div>
<div class="bibliodiv">
<h3 class="title">
<acronym class="acronym">DNS</acronym> and the Internet</h3>
<div class="biblioentry">
-<a name="id2596586"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
+<a name="id2596593"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596612"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
+<a name="id2596618"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
Support</i>. </span><span class="pubdate">October 1989. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596634"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
+<a name="id2596641"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596658"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
+<a name="id2596664"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596704"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2596710"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596727"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2596733"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
</div>
</div>
<div class="bibliodiv">
<h3 class="title">
<acronym class="acronym">DNS</acronym> Operations</h3>
<div class="biblioentry">
-<a name="id2596785"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2596791"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596876"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
+<a name="id2596883"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596903"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
+<a name="id2596909"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596930"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
+<a name="id2596936"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
</div>
<div class="biblioentry">
-<a name="id2596966"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
+<a name="id2596972"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
</div>
</div>
<div class="bibliodiv">
<h3 class="title">Internationalized Domain Names</h3>
<div class="biblioentry">
-<a name="id2597012"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
+<a name="id2597018"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597044"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2597050"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597090"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2597096"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597125"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
+<a name="id2597131"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in
Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
</div>
@@ -487,47 +487,47 @@
</p>
</div>
<div class="biblioentry">
-<a name="id2597170"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
+<a name="id2597176"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
Attributes</i>. </span><span class="pubdate">May 1993. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597192"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
+<a name="id2597198"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597286"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
+<a name="id2597292"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597312"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
+<a name="id2597318"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597335"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2597341"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597381"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2597387"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597404"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
+<a name="id2597411"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597431"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
+<a name="id2597437"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597457"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
+<a name="id2597463"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
</div>
</div>
<div class="bibliodiv">
<h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
<div class="biblioentry">
-<a name="id2597500"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
+<a name="id2597507"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
Location</i>. </span><span class="pubdate">November 1994. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597558"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2597564"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597585"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
+<a name="id2597591"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
</div>
</div>
@@ -541,39 +541,39 @@
</p>
</div>
<div class="biblioentry">
-<a name="id2597633"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
+<a name="id2597639"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597672"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2597678"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597699"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2597705"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597729"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
+<a name="id2597735"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597754"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
+<a name="id2597761"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597781"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
+<a name="id2597787"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597817"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
+<a name="id2597824"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597853"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
+<a name="id2597860"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597880"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
+<a name="id2597886"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597907"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
+<a name="id2597913"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
(RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
</div>
<div class="biblioentry">
-<a name="id2597952"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2597958"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
</div>
</div>
</div>
@@ -594,14 +594,14 @@
</div>
<div class="sect2" lang="en">
<div class="titlepage"><div><div><h3 class="title">
-<a name="id2597993"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+<a name="id2598000"></a>Other Documents About <acronym class="acronym">BIND</acronym>
</h3></div></div></div>
<p></p>
<div class="bibliography">
<div class="titlepage"><div><div><h4 class="title">
-<a name="id2598003"></a>Bibliography</h4></div></div></div>
+<a name="id2598009"></a>Bibliography</h4></div></div></div>
<div class="biblioentry">
-<a name="id2598005"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
+<a name="id2598011"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
</div>
</div>
</div>
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
index 9be4eb6191e2..cb6c21168916 100644
--- a/doc/arm/Bv9ARM.ch10.html
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.11 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.12 2010/02/27 01:33:42 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index e37899055885..5b0a3c7788cc 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: Bv9ARM.html,v 1.85.18.90 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: Bv9ARM.html,v 1.85.18.92 2010/02/27 01:33:42 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -41,7 +41,7 @@
<div>
<div><h1 class="title">
<a name="id2563174"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2004-2010 Internet Systems Consortium, Inc. ("ISC")</p></div>
<div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
</div>
<hr>
@@ -51,39 +51,39 @@
<dl>
<dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction</a></span></dt>
<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">Name Servers in Multiple Roles</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">Supported Operating Systems</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
<dd><dl>
<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">Signals</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
@@ -92,34 +92,34 @@
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">Example split DNS setup</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">SIG(0)</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">Address to Name Lookups Using Nibble Format</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">The Lightweight Resolver Library</a></span></dt>
<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
@@ -127,83 +127,83 @@
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">Comment Syntax</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><span><strong class="command">trusted-keys</strong></span> Statement Definition
and Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
</dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">Zone File</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">Discussion of MX Records</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><acronym class="acronym">BIND</acronym> Master File Extension: the <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt>
<dd><dl>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593952"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2593958"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
<dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">Where Can I Get Help?</a></span></dt>
</dl></dd>
<dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
<dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">Acknowledgments</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>
diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
index 12dd76c113eb..a59e03a212f0 100644
--- a/doc/arm/Bv9ARM.pdf
+++ b/doc/arm/Bv9ARM.pdf
@@ -1176,16 +1176,13 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
682 0 obj <<
-/Length 999
+/Length 1001
/Filter /FlateDecode
>>
stream
-xÚµVM“¢H½û+8jDS]|Õ‘FT&Àéؘ™ƒ­ØMD+®âtô¿ß„ªQ·/*«ò™ùòe@4 ?¢™²8åšÍ dbbjëÝ
-9P§›ú·êO«ý§0çã¡<I÷GQ½ Káê“ò,õÜæ êÆ‚(ƒÙÐÁà¦I›òÞr‘ðE&x=® )IüÐ8Ë?Å&ß(º«JY2üê¥ü“wRˆIk¶û²*Öy«ÁuÁ‡+i{ðÃ!_ɪ
-é_½¿‹B¸ƒ8¶Ì~%»ÈOÍ ÀðbŽ˜Á åÄFœQ»d3_ŽZ<ÉžGœÝDž©XIü#ûc±«o¯›*D½¶Õ¡'Œ1X¡Ì%Ø CaÈ,‰e/ÏA6VâOÝd,®%<wí—”ÕêÇšÍÅ;ä#/\Žƒhz•<˜/Â@ÕrI<ëÜO¼8F¶1tŸ‚0Èþê
-­ÙYˆŽ­Ø‘†Ý$È"?M‘â ÖHòõøOžuŒ”^O’z¸O¡´'q¢²ÊôéÂ÷7|P'¾×pTOÜèæB4@0²úbzq”úß—À
-"Ê€îܶZ\'ïyŸgn%Kc(,QÝK—asÚJ?Iâ¹,,N;‘kJÁƒñªÁËÔWµ‰ðMú|`"AéôAñðaŠ“¾æ®Z½,ˆ£~k¡ì,q{Eþ4 ¦~äùýLq¹æ
-_Ô!ýv‹aLF̆zãez™Rv“ m¥ˆ—YŸI|ŘEþãîZ´÷ôéµµ¾øœ‘¾ˆ ?É™»]=“¯®Ìí«D~1ÕŸIw¿ÆT¾ÿü5¦«lºa#æ8ôþ«ˆ:q›µ¤šë qrÊ,z‡ù?<h÷endstream
+xÚµV]“¢8}÷Wð¨UM:|å‘FT¦ÀéÚš™[±›ªV\Åéê¿’€¨Û/[[>ä$9Þ{îÉ @4 ?¢™²8åšÍ dbbjëÝ
+ ¹ÝX¢x¿À8Aí%%A½±!QŒ‡‘NM\C³ƒVí:ä-$X `_åÇ}^‰YúyªòÝIL¼r*UqÞ=(îtF0È4ñ/J õꦤV=ð³ÖOÂ(2-ËÃ47¿4¿eë—ô[÷ ³áÔmÞEý7ûéÿi?î,%¤dwÝ-·ÕÇê8"Î0¿¶]ûíM)v4›2Ði9_Ú§Èú%ûÖ=ÓASÒŬËYäÇ]q:å^hªJ1žO¹¬g öŽ!C9ß•›bÛ[Yí7åQàMqªŽÅ˹’5Vo…l¨ÓMý[õ§ÕþS€Ãùx(Orû£¨ÞR¼z¥<K?·¹äA‚úà A”Aoè
+KÔé¥Ë°Ym­Ÿ$ñ\§Éµ$ŒàÁxuÀËÔWµ‰ðÍôõ@G‚ÓéƒÒáC'}Ï]5zYGý£…²³ÄíyùÓ0˜ú‘ç÷3ÅMäZ+|P‡ô[4c2b6Ô/ÓË”2°›ikE¼ÌúJâ+Õ ,ò/w×¢½§àOïXë‹Ï雸ð蜹ÛÕ3ùêÊܾJä—3QýÁt÷»LåûÏßeºÊ¦6bŽCï¿Š¨ƒ·Y+ªy±Þ‡&§Ì¢w”ÿ¾Èjæendstream
endobj
681 0 obj <<
/Type /Page
@@ -5201,22 +5198,22 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
1302 0 obj <<
-/Length 2472
+/Length 2617
/Filter /FlateDecode
>>
stream
-xÚÅkoÛFò»…OÔ¡Úîû‘~rS'ç¢uzŠ‡CšŒDÛB)R©8¾àþ{g_ÔR¤lç’â`À\íÎÎÎ{fgÉÙ‰¤¡f¢ G1YnÎðäÖ^‘
-œ½¼üåÂ^ÍÏýõ|>-Höâïç¿-.æ~I?^^ýägŒÿœ@:¿xy1¿¸zq1}·øùìbÑñ’òK0³Œ|8{ûOVÀöÏg1£Åä~`DŒ¡“Í ÎXœ)ÏÞœý£C˜¬º­£ò#Q&éˆ
-FµÃmËuÛ%ÆÙgw¼H Æ#Þ(?{ˆ²^æ¥êÉoà© ¿ÿûßžè÷øEP7éSÏŠÑÎSˆD„ƒ`@8Ÿ7EÄëÝ
-DUÝ$¬„rd8áÉ¿n «/)²Í¾l×ÛÒÊPÊ,˜Gí¾«Æƒä~6…h÷»ÊÙ ,¯+¿’ŒyÕÜ9ÝÙµÖ¯mò{?ñ> Ù7Åõ¾ôs`î ¶ø;ÆôfŸžvàWM³Ìêë°ùöé#*Ù–ùÒQÍPíŽå<`€©`ÒÎ8ÁVØêÖ†!Œ *¤üín˜ÕVø#’ Þêa›6o‹MQµþÈm±Û¬³!þóvíü Ÿðí¨ìä`íö @ÆDÑ’ M꛸S˜Nî?‰5À¯>žtî $‚³7E€Ï˦ö£v\nZAä"Ê"úáPhŒ#Lé±Ì¾;ÓŒJ^-&ÂÀ^Á´ ˜~qw3ñƒya;øYºaa‡x-o Pz½¸TãÝ h2j´a=š±¾ƒzŒ’6K ò*eìÐHÛr‹çÕ˜è%€+H´³Õ”p8Ij­&BS>!OIzˆÓz<åÍ"ÂYŠÑ³Ø# c$•‡ƒÒ·ÅrÄ0(E‹èMëV…u‘¬†éëº,ë»æyˆ¸ SƒE?¼]–yÓøƒDï ‰ ’ á *! )f%&¹­dØWK¬Ã8KQ:‘õˆ# NE­È"˜%²² wDd ‚yàäÍÛö~[Œ° ‘Hí$õ¸6 G¬å7ä:b|Œkp`ü+¸>
-\n<Q!›g,úCãbó¦3iþ€1 éÈF/†™ê›Ç"ÒV7y¨Ý?æå¾è‚ôn„8­ƒ`Û$¤@eºò*”ªÏA DàTcà0h⠾˸F
-êî¾÷þo»"!¶w‘éèá÷aÀ†qÇqÜŒL͸R
-qåN*˜¯¶U+$)}8ÿé(ãŽÓú¡SfÈ#úƒ(¨©ðnµË+HS_¨?‘Š½+æ;ý ÜÝšzaüAGYDñì©'ì|ˆþZ© ‰™G¤.$Ò
-êFWÞ/Ëõò/“zž
-ËZ "÷Ÿfm©u¹ÓV^ŠÄî%TjaBU_yy—ß7ý6åiï Òº>Ëyl}&ÍÑ¡ŸmB0;YF®»2¿×"m"ëáõh[L2#Ž[<‘ƒí¶È-‡
-÷~„¹® z…(9 ª£Ê,*€ÚR"R®‹jþS®0ìiÝ7=#øɪ
-)å—"qÇQHî^YlL4`qIhël’ó å GLúãU¢¸J @‚Ñhú¯!Zlÿi6x”XÁÄ`bêäÄ Ìa&;Fpß_nèä§Ø™$E¼³±ãHÒÔGµmy¨ ÅÜcÝåÂñ${·-Œ¸JìpJDæmqJñáÜC)SkC†mZƨ¿(Â×™›Ü[D…ûÁ²ë}iŸS  2vŸµD7Qù¯‘²#cߨ°Jgüg¹ßÍ|0QNe¦Ÿw€Õ½Ú(ðÓÚX¥ƒÀ a‡Í~»µq×Ð~ÆF4µ¦ È^…
-öó«u“¿/‹€Õb³B'Y€²-†Åí:7ÚxaÀŠ!4¦«×‹±–Çlêè-fÍ ¸êªX!ÛÄð9vqª“2,3DV£i,3 Êküà^ ¸"8äÑuµo‹ÆíÒQµ:ÊY›üÓz³ß$=“‡È—£6[ù£ˆ§G"Þuµ-9lHÎÉ„ÈàFÄFO½Ÿ=õ¥üàÐÜ6¿4·çPã³H”SzmxR’þ'‹¾Bendstream
+xÚÅ]sÛ¸ñÝ¿B“'ªsÂá›@îÉ—8©oîœVV§ÓÉå–h›s©ˆT7ÓÿÞÅŠ”ì4¹édÆ„€Åb¿w±™`øG&B"©©ž¤š#‰˜,×gxrkoψ‡™ Y õóâìÇ7,h¤%•“Åm„K!¬™,Vï‰(šœ¼zwõæòí?æçÓ”'‹ËwWÓ8ysùë…½ŸÿöÛù|:#JäÕ_Ïÿ¶¸˜»%éqü|yõÚÍh÷9‚t~ñæb~qõêbúañËÙÅ¢ã%æ—`fùxöþž¬€í_Î0bZ‰ÉüÀˆhM'ë3.œ±0Sž]Ÿý½C­Ú­£ò#Q&éˆ
+‘ˆpp
+ð´Û-h`VáH^`$RðVÛ´Y›¯óªuGnòíº°Î
+„ìùÏÚÂú@X>áÛQÙÉÁ(Ú‰¢%AŠê´oâVy`:™ûDÖ
+A‹ ‹à‡C¡1Ž0¥‡2ûá0L3*xµ˜ {S&`ºÅíÝÄ æQ„íàgñ†a„â5t\C tz±©Æ¹!Ф!Ô(Íz4 b}õ%l†äTÊ8Ø¡–<„·Ô.žWc¢—./ÑÎVcÂá$©T:Š‚ð yNÒ£@œRã)oÎbŒŽÅi#™¦b°Uú&_Ž¥ˆc¼©ðYa•ÇqÉØ¡Ÿ¾­Ë²~h^úˆ :ÕXôsÁûe™5;Hô’* âê bÂPÊŒÄ$7• ûf‰ug1J+²qÔ™R#²
+0ö´MB
+LuW^ùRõå haüj M<ÃwW(…º»ï½ÿÛ®@ˆ©Ãmd:=Ü> ¸ü0ì8Œ›©OS€äìH‚%qðo®)dé” æóòåP p1±–æ:ï]8Ž.œ^`ÙÖ“<X$€Äe»› ê'pØt€'ÿ®«|¬¢7»Êª›‹qåN,˜o¶Q+$)µ?ÿù(ÃŽãú¡S¦Éúƒ(¨¨pnµÍ*HS_©?‹½+æ;ý ÜÝšz`ÜAY$åÉ ©Gì|›ˆþ\© ‰é'¤.$R)Ô¶|\–ÅòO“zÔ»j5s£›°þ\ùGŒ}/ùïûVÿ°I¤F,‰Ï(T\³øR5¸\ÑTêSŽ“ät# nàóÌ]<ÞÔ¾ï”ÎÖp~y¤¡¤Ln$ƒ@ÔS
+÷ŒÞ…ÛWGêòÊ}m•mGçîã
+3zaÚNÈS‚–õú…›Îrþ9Ú‚Š œáúÞÓa½§ƒ¶m¥ÊÁøî›”É2Û5yèû<Ƙ}sO¦6¹»6ŽåÑŒÎvšd×JòB2C#$ƒÉ÷aæ>ûäQí ›žv(ä9–’P<Šp„M-4­±^¡cXóDdîÓìn µ6wšÊ+%¡{ •šB˜ÐƒîJV>dM¿MyÜûODZÛg9­Ï¨9:ãó£fG"Ë¡‘›jµ×"m"ëþõd[L2-[<ƒÍ&Ï,-û
+÷q„¹® z…(8 ¦•1X”5¥D8¤,òkþS¡Ö§rNÔý'pÓÓ‚­ú ‘Rò¯ÉnÇ é^YLCÃÅ-ŽmCCF²N 'p5AÊhÅÈù*Ò\&‰» Áh0þw/H²€¿4<‹
+2÷n“ËléöP›(a¥tOvÃöS@RT«biŸ6üë
+vó«¢ÉnÊÜc5ØŒèIâ¡L·aq_xòF{0LÁ˜ÐM®Þ-ƺW¦ÌcúàÉ-$Ð5xì*_!ÓÏpévq¬©2¬8ãH+*(¸Æz@¸×M®ö)µ¨vmÞ¸£mfªVék}.Ö»uÔ>9E8Õ,CÔ8=ñ®ÁmÈaCrÂCdBð *»å×`«öÊ¿ý¸g¬ÖÝ[J«³ðFg€Öp«iãW+ž´ÅÚ¯¾¾º¾¾xåÆÀb±êžÁDr›¥ô¯eQÿ€;\ííâµ"lp˜€»b6V-wâ­}¥ä±7ú®hêñÏ]7™Ÿ®`® …îÙº¸”#ð¢N]÷’ƒW4agV’u´|ape£‘Ož¼M?÷ÿ5ì#/7­JEÇcŽ¿‘±@”õ: ¯þ?@ Iÿ/c20nendstream
endobj
1301 0 obj <<
/Type /Page
@@ -5249,10 +5246,10 @@ endobj
/D [1301 0 R /XYZ 56.6929 501.5031 null]
>> endobj
410 0 obj <<
-/D [1301 0 R /XYZ 56.6929 144.8407 null]
+/D [1301 0 R /XYZ 56.6929 159.714 null]
>> endobj
1307 0 obj <<
-/D [1301 0 R /XYZ 56.6929 118.3973 null]
+/D [1301 0 R /XYZ 56.6929 135.3825 null]
>> endobj
1300 0 obj <<
/Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F53 967 0 R /F62 1000 0 R /F63 1003 0 R >>
@@ -5260,28 +5257,20 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
1310 0 obj <<
-/Length 3899
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÍwã6¿ç¯ðm÷F*?õqL;™îìÛv3i/Ý=(6kÇ–<–”Lú×/@€²dÉNûš ‘ ‚À
-¬_;w(/ßòF®îPÑóg¸àAU¿~ÀÛøæã?ßÑØG3â&ÅØ!P­³å¶nZ¤rÒhC­Ô›Œïܺk¦ž»»Æ+Ò¸ó¦ÃCÞ‚[?}¦_©`Ç“ß>6ÝÀßw7DÓV|x ­I Þ
-à„˜ì" ÌþH¨ª3ygó¡*Xm*cIŸ‹Æ ˜‹É0b<U¤‹,6IFÈÜkÔ ÁZÜó6Iã\Zë7ûi  ›€Qy…ÅV÷ÆO×Q"!¨«\ÞNT“j8Ã…U:à4¸øâëBÆÂä¹&®íw{Ô‚oøîãN-Þ×°§Åp[aæh8µßW¢F7l1 1ä;ò†–‚ïö[·ƒûÝ›.6TôˉPùäÀMž‚c%z1Té_;%Á”9¤9Ñ1;ùk6\`'~,mz)l€{-3±Â^F³žË‡xåSV¹.Û×ÈÃ?<MÎ?µp6™Z ˜"[àš‘c„l nš@9äóÞ­JÌQü$8ÎF" Òþ¢‚_
-Ï´PxeÕ';¸)=VÑóËÆUD½ÿôùóíDÃΫ"0òšE×Ö»¢¡RgJÛñEZ®àª~%xzr•;P©¥¤QúÀyf[Øìe‡öõkUìÊ5vû5LÐP^°§º×*•Fݧ
-]ï Ôyxb÷ºœBÏ LOa:/Åp+JŽP6¸€&Ò¤&¶9¨b8ùÄz®·d˜Ì†2ph
-ïF:x¤pz¸ä3®•ÈÂ6*(m™ ¡BC.˜Ó…Œé±ëú|'\«î@íUÈ„8¢äDÛmýB$}ž´-weŸm»º ³Ôœ`­¶õê çZ_Ü Ö7ÎFwF¦±ùÑÝë®>ºs×l"ÜÞ;“«¹fÏÝ^§¼¡qâAYŽ ovy =×ÌF”›8‡”m¼‰{*aÈ”ë-¦¡0–"´-5ø£E"$]Nü­áø Ð9÷p>´›·)žK´ย_2‹GF¼MY=Q{A?¿“•iJž¾v¥¹Ã+s¶àûüÓ «MQ=9NüB‡áBm?À¾€Ä~Mt{€„ï‘>a—¿4¸!—[ |òëµ7ç´:ø¤÷ã†h’-!.´ðf€*z/¬E½#HzèZj ¥¤“9ã2.+@ëÃk?ˆˆ]Ñ`MŽ„ç}*ŸiÛÐÙl‹gæëfœzÍe˜-4 ¶>4ÁÛvüzhÞ#ŸC-„)G.ð|F\ e6´7ˆ¥Žö¦Ð
-Á {…àÃñäáÁ‡]D’•Žy}‘hÚîšP¨†—çnð•m±ÛÏB|Àm2l &ÚòP\­‡½íáõîÍÝû›>X[j^ç“q ÉY.³ì2\¹ÎÃuÏån]5Q·ÞGMù»›½òXÉÌ\^¾çšY" ÐÓ±
-ªñùk
-ªºŠ¥Hy,'Ê~aÈ“c2,œ„ßXÐ ¹£UJN#?­˜HÓÕnȬº§ 5<ÐóŸ6iá_‘V^
-L¡•’ØØ,½¸tÏ4][Ÿ”EÌxi$1Zk0
-¼1ÁuèÒ„g$d!ÕPßOŽV;ܨÜSB†Š$±n=÷
-ÉÄiÖ¿ÐáguþZF3a*"ùp Õ–CìA~ÆŽEUlÒÔž ûì.wÞ:±MF$¤†ˆ„Ï="yvHØ̈„$K Ô³ሂ„£‹ËH‚}Ç„4éß IËXFŸËæ”Ö,BrˆEø챉 XÆ¥Y:xw Š ·©`Î^ÐÏ‹°!lH¿iû!‹ ›’öøötÈæQÇŸ©ÌáLu¢Nƒ–áÍ5Ä"%Ì‹”/ýøŠ6²s‰e áÈ^°3`ÑhŒ 7´3§?¢0Ñg6þ:‡E\Û.›¾žM¿ÕÚíÁKÜifÜÇ]£Ð¢ÙüµÎ  +úŠÒ‰h!âêÞWùô÷UÿÞwN1˜"•—ñtÈuP{.2cL†ðð·.ò_(´`Mtœ(]¢çš‘b­øæ^ÀQŽÄW)exkÅŸWl™fù<MU¿ŒÓÆ#g¬hÜ´J
-³au/;¢Ov¦Ð'4̾<hÝ·vÆ–•†à]hfzDZ°Jb‰oWFßÐËim(ðÂ_:mŸ“€¬¹ –#Ø6!„Üs¢þ\ ~qs™Y~(éôqÞŠ~kJ@‘$Ûih!Ój|‡˜ªä¦q‘¯JõußW± ÖV¹Þ­m'™JN^¶‚qÐk~Z
-ÒáyP
-"Tn3wJ¸¼t>ämhuM»¢— ¡Øï)o ¹£Qg¶*•Ä -¸Ä¡x™ÛªˆµNçvêCrݶ¢ósݹÂWž,Ub­
-. ýyXþzÍêsB
-g‰ÉßÒXaGRÒ¤»Ž>Pü)–¡<¾”í†8ÎÑ˦Ø1åMäÖ=»-1M8¬2¬H‘-z ±'_Þ‘åé3…ˆióäm73Òö–PW¸ìSw(ø³B”ÛK.ÿÁ­Ñú×ÔüHæYqd¦Á>{˜8H—Šd`.\M¤úʸ†H…j¬!,xø8C+²“ ˇr½ö0«S®þÓç!ð3,2ÃaÜã+¨¾ç¡h¨”Ñ¥MeµÚvk®ëã¤3çcÓ²'õç¡®ḆG
-ë$î*ѧ’[ ÷W¦ÒÑÿ­“š~endstream
+/Length 3813
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÍwÛF¿û¯Ðmå÷Bf>ùqt§›¾Öé:n/m´4¶¸‘HE¤ì8ý EŠ”Ü}µg03 ð
+‚óvÉGïü6/ÝC±_·zÕR… ÿýäV©ƒ~<‹Î{,yœd`;Ä!E&ÄÄ<ZÅÆä–¹ün– Éú§°B¹ª÷»ÞåÔ g*Î…QÿŸä’ÙEUÕ-­â¾-œ?_ SÖWñÂÒ  {k™€[94¨çr½&\ºwôlÊ5üú…ÞÚÝe6߃`-­ È‚à™Ò#¬$æåOàM«ÇYÐã‘=¨õ¶
+ÎÖÔà‰oA&ñ¯†C³ ¦ö`Þ·ü{·*žJ´ย'™Å#Þª¬©½ Çw²2MyÓ×=$hn÷Â\†-ø>º"b±*ªGÇù_h×_¨íØÓ/‰nwë=p®'ìü·—!ä| „Ïûa½v5™Ñêà“Þ¢I¶<D·Ð›ªè¼^° õ† é~ßR[¨"ÍÙ—qEZï_ºADlŠË p$<ïcùDÛ†Îf]<1_—+ãÔËhÊÛ1Qh@;m½k‚7¶í:øuß,¼G>…2Sî\àù Œ¸
+Á—ÃÙ˺ˆ$;",òú
+-,дû{jB¡^ž»Á[ÖÅf;eÑr“i1Ò–ãjÙïmw/xo†øÞÍØtáÚ²Wð:‰+¯­ÌÒó€Ýç: Ø—?ºeÕDûå6jÊïn\ñÊc%3s~ùŽkbýa`0:O‡pÅ BQRŨ-©0 ï×ï±>‚Ôoï%â~ïëñÞê|4úû¬9^|\è'®é9tÔþŠ‡áþ6… ·Åâ x“œ7ôÎ¥W>abM± xV§C›ù œíR÷pˈžíB‡•Š/ô‘'Ô‚ ߃÷zß6åÒ[»*¹y‡OÏX³óÅ/ÃÅZèïkqñå÷ îÇ-9^Ò"åÚ
+‘
+%ì‘U¼“8ïÊTàó>ªºŠzuHy¨%ÊnaÈ£c2,œ„® ;G«ÔQ]Ü£­`"MCT»"³Ú?®¨ážÞ¿øÄI ÿ»iå®U´ÌN¡’»â1$á´Ú!
+e”:DJ,ã öÓ¤û9
+¹ðIçì³1
+¶Áº*׺µMâ$SGj
endobj
1309 0 obj <<
/Type /Page
@@ -5294,14 +5283,14 @@ endobj
1312 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [326.242 468.2497 375.5914 480.3093]
+/Rect [326.242 452.6821 375.5914 464.7417]
/Subtype /Link
/A << /S /GoTo /D (dynamic_update) >>
>> endobj
1313 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.2799 145.2015 410.176 157.2611]
+/Rect [353.2799 133.2463 410.176 145.3059]
/Subtype /Link
/A << /S /GoTo /D (zonefile_format) >>
>> endobj
@@ -5314,30 +5303,29 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
1317 0 obj <<
-/Length 3504
-/Filter /FlateDecode
->>
-stream
-xÚ­]sä¶íÝ¿bߺž¹UÅ‘Ò¤Ó™Ë/u¦ñ¥¶ÛÉ4郬Õz5§•öV’ç× H.¥ÕÚÉ´sž[A@
-ñòÃç›O×ßýóöý¥–ËûëÏ7—+žÄËO׿¢Öw·ïøáýí劥 [~øÛûï¯niHYß^ß|$HF?gˆÞ^}ºº½ºùpuùŸûï/®îý^Âý²XàF¾^üüŸx±†mG"K“Å3tâˆe_ì.d"¢D
-á õÅÝÅ?<Á`ÔL•‹#.Ÿ g
-±N¥âÌa!£E]•Mß­öåá’¥ËÕס<¼¼#žvù¯«Ùñ)—\d‘L{M5ÃçX’2’JË1£÷Û²CÆjÙ•=6+R€TMÕWyMЧ¼,ü—8‰w0¸vÐd4ž7k…ýáuša÷PšÓ_¬˜âpâ Ž>KNº±¹Ä=, Êb8tÕSI èÔ}Þ”íФ¸dKõ7 Y¦‘7/Ôx„Ù 5I¨¦‰“v±ðì¸H£D3§^™Q@i™:=þÚä»òÝ×þeÿuÞu3DS •;å¯oÑ´&ûmÞ»–“@yx*ÍÓåsU×$H!ãH
-É É•åEQî‘@’.J”
-ûÙrm:í~_5„‘¯×Ú‰9^è[Œæ v¤b‘Y†Që™] ð4J»mni¥¾/wÄì¬%`WÖjõCc™ì·UG0§k8Û¨ŒÛ¼y,;’
-‚=Õ³,â1O­þœ½—'Z—Æ¡'m’öM„õrrù‘iÍÍŸX±à
-FµÓ œ5ÄÀ#éæÏ8S¯Y'âçÅ ±e¢²’z5ö™È˜ÅÃÒ@Æ’§$cɵ‘1KÍêÁ@ cì:MK󇽂ÚåƒÍÖ̲óó†P«Ý¾íJ‹ñð2³KcŸ\HϸMÏᦙs`gCÕ]*ÎFð6T ±Î‡ª‹ÜY_m^Vë²ÎO"PÆ8„ü`¯®î±f–(ÓmI6^Ÿne .ÒpÀ[¢¹¤‚.3)ÄöëÎ@%hcÿ\–~¨Y“ŸùIh»€aÚÁve×åF»µ»MœÓ:ot¿i2äÂèT6òI”i©Æçìtp.zZA
-“Å
-fH6Ù1íd
-þ ›ŒÁ¯};Tu¿r9úLž¬î‚”9Ó#0Fd3¸®¼XEz$&R¶Ü›OÕÚxZ5q¶¶e½ß 5!®«ü±iÁ»48âý–H [š‘Üy'á) ìÁo{Ä¿A
-G‘rRˆ«!šUgݥċž¿åÑu¤¸¿˜1´Ë¸ Š á=5vªŽ~{7JbÏkêù#ÃŽo m ÈÌsì9j‰ jHÆïöe(ÚäÌÕC,™êÉQØuæËêF÷¸›´Î™ò
-xmmÃUd‚r¹/9œ3@&£X1ù†X¯ ÃB^·V:Ý… 1„RJ½±²ÇšYzœ<‚l¥ž¬Mf¨Ô‘ ÓëØÛ¡
-
-xà×Gvcd‡Š
-2Jy;„¦tHóœ¦,’Z¹¢ªcèœ!š‚ÃØ q‘y3„àì)MÄXK~—=ÂÜä|0Âç±øæ$©H
-Œ9ÛëŽw´ù¥|%<SᇸNŠmÕ¸tß…(n¶
-rŸÄ†1‹U
-ÁV*Ç’ÙP€KmnS.•¦úæXÂðÛFž€± ›ªKaÂþPír£ØX; F7
-X¼pâþŸ¿K !tA?óÑšÆl ˆX¦Œç•§1¼ý€ñ”õÿæÏ endstream
+/Length 3599
+/Filter /FlateDecode
+>>
+stream
+xÚ­Zmoã6þž_áoç
+éôýçÛ7ßýëîêRËéÃÍçÛËÏÒéÇ›\Sé»»«OŸ®î.g,ÏØôý÷W?>\ßQ—r4¾½¹ý@-†>gˆÞ]¼¾»¾}}ùëÃ×a/ñ~Y*p#_/~þ5,`Û?\¤‰0y6y†Jš0cøds!3‘dRßR_Ü_ü3ŒzíÔQù±4áBñr 0gIfL6Ñ™I”€.`ûTîvÕbQ6°5¡§­ýæÓ‚>ÛrwÉòéì÷¶)݀ݰç©*Ÿ©ç±èªŽ:_¨©jæõ~Q5+Oä\±ˆ+žé$…
+ìùÙ]_î~IS^—³e»Û½›4ØJš˜,5nN×}¹)›ž}®úuå¶Ñ¯Ë‘5gB€I Âc (eÜÒ±›<]ŒË$ÕF»Å`ÿ§J®2á†X‘ŒÒQ\gnÐcÝο:Yfá‹ÌÚ¼mP«ý®è«Öõ’L’•c‰fLM4Ó )\ŸQ4‹G‘†°1ó£Ñy]h»™?ð¯ûr÷òŽxÚ¿ÍFû¹äÂ$2Wìu6è>‡’”‰TZ}X—
+0UÓ®D]H3'Rh©šª¯ŠšZŸŠzïÚI³t›ýŠŒú‹fA½°?ì¡J³ß<–öôAm‡×Æ+y£v‰Zg¦Vå|¿ëª§’š: S÷ES¶ûŽZæ—lJ¢£ú’,ËÀê/TXÁ솊$T[DŽI»ØÀŽ@¥3ͼzýmDu¢eîõøkSlÊw_û—-ü?¯‹®!š«DôúïoÑt&ûuÑû’—@¹_Cfù\Õ5 RÈ4‘Bò¡%óy¹Eø’%ƒź™.l¥ÝnÉ­Àˆb±¨ÐNìñBÝid2f¨°#•
+ï9P‹‘] ðºJûmYni¥ 1;k©±+ë%•ú}ã˜ÔQ›×5œmÕ
+zçë¢Y•I€sðüxp ø5SØ?}ëvµ*pS –¢®Së¢\ XT±kuT.2K§,uÄ6¤V<°C¸a}à Y¾™
+|C±[·ûzAe¢
+¾H”óžšÖí36¤¹PBu­,',o¶q„¬£ƒ/©:
+úxE‡"žÈp0)ªÐåVî‹/¥c×Fà¯kë§2ì/«ÓK
+Hõìs$c–J„è‘Œ%ÏIÆ€^¬Œ±!’±ÔÜ«ÏccÕhZš¿ßZAaÓc»Gù`±µ³Üü¢¡¡ÕfÛv¥ñø2ŽË@üèBÚy<ã7=
+Ø~ÑÙV ÚØ?—eèj\¤:ò“P²vÝ´7jÛ”]W¬¬vk›BsAtÞè~s3äaT*‡<D–-ÕQätp =Í „1©R@%Frbp¦àBëÛ·ûªîg>¨ °Ï:Ñ…˜YS$°F«H…<ÈUäb"gÓ-ñùT-¬«Å^ 4°´.ëír_ÓÀEU¬šÜûœ:\`C¿&RûÕšfÔîÝ6á1`ÛcØÖˆ;
+éû-c8ï}’Ý]±ë©dEE)¬Fƒ¥ °㘮,Ï¥P¤
+wcÉ£xü©½žPÅÞ„%UdÆj1g§^# ò;#^Ãzƒ‹SjQÔ<X[‡oŽ NÂc¡sõÆ1¨œm:¹®æk"KÐ#18, u ö˜.Iù7Ôçж‰<T\’dz³Î±ÈÓBóÌ+ÑÍíØmþBKŸñù&,Lêä£=ô‘\¹h¬êö±ðQc–'Z0=D³ÁÕ¼Úñh;ªt{+.²½×Y’óÜ›[QÂ;{•ÃÊ" c-­
+Åv[¿ÐZ$Jcoïέõ€QI
+œÞ“Ôf"àjÇOræ¾Ô˜O³^ÛWyÙŽ]™
+JX:FUgݥċž¿åÑu¢x¸˜Ûî@‚§ÆJÕÑ·÷½$ö¢¦Z82¬|ek@vž§àÎQK\PC4~¿-ç
+:¦yÎs–H­|VÕ3tÎmÆah†¸È¸¸{Ê31Ô’?d07;¦@ø<Úô€$eI1o{µãm¿¯ÄGƒÍC„î ®“ùºj¢±tßÅCülÅ>™ƒ1“Y` Ôa ™%e
+¢;‚¸78‚
+u$ÞëLMvx{Û3òôÎ jÎÁg‡EÇ3¸ÀX®1¦n6HáêÑîõfÛ¿Pñ?,a{kv&2Aï]_”(; MQFj%QÇ!>·­x
endobj
1316 0 obj <<
/Type /Page
@@ -5350,7 +5338,7 @@ endobj
1323 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 431.6566 116.59 443.7163]
+/Rect [55.6967 426.3573 116.59 438.4169]
/Subtype /Link
/A << /S /GoTo /D (view_statement_grammar) >>
>> endobj
@@ -5358,19 +5346,19 @@ endobj
/D [1316 0 R /XYZ 56.6929 794.5015 null]
>> endobj
414 0 obj <<
-/D [1316 0 R /XYZ 56.6929 504.3703 null]
+/D [1316 0 R /XYZ 56.6929 497.3965 null]
>> endobj
1322 0 obj <<
-/D [1316 0 R /XYZ 56.6929 478.0508 null]
+/D [1316 0 R /XYZ 56.6929 472.0732 null]
>> endobj
418 0 obj <<
-/D [1316 0 R /XYZ 56.6929 168.112 null]
+/D [1316 0 R /XYZ 56.6929 166.4376 null]
>> endobj
1324 0 obj <<
-/D [1316 0 R /XYZ 56.6929 141.3042 null]
+/D [1316 0 R /XYZ 56.6929 140.626 null]
>> endobj
1315 0 obj <<
-/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F11 1321 0 R /F39 868 0 R >>
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F11 1321 0 R /F39 868 0 R >>
/ProcSet [ /PDF /Text ]
>> endobj
1328 0 obj <<
@@ -8588,7 +8576,7 @@ endobj
stream
xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä0 00Ì ÝÝÝÝ’‚R"‚´t ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶‡Œ5Ü
¬‡¹rðpr‹ t´P(ÐWç…C­fL9g0ЇÉ]Á¢
-Äü{fXE
+Äü{fXE
0Üú÷äè¹aÖÃöOÃoäæìüØã?ûÿxýœÿŒ=ì a.ÌÁAb¡ö™9Y® Ä£ò/z{xÂœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
rn­êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
b¬Å7ÎßÊçÏVð™h9Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ êt›œ(†Ì%³LÇî)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý %õ‰>•pjÕr{2–ÂwÍ<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
@@ -8611,7 +8599,7 @@ $OíœàÅ€DÈ
t‡Í=žÝbóÆÃwî6ß"£“˵?”JËOP2RÐ oQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ­(e÷åû È"QÔüFØs(úF$'‘qL ®/¶!õÔ ¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ° gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
ÞyŠGÝ ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’ ¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?ÒK áéá@F)Ø,êw÷ó?È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý @¥-«ä%Å~jÉwXjz1îi´·î¬%uÕ3^¿±g¸`d+ÎK[ŽDe—„]âò†YèÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š” ™v_Å [ªJÖ®²9m=·âú?\‹k>¼à¬‡¤*³Ñ³ž,Y ê<‹ý¹uÓ Z/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_ï‚¿œ%%½¥åŒìé|°D>W²7}C–Í#—ZR¸­$º`bÛGο…a¿9gÝS%\”Á/œîñhC|?s§ Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
üõí+uqfº`Îa‡„°£â,I§ã¯½/‘˜÷ÇÝ›Á¤'P6ߢH‚Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)wL=(‚Œ£± L|)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í; ¯åä²fùOî{&*‰äyÒ¯9ÛB±T¨d>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
-*s"}Y ;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
+*s"}Y ;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
endobj
1506 0 obj <<
/Type /Font
@@ -8620,14 +8608,14 @@ endobj
/FirstChar 67
/LastChar 85
/Widths 1943 0 R
-/BaseFont /BINIFX+URWPalladioL-Bold-Slant_167
+/BaseFont /ALUQPY+URWPalladioL-Bold-Slant_167
/FontDescriptor 1504 0 R
>> endobj
1504 0 obj <<
/Ascent 708
/CapHeight 672
/Descent -266
-/FontName /BINIFX+URWPalladioL-Bold-Slant_167
+/FontName /ALUQPY+URWPalladioL-Bold-Slant_167
/ItalicAngle -9
/StemV 123
/XHeight 471
@@ -8643,16 +8631,20 @@ endobj
/Length1 771
/Length2 1151
/Length3 532
-/Length 1713
+/Length 1712
/Filter /FlateDecode
>>
stream
-xÚíRkTSW‘ª¡¬òRIÕzX%2$¹Ñ
- ±hxÊCbî ¹%¹—^.4€ˆ*©Ê²ˆE—<EE©°ªÔJ-±
-SÀiaËqªUð5¬««ôç̯YsΟ³¿ý½¿óÍp‹{‰`|#"Á1Ò bAB$“I! ÎÁ"‰âX°‚D„
- ªa)xA+Yœ•oq4]‚ê8%•j RhÒ‘)ÁàéJ(ÿ¦t°#ÃC$±çï_;•ŒP ©OC
-¬>ôs+õoi“ý:{°›)t+}¿GšŸS#]p¬ÒIY»@ãRC·FÚÖ·jý±‹–†µùN© ]\¿b(­i/c]òø+ÆoKvÎ|šøâEßó7FzëC¥ÁÍÊõÄŒOŸ™žÃÌÝöÚ&·8…ú«{¤( ´Ïn•±]û÷€ì–1ˆÜÈs¹yô w3—v_8®ÝWñ7ÙzÏo›M{Ä:+AÜ%ìãªGÿºÔj<ÀM’Å÷%Ÿ¼åy¹®ñBu°s]ÁÌDS³DR½¤y6Þ;8ßÍßy¡ï\Q‚%¨w™/ö芨Ïe;ñ&Æzìyé;ôSI”©iäˆ÷¢\Û¡- Rw±D.7øüjs>¬.YßåSwÒôã¼eûàÈl¯µûR׆Õn×ê æì=&hxÙTdŸ{*jþAUNz°MÏ–3Û®Ô=&Š"^T%³ˆ¸€³­mYNŒ2¹g?ÙÀóMHyÝãdÝ¡ÃîMßZ¹hÇšÐn wP@O^’ûfëhoH†£¸¹#ÞŒÝ;VzçÇ~T0¸åÜ!Ç w¿Øo–ú·Òë/üclÕZ/®£*ÒÀÑÄyZL0à–*m v±\T¤x˜]M2çï¥O]1SKšq»„d~u²º$šké]uÊÛ «bò¥ÒÓšåV3îÌ{RâjyFl>x-”ßX± ¸]±~´rÂïn÷DFžó•‘ÂÎ_ά©doâå{“竲ôº®yYÍÝe *tA^[Ï|bø’ûÕicÓf«yÄiüµºcûuç«¡ÑöZhKŒ@Ç}~4¶3ßæýœÂÕtúg˜qiý˜n}h™¥ÿèÎKYQ˜îzD»–‰K^[ÇE×uX—'æ
-š”M Æ=«Ší?ŽÖe‘ùÊöÛI[VËêOì¶ÛRgwÏ-h™µpçæŸ]/Ë”W~½Þÿ<??3úœ„×0ç{÷ÅEjNÊ99T$®9˜rOÜšý<à‡à÷lƒG—<‰9[ZXð¢î;ãSQ,¾Ò%ºÕ¶‡Q×­i®)+Ø#›[ë´á½‡ÃW„×üvwwð>k§/#_¾Ž?µÜå[}rÜc|ÒžcGZñ`û5}MNí¬¼<QY`÷]#ê¤ÆÎëåy¿`QòFúD{õþ9PTÛ¿}±X`3ëþGWã>ÿ.¹†?8vAÜšx­÷Ëѵ;ù/͉lfb‘—‚\ÕÛgÞø4+âp~5½n€ó.Úÿ üOPjAâZ‘Jû7+-Œˆendstream
+xÚíRkTSW‘ª¡¬òRIÕzX%2yj   b,Þ/‰¹7ä–ä^z¹¤D|PIU–EltÉST”
+«Š@} Ô«0|‘V†°©Z_sÁººJÎüš5çü9ûÛßÙû;ßÙ4HCaáP %&G‚¥R ‡ È3›M¡Ñ‚qXN "'`!à>`µV ¸+
+9
+¤rBkÈ
+¹È0z&©Õ`ýäL°΄ñ,bR8
+l„Ó”šÔ$A•à¿…!mÆ»TŒg’¢€×”L: EBªÖVRXk1²LjùoÈš^<T«V¯•k&ËO9õ—¼\ƒ¨õ¿30M†–€q Å G§Scá·â¤0„h5Ó³B®F"4M g%“½ò-Žd†":ŠD…
+(åêLx
+‡QhºÒ¿)¬ q‚8,Þû÷¯JFÊ”ˆÒgÀ€ý{*æü“&áˆ$²™l6‡$’ûÝ)yZ31ªÀ M\žã¸\O!‡ˆŒxÀÀ
+Á:
+¿­Ÿî;½½6O\ÝuÌžž¹ÐtdkÇùm§L~Ìá>?—ëxÓOQðG¿9osþ9îT:ñ Ròú©§E9fƒŒµ­×ÙìèF¯Ü/›õP1œ”2ãry{Ûšƒ;îY[3š¼þìùìnÖyûú5÷9ü*êHÑÌÚ[7_=ÉKßÔÙoqøò*¥$—ŸY³ŽùçÝâ«°jÌRsy~Òþg®¯-Ô¶;=é·Mc¹Ôî†Éÿå6]§è¤p¤/¶Ä• VË„³ú\©0›ý=Lq-ÍÒ_gvÓƒ¦÷{$¹¥á±’èÑÇ*]µ Ôþa5T[¸¡-¡U€^,´6¬+pIoèâú—p2šöÒÖ§Ž¿¢ý¶dç̧É/^ô=c¤¶>T<lÜÖõö=˜åå=Lï`Sí¯}aöˆ—«¾ºGˆÃûVÛ5Èi“‚8Á|·›G¿ð´p)÷…ãš}“&xÛlÞ“$ÖÙâ/¡T=ú×¥VãnJhpb_êÙ¨[Þ—ë/T‡¸ÖÎL67‡†V/ižõÍ÷p]è7×I”dª]–‹=ºâªs9.¼‰ñEÇ…>{^ú ýTmn9â³(Ï~hË‚ô]ÌQË ¾¿Ú¨KÕwùÖ4ÿ8oÙ>(*‡±n_úñÚˆÚíýcÁœ½Ç 8v9瞊šP–ãÅ Þ+bÓ³åôvÚ†+u §âÈU©L<>ðlkŠ£Öã†,îÙO6ðü’Ò^÷Y¨Æ°{ÓÃÇ·V.Ú±"tèP3ÄŸ—æ½Ù:Ú¦up7w$ZÐ{ÇLw~ìGƒ[ÎrÖzúÇ}³4 •Zác«Ö1¸ÎÊ([ï]d;0AƒZª4un4ÈÍz9Hžæeq7K]¿—<uGÍ-Æí¡íð«“Õ¥1¬<kïªS>Äš±*!*[*9­^n3ãÎ̱'¥îÖgøæƒ×Âù» ÀÛ•‘ £•þw»'´ù®WFŠ:9³Bª”¾I”íM¯ÌÖëºæe7w—-pªÐ3¼¶žùÄð%÷«ÓƦÍ6óðµ’Hè;[UÇöë®WÃc5œ-±÷ùѸλ÷s‹VS©Ÿ¡Æ¥õcºýõáeÖþ£;/eGXh¾ëã^&.}mS?Ôa[žt˜+tiR45÷\¬*qü8FŒ—E(Úo§lY=,­o<±Ûaç*§¤{naˬ…;7ÿìöxY–¬òë„€óü‚¬˜s¡¼þÀ9ß{..VPJîÉ¡bqÍÁ´{âÞðœç?|
endobj
1321 0 obj <<
/Type /Font
@@ -8661,14 +8653,14 @@ endobj
/FirstChar 60
/LastChar 62
/Widths 1945 0 R
-/BaseFont /TLGFFE+CMMI10
+/BaseFont /BEZEGY+CMMI10
/FontDescriptor 1319 0 R
>> endobj
1319 0 obj <<
/Ascent 694
/CapHeight 683
/Descent -194
-/FontName /TLGFFE+CMMI10
+/FontName /BEZEGY+CMMI10
/ItalicAngle -14.04
/StemV 72
/XHeight 431
@@ -8688,51 +8680,49 @@ endobj
/Length1 1608
/Length2 7939
/Length3 532
-/Length 8790
-/Filter /FlateDecode
->>
-stream
-xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"ÂÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!
- ³‚:  
-uû €¡
- sDn³jÉ+þÅm Fÿ΂ݺëÛHÂÊùwI|·0·^4怠¡nèß¹,¡
-*Zº\¿MÿDiݪŽÖsw¼%ö_u¨# ÿ\üÆ•E¸<y€"‚
-a%ð21% ]F‘Ñ5 ÿ¼­ˆÕè˜÷Iï}¶ïGD³Obð²hÑ‹ëÒ@ÞÊ¡g7uî“;Ž?×U87zZÈálÍñЃ,Z/&ŽÖìG ¬ "\þ|æy„I»†áž‡jKØ&Oø 6V´uÌs¯ï>jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në: Wz$>‹˜ 6!k˜¯S:”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ Àd ÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$fÚõSëÁ·RÞoÛ@*¾« ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”‡yÛ}sx/Gj¢T«$Jñ£•H âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1òx£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥ èé¹éÛR§ö
-^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚ œEë=öÚÊÔïƒ.Œ}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
-8xÏŽo‚¹ Lœ¸
-R!ß1Âr<;Þâ$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb äBñÇ›;qäë4‹¦y,'XÈ.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤ay þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘|m÷L¨3X´•¢|FSp õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®uë.ýe‡°ƒ5­†âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰ ö €À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$QÛ<.'DÑ
-(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å/0õî¼2³–ÛOy«óCúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQè
-Çö7=s`[šzþáÞ•MåME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4 G‹Æä5ÍɦŸñ ¨/„~ 2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#"Uòe¥rÞ‰Kÿ ñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô– -ÝI{ˆQeY:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúmò'ÄaeG-
-óŠW¯C鶰€®ô
-„©ÊìiÝÇ.h™³ 6'¢È6
-VÍŠ2Û71sz8o+VPÚ^­M£õ‚¨‰J®ÆÕe/ýéœGÎ>Î
-òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n† Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X ²‰¤÷•Ï´±ÝÈ/åµ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœš®`¬õ<xö¡Øà
- 1±#-@ëÓóÄ<ì¾âæ©)[‰Ø“9QuC—̨é-ûFæÉ€?›ëþYû|96£àj’òÖåUNºnî…XÓ°‰Ä·ÏGÑÅk'uÁêFd×É>0¼f»åæ6ç -#vƒl|¯göÕšŽùí:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È” §{õîû7l]
-™mÜtW?e‡ÌŠØÇRXÝŸ¶« qÐNøb%2t)( æß-Ö§9¢A¸‰Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
-(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü P!HlÆ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±Ç øË
-*Ïp›Â¤A wÓ'v•ù7Vš4¶¨ž+jÙÚN9dB<o¬L©oÝÌ#%p áÔn³òäAH41ס tö. Zm½0ë¼r˜$‰®XrJJ&¼è ¢—Ë™¯`¾eM¹»3µ¤¯û_ê÷ðö}d½)(A=À_D‰ÔôÛòbN¿Ø}® ÆÿÄ5,¢Óc9A7!ô{•K*J^ŸÀ~™j'÷%U­Y Ü{ñ•Ý‡å]ä"Lžïxiå2¬Ž/ïb…U¸ƒjå×)4§"ò§ªÓ
-?Uôü¬Ë÷
-žä²5Äõv!.[7$›\ÉÌù ö)%Ü-DÇ9øÓ\¯äͯø7F Oâ×ÏžÅÚÅ8i“£òÅf&\†
--â×6™…ÈXÓØø,ï¾ÆÇ„Ék}YÆð”êA±<‘‹?qâoYêLÁoȯü¸"‚˜‰œñµŠýVw$€ÇÞ5-M¶Ãú&š{ ŸQ}2Ñ»5ãùáö¶xĽuéBÿ;¤»¥ªïÕ\rþhüæx¿Í?‚^iºÇ&‹ ÕCžËQµb\¸THüe%¤¼®QÕE²üO¥}¿:y´ÀJ ÛAHù åP¤-´á€[kNÔ/ˆ<Í©ÁEÁ‹zHÃ('¿8/ÖÈ><ï·NZN,±$íŽÝ\ë|.ʳ4
-Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿæ‡ ¬ßôtD¤ûfP˜{s“cÞ·+J .>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡ÀK’jùÚ
-}~ÏLcÄçt>í ÔN$c÷¬¤úœ ú=nÆ©ngþõžå ÆIE^ÕÖŠ
-!dÌF æö/¨˜õpŽI^ø©Ý©²‰µ([|«Fv/f»H/>_!üËê¹ocG¥%ÅÉ s5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡ î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
-IÇäœ÷îÍóÍè v ó4ýð CihTðÞ²° ÇÒf%’2Ž
-Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ rk_‹öw€º«¹j!:/œ*¼È_Ô¦ ¶S+³(#>û­pKÕs%ìÛø“hj£ê·ßN
-\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊTãO³‰³7 †³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y £7À­ÔÁT}I”C¶–‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq Y†¶bëÑ4r3ÛDZëòa[ö_ó> (ÁÔE7 bO;8<0¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú È•†bn¥æf§çƒ\Qù²1³7›
-3ú·<Ȉ› h¥=¯`·C-ãZ*¾•‘Û3ØJ`+>…p˜;w cÁ¿ù\åµdf؆:îÉVÂÊ£QÏ
-Ló¶Ú±{i C¤üD8þúñ7.4ß=£Nƒ~ØA·™Y¼ŸíQíì
-;dÕÚÞùYÌú.ëÅ3¬m
-Œ·Ò'OܧZM•ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
-A7µ¢¿ï?å151"yUF„I×íòÏfwÊ*Q;1WG¬ä‡üÖWG9
-dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘n"¾ÿ]½GF&<ç ¤3dRµ°%‘ ”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖlNA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄ º‚íüë£-« ‡Z‹ÎîpnöŒ´Ð|˨) 2xqô¦S=w¶Æß jIž6a›6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Í æá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\Ü Gái3¼q¸Qþ¥L
-Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<– !!’=j‰Á bê÷](åÏi·t9ù
-KÆ.Ha½+-Ε[åòÿÑÒñx Ciif|-is \‹¦ÿ€|6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
-€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹– sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜Vd[ƒ1ËiÇO°<Ø_¥¶%yÐœáZ.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ £x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$Éž {ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸  âoJ°]^¯ÿRÓ HmØ;Âúž
-8>Ô
-²©
-3ã½+ôÞÊ•÷aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~z M“èRVt}õÚ+'˜ †4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹à åÏIXUb_4²üQ ¨:ù©^\õ47ãÇU¸µ& ²ðc óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg #$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
-#Ñ{0ÒŽàÿ
+/Length 8789
+/Filter /FlateDecode
+>>
+stream
+xÚívgPTݶ-HPPÉ™&çÐÉ™–œƒº–††î&K(HÎQÉH ’sÎ 9#$ˆ€øÐïžsn}ïüº÷üzõvÕ®ÚkιÆsŽ¹VmVF-]^Yª„p@óùž4`ö–Î(]°ƒ¯ÜEXYå‘P0†pP
+G8ÚCзÿãºP(
+²BÂÑ€Û¬Z
+JñDÛ‚Ñ¿s£`·n
+œ6B†NšVµúz9S,nq2BÙYÒ_+Ÿ¦Þsà›`n'.@b%iî§ZüwœJ¯îsúð {^¥’¸úCHW —Z “èŒÁv,!ieí1«¥O˜–©í[oF‹£‡y‚öƒÛ¢Aùx@”SÜeMIƒZ|
+úˆJý€•<.%sõ JŽÅ?ANïÝy¯2}oÁ[+B”z1’áž ‚`Ïtf¶¢tÈwŒ°ÏŽ·xÀ©þ™Ììè)‰ë{çqéœÅâêsn¹ÁâÑÈ!áLâ|®Å–êjÙµXùPüðáæN…:ÍâŸiËÉ#V
+.¡Þ&ä± .­µÙ:á%%¯ÆƒÀ+Ùì£àrÒôdxå ~åj}vøñÅ
+E“õî ÷*\ÔíÀ5´Êµ³nÝ¥¿ìv°¦Õ°“@<˜ÐÀÁæ„|º‡¹Uº–ÒSCö¡•Z„þîýÐni¯0q¡~‘
+5¿Õ¬g-Í=¥á`8Z4~  iN6ý”@}!ôk °)„COÊ,”úP¹EÞ}/šòÜ:o«4QßФháôBlågË”O„á1 QÏ—= GÖíÎ2‹$ö"Ä‚B5GmÞœ!kÊ€ÅÁFþ9¡Ë+TdùGô“Àû"6®ld&Zíeí{4BQãÛ£x­æ
+Çžó,g½Ã!‰âŒOòpÓª¥øℱ—ê¨,«镨’/+U²ðN\ú_øHîÙ;š2™´@r•zPÆœ±¹ú™5¿,Oì°v^=³ŽÐŽrûÊ`ÉØÒd±‡U”£'„/,&z‰â£óõ¾ Ôá­ÌÚ_'z8ƒ^»‚!OUáö:§˜VeÞö¨|BVvÔ0ó+·–0ûÖÓ¶Ú,V¿š J,â^´S´+kNï¯s¥8¡ËÐ f´“[„wO¹¹Ržáè.ÁFFM„l-¿?®f$i½*Z§g´É-@$ˆð‰´…G©3ªV;eW„ôÆwœÃðÇkÝüÓï«Ï0¾B¸9lZàâèàø3 x?Üßj¼¼ß· E=_a^ñêu(ýv
+-gھ蟖¤§I„²kZKéä”ð
+›û,¥ñ­º“Ûý ÙU@žXÒÖrÝ}Â;´w`D­.à™Œ«ž¥ÅÇ3\™»ølð­…Ébñƒ¥‚U³¢ÌöMÌœÞÎÛJ”…¶WkÓhý j¢’«qµD¹Kz瑳³B|óG\Caî+þ¹*ÊÛ~¡ñ¥ÎGÙ§}–ΪJæÄäû§ W÷HíÚ>ÛÀaòœúò4ó üN$ÕYYšžÇï_œ••W+vqƒÛSš:± 0ZÌ©„›a‚â[‹”%sˆ{¬Þd?zä­7~ÞÛsý3M{öži17ÍÖ‚\"éýGeã3mì7
+Kygm/®SÉçÍÄ\ÊqÈbO;z¸‰ð «-4'¤§€+k=ž~(6¸hLìÈÒúô<6»¯´yjÊ^"þxNLÝ°Ç%3jz˾‘e2 ÃÏfĺEÎ>_žÝ(¸š¤²uy•“®ƒ›{!Þ4l"ùíóQtñÚIÝE°ºÙu² ¯‡Ån¹¹ÄùÂGˈÃÄ ›
+?y“w¾ G$ÜË×ß™‹<Ê™2ãtÏ¢Þ}ÿ†­ @´yIGbc‚²Kê·HŸ|ëÖ x°–Ñx½Ùþ2—€_M”+=‘Û~d˜„“•/tŸ†ò³vLFd*°Ä¾ù±b«&} ¢¥çË/à¥2 ?‘©"B¾,|BÊ1û楛æŽÈkf}°¿Åø«þŒ„g“IÆÞyã8‚© .ͲmhïF`”ÜN‚”ƺʨjÊéž=wþ¼æuußÆ?ÀTÓˆ½~.%º·2¢_½¥’()“5”ôe-èÍÜhxlšŒS+é\d®ýÞ¢Ïd=ºñbfýFÇO¹!3‚"Ž±6÷'íjCœ´¾X‰Œ]Š*ÅÂBùwK‡õiŽ€hn"d²¦…Œ·âg쎓š™Îë`ÎÓp¦»²'UJfaþ»f[Ĉ]ˆ•á®þÍz´&—À$ñZ¼¡®i¾—fG‹LßÇzbÕû\dÊÅï격|X“Ý\sÉ•ŠØÊ+¾ÿ fÜŸ|>„%ýHÎÌÚ`=6"æ’P«ô9#Ñ\ Ó#3z-Rô|%ñ¨$¾Gc^¤‹M]÷²³Ôú{'¢_ýDÊû1éÍ*õ,θÈêÝþ²â³Gƒg¸LMa2B Æ»é»*+M[TÏ•´lm§2!ž7V¦Ôˆ·nŠæ‘’¸†pj7ŒÙ>ò"$›XêÐ:{—­¶^˜u^9Ì’„‡DW¬9%%^ ÑËå,W0ß²¦ÜÝ™ZÒ×ý/õ{øúÆ>²Ý” à/"ŽDkúmù0§_ì>WTxìÑéƹœ ‹›
+zƒ½Ê-%¯Oà¸L5“‡û’ªV,î½øÊáÃz‡>ò&ïw¼´rY6Ç—ÆJwŽGƒ ±Â*ÜA5ƒ
+ëšSùSÕi…Ÿ*z~Öå{OrÛÎâ¿z»—­’M®læ|Pû„î"‡ãüi®WêæˆOâ›Ð'ñëgÏbíbœŒÉQùb³ 3.ã…ñk›ÌBd¬ilüÖw_ãcÂŒ´¾,ã Ž
+¢&tG÷ü©Ï¾2¤ûôþÌÓ(v'«.Š
+òôÿÑü0íû¾€Žˆtß
+sožbrÌûvE ²ÁÅ/ÍWRÙu/w¦ØÒÕÛïòxœ‘ h<LšøÖ‘píÇâa ®”Y
+Kqh|>6œÊ³(æÀ’ßë.
+ a‰ñµoWkrŸÔgÔÅÖº›Ð˜wÜ6îÂÞN¾Ùö i± XüÐ~ýÅ´á´ÙÞVó Þ³6÷³Ý>EŽ
+‹^±Šî±nl#šñ‰65%,ç_°Oê”+µNý%Ùz¯>W7¶]•fzã}A}H›ÎÀSÝÀ~ƒQrNÉ)îs¬þr]Lf¸á“
+<á¼ØËûò Aê)¡³k¯×ývuSøGlVªs#Nu¥¬·OŠE•?.j?ø ÿ©ÓwGä“øݺ23oªkvSÛë>Ñ=¶ Ðz¸^"èÁ8¡-òo*N¡žº3Xl‰eÓk‹þœ %¿_>
+Ý‘o•~~æHj¦ä=ß‚§§Øç÷üÁ4fA|Nç“ž@íD2ÏJªÏ ªßãfœêvæ_ïùQÎ`œTäUí`­Ø@–¶Y™i"Çø¡Ñ=¸M×g•Õ´1š:Uпƒfèò©ü¢hçˆ Šl`‡N¤·èç«s¼„klbhL˜:g6(皊…KQ}ÈÞ]Ÿjƒ+ÅÁ7„,IL$¥<³ Àãyª1ÕÓ¬^Ubó¥s¼=õ¤¯æ-_ãº"/·ÒøìX¸¶å¤)"<XŠxÜ*%Å•€,Kß‹?¯‘¬’ÿ„Ç#8,Gi§ñ
+D¯°4Õ4øO‰h§ª‚Ã*÷)É›%ŠØb~ø-GÈs“I»øNà9-ŽSqÈÓºD {Ú½S\pzùÃuyjD¡«†k!ÈÅ¡ùð4yªQemˆÿÉX‡Fiomß­¿»jÑÄŒŸ*m—­´Ã”8Fèc…ךÆàAÔÉÜî°’Z¼5è篫a¸”dñF~²á)ž!“F³ò±Ëâ7£gªØjB}X€‰/‘'™“š"ZtÍCöEqË’¼R7ö¿Õð®ÒÂö@.)¨F…t ‘½uŸ¬®%Qò«§µEp˜Çd€™ÑÛkï#ÝýFø‡‰0A³KE*3Æ€F ‚é®0BÖLqÄ`nÿ‚Š%P爉䅟Ú*›X‹²Å·jÔi÷b¶‹ôRáó"¿¬žû6vTZRœÌ°T3 Séèv\ã«%øÜýI ¯”Þ¯é¡ëæ®ZÖ·mpßú”Qn?ø&Å—Â#Ôߟ›ì}ÅÀ^í° ª"Á"çt{RH:†×¼woŽ¸ÏhFO°™§éç€oÊC£B÷~”…
+ sœçã¸!q?Oƒ¶•G¯îW̳ŒÔ)HænÉøoÌF–A£Êå{Ç‘æä8£jýäUu;W+Aà¢ïóÇ;X;{¥ð”ÇÎwÆ}x" Æš=×N¿nc}& ±Éy[µ~œ ¿öµh¨»š«¢³ñ©"Ì‹üEmÊ`;µ
+Lj
+â³ß
+Ì Q=w¾?‰¦6ª~ûá¤àõd‰xW/aéÒÛ‹†Cú\»UÒâàfÒ~…¶‡Í
+¤´HNú2HBÃ8—GÂ+zq(6|£}h`wŽXn‘ÉÖ­\ƒd0ÖŸ9yEúQ§lõ8þ4»G“‘Èh(1›‚#Tšl8ùñ\^ß/Jö\¥H§¼¿Õž‹r2Σ}‰RÕ»Y€|áCžÓ|ƒi xCªݪÌZ-›Çð0ÜJLÕ—D9dkùåΞ‹üÀu !!‘}U?³9Ü«eŒiÒF̦ì½Äõ–çwNRi¸Ž~ÑqÂzÊ—eh )¶M# ±M¤µ.?¶%aÿ5ßóÀ€L]t“ö´ƒÓÈÙ‹CM³S­ê£²lµ^÷³²ÚfÉÔë'7±‹÷bqÛG2®K œ¾’j…Ã×?“ vœ:Û¤~í ^~ŒÓ}ü>[6ï¥Ô‘Uïi!~£óú“á{±±?Gywuîj>S–µ¿ƒÆçò8CëD?¯‹{ÇéëˆLŠ"X?¹ÒPÌ­ÔÜìô|/*_6fñfw
+=ÂRŸó>ÍjóðÔv)Ùyÿ¹[G¼Ü5)­…ðwÃä¼Ar«òqsV
+…üЦ^o{<´p–…p¤(„¬Ý¡òž#%
+o– ›.%§ª¿ƒàêÕÎ*4Z®÷„&§xás=G‡ü<ṼǕoÜRŠÂò7ð|lä”güâ(l€Â(Ù‘(8Å|)ÿ¿wÆô/þQL™ uG«ØâÐÏœÎÎ~N*{cÀt(û6HÝB=viˆÀ%ŒÐ/ÌÐà>^P䶊ŧ¡¯ÕrȈ=ÂÆé2¾ldÔD4“kêœÐw§3\Wd†@$B}vÓmwÝK&à#ýÁ?¡e6êœÿ¸¥*IÖÔ*Àií¨²Q„É¿åAFÜd@+íy‡íj¡×Ré­¬üž±àV{ñ)„ÓÜy¸K þÍç*ï¬%3Ã6ÄÐqO®Vîz
+Pdž·ÕŽÝKcì" ÂñקÃ߸Ð|÷”: úaAÞffñ~þµGµ³+ìMk{çg1Û»tîO±¶)0ÞÊœ<vŸj5Uq"¯}h‘ïÎ[ ã^ý­ŒwXcsÝX YVW³Zxg/ÁÍ& YÜÔŠþ6¾ÿ„×ÔĈäUu&S·+0›Ý)§LI4îÄR°vò[_•(ÉëOJ¼‡ŽÛXÄbÉÛú󅟃HÙ¾üª½[!+ØÑ™õd­¶¶¹c ¡µìÉŠaüð L²ëb_Àå¦RnMúY6F¿ÅýíÕ<úx*¸÷â&?ñiÛJÌ¤éŠ Žô·Î±¯‰Ò%§¤+Ž pñýïê=Ú02á=o !“®…-‰NØ ží2_Ûš,l|%ÕvW”v¨q$M1‘]–OmÍöèÂg®eÝ/Ý»ÈÔß1x±]Ô'ÎÝíÎ<± úa’'0x{&¿µx¯ùí©wÏ.o†l¬AÁ +Øο>Ú²Ê.ÔZlvp‡k³g¤…æ[FMIÁ‹£÷0ê¹³ÕvœøæhPKò´ ûäx´!vyÚ³×eœï?uúfK¿ŠÈ+>ªX'·[ò&&ÇŒÈSm"~Ê\mŸ$¯ GÊ-ˆýJo%ÛÞêdyž†õJ-»Û¼`~DÒ]FB´§Aäû¹xx²Ãò`}fZ%±ÆÈr™6³Á‡å_Êf
+í&2PƒóuíIŸ[^|uÊàïíŽl«0x¦ŸøpÙ(ÈÅ%mé…ÆÃð½/¯ ±sqØo
+ŠÉËQfþNÒúðÄCzòÛgêg_åD6ºq¸I“ª¸ÊFØ2Ëv­Ö¦™˜¤Pé¿g¦Uu䂱~Õ#ÉUz$¼
+ÇHÄ•vËÕ$«x-‘–ß™š¦#{eöòÓ`ÐhšDŸâ°º ë«×^9ÁB0¤ñ뫽‡í»˜m×ÖÜ¢Ò ¯-‘+ÖŒ!ÇBPŸÕvî¦è ·?§¡ºƒ¼E^$‡ý…’*O*n˜.—Çw2wÏ5N¨°xNÂø,†éõG#ËÕ€ª“ŸêÅUOr3~\Å[kÒ¸! 9×0ϵ
+CÝ_‹{™éÉYŠúð["šgì2eàß$‹îy;Þ;Ú
+_ƒ ÃižòÆv==·%!Ãd2KVûBàùü€ÿ'
endobj
1003 0 obj <<
/Type /Font
@@ -8741,14 +8731,14 @@ endobj
/FirstChar 36
/LastChar 121
/Widths 1946 0 R
-/BaseFont /KVEJPS+NimbusSanL-Bold
+/BaseFont /IWEKKH+NimbusSanL-Bold
/FontDescriptor 1001 0 R
>> endobj
1001 0 obj <<
/Ascent 722
/CapHeight 722
/Descent -217
-/FontName /KVEJPS+NimbusSanL-Bold
+/FontName /IWEKKH+NimbusSanL-Bold
/ItalicAngle 0
/StemV 141
/XHeight 532
@@ -8768,45 +8758,31 @@ endobj
/Filter /FlateDecode
>>
stream
-xÚízUX\[Ö-4Á½p'¸»»WA!T¡Á àî‚»[p×àîšw÷Ë9ýŸîÛ§û>Ý·ûݪ‡½Ös9çXsµŠŠ\YIÄÜÎ$iudbeò!¶¦Np5¨<“*È ðrš`RQ©Cm@ÿA?b0‰#Ä*nâøÄ«[:L`
-´ƒñ”a[»
-‚Û9ÁÌ@p>
-³³wƒA,,´ªZt ŒÿBXyyy¦n1
-
-W4±XDå%uEþÞû?£DEíž$™X¹9
-}¾-æÖ#}H^t¡C%$6„¯`GäMz¥»¹å „JBV”U‚¡´5MÇûòÆï@IÚÆK…u²¿Eh嘀%ÛZ;vM#«‹U»wIPÒŒo<5Ý%ŠÃé= …éXydJ¢SÀÍ×2ÔÊvcYؾ)ï·Ïâ”e7°_`ì΄ÔÎXnÖ„Î51X{á¡Ætç‡YbÁ"ðßÄoÔõ•
-PÂ|®Zg{°D4Tí_ý”¯UmQ25¥|AÖ)ëLȳZ¥ Ñb^nôn ú²ÞB…xM£îR£ùDK$j£sQ5RÓà¹Ð,àêz)ÙTÆËl;bÑBÛ²Ëe£Žöè
-G¸»—Úä–Ú±æÂ-/é‹-
-ýWÉØEºëýhÀX㣄ÂÀf"Ót¯ÐƒpÑo^¯1±¸.öØHˆ=åªåœ÷îߙǹF/;¤Ëfù4£õ?Ò&V›ÚW G IÞAÜ…tΛ§2 GÀ@*7­¢µ\N¤,t(ð£šlED¢­|€ÕmÑG,]hR!¦æâ»™­¬Ô.)ªä^d>lí7Œù,̧—š‘ϸ$ßðÍ1QXžJ¸¼CÇçjP½Tä‘‹¥J]È<$5)‰É¬-²F3Ž­óSøóÛú´ ¾À;Óû4ï/çŠzíZ³ÄFMöD@7IÍŒ“Þ}¬?ªÜÓÕœ\Ç­2k¼¦ž¯#Fß¿†¬®ÿzð¢úrýA[H‘:%áYT΢2%—Ž•#õ;ð,/}Àh;?NTŠ•y^@Ipèþ‡æã*?ׂ§úWQäÏ|z8=Ѳ…~GX¯ÆÆ(‘•‹û9!}ãOnú 3Ÿ¤ Ö>¿ˆþ%VÝ–²¶Í-º“ø}`ã®k\ÇpoR²_ô  ïƳ o8à«F+¶WO¡£We)cÕ SK?W¿:öúª_?×…zêBBãõѼhjAŸY-úguœÜ®äÂ`g¤JÌu÷!-AséEŒV
-ô¢=úÒŸ¨8¯é›«p1{h~õ}Ú:cŠœNêC
-¡b!Ñè¨à%ØC½<«â Y+·þyõ¡”ÿ}¬¯—Ÿ'A¸’|ÑK_
-›—ê«ø¬;Þè%Ïák-oòJlsùV{ϳŒsø«T-#ñõ$æ¦ÒUhŽJâesm
-î …^×Æ}<3ï°÷Ñ;ýeúr¾Æ6¼uˆÄFQÕøê°Š _¶ÀÇÐKQÇ·¸cq^Г‰Ä¥‚õEq5‡j½oLnÇ:#þŠÝâ°¥K+ÑX$mgãEXRmƒ>ôù’D–N¶¨éÆ{÷Ó#7Ýü¡§k™¼É©Ø6 ÒË*‡@=&Å”\Å¢¼åÕÕä“ÑÌìÙpÊ!kQù··§¸Úg#÷4¥E½ì{5ÌP£ª1Z·•ÊA:ᙋë_ ¹È!²¢ÜéPœ!deÍ¡Ñü|E4ÔJ·„0l®ÓY!8aÜKåÀ82o®˜¥49¾‰2í.Ù•Ó‚f¾wµÁÁ¹˜³S`úÏ{Aá9”´6Õ»ÛE£r…˜æ;E¤WØvn3©.un/~ ¶=½û[œ¥¢ð|àÝ+;ßR¾zÞ³$CÉt>}_rÏ`‡Ôªýž5â$é"ÞÝ]P«túqóöD™}aG›%D˜À·þ»UÅZÝj›ô&œÎŤPÃwÄ7ñÙ[ðï,cÒ´‚½l$õwÌaBC$(Vœ®¢]Ñ 1Q±i• Fa =|~ã9þr\êeqØŸ]kgªü»¾qçKgqnMªà~µºP™»ÜwŠŒBeÞ§GPñô…¦ä»÷_ãª*H+1,x¼ñLa¼×~X45<D·â+¯Ÿ¨Ö$J;ÀB<ÄÄ<¶3TåT_L|6¦ë—Á¦Õ9U N¿šû,§ïÙD_Råù-â(¹ŠØhˆØ”T«´º˜å~}'$ŠÝ’*t¦Óè”áÕYÙH’·Ø ¥÷»ƒAÎ.•DÜûrÚâÐíXÞ#÷î£DR}eùY{ìKÅxág”â[ï^º©âL‹bàbw©Î'Ä*\•ÕáƆ_îßàø!Ô[7t¿mäxîýqt ¹$=+çË$¤v}¸‡c
-Ô!ó®£éÞn¢ò¿ŠM¡[òã¶%¹é!° ª[ñ‹ÆÚ²1~cX윿Ú´ˆ­È—EÆ¡Õ)™K¦¶æEº ØÃ Û KÛJúú¼)^^ºñÑœJ#D‘
-Nf›@‹JìžÔD÷ÊB:]µõ>“UÏ ãÙ™îÖÙñB=4@ŒKlÅÞ6 ÂG&½øKzFäX1çl¸·’ÆE·Gs'06‚ð›õ[&–O–·ÚÁ=üœ{€„&™&÷Ú×]Bó¯Fqƒ(›¦Ï0w!rF¹âå‚Ȫ1»,%÷>o¢›d‹Ö$9ޥɼ&ª†Œýà°é$!òƱy/F³tñžŽ~¸Áàò«ýK'ÍÎJ¤@­ÅÏþg„èá×Þ]…µ dOÞaéU¯ŸÎ¬šølò–¾ö˜¿ ó”¹ÇÇPƒ™‹ÀZ¨Œþ¨GÊŸ±ñƒùÏ4˜]òy¿ˆÊÅBuvVÂ×T<ŸuÙ«é@Ö­¬bÀøö¯¶w6}z~Ò†ƒ¾
-ç£C×|h€I_*bMWB¤ÍOÞ$Æ4ŸØÇÛK–¹¹néZ›ÇP®¥µ-Åû¾É‹ÀmýÑ0VŸ©Ú&—ÃØcHGI[Ww÷M w’X{<­õlÏS¥0,ìš¿Æ`·ëÅC%HˆC¸¤êp–™ ˜°„”|@<Õ+ä„s:$¢íµ1Ü-ýÍKkïs|”™6¼W!ß¹XB}Û8ÇõVŒ¼e¿9a`¾ä|ÖÒ{3Úoãø±fíÆMÅ`i0Éâ¨ÆN‘AßÕIdŽxå^e Q á8lqh—(úÌeeohë«ù/?äÅ(É@D-Ê°¹Z™×yå‚tD®|lG"¼/ö1Š£rÊ–È5·vû\?êïõŽâÜ ‰ìQÆLQ"‹Q6fß^S‡mY‚Úž"G#8QeùtY÷£ùAqT\ÙˆÚ Žxc“Ì:2„¥5Z­ï‘Þ¯¶ ý.Kª×j£cëá‰(yÀŒ}‰ª0Žõ;HRP^PxGlõ‡ê)ëqЕÉ ´¥a’;Ò¢‹öÊžMBZ~X^ìÌï¾äàá±úArpרˑ¦âFÀ´"nÚ6ë
-VæZ¡ác€†”' ¹ííÒÌŸ‡k@…’SVŽþ<3#êZ¯ }â|çó÷
-72øæÃ)"ŠÖàÈŽÄuD"cWd ,?ñ¹ íŸžu
- Êæ§=„2ñq¿X‹í41I²õMi~†A§^sy¾]áïý––¾xo7Ï8£™éÀ±É?'©ˆ”óé•5 ÐòÜGÙÖo
-'+¨£À7E6Šý5kI)‹4Ò¥(ib^—ücr8GCúg¶ªç‰˜é)oì…©yË[ï"åF³üò¦d îƒØ#Ê‚ã¼D}“M uÖ¯ÙsvO¤*<w6|Sb *EÝM©‘ÆHW…ò]8¨û^º²W©"we Šý¼h6V:®÷v!(;»³·@åfÈ”¬ø
-)ÒQñÀ-ÎXvµ!²‹®èÏ]@¡™A€5a¬X<5F1nÐ;¤BP•pžù-¿¯_0œf¤£âäjeù¥ç0r¦,–il¼zÂE¯oa_†Iy–=Ù)ïyÒn¸wIšAŸ®^~¼Yà1)–0Ë+üy7°¢ñðN_¯RÆ­»×q²©5º ÚT óüÎóÚ¥ŒV
-Hò \ŽNe2øXÜüΣU•³»7jèC^+Ç¡… Äøê CMé¶&/‹ôÄ´Ü…+ýÅNW3]h›/jÌØúAüò4!ÏʘêÁËíd'Ü÷~tÕ´1ûr„™qyëíLËæ§ÒõÉÀøä4LîÓw :^?Ò1 xÙqùÞzÿJ°oeõ‰×toì!ŸÜjjæž:ÒkÄ*ÜÂfñ|Ç .sÀÑ •Ä@K9ð›£xµ6Ü” o
-VåŽÑ6œV¹6?±ãG©¯]g%X춱™Ñ¥÷œtßøÍÑHóÊÀ»(N’¹a×2ÚǶÙ»Çtïù´ü
-Še~Í7
-¹„ÿ¬ —ñç)[¬ÜÚøxn(:ÿÜÎZ(òª´ÛÖ8ŠXÒ'¼Jç]=3^ÄoªGLJÛšÈ醙©Lìƒs?º…ªzm VfZAý÷2½|U”SòÀÙ×..­bì
-ûÜ(lC‡#7U"{—k´J¢‘ÑÉ­J^Þ¬Èxèõ¢
-i>hÄ,?Œÿa<”ª 6
-*ô ¦ßFòÙ9HÒHØS"‚Á{&í\ÐJ
-rý-Ñ_dg0%0kü$´J¥ó4 Ö Åy¿ÒEn@~U±Tþ¬§d®’µÚËAƱÖ®]fmŒR]彺ãÉÛfÕÏ°{;AªÞ 7ˆiŒÈ}4K)R?~YŠL/6‰ïÏ`÷³j‘áǬq4Ÿï°ç¾ÞcP\Y§&¢#'m#×RΩ‡Q­dÍ[_ n÷W©ãoÛ*m+Ö  ÏVv—äà‚¯‘烦U²
-t"Ÿ8ˆ¥ï]zŽ8…`*‹ý©f´e†¡‡-áÒKˆR.Ķ”¤xæ:Ê1¡’_SÏõ<öªúÔufVÞjÚöË ´ÂzqÙ+„…7Ô9 3•"Í â”r)©£ eïR‰Ó˜D§Í2’¡%=}'¶R5ÏïL÷S<ZMoź%³Ð'©cÐð\,WÔʪ5”¿a{b¿ê£©·¡á{àéXJ¾`‘³Ó ™nÝh}V™Y£nöÈÞ’ F=ë -ÊQ‰“>º,‹Ä}#/7 nmFY,8gM8k˜1ür!¥€,…¡˜²±mǻ²jºAI±­…Ññ¥G1ùQC“#‰[nʶ€†Uòš}fip­Ïþªu­1gà°Èx$­yi_ —hÇŒDµ6öQ@Ç®…nSô€BÔöˆF‡ãj¾ñ~¢-n´éMҢƮsÁ|Ëy3{þâxfz[k.˜ʇÌJÅ,¯Õ ’b–ñT÷vÁÛ±äóžá¨FÔ8èaØ{õí¹o‰“tF•G4m•Ò”î£)ÊS5ãx$N˜6#CŸ÷o m‘Ç–¼´>x\ù70ŒÉZ}yÅä&®ûŽM“Ä‹ì#7üCJ6„Ьíþ[äPþuS¬ÐÌNì˜Zü9Å
-ÛCg‡Kh FýÂPŸúû£ &FÙ^;+¡(Ú¢[åºC©Dìôa¦ëKU]~SKÅê¶%ï/O?7r/Å *Éö鱬ÆðsMYº4¨[†Ê‚^®ÔJ¥¢Ý|‰J ˆx!KÚ89‹â¾"x4º‹æÛ³^›Ù„M…º¶áñ²Q5¬S'A᎖±t­[þ“š~›%´OR;³ŽZ×# /µšÞ5†vð4UÐ_E†IÕ R}Fc‡ÊÌb\}|›úlT櫾;MI¼9¢µD^Æu{õ1¶¿{´1öFy”"}±FúÃLf_ÜÅÅ;FOuæøþ|~5¦Î ÇëÄCš¢Õ„’+ê´Éø–õzÓ&丿ª¬’E牊ô‡Mâ‰t/&%Ï©J5ÛÑ¥Š‡¬GÊÔ:Îøö•¿ÒÖSØ:–’cˆº —ûq«Å(Lä@Å"^$¿u1§.j¾ÀZ¬Ú=;ˆðá:Ø3ÈäÁÏ/én¼¡,*¢`\ÜäK}[¢pÊHTÁÞˆo`ÝÙýz„N¢&j¸'µ6ó‹|K×c6Qém)' üÖšëv?.ßüê¼–®XÌ£¯íV]GOŸIª~Ib‚µ³ÉЄH\Ô‡óÉ}vÆù¾%°å1ù{'¾Ëgâ݇ûmœ‡½*œ‰VákÑJ£Ù9ÿ>IžÓZ䀴Òï³€!&A»p¬€Xy¬×ž£ùÅm{!éi„„·}¿·CÚ?/UÌ+¿r"*Ý=AVˆkr˜ˆºz)–þpÙæ YÔškªw¥°8ã q·An;d„jê®ïé¤ñÄyâ™”‰váˆÒEjüHµjøÖ äzÑw
-ÐöD-.ž!?çìK‡½«ÎYW IaÕR@BJ‰êGBy´øxF^°D5w¯mÁŸ–y ÷|pµƒì{žù÷@¶¬,)9ÅÌÑVŒhj|C?Åã˜Df¡×›ìë¬)¡=  SŠ ¯ª¢…¹"$ …\ÓŒçÖéiøœY
-u^îsï][øWü]¿›8¡e±É^&UÓR¨³tøÃÇ@XáѧF÷§€Rç ÙiîÌ#=sç&-<~èêÆŽœE×–¶÷.Ö}ìhrr²ë«À±æ K<ó$wtÕ°Cn%µ@ݸ*…wN.߆Z¢r™NŽ:úõŒjLâTãPê".!)Où?dð<Ÿ½h·Óô¯=B­›B] oº×bûJèo×°Æ°­\FØQêX¢öC@iSÑÕåÖ÷¥<7_±­¸ôˆ+²»ÞÌ3å³_Ž¾«–’ñ +¼Ì‚ ¸~sOsÔ|ùÆ©-Ê §>8ß`@).æXIw5ßJyc¹Rc
-Š'ù¾r*X¢!Ïñþ¦ü—E——Ïv¬ƒ­Ý¦·P3k,Á´ESpQÆ <4» ÕR{_5¤},ÓI;÷Aà·álUM„›¸èã>ÃÂø¸v\Þð]D.½ù'›ñé“¢êwm´¦ºo´Û…žI}³Þ9 ñ‚;Z ¯ËörMÅ@y=ÀxHéRÊËûrŠt$úyóy±‹ »…ò½­[Lös[ ápkï1’שÛåw‰:Èy‡„VqÑ„\uË!ˆ²I™\±NzNÄV^Âê©(µy¿^#á@Pjîvaød~ûlt•ê²2I3±¯ó݉åU‰ZÈè´&~#ºGùŸxTHÍ™lú¾°mo÷&šŒüŒü‚jø=AÉ+´wܺ*ݬ/çöµ0oö/
-–ðO?}ÿJÎxEY{¶ Œàû±º<0„KuúE-+È+õq‰I{økå‰"ÞŠUj#¾~Å©IaÛþE5ùÕºýË»xHͺתèÈNÕ”nóN pðZíÁ+ì–«$ÛMÔžë=£˜l†xžlÜ8Ž×:(n v#¹ÐWƒt@
-`Lᆫýó”5]ÿQ¸5åð—“/>ßà‰õ¡SÒLrÞð š‹a¶ÅŽ jé9Z ç„ûc휮qövpÕw2™šŽ_
-™]Á·ea~šåè-q#Øt˜Q’0ÚŒ¯ÞáŒ: Q
-f¯¦Ùü#K#üñàFÄ×`Ä÷ˆÛ7`Ë$‚ñlj9Äé“ÂÖ$(?¹Nùe–à%¨"Kä­^Ë«£¸EŸÇ÷!Ý”âû¿B&ôJä“g]œlùÅÞܸ!&B‹Ê樅ùÞë~ŸÙoE?/猛åXxÃÕò“×Ð*®j­Ø¶eJK}› ÉqAµ­×¹Å$øÙ4F;&ÿ¢ÎÒ³ô3]C9Â>¬w=ÄŸÂËUåæHßÌÜn t¿”è®þÝâÖn—ü³¦h ?„K¤AØñì¶,á:  á®Còí'ðÿòƒùÿþŸ0³™ÀílM`Ö˜î0ÜÑöÇ?Ÿ0ÿ\
+xÚízUX\[Ö-4Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3 
+në3Áù
+|ØGè´£ÇÀNâ¨Ð× éÛb®=R‡äEÚTBbCøª¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä–~ X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“’˜•G&$ÚÜ|-C­l7…à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,rÿMüF]_©
+ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙAÝ$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼LôÃaìtþ8QIVæyU&Á¡û«ü\ žj_E‘{<óéYàôDËæúløa½ê£D–Îîç„xô?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷AŒ»®qmƒ½Éý¢¹Hx7žMxÃ_Õ[±½z
+¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯æES úLkéDÐ?«áäv%.
+šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü< ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*Yƒ?åïyÚóíʈfüλ» ²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5 œ} ó.T²¶/0žyÖ]±!3f\CÕ1WR|#¯o‚Ǧ?}Fq?¯ÓfÏ ‰²¾RŒ2Á œðäÞ"#
+hŠÚ?åðP‘­||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´ Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä ßÉ`hˆ Y›½ goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•HÝ{”é·ÄÞê
+Ô +¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce”­µEx`Iµ5úÐçK:™¢¦ïÝOÜtó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâjèßÓ”võVسïuÔt2C «Æh]W*é„g̯%ä"‡È@Šr¤Bqf„•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVN šùÞÕç6bÎNé?ï…çPÒZWïn›vÊ
+bší‘v\aۺΤ:×}¸½øÚ"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0oýwËŠµºÕ6©M8³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ* ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡<w¹ï…ʼOŽ  âé MÉwï¿ÆUQ8øx¬È¬¿àñÆ3…}ð^ëaÑÄà|Ý’¯¼~¢Zw(í
+kA,Èž¼ÃR*(^?X5ðÙä,|í0&æ)q¡35QýQ”>1(`ãóŸ©3;çó~•…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
+îlúôü4  }
+¸iÛ¬[
+AEÂiæ·Ü¾^Ápš¡¶²S‹q”)ä—®}ÀÈ™’X¦‘Ñê ½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñfǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ùG«
+gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm ^©‰iÙ;4
+ú‹®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe 3+âòÖÛ'˜–ÍN¥ê“7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f£N2ú
+wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>3¡6º­1•üVŽ mjƒ3/7¯=Íôþ &!nIy<<QDð"'É[nt”;D[sZæZÿÄŽ¥¾v™•8`±ÝÆfF—ÚsÔ|¯ï7G 9Î+ ?Iæ†]KkÛdìÓ½çÓô+(–¶ÿ5ß(äþCT°‚\ÚŸ§l±npOhÃíÜ@tþ¹3´6PäUi·QñGŸð*íwõÌx¿©1)mvj"§f6¦F0±ÎýèªêµÌY™i õÞK÷òUQNÉg_;;C4‹±o­%bT èŠÍ†d^âF G ÐÛk—W·>`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YMçËá.žÜÃ_bÔõ~¬›ÖwŸXöçÏ×{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“ Z½¼Y‘ñ&ÐëE\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤ÐiÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì„ýn&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê
+F‘PÖçhé!ÍFµù„複ì‚4ãE¢Q¢ªÈŒ êË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä —QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š†Â¸ª¾àÛ㼿°è/©äG Z­Ö¸µ²¤Ë›w f§þĺ#7^•Ÿ?<Žàa¶Úñ9" ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
+g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘ -éé;±‘¬y~`²ŸâÑjr+Ö-±˜…>IEƒfçl±¢ZV­®ô ÛûUM½5 ßOÇRòˆœN@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ùq+SÊbÁ9+²ÀYƒŒá— )mdA( Å”µˆm;ÞUÓ ŠÊˆm-Œ/=ŠÉ?ˆ)CH ÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
+ ¢6G4ÚWó÷mq£Mo’¾íü0zt™ žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV³Œ§²· ÞŽ%Ÿð G5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿aLÆòË+&ç0qwl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç} ékŠ»*lí,¡µ =êïΘexí¬„¢h‹®•ëö¥°gЇ™N¬/U tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Ê º=¸’+•"‹~tó%Ê"â…,iãä,
+àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^$¼Ôlz×ÚÁÓT @ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº —ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
+Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢ &j¸'µ2ó‹|K×c6Qén)' üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾<§µÈi¥ßgCL‚¶áX±rX¯=Gó‹Ûìö.BÒÓ oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQ쪡³¾§Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒËEßE(@˵¸x†üœ³/ö®:g]!$…US ](%v¨ åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ïlY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UE s $DH@
+٦ϭÓ%"Òð9Ó
+-ý¸Bçhµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±íÅ EþoÉ|Ľ„\cvê´
+Y É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh"rr²Ë«À±æ <³$wt•°CnEÕ@¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B] oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±¸Ôˆ ²»ÞÌ3å³_Ž¾«š’ñ #¼Ì‚ ¸~sOsÔ|ùƱ-J?§>8_@1.æXIg5ßRic¹Rc
endobj
1000 0 obj <<
/Type /Font
@@ -8815,14 +8791,14 @@ endobj
/FirstChar 2
/LastChar 151
/Widths 1947 0 R
-/BaseFont /BLFZAM+NimbusSanL-Regu
+/BaseFont /NHZOHJ+NimbusSanL-Regu
/FontDescriptor 998 0 R
>> endobj
998 0 obj <<
/Ascent 712
/CapHeight 712
/Descent -213
-/FontName /BLFZAM+NimbusSanL-Regu
+/FontName /NHZOHJ+NimbusSanL-Regu
/ItalicAngle 0
/StemV 85
/XHeight 523
@@ -8838,42 +8814,37 @@ endobj
/Length1 1624
/Length2 8579
/Length3 532
-/Length 9445
-/Filter /FlateDecode
->>
-stream
-xÚíwePœë–.îîNCpwOpw‚o Fº¡iÜÝ ,¸$¸C‚ÜÝ!h€@p’
- €€
-àçû[nëáúÌû«@lf†ý) -âì°ÙañjAáO.lÿ³.óüûšüohñ¿¥Áÿ–öþïšû¯=ú/—ø{Ÿÿ•ZÉÃÙY èò4
-:ÚœÿÝnýKSçiàú>® Àÿqc¤ µýÏÃ99¨7À[„À- *∉òü7ÿ¢áÿçY‡½¦|<||ü€§ß|ÿy2ÿEˆ ÔöÏ̼„!¶OcöŸ‚?° öÔÝ¿nþSÒÿ8ÿ5ð 7Èkij#¯#ÏU0íéæGˆp-mÔ/)
-®veFoŠWZý®ài—xhõ™ûæz¿£Æ±;ØMæÌÚ•ú^HðŒýsáK»(çn(¯E)nÖ‘Q¼ßé¬ÆŠ‰ŸáîÖ¨®žÅûßh´ãí‚0ŒÓöàgžEÁ$L×®x6 ¯I;šˆêŠ¿±¤Ü\³ö }èïúúy‡š3ï5&³¤'
-.K\°[µ´‰A¥_ Ó Å¡Bl³TÙqÆ?ÜÀOqDú!Ý‚+©r:çšôäØMbôfÃÚlƒ*Ô—L›@“à9ù¨è#àÃÎΙ ËŠ"¹LBÜZcùi{P:Ø—W¨#pöó«ŠM¥Ð
-8G…cDùcì‹¡ŸˆpÏw¬W°{÷¾qSv9Íš©@ýª…?ÏTé‰8aUÞX"ß ­Ù1I G N?öÉ; a½Þ6Ä“¬Í2þ*>Q'Ñ
-ùjêÆ×'ùæ¡y©Ãm¢•N{µÀÕ’¯+ÙÄꦛõóK¼ âIR'¹èºGcSCê™ïßzÚÓ>Ñ€Ò;,búñÖú)®Ö‡ÒŸG Œ-Ò<ÌõOE,ÇH£òfd&¨³ :Šó¿0s[jöµMáÄk‘É ‡+ûv­el3¼)IZýU+Nšßø^’©‚´a¡üs…&2¡$ïâ±ÞµmC×/VÚ‡gÓUXRúTé¯.Mßjaé¼ËÐ;ºÔh}éP`ên—Ì(8j"¢ºiµΘâ î%Òà
-¦¸â¤$º÷.ýç{‘QCöVw>ÇÁ¨qŒyöù… …»¸ßÂiý#ý«:¹öRÜNìC‘ÿ]= QÂ@ âi?cU‘ÈšêÑE
-Zð•ÙòëŽ(¿uûƒ‘›
-Ž**E×…þòõÏ
->‹¥Æ“Œ½ü2ñ1É:”#:N@ØÀÕë—b6TæZçÈ&Ý’jŠNë½O'y˜s¯Æå–Å¥\Áf¡èñP¼ƒ øÓ‹Ž
-NhŠÉ
-›yJzìÌQÀêéÒû_>™ƒ2¶Jâ*?¶ ¾
-?×Ô~Å)§p°½ž.Êiük‹óDñØß:[p1\#ÓêEãDÔV<D
-ÖF½_hÝü¾e-=§c~ :‘sT¢IƒÐ|–Ö·oÂÄœ3Ñœ"x!‹‘pÉÝk6FŠª`OÜ¡[°ªfîªAe“ŒAï‹"Zv5ÛÂ$ÚaœœæÇ´3ÛFtü7¼–‚c†ž£Â(4,c›÷Ç,ó
- úªôÁšRú²Uc9óõßwŸÀB掾²4=D§Kú6Y\$•¦I¢ &9M«,c4Òæû£H)¸Þû~ÑÑ/ÑÆ–â}r­=Ç Ñ·ÖnYÉn&ÐÛ?9Ö8Íùå§}"¿Ë¬EÒMO,¦ß·@Õ|E¥Omhx™RDÁ¥]Ös˜Ü g|_¬ÑTºç{0NñxÍIÂQä-àÝß}X5´Èñºe)AÚÏgsÉÉÉ{/L£Xœ8Ïf¨T[7eóñ,®xiHÁQÏI¾eÒ²Y5Ë&tÉúµ'ôî~/µŒÕ{^lÐ/+Z½nнH¡h˜g;
-¹‘hþ]ð‰”OаÀóç(óÏ.6=5¥·‚eÕfÝÆ]ý…ß9_1úIÉla?p®Üÿðô·îŒ];—a9¡E Ëï¤èÇù˜f}ÀfsÝÈ©ÎÑ©HÕªv‰/Ø/b÷Õ”£ô*‘j9•ć֕ýkEp&Dž+IE°"Æ(ff5›ƒç&mà@²Y˜šçç¼E÷À?¥ŽëxÄy¥>&3Û˜nÔ|œã±nÛý64äòŽ¦ ác›ÄHtWlÁÝ&Ì€CüEe•S_ˆzi&æHvß%;M`°dq¢R‰Ô¡<Ô?–E m&'⸋ÿ*[DQpÞ߶ÒÐnErÝ?Æ=¤ó˜~cÜüp,sÙ@ìééç—bľ_(ÆÍm”6ç#¬ûæß‹€#üìÖƒ[q2¦‚<­®?¤\Jyq'ö9>ÄBÎTjÛ;©íimˆúHëÇbå‚¢Ó'¯¬ýî’¬ZD9Ò~Æ ®qWŠA8±Vå§78ˆa×8S÷ôÏloq²«Žíƒ¾ï=þ;iO”Ñ}ú`w~”©ç‘Qx†®Z°·4ìÍÊ`¢Øyy²r[‰õ#eyð'Àó(¼š¿ºó¢Ï¯ÓŠËÊ–áµVÇ',S¬Zol]{Fk-¬›ÛDº®÷ü
-`šÞD-1¼8¯?ö+:Ÿ“¯‹ çج0§*.Vc×NèÙ4–f2»'yæó¬ÌͳŒâïÌÉ¿çí”T
-/ýð­@DnJ‹€6S5¡ŒË¡‹=\0ˆ§œxÒ‹À]aœmY7TÐØã0ŽÔ&ù (õ¤&©7ƒcÑ)KÕGqÐ{ÅòÃ$¬2„½çÃkž^mŸ„¾*ÛÉ|=`(
-ØÆïk©1Äïi0<l+¤•SÍŸ¡k'…¹9—&9«85IJ0°þÊ«—IœP^5²!öœHm²øQ¤ÿ«ðÕgÁ¡°ÒãEd]ß¾לÊk2,cº66’J ZŸí¬õc]¤ú¼Âv òÁ`^âØ»ïKjÚS®ÕéŒH¢è· $d¸•x²}2Ú“º¦[HN(”õÛóî©ú1„•]ÇýœÌÆÔJ" Õú4A&y¡ü¿±>]ëQy,ö * `uy³ÝÕ „¨þ¶a¯()è©_šcT±R>ðNˆþVòÉÓÄ^eÑÇ«Ï4xi|jö¤8jP" Ùræ~‚ä¨×hSÜ«Âu3«Ë·s}·µ¹|MÌÐK ïÛô3Äk@0ýNnŒÍ'€ >ŸOR}»>©P_ºÅÑØîôæØï+àq&|¹\K¯3¬¼§Y0,͉÷B@>9ýX¶°üÍ/0Å,…`ÐHÓ´í[ÿçpûÖuäñSܼ˜=»„›Ä+Ñ.º1L’ú¾POBÉ=.jÊ.Ì«“¼òÅ ×ü›:.Yí¯ñrøàxË$®™»îˆ]~ÍB½¾ˆW¥14 @žh
- û2çÎ{°îÕB¦i¼å5û´¨é»^óu›êǺƒ:UïnïVYÖ"ÎTO:cѽ\‡% í nôgØ,5>µbïGí‘-O8Õ~üýI‰`nǪŽ‘{óc—žvâÛJ¹Æ¤»é(,6âÚ·ÁÚˆÓC0Ä>T6 ªÀKÑ @Ո泟°J›mVTb C$Šý•–‰ÛïJžoju"ìÛzIgß'é†ËõxI}M¤ë}³q…ï|àóý(?ålÀ¿nR[*"¸«D]2Ñ„kþaÕ\Wµåð¡’"Gåwí
-?¥ˆÞIÆÞ×;S£ÚhH}~ ²y^Ç"•oÞü1bºÒÁ¦¢,#2éÊÏ ÿù¦-fRWí«
-‰cK ‘}âzåÔŸûdŠJ˜Mâ¿Øcy±®ìU·Á)ÅÚ‰˜z±_K0ÑZ‡ÅŒ`wÒe42 ͼvX9ÌtéÝÕ뛯)Qö¯WK±Öv ÁßÿQ@WÚ&²d‹Y„^×[¹ =ãyCmÅ&¯k±HRÐfeU7ú°¯ué¢Ñ§ës*œáµ‰"»¨õ£ãÜdù‚–¤öº~¾§öUèIskÔa°œ‘|±ð §Ž¶ÑãéN”Ô·ÖÐÞ²ÊS§¢7HƸ
-l§™ÀUë’‚™Š¿µè— ½ó"›YFGÏlëE|…"ÿX7)Aäìq„m_:QGnQ•›MÃ캿8»˜MA19Íw¦XV¦Ôkiê8U=œDSŒ¤ñ0)°·ï öL $ÍûÓy_ȘÊþëuí¸Ù‚ª•[1êûfbKÑv¥ŸöÔ¦<2\†!· pý%ä¶tùÕ4ÔŸË’4×zß2íâ57ùº‡ƒ9ï‡èÜCzÏhȬº<É+ð«î»Ë%ž]<Î}z˲§ ¯q¡|W—H;fÌõõ’ö]ò–ÝÞàÉÂæy6?-PRJ)ñ
-1¾icçô.P &Ma´ âiÏ3ìŠqJ¤ý@ïq ¤8LÖä¾Êðœ·ÄrÉÓ±ü`Î3ô y*Ë1\—!ÆQ¦_Iuh+ë¾-”Pˆlª¯q›í>ãßøvá4Ó'h¯]©NX£j,­ÚvN0& ¿ž¢0}üÀ—[3Ï?x×”«þÌ
-li]³¸Ùø_27£Ÿ+×
-½Ë¨’ؾ n±õ`WÆaeÊ Åó•ÇÁ<"bãx+6Îã;‰‘ýÕ{xï+™Ï^C´¹y=ÓJt ¨q—ɶêÖÛîþ$`ð÷×@@/×2WW’/ÜK$ðs†-à ô jý¢òßœYŽr,s1ͨcüåˆö†×دµç'Æ-¬˜L»n
-Aï,´u€$_­õ掭Á!ˆ |jÒOt <[cÄUî4O/ƒm?Qjù—·W¥óÕãBö6Ma‰™õdtC÷7¶jVñk•ü´Æ»²dlkZ_é0ϲèk™ ö9ç»ÛÁd¨$U™}Zºñ‘¸ò¯CÎJíÞ*HÞ?äŠ0<4vò6+?Kñ¹nß ùy³°ä¶¼*PCæzu¡°ÆUhiñ½ã¹4ñë{ˆ vŸàÏ~p¼¶i–r/Lµ-Õ°ýyDÊc ›%·}z·ˆRðª5
-ïås^ÞÒ¹éÝO¾ŸàR«ÉëVôºd±‰_uà5|œœ÷sÔgšûM’“[ÂØu,B´‡þ n½-Qo'£þ!” ±y„u¼Ì¤{u̪ õV±æ‘ùpîàÕÝrŽK‰RÂr¼uÖ²øÒhèk=~*¨ Ê7ĸú[^N:Ó€õ³RiØøx²CDÑÈ{»&A¯IÁ1HX=-Œ¹™A’/­ë¦úD–½~\¹3*ï^(¬è:äç@%`”{, úÍ”@ >_±'®)}élµ8ÿfrbø|Ù»—!>oÑy܃¹b1šF«êbÎÿ·ÚGoXg[t‹ÍŠ¸™ÞM²ñ he·Õi‚Þ“Õsü—1o$¥·Û,û¶ÞÈ‹¢…Ì„¬dQ+÷ ~V B4ï1ë>~j#²5Ôg(¸ËÔŒ]eEÙ@îTlÀµ%ÖBŽÉ°ò,• WõÑ‹–dyfI·z¹ú0#\ ùwNQ]Ìײýž"ò;ìcКÙ2Uĵ4- ,A›“à§sÅ/$@¬rút
-G+q|~R–Q¡â÷<ˈö‘ ²!Ï%ÊȉëÙ}»CÈ©}ŸzT szÈ‹$:î>iÄ+Z¶>–sk÷±N<Ö)SÅ“¸¶Å¾­]œUf‘i×8¼’“¸ž9qÝ[¡bƈf¼¯ÅØ
+/Length 9444
+/Filter /FlateDecode
+>>
+stream
+xÚíwePœë–.îîNCpwOpw‚o Fº¡iÜÝ ,¸$¸C‚ÜÝ!ÁBpO Ùûž9Sçί™óëÖíªîúÞõ¬õ,}×WÍÌ ó’[Öj R‚BàÜü<|
+@8H`²(€l
+±ÿIÍç‰KÖ
+‚¹€ÝÝŸž`w€= ?Õ
+È}ÒpyžÈt îpwØxòª£ ôwœp üowð €Ú=iÚBm<þ¤ôöDó„Â`ˆ;
+&aºvÅ ´ÉhxMÚAЄ@TWüý%uÿæšµoèË@×êçoÔœy¯1™%=QpYâ‚Ýò¨¥M *ýb˜^(b›¥ÊŽ3®øáÆxŠ#Ò¯é\N•Ó9פ'Çn£¿ 0ÖfëT¡¾D`Ú$
+uÎ~~U±© îúŽø÷]3ÈÉq©¡÷EïyR*‘^ü…âßx8—aáÖ_‹èèU,:Ù“ë#Œ½ñë.¸g¨ûUrÏTr ÏLåï%µÊÞ§ßO„=¾1.¨€ÔŠ>Î9~«%§Rpßv£>¸ýù¶¹­¶ð0²À û5fw;9õoNrÚ:&Ó+à÷òÒÙ™¬ö©òeQãà2iFŒIDÅAÇ%j™ñHú†ö.Zܸ=#ëOïW¡V$-+{¤rvº‘f‰
+Z³
+4åqª=çjö¹ÇM¢¢MmU«aU/õ+1:"ßòÐì}h$ºa¦£Y06 ƒuc]Ûe!ß÷6Q¾IN(Ÿ/W2Ù£ÇexÆœü4ô×Õ{¶>â|®p¾_ædÞH7b¯“UÛ²2cå;õ!ÐÄÒg^l¼­ýS¦I4Ôñl37ì÷Ý é*?£‚h¶¦¯mð[¥÷x¤WQòî|¡²™D®ÌoYìR ãÛ÷¼Úm‰|å;¾D”ÃÐ2W‹i¢Í?5‘ ê ŽôÅÕ½®èÛJ¢ì2ש(׌/lû¹"Hé¶ÓLÐ6Ld½Ï \, u¼Å=ôºIH²ËÉ©dÍo­y¾Z¸¤³yªE2•\(òs²‡ƒœ>%Ìnù³ D‚Éy@U5ë&…‚µBï‰Ø®gõ²ª¿ûÑ­!M*UgÇӨѽDþîؾv¨å%¡›¿„Œή ÐnÚ{uÊTÃ[ŠJp¥Ytó 4Æõáû.…¢Ód¨pÏ)ó‚„”àåŸB¿Þ€¿N0Yë‰~Ÿ³,ÿ<Ê£ÈþSÚKÒÎdã”ØTÕÌOÊ¢yxeåWÔ…Š»ÿl²ÌÍ-¬îh§è?_$‹ÏÛfþPs`LklÜq=R^íϳßÈB"X-h#c®†ÃªÆ~ÌÛMÃœ,Ù§ n¬åÝk[nøý­Ž~]6,¸Ðñ„Gg¸ÉÖÐV¢®=F.–¬’Àî%vá`ZD§Ê'h%å°,z‚…ºÁ—…J©ßíËpŽ
+LjòÇØ9C?áž îX¯`÷î=ã¦ìrš5SúU ž©Ò#pª¼±þD¾AZ³c’Ž@6œ~2(ì“w@Ãz½mˆ'Y›e†}U|¢N¢2òÕÔ!¯OòÍCó.R‡ÛD+öj«%_W²‰ÕM7ëç—xÄ“¤NrÑuƦ†Ô3Çß{÷ÛÓ>Ñ€Ò;,búñÖú)®Ö‡ÒŸG Œ-Ò<ÌõOE,ÇH£òfd&¨³ :Šó¿0s[jöîµMáÄk‘É ‡+ûv­el3¼)IZýU+Nšßø^’©‚´a¡üs…&2¡$ïâ!±ÞµmC×7^¬´Ϧ?ª°¤ì÷©Ò_]š¾ÕÂÒy—¡vx©ÑúÒ¡ÀÔÝ.˜QpØDDuÓjœ1ÅAÝM¤ÁèF.{5ªš‰Ü|6‘Qá œ¹­­z¬­ëÉÝ1·´z(žZZÚýœ
+JÒ;:4AªWŽ£çÞ
+#µ,’«Oa¦`mô×û…ÖÍïYÖÒã1q*0æ—±¡9G%š4Ígi}ÿ.L(Á9Íi!‚Òhб —ܹfc¤¨:Fñĸ…«jæ®T6Éô¾(’¡eW³-L¢ÄùÇi~l@;µmDÇÃk)Ø9fè8*ŒBÃ2¶yÿƒeA¡T_•>XSJC¶Êa,gþ±þxç
+sªâb5ví„.‘Mci&S±{’g>ÏšÁÜ<Ë(þ·9ù÷¼±’
+A¡À„s’Yéí|ªH¥õ:.}ʼô¥´3–BXvÞ|Çá2Zg¢e<¹d¤¾*áh%7(GÛG©úë°ãÜê§JÃ3‚NSLøIঘß60£åÊ?paöÜ¢šŒ
+ùæ»°›À‰ºÞäæi%Æ„2 jKV£*´†0^ÞÍóHlQv³Ãøó ÄåÞÞ £:¯k¨ˆgD1øŽk'*!}Óï”gr$T X|Ø-ßß
+DÑQÕ0>“­t—ˆlgžDù¦6sO^40‡*Æ^YÙ“Üî˜\C5pÒH`~±ò• ¹u’‡å0Þ5Y˜p¹ñMK=XÓ"¼ìÞ¹u_6wá¤ßjS澫";˜‘ºkr1@Þ‘Í×—Á¯X¼‘JØfœopk)BµÛùŒÞeÙRµ‘Ÿ«‘E^"Q¿
+R¥U¿˜u’bNRÒal.ä˜ô;ÁpîD”èBSb0aÅ•=mþÕ¤¦c½ì®iïÇÓuW›7²xÜ >éâÐ'ð¼B‘¯g‘U‹;7÷5FBÞ ~î¥aA‹¸Ê#“ZYÓ¬ÿzš?Nu48ñ>܈pÁÈV’ŸIŸ( 1u¢ª'S‘œÞÆ3Š&¸”Ì´Ë
+P_Ñ’L )÷‰ë“&ûs‰7“<p1Mß^1Y‚ŽTùª¶fˆ4:ƒK/–™á¢ˆÐé^FÃCda÷ò£Q÷‘Œ„s°¿I31 ÆÓtŽß#%Pá•|[eá–[PyÖ´G༱B­˜[ù´ZJ¨¾´®ÛØ0´Ï Gkd™eÆìɾ>5mý»Öñ0S¿fÆV·Rˆ;ÛN>NšßXG$Ês4.ýág’7Mš¶í·k‰nâ D_Wÿ"»[«¬Š†íO¾é/ZÑò2¨)ÉDàj›ÈqhsáúŽ,&É`õ³÷C.‡aÌ3ÃŒþB ¶ø:dû±?ŸGtù¹PkªˆÇ¼¨ŠaF)ƒéà›Àògs±/Àý´¼
+ØÆïk©1Äïi0<l+¤•SÍŸ¡üÐN
+ss.Mr
+Vqjþ’”``ý•-*V/“8¡¼jdCì9‘Údñ£HÿWá«Ï‚Ca¥?‘u}û\s*¯É°ŒéÚØXH*Ut‚j}¶³Öè"Õ?à¶KóÇÞ/©iO »V{¤0"‰¢ß6áVzàÉ~ôÉhOêšþÑBrD¡¬ß¾˜wOÕÑ ¬ì:îçd6¦†Pyh¨&Ч 0É åÿõéZÊc±gPY
+¼½
++•dÉ7Kýæñ |ì¡8¶°Ù§!®WNý¹O¦È¡„Ù$þ‹=–ëÊnuœR¬ˆ©gûµ­uXÌv']F#ÒÌk‡•ƒL7‘Þ­±î°ùšâeÿzµ‹am×Ðü½³ºÒ6‘%[Ìâ ôºÞÊéiÏj;(6y]›ˆE’‚Þ0+«ºÑ‡=­K>]Ÿá ¯MÙE­³ŽsCå Z’ÚëúùžÚW¡GÍ­QÁrDòÅÂ/œ:6ÚFLwÒ ¤¾°†ö–Už8½A2ÆP`;É®Z—tÈTÔ€ü­E¿LèÙÌ2:z.`[/
+à+ùǺI¡x "gŸÅ¶5~éD¹EUn6 ³wèþâìb6 Ää4ß™bY™R¯¥©ãTõpM1’ÆäÀÞ¾3Ø3’x4ûìcLç}!c*[ø¯×µãf ªVF"lŨ-EÛ•~ÚS›zðÈp†Ü‚öMÀõ—ÛÒåCTÓP.HÒ\ë}Ë´‹×Üäëæ¼3ѹ‡ôžÑYuy’WàVÝw—K<7ºxœ{ô–eO/^ãBù®&.‘v̘ëë5$í»ä/,;½Á ’…Íól~Z ¤”6RâØŠ­ÐmY·×Ø/"ìg{¤ZÆAõÙ™¸åzK}BÖ±Y”bSž joÒ1žI 3ÿàHèd§ß©ÄßXnŽû¹ýW‰T¤L?Þ£éSÀ˜lÉ4ƒ™’ÛOd쨤„ÊNO\= *?ur7 â—VÏV¦æWER¥çÉÚôýÙ©o÷7^=ºœgËêþ5Eן Û·ôtàb|ÓÆÎé] LšÂh)ÄÓžgØã”HûÞãâ Y“û*ÃsÞË%OÇRðƒ9ÏÐ'æ©,Çp]†Gtš~A~$Õ¡­¬û¶`PB!²©b¼Æm¶CúŒ_|ãÛ…“L7vœ Ýv¥:aª±p´jÛ9Á˜€üzŠÂôñ}c\na4BÎ<ÿàS®úS¬¬Yg’:/²vî¹im¼Îß#d‹ƒÕI¼ Ãüöc1 ‡f+Š²°¸XZÜi¬}0;­³–Œ”°¢“>mAZ¥+žÎ™å‹äÅÖí86G(3ÒùŠâ­º5»§]ÊöL¸?ÚH| |´å¬À–Ö5‹›]ÿ%s3ú¹r à “'ÎN‚Ä3Chdv:í¦Ð»Œ*‰íËà[veV¶¡ R<_y|ÁC"6Ž·bã<¾“Ù_½‡w¿’ùì6D››×3­D·€Êw˜üh«n½íîßy ôr-su…!ù½D?÷gؾ@¿ Ö/*¯ñÍ™å(Ç2ÓŒ:Æ_ŽhoxýZ{~dÜŠɴã¦ôÎB[ÇHòÕZoî‡!8”OMúi‚.á‚gkŒ¸Êæé%`°í'J-ÿòöªt¾z\ÈÞ¦),1³žŒnèþÆVÍ*~­ ’ŸÖxG–,€mMë+æi}-³Áç|w;˜ •¤*³OK7>ò¢WþuÈi©Ý[Éû‡\†‡ÆNÞfåg)>7Àí;!?o–Ü–WjÈ\¯.Ö¸
+--Ž;žKŸ]ßCl°søüöƒãµM³”{a²¨m©†íÏ#R†[Ø4(¹íóxÔ»E”‚W­Qx/Ÿóò–.ÈMï|òý—ZýH^·¢×%‹Müªo¬áã伟£>ÓÜo’œÜÆ®"D»èâÖÛeñv2êB  ™GXÇËLºGQǬÊPoUk™æ^
+3.À@4ãEx-¶ˆÀˆÍ–måo¼Òy›5ñkº¿-ð"¾½ýe«3Æ>zd±r]­^¥Ÿ”ƒ™è3m“鎵†^Gë¶/<ýœ+ˆØ^bp‰p˜~!Þ6ØÝ*&UÆ^ô=!”f÷ÔXç‹!®%ßÿòƒõÿ þŸ °qap¨ æ„õ%*endstream
endobj
975 0 obj <<
/Type /Font
@@ -8882,14 +8853,14 @@ endobj
/FirstChar 35
/LastChar 122
/Widths 1948 0 R
-/BaseFont /VUTDPO+NimbusMonL-BoldObli
+/BaseFont /LCXBAS+NimbusMonL-BoldObli
/FontDescriptor 973 0 R
>> endobj
973 0 obj <<
/Ascent 624
/CapHeight 552
/Descent -126
-/FontName /VUTDPO+NimbusMonL-BoldObli
+/FontName /LCXBAS+NimbusMonL-BoldObli
/ItalicAngle -12
/StemV 103
/XHeight 439
@@ -8905,38 +8876,43 @@ endobj
/Length1 1630
/Length2 10420
/Length3 532
-/Length 11286
-/Filter /FlateDecode
->>
-stream
-xÚíteTœí’-î\›à.ÁÝÜ]h ‘Æww—à.!$@ð Á=¸[p· Á!—|ßœ9³Î_3ç×]·×z{½Oíª]UÏ®·è¨Õ4Ù$-ÍArŽ(;§@ì`îæªìQbÓ
-rrq|ñpxÁ^ÈÔ]¡®.`'(à%«šŒÜßuBm€Ð?¹]Á/0ÀÑêÅÓÒÑÂíOKa/4/(†¸  OèŸ\æ €%ØÕÉèõ’û…ÌÉüWn®`ˆõ?+`¸€¬.–ö Wךî?·óÏ>ÿ¥{ ““½×_ÑŽyýg `¨+ÈÞŠ‹û%§ô%·5‚ÆñgXä!VŽ
-:€í½þ›ÀuÔý]ìðý+,¾\Š$ÄúE6.nvοÍ`W9°'ÈR µ°Xí_îì/»6Ääb†€^´ýëZ_‚89ÿÓ²[ØAþˆÀû7‚Xþkù/rýU<‡¶‚²œ¾Ë·aÿòT{™¨–—ðit•-ÿóð‡GJÊÑàÃÆÇ`ã~Ãàççpqùý7ÿ¢áúçYu{ 9Ù99¹
-Ì;ƒ„ö é ÓBr?¦®"ÜUúV~–`“rÌÌ#ÝXŸ³¥5>Nïê&eHc­o\PÎn˜iÜ‹ñi¯°ü-Þ×&´áÔÃàÕѧìß\3ô ô÷uœ#vm“±ä% Ò »#`ÒÇ:瑉hWúD±lÁ}Ù¡ŠïJÎçâYÊÝ¥…ŽeÌ|,PwÐÖºàóoËóÍQä‡/Kk×ØC)3ù•kKКM,y]íÝ»IWàCn‹ÿ³ÑžŸEbg¬BY¶â EœÞïýoÕÍ%¢_¹ p¿ž²Ÿ¬?BûZ·bŒ“ˆ·d*RˆÈÕÝÆø÷@÷¯¾òðgŸoÒÙÌ2ô!í¤ Øô‡~‰±ùÁpÕ}ØK³ ç¸ûC׫F%=ʾü+Þxè7§Á½€Ö
-µå7„ùŸ{D/kÅ:NŠº3©1fæÁª®ÖÌ>›ˆ0œÊ-~ýdžR¨X<™6Ú4’ÑzVÆ„öO”ðµaÕ= åƒd!?Õ–¦.OB)»OÞ8:eõ4 ±ÎÌYÉzM—I[Øù\ó‰i·Ó¯‡‚¶j×ÍX‰õ­æáBJ÷[ØE¾RS×ß½c&È1Om +bi¬NÈŸ
-"¿ ¹V6Õ›dJ VOÆýräªÕpê9£åLV±Bï÷Õ&JÀà»<ëÈdRs΄5Ãc6âš<ZˆÚ½–‘õxc~Œð
-7kXp-ºZc¤ë·8*ŸÑ¶•â–Ÿ÷µÓ÷“hØ4WžL^ñ¶AÞež "<ÍyÅg WõxÅÇõo)l)ºÍ¨øß*—–£ÉÌ™ üÑõÊ”ÒtM
-Y4<z€¶TÙ±šm·àÇ™y„>þ=ó×½Ó#|õ‰2Ìu÷Ñà 7$tD;³Ì/>ä…¦+²Ø˜±%œýD@X;…1OžK(„ØfAH̦Ê"m… `²­èF5óRX¯.èÝÀ1_|qãŸ2
-òâ¸ÚqÍ\ó°aTúËî3ìlŸBØ0UmËç:<¢Lµp. «ŒHa>7÷ ¡$é$aLŽW*æ—ôZÇÝඔ‚ªÖß.«UŸHeYê¦äñ 4’5¡ö|Ž¥ò ïm´ÑË­çŠß“Trו?äÖÏä‹wJf–h÷3»7P¸bF»`œ/[ŸLÏ>¿¦td#ø5‡ÍPÝ®gÊ |Ô«ÕCY…#4WÚ*€¿0Z^oÖ,F±ãƒiôŽ¬÷“Ön4 ‘EMI;h!ŸQ5r²©äÂÏ †uVrŒyq ò…f~IØA¼þ8«+ö}¤&ØõÃu"ažyº-¡Íß*à ɹü#Líj)¸|›t¿Wu‹ü4°s!MRmYŒ5 0ÉWýŽƒýÝGiÅGÝD¥å²VŽ>5ºöæw&‚ß3F\Ü~'²Ý»µIËO™ù™õ¯âÑG÷4•ÌËX¥+© ¬ŠD¾I_åhkˆÀ/ÀŠr2ûHïíæ÷¹Õè9D¾ÏÔK1Íœõ.ÂÖf:¥©_ˆú™4LT™M7(¥o3iså—ò»ºö½_ÚC'¿{drmcN~µG§;ÝÚq´ ÓCLs:l ‚DFLS¤ÁrÚ'»H<uw0¥ÞHÞúµȘlN–D˜•’Æ·+¿Éþ7Tš2|ß=›OG~vu1b4ršTªgŒÌœÊ²ŸŠÀ_|Ž‹lÕ‡—0ûº“8_VÏ»×ö“ý#ò°R—¢“Ë-{z—ú{±Šöý‡9¦/Ú‹]¨mȨõÖ?2T8¯f 5°Ï9[X©Ûß>íÚGtH”ÁòaÀÉ©ZʼÎ÷h96åË—¤õÆ3ψ%6Ëpx¢OÚe.OSåÐœ©<³Œ)˾ F‹´®7}Ë”#)_Z¥¢Ê
-7ÂÃD R ‚¿è±¡~HYÑ+RÝ,=Ä-*Òÿ‚´-°?MVC˜$™œiĵ5˜Ãù–…Z¶a8W‘OYE«Pj5úïNhŸüˆ×KÈÜœƒ[—ÝËŒÇÓ]ûʲj
-eÕÔ×Ì:8}L¸Õ÷aÈN˜üŠûÔªÌéjb¾ú©;¯ ·»ñÐA¨1ÆE“¦{øc”’³l
-¶§£âŠîZ<3ýrãrö, ˜ú¡ü´sÛ£¦üÇçt™-’,ÊÁš2šv^I4{|ãfg£!Æ-’ßÏ
-l ,vßgª[™GV©SÓÄu rbðW„_±}\7Œ]Kö ÜÏŸŸ=8RÄC&)Ãù13S³à™ÜˆzÖó &Ü{ Òâ®;›{ºw/L=®¹>Îi%Â+06wIœ¢¸/óÆ1qx≓–^½Û‚ŸVæø aF©kH£ ¸p”6œB¨EAb¶¼4ƒ"Ògå#ß–ß]ßÙ¬’ÛžâÀÓÇQ´ÝKçãëA”œ˜jô¾ð‚p ?Ѓú'[yõ |#—Qb9rȾÃFNw®Å^™Ý~¹6”Ô™ÓEŠïábä߬í#Áæ#ÚWŒ¯*È•:ëè$4×hÔË×öÂnD¹ïÜšÇS×¢FD¸}¸ÐXëÏI¢U1Øθ3o8ú8J)u£e<Ô…Þóh|¬"=–gfíÎ1 `[u˜ÅQAØÇyïóÎp%oZ’øqa’…aÜýËC5¿‘ˆó^ÐŒ
-ûôÐÓ]2Žá×ðÂŽk•|½Ç7X>럾·Ù(´Í¾o÷ŸÔÌJmˆ•oXGUç²7w&¿#
-)FkcøÖ¥Ó‰]Í¥D¢ØMÐò÷*Óç”t…f¼™¡øÜÏÛÏFfðz•¬ŒÊ2Î`®&qTYOý“ê9JÇÎNy…ï´Ûöpì¯lbúÐ8Á©æf*°©Ç 6Äê••í-Î ¡€Ñ„š_`-{F”šZ…ü‡ LAîP«Ç. :öIæñhž;³»)ÓZ\ÿ/FÉH£}QôùLÊÏ+w5]D0|ƒÆ&ÄW Ž^„IU5lª rôÒ>0„“•¶}
-ê(O“ùRtS63ZÞ0CFv߲ͳZ
-|C·r®ÿµ?Øô¼©F¨$ @¯ÍrjB/áH $=@"¿ƒ£
-€ñLœ #Ž|DøÓú$LP÷f(.€RC¿7é@
-ÿ³±Ž“ˆ¸*„e³VtØø®Ï`Áz)£`j|S’»§²×¨?È4·¼-ó5W¾”8˜ ‰¨WÑ÷Òh òµÈ~à&JYÈ)0­ê¶D©:Ç4Á¬Ãšž“<Á$ ŽFô!uæýÔK~Smò¡z­2 ;zëJŠfÕiu°„j–ó¼ÍÏ}ÃGL0tW’e³Þ‚å»0\èœCå™xà¶}½©âV<=Xeys¯”òLV²º3#†–¡ØNs‡Nɶ¢»H*åÀ›õ³?ò
-/RBùðMÍÚËW?Fóm6¡Iyþ%ÓYµšÕ¥oÅ{;sË2¯Ó†{®G ‹LãžRê ú AƒíI+23—(-ãAqpå—Z âãö¥‰u#̸{OÿÌ€;Snúäë)ªj¶§×o°O'Iª™›ßá蜼“Ñ;ö~Yå ¦<úhDsÙ˜´\ÎCldS \“2ñœIsd„­|ü0"eq’×dÛÑ
-ÉÈصM"-!J$Th ¸þ`1/ù†ñ\âîô­ÜTQ‡ÐŒÈ[ÖNåÝW…ˆãíñò Φ·9íïCÆ?öaô|ºé´Ó2gz µÚ|펋0T§ÃLÒº2ÖËàÃÍÄEßþ:–@A,™Š`k­û úm«§”G6Š+Š9gÃÀº‚r~I÷Où­è·DÊ¢[ {­‚¯´rÁ\CPÉ#†|m\¶}äh;¢µ…ÿ´fB­Ã0=­7ÍRô‡/œÀÐÀÝÔk¢1fR´^¤ÛºÙCñ®Çäß>0c(¤‚e(Ö.×ÈîJêùô
-Q9!™¨‘™y0‹½zÞ½iº˜^Ì /D—Ó|eæèù>JB»!|A¿,S`&ǽï.÷L5ü±ï÷÷ˆCX æçÞŽ¬ å©aÜó‡Û /}WRèŠ"µ±gÚѾ­øÿ;.¾‹œ2Q‹)3–+À#'[¼„ì×jéXÜö¤êáEIkÀò YBUµ<ÀòÝÉÛ‹QË¢Ÿ¹Ù¨ƒ-*
-HŠ‰³ÝÒ¶X´2l‰ÀëRC/ýÕwÆY@}!ù~ƒvÖ³K®×YËE.®\ØÍ,Å»ÕBj>š…¢«îlô~â†õàØü-³er@ÜYŒÖäžîj«ýT"ŠÒãÛ¨×KÜð%ì_í[~«¶¬ƒxRåøž&'q.kýØ®ƒ”ÞÑ‘ccšÀs1\ÖEÔõŠbº<&zò¹d£}‘l—¾¢@ ¢¯uR$î-±ÌM
-ñ,(Zà …G!½½,‹8yKæ;~ã)_Çzá8´‹öÑÊXÐ/â&_5º(Ƀ|s5š)ˆÒá+>úÏ°c²±lj×ú²ˆ%¯ñQ eÃü²†‚w¾ÙÁÜUú7|Þ–ýö‹ç4Ï‘³·¾hB²’Œh'à¨]NåD¡·T±TÎ$nñõ½Cm¼:1 S’•ÄéEÔ¨“¯Q/nHbç A( ¯öÌ'rÀ/V±¼.p:F‹ Ö“»aûÏÕwïl0yß]Žˆ”.z2“ÖŸ~ÝÊü”— ³z^¢ä&Ÿ›ÚÕ_BXÌ].ùÞ,y4DñÓY=õN[“ou1~KM“éýeülÝQЃ$¾®QJÖ\â3¢¼ÛÚ7²_ÞU2æ°(²89j¢è‘X(ÍàRêôâ
-ïÝåJÂYsD,~ ‹j%ûÏ.Ÿ(gªbç7ú[([7™>"Ä«1íKIkJ°rÚ(t~¨,{|†xáïÒ…CWá §­›ƒpK¾}AµþÖoX4šÝØœÙ5)köa³ŠGöfeÌƦ¦»#%ÝÅM'zŠX³¸·®ËÂV‹ïÞ,]0.Ùìëî9¡ß‡'¼Ó+}ÅNw§s»çoXçð:¥r•Çu’Ÿ¨óUºÊ‡˜BsûîsŽ1ðô]¸ÑÊágE>èé6±: ËÖªbCÀÙ‘Pý\rËÿñfóªÙL[1Ë@í×õˆL
-Æý¾> X¿ ãŒ0ÛÙêpµ~è~ñnrÆÀf·*zW–Wµ8ÁˆåX“7`i vXìq|¹*ÚÓÝ;É} …ºÛKå×B@ÅSCÂHØjIúœº3NøÎOm‡êuHÎ&¯õHì{ÃNIv-%ó2þb*BÁÁˆµ.Ú¿ÉË(-0ÆÃ.™ bÉJßÒú×קínjiF^Aƒ½x”®8¤á- …Ž! `ܯ¥ LÑËëû.íS@&Ÿ$ 1~G„¡é!nó[‡:sHæÏÄzŠê÷ ÜPÒõöoaÇ"Û£]¡{;XÎ Fb úzÛçŽw¯ëö
-v{Â~[ Y퉷kë[ÊF.Ëë®R2:|µ&˶ ù&~t±³íšá–kAYÆ-Ò’Qíç^Ü—³AÆPR˜R†ŸAÅ%®’+Âã9ÔR´¹«{  Ó’!ŒUW2i÷ø¹ó› oO7BÁ._«¬ëyŠ D(aá]k~®u– ®Ý‘»ÌF%ïýÐ×ÙÐdf»qÅ£ˆ=#ã j)Š¸)…ào}Ú|(¤»ó$5÷)ê:×eÝ–\KÒ|ý`S';ZU©Ü
-Ÿü._¯ 7#°  ôcö›ÐB¥×¢ fÜÈ =°ŽÏÚÜÙê?½zêý0íCÊ‘!´æûtÍç«1žu?K+.®o–/þRi†-zSÇ6ÊüdrhŽtFš(eL³‚/umDðN”Vï}º3,RÖŽXí;m?´oZ92íã“Á‚?†}æ]*ý|ðÊI¡¯W•’­Ké6¤,È5ßsx˜ ™ßV$$öøu"ÛºîŒw£¸Ô
+/Length 11283
+/Filter /FlateDecode
+>>
+stream
+xÚíteTœí’-îîNÜ%¸{pw·iÜÝÝÝ݃kp×
+äh-
+×u”ø¦ñWÉê!r6Y—fü…øÙGRŸ¾yKR‰vUå)0o+Xä
+ ø`8ï&-Ô§|_wñ˜7¦æ 奿i®™ÀÂÆC6K’kФZqÿ©Üõ-„8ª±Ïë½=Iæ¾xV@f³6Å-ýwËÄÎûñÌq#Eûu$u±ë5Äel&Qül‰x„ù»ƒ#MeȦ’9ázÚð¤Æ¯ëÃÈ E¸½ëâíŸ+óˆ°×CˆØ³Üg¨´ä·[¾Ñ÷pÒ!ìSðŸò“Ø›9"ÐbòMÀ8Õëq]yZsY£4îV ¯—…d<¥siáøÞù%Þ«¯ÔˆÝ¤qg'ä·„ãKä´¾ÀGq!»:½mQ!!&ßa?F±1Ž»ÁÞ¥Y†eP.hNø­1!/­öã÷œ½ð&  ‚¸a©7hèÛûŒýóÇÙ‡\š¯+D®ÉÑÐ Zƒœ0üÓvÄùØEýÉO¼ö~&ÙRm³ŽÊø=q¶qÊ¥¥»5ôÌ”ëb_ ¸mÓa…©!RÇ<Ê)¯$KåT¾C’"ú3Lº wìóÏ #uCm…›®££¥b·B_iÊîð¼ ]7‰Œõ• ðeQ ,®€”]®ì­|va!Ø;ýF‰E=ÅÑ8³¬5)Å¢u, ûÕðì^È ›Âê‡V+ƉC~~UY›¿> %<{ïè—ÒQs…ñpbÈNÖi¿KÚëC/`_IL»/\x7´×´mÂdšØÒeÖίð¸‡^ìë!>ûÙ;æ ê¹MQU,¯ÕêÓÉKQBäg~—šö–S£,QØú¹¸_ìMjŽCçqTlÉJ6È£¾šø (Ü×}Yô*NY&X ìs'«Q·’RïÍnƒa°1³'ù¶¢;\ ´ý6§eã3Qº7¢RÜ
+ã>õû~
+[`Ï—Ì/ù®—o MyYU‹â¢/ÿ¼Ý›Âœ¢ÝˆÓ[³¶MlÆ
+ËšÕ˜±{[½¤-üyª!Ø¥ò6¯Ë,ÝÏ–r‡{ŠÒþŽ•ðRö¢i³ 4:»ŒNt8¬¼GrØ¿š&¦².ÌP˜ã®—ae‘©Ö’ГÖNTX/ïbmåV¡îé1âûœ9åì¾ú;‘ùÑ­[BvÞÄÏdär{,‹&z¨½tEÒ2]A fS0ò}úö4kwçXN!ZÔ¿£I5·›_m—Ákˆìˆ±—|šÓC„8Ìx^]·=´–(LHž I3(ed7iwã—â ‹ª%ú£%wÚS?{drS[nA½G›;õ>Òi´ý'mLG:dŒhfL{¤ÞzÚGÛH,UAw™Ö PÖê=µàŒ dn¶h˜¥‚Jï ¡ßÜè{ruIîÏžçS?èôQÚØŒjT3§Ïñ¤ ŽYΡ¯jã"»t¡EM>í'ÎÄ—·pýèþÉR ?©0 o‹Oï|Ï‚®š!\Õsø” ¶ìOߨùu
+/À/„¡œ‹œãWÃ5t/‡…û’ÀÈÍL´ÀhDÔËá磑À÷7
+Ö«LA‘G´D©(aÿ à;ÔAG´Õ JU;_^\‡uç.-©¤î,+»¼Z‘=•¿RæŸÐò…FIجóÔ~ÅÇ›º1“|÷dÈ…¾^¢§ =Ô**sç «n-Ø[”Ú¶Q¶ñ¦D•œ1ÃØu®KÁ¦¿µÜ†y€´Pä†c(âÏnh0(iX²w¬N¸×õ¡ÍI˜û„ùÒ¥Èæbd¶ùq0«s°ö؆¿-ÆN™¦}ümšŒ­ü‡+ÈŽšœ=zàë…qãWÈÅ+¯|jeÅ5ÎtÿwˆŠoµé¼’{„Ùdã å”=\bHv8†Nt{„¿_å<˜m«3²”K,Í"ëT)(ãú`ÙP¸&«Âo˜«·õ£C·’=ø V–ŽŽ‚ä±à Ë1>F,.6¬z&·!^ ý‚÷ž·9š/–_Ý‹ROnOs!ºð±
+ ÍœçIËýMãèY=±Dˆ*
+Xÿ÷Ô­&?=b¬;”½î‚™ ¬«zGn£P6í±ÿû±Ù‘,œPýgµƒ6å Åù„ ˜:vn‹
+®õg JŒGâÖÜ3ûRÄë,’ Órw¨¾}óã”sᓱx&á=¥Ì\_ Îƈ߾lz'¦vC>_ €1Ä8ïÁ'nX«ÄÿÔ_>E듸è3cióú‚"“š¿X.,\Œ:ÚÎä½s¿ ‹Šs©h‰74’žÅïM$úÚ”t¹A¬Å‰V%è¼Úï¯àFð¥ìÌšjIp0!{»¢”§îYý2™‡5¥C)›¬ÜgªïvPc,ØÖ1#H¼l€àT3%H°øófØúï{l;¸¼ûüÓ ¿@vt MrO;¨|¡–Ï즪ègY§Óùî îÆô[q£¿èÄ" …W²Èj7ð!¸ÇŸ nV¼ð’"ꘕ¤i$| ðæjlF
+ÃÚ¶lóE7÷³3™N/,*+¿PC.m.>ÊÖSyüŠô¥–ƒ®v«~@ P2ÝÒf­NMTP-OÏ<a-€…>oIBeqì†bHpæÔt‡“ŽÄqj µ¥u!Œ»MB“†#z«Vk™…ó³;¨b„èC5ãAÆyÝYïØ ü£D@ìpøÃò¾×{àOÅvcwQŠrøŽ €e·52åeú/ ZLé¹ÉË`~>\‚hX"'N¡Ã$wõ¶!•õ[5ièÑsh7â”›Ž›ã¥ä»l—Ý~ú,;>Â|¡bŒ»-挟 B—ík.D¿ÛµËïÅÓ€”ÖWQ”‘]H‰Õ÷gÆPіتïS+ØT ‹§y3ÕúÑ›:u–ù§™Ã ×&_¡TT}4ÞÝÛ˜­¤¢ÓM2²%Òì½#øE=
+;½N
+¸»v ½Ê…éÔÔqKoœâ\¶Ý€×Ÿ0 hïóÚR
+¨T5=š€áÅ
+•½*V^¾º1êrðŒ*
+®é/Š)T,¯}«2lÍ,ʽÆÎ[ÙŸMÕ° Ú~(¤ÞQò«Žã¶ÚœuÁ3° QÑ•×46™›œö¬}Ù6tF-„zôôÏ
+x0Æà K¾'¯g~y÷ý|Ž°ž¡CCëLFRçÔûCx“U2x’ì¤Ú€òzô8i½‚“ÀÀºP &&åËk剺âi-`JÜ&â,¿Ý¦¯˜Á¦¯z‚+Ý°G…˜Ö¬l†0ÏüÜÖ9oHƒT>vüŠ"nC1Ç=ˆ§XØ„?ýËzñŽ7½Ò!·51 ضMcÿekxnºÒº1Èv&ÿ%V¯Œ Q¶Ù¾¡cÑ4~€Úgo¡ =;?§‹c6vÖÂ5NCÞ0è+wµ ý¶NùLCª•û‰­r,Ïbj¿ÞÀ×Otm‹yã«÷Q±âm·/SVæK |“D|VïáEV<Q¡)…xú—7'Õ^'å´U6æAÂÉ¡ehSÃQúÙì6p5 =‚ÔKÅ´t,ý‰> ¯-¢A–×pE¸6¥]“ ¼á£Ê h3–©pD’&ä£Ä É +k«ût‹2üWŽÜª|nÈ<~'>m8MUš™Ö²Z†>?nÆšfcBeµvG5?ÛbêÀ:' ñ” "en<Ma f'2$ûÌ]R_­I¬‹ÃXż #—ˆd}lu>ërv×Mq(‘¦aíÅýv&…æäüá —<šµWˆ¼üe®vz{óü·ÄÜÓ òŽ¦G§IDÃ"b_Ö Í%ËŒ‚²¢êx‡Ê^‘$Û„ù…üÆy uÁéQ_p$@ÖU/Èãˆ(w¡id-êl¡å¾kT
+K§4xÈÔP¶—ÛÛ‰Õ[û‹ÕÇo›_¶¤uÃwü`@Àr4ýÃ¥Šùâu.Çc^ʈ~¢{ªŽËûb²OÁw}ñx×—`c™ãø?$?q;a—C¸GKÁCÐJ&Ÿò"t¸§'¥=€gh¥Þ¹ê ýs§H½Q”þ¯ÙN0ViT®I‚ÀRÜ#Š,šõ@¯»Ï„S; —nÑ´„(ÁPþ±Óí'ó±÷t—¢ç©¤ç‹ûø?0õK*`ÁÎöÄË’&8¡ßçöìd„ÌV  }¼·Õ0£¢²Ü}çŽ 3ѬÅ@‘Òµ13LëÃAÏNÓó.WN8™œ `c¥ý
+üm££O<+„ºlMË´p~Mý™[ñ©ø·hÊW·N–&9_ 9øÂåÖ ÒgÙ0ª¸Lt»ÈéX+sÿõ„&ûI*ofʸèÊ /ŒÀÐÀƒÔ[ü"¤}.¸ûæ¥c‘çäß>3D|åOVη}ðî
+(ª4rQ¹!Yzˆ‘Yù_‡u¼‡Ó´Q½Þˆ®¸ËÛÌ«
+|ø2C¸Yƒ~Y¤¬BþLŽË¬ðLÕûvè÷Í ³˜U@âçÖ¾”5Ù¹~ÜCåýŽœ—® ‘ë†<…¡ÚÉ¡È„¿ ;÷Un¹ù¼‡ ã à™9 ZTêS½D,f¥‘j@xqÒ–iEÐ+ž²J>`ýáìÃÕ´Eñϼœ#ÄñN%€õÐ7
+l^¹C8I‘èe«3ÅA¤Ã¯ðÿØòk¾Z¬nk¢ªh±¡FÃ]ðÙ›·²îtxrJ¼‰Ù¿bo
+d©‘¯l};¥ZòM«yŽÏ‚ÐÛe´Æ;Î÷kßíªêÂ×¢èCsú?êÂr؇VÚýV.K“.ÅÍ"ûUg§ ™áön~ vµ2Äv gè"àÃ\ôAm»)Zÿh”RøÉR¼.|y÷¹'"ˆ*&–ç>™#xr§cm¦Æö0žœn³‘=ǤslF&~k2E«jlþ¬ Ƈf„ÃLbJ&ÆRXc6¦KnÄÎäÖ¹˜O"êûðΕ¦#{äÚª|^3ŨÊ;è44Âr1f5)·g¼_ ì(1%Õ
+rÒŽ½wÂø’>;Slêô‰‘5s¼uÖ²Å#&ëA¬!­ø5çÈÔúÉÂbªªF%.ïîÐ{ãRU©ÉàëNyÐÒ6½/ÚÓNEg“É·Û¯êÏò¼hžNº–Ž¡]Șùj©<}crÑ¥d­!]ìÜÎò>þ ÞÄ ÷{€m6"ûªùø@P¡S†¸s}'V%ó.£zùˆí]¡I^(ÛùÌ6…–¯ƒÑ|4âsæþ>êYÈ-Ï:´¢Ù2åÁÅs(×±@¢ =}Åæ—U·n6 ÈBC¯>Ç!Âû@u=å<²—1i=íÉú=ƒ-¨òZ—ÅM ­Â4÷–@tõJæv‘q½ãû´yç¾vr«Ï„¾VnEø„}j*7Si‹{=‹Áï£!æXàý1±J ='»Ê`W¸îÌÒìì;ïD}Âv-wŒ$ØM0½(ðö¨ÍéM$ÀzCç§ 3ß3XôåB£
+°œâ‘1é#V~Ö¤›½hBñ åùjtw“bsYŸ´5 ¬˜ºÿ“,W²ýÖ»X,+'z7ÂàOe~a.!dÊ«+¼˜å¡ñÊVóÎçõîú…*>3 þ»m'¯¼ŽpFTYDº9HÁ†“lPËÁsà–Žý„Ä&ä’ÍåìƒÔ„¶“MÊBW{a
+œây[ƒËu¦YÚr!ƒô$l³Ø a£.†þÌGƒaW]èPj©"!w¦k?…Bm$¯œ:#ϯ˜R¡~+Oø0¹`5ÌP(ÅÍé=vÛ „ú"þÀ‘—Ñî1+…¸Ý¸&ߘ óÚ*-‰Š ”8ÕÐYNÒcŸ˜¾üJìsMQj[F¸‹kzéú¸ä(ŽÀK¹öëÎá½ gnä@@m35N-Í˨d²äí«hV]¨Áà^ƒì÷¾­Þ uŸ÷ÚÖ¦k‰-¾·UÉ[~¡‰è%?Ôé·SrJvı}Ñ™¾Ä=3¯rêÅÀØ›uYoaQ•L}F¡©›§ü¡à:Ežir¢,sÊÜ[<z˜¦öÚwR–o'«èC=Rp3s* £_Ë•Fª!Ñ ŒLïЋ˜¦)§í>¸©¿ÄG€ÇàðÿÀï>Â6SGÄT¤®I;@|&ÞHJstÊk=Lig¤5è‰,þm!7ÿîág=ò"Œ
+<uHîPe£C³PÍ2EíäÁ|ËM ó«QX³g9(bçŠvà‹÷µ/’TÂèó¹ÂûàEÔ’÷¼¡¿J£ºV]CG ;f¥/ÁàL­÷mˆª©’’ùê#°ð¯¸1¹C‚U=è3TnÌó´sS_vçahîÖ5ImŒ=_²ž‘•9–ãÆ›Öo!|>i÷.T+=a9?wô²ÅùÄ˺éN¡¼‡Q²¡\Ýq.¿³lߣ¯ÚÌMú‘á£óäPêç@lʼnT
+¨JUŠÆ•ý¿Ñu3·àp G„‡ùbÃéÏÝDŒ%çwì´¯ïª9áÌ ó5SsÕþ†ˆKë†Üœ¼e}Vô™¡)‹$?·,V§¨$Uã½cNùÕTD ½³#éˆF»œ±´Å(EB‰w%È {|(¬3-I™¢m8W‘r…XÍe«àÞVLL¥Q.*Gõt¹IÚ¯±™^_Ø“’ÚÖÈûR˜Sö «îÒžÿk./·9Ï•ÅyÊo •ÓwÉ×°ïJwYâ‘ϱî¸6eÉÑœEɈeósS}¯E±X8‚ÕË#¤y 㼟KuEüì£!o´öUöä”óÏéŽÃZX©¨,M|eÍóÉÝ)ƒ^»D¥?O­Ü]De×a$p*£<Ôu¸-‡•²·HÈÁÉ'. JØ QíH2³&šÞ–é{IênÊf›êòËŽêõ0]\³Ç¸,Y|egσÜÍ–Ø,’ä¥à¦¥\ÂO°ÌA%hP ŽmÀÙ3Y'Ä]ÄhÌýð±ÕÞì²›ODPxþõnº”å“]ç7CåÎm gªô÷ËÜÆu“óm‚ 5 :ª4kíusD󰈪KÀs¢'·»^Rå”XÄ ) >M“£<Áp©E^ˆž+vxE$¶ÆöÕ¸œ eMÁ$ ÷Š¡|¨•ùìü–îøÈp¹[䢧ªT«-ĺ ô{~Êfª~ý WÑ8æôQT“yi¬W%>ùàw—3+¶ë‡IÕæŒ}'Î '>š! ^ËÉ´¯ƒT%¼àn=0Z€ÞOi°nŠŒƒÔ'ó'~
+\´)(ä t‹hß÷çuÌîÈÕyêáTÅD_.àÞM`¦_}\_i¥ê#k?×ziÓÍà‰Á¼­zñ)90¥7€•ØIgx¶}/b
+(Ñ-ì@¹ÀËq²<Þl™xüú0·¨gOyP} Å¥\’`ÀxªÃÆ°6‹9)ü<»^íéîä>ƒ@1è¥ôk5 ê¥5a*ìH¹4}YÕ #|ÿ§¦}ý68w…Ëj*6Ã㸟QmŽECÁ¬œ“§ÄƒOoül“³æoC’rR>s”Ù°ký“Xâ²Tþ--i»ê‘7`ù`/N…›'¶1 h <þS°=xÇ4î×ÚT¡ëÛÇÍs=@· 1~_¶ý)î;ÎnoŸ*CHÖÏÄÒú `^¨VY©êKŒ·€’ÃN±ÍÉÿ£†-$Û:5š›B§>™ÌwÍ?
+qÒ¸#q¹àÞMn¢¾ƒ†ÇU­ÛòA ö5 îQ¤±£-•²x^€’ÙtÉ¥óçw¸_Ü ý‡ýZ;Ô4ò#qó)ùtƒ/UåÐnp©á„Ͷ5ž‚B²W  ÎQÝNk›‹v<§sïU'¦J*"Ñx«xóoŽú ¡…ÁÇ••×ÕqƧÇãç‘œ^¬³“RöéEhæå)ôd6ºØ¦Nr ?â¿®¼Ä½`„ˆÇÐS#£‹c†MéáßÞÀ>RÝNf¹h}ù)æ_Èt€½
endobj
967 0 obj <<
/Type /Font
@@ -8945,14 +8921,14 @@ endobj
/FirstChar 34
/LastChar 122
/Widths 1949 0 R
-/BaseFont /UJMFYR+NimbusMonL-ReguObli
+/BaseFont /OIHBVT+NimbusMonL-ReguObli
/FontDescriptor 965 0 R
>> endobj
965 0 obj <<
/Ascent 625
/CapHeight 557
/Descent -147
-/FontName /UJMFYR+NimbusMonL-ReguObli
+/FontName /OIHBVT+NimbusMonL-ReguObli
/ItalicAngle -12
/StemV 43
/XHeight 426
@@ -8974,7 +8950,7 @@ endobj
stream
xÚ¬¸c”å_“%œ¶í¼iÛª´mÛ¶³Ò6+mÛÎJÛ¶ÍJ[oýŸgº{V¿ói¦?ܵ~'"ÎŽ±ãœuÖ%#RP¦4±72³·s¡c¢gäÈYÚ¹:ËÚÛÉÐ ÙÛ˜
–WД”PŠË©ÄMíL m
-®F6–Æ
+®F6–Æ
…$ØVW˃÷æ¹)Àõá}@Jš2»œœ$~P–D™ˆ‡…:Nq©ó#5ßì" 󧈼ˆÎQ僶J–©Èµôc“Êç؉/Wñýê›X²˜HO÷|¬®-“[ÿƒn2ç¡‚÷`ŒàõÉùKH}&¢~t–ßêÆ“-µZ•÷ÎäÒàMV]ÓYÚñ‰‘06Îó'ˬy?‚²9¼oºÝ²Ï—YzÉA€&s5õC`ýnXÙ°ðõɃ í’D,÷gÚUÑ{MX8“Ž_ZœìÊø)“bzlS âz/ˆPr m¤–ÕýŒø86 ]¬
+½ÄGL~Ö§æ0GW˜RS4Œ–¢V˜,ŠÈZzU¨âè(ŠcÆÀXÙˆ-jà±*ç+êJ"ÈhZå ðIƒ ïŒ œƒŠñ]Ñîç/µÜhà÷ šEh3ŸiqÌVHXn´Nx-ÿQ9ƒ]ne£(‰ßU;<kµ˜\û·h8V)‡5ª#ñá»+[?C6õy‘®G‹gõ›ˆí¥¯vÂó†ÙÌHÝ—Q`£n(9åÉ‹Ôª†¢"ñéÛ>aXSû¦Ÿæ¿rçG.môú¥»ÁÊ|a™â¡^>#þ»ˆ^驵]M»qÁO>Z6Úl ¯=µ)¢_¬¾rÔ—!U;:±å$z2»?Ô?÷,|gP¨Ö:`ÌG*p²Sí»Ï³œ.ÞJ;"8çÉK­ñs·Ìúe”%±¶ Ü-.EÊ’JÿLئ h·ý,hïY«M÷s<ùi“©Ò£úþÕ›j2žE)mœÀî;Ÿ¡å×)× ÄãÜùšë_`Âý܃4¨G³0 œ{¢zÀñ®yÑ C‰ÁŸèP!“2Ž¨Ÿ*§_‹Z夻'ªá¯›ò =2ç#µõ-»Œ(…’jáô˜iÜS$J
éèóQ.ž¾,Èv‹®Ç'Ÿ¤Îûz5+Éí.þÇÌHF.'_6®DWeN‡´¦j×I*92RÖ¾Ø.}ùÚu¯c†ß±©ŸoL¼`Åa \¯²ZÕãLƒÒË+-(þÍHUëO˵Íè|ºZÖe ±šÜ.¢{sN"p6¨Wvg‘¨ÚTzVóeÿºŠÉßDbþ}fìkGa<ÊaÆ#sSs&ÓçQ‹Ö:“m€¦ý)®ý]ѺΈ¼ÂP€œ_—ÁJîY*ùEÇd@–NËoÀ*EëgšþÐ*Eì/5
@@ -9040,7 +9016,7 @@ r_å~ŒÙsK=pÿëxoײ^I'níça„SpÃ÷ëáòþ½ñ3|K0À¦ ²=z,çÝ•âïcíñÌIér‹‘¦
WBˆuÀB="÷Mª†ß|j¤E˜&µ»“=W¸õNtéÁ¶5dPGŽj¿wj‡Sy®¾"‘Ê UW# ¡4‚0‡©¸¿ô3‚´RÅÒ]ʽM§ù Z–T‹0ž0Å•$í£[É‹Ícãu1ÞeEpv¡„( ©šóˆí濸A·Â’ò·äûtô±(s¦“Fi2Åx\èE(×(9Å?UËÇ|O½¤2o{¸¯}a£ˆ²zŸ–δ€R"ô¥²¶‡ÀØßš)ë*m ôDs§úä}á·D
À€èö}»!Xö&#’Qƒ÷ÄQo”Cþ¸G FòñͳH³ 3ànGZ(ÎF_¯AYÔ%õˆøcŸ=ß0ßpMv¨ú¶Lbã1†ŽêÁ³†L *öVt°Áëh-½m—œ(<ÊxSæN£X»œ$ÚÛع4›ŒbŸ…±´þÂÞ±Üã‹eõ”~ð^•ËÄ·¹©ëPXƼŒð;ö2nµ *’ç#i¥¥ÈÇNÚÝü…+3÷3ÌÌ^ët]XW¨²¸DLèi[Ó8OÛþ>M6¬˜NJ3ÆzU1nç€ 6QÐ19‹—Û¥ŒPÖáZvõ'P¶—YãšUrAIîžÅÅ€1›MejùzV+ÕÖù7¤¯¼/E^;æ{/ZÀHgâ×j\œÿ+jÚ¹U7ÿ1œ6Þõ‡cuªæ®öèT8ÀõÅXý]¿0Ô¦‹Y‡½ZybÅvë$n§ýõ£±#ù2 [*ÃwÅYårÄ9V@»”d5ÙKˆÙ"ûº°yó v ƒ®'XiH!ó á3wIykÿ#J÷lÒ<¦s(sUø®û¤Tð|á:/pœs§Ô ëP’–<ˆrÞbL|}ä’0ω´üûÿÛÏgÌ_ögk=úÚú¥¯®®‚_{íÜí ÿíü®Ò§à1ñƽœ[.I$Þhè
¶Ù½äÝîØðmŽR/´Ï8e°ûœ“|ñîëszC<’^'¬üš~xõ¹l­SÒ|úcä',ü~Ç+L`áƒm¡à¸Ô›;ΘÍfyüØbÏþ9%¼Wû^š¦ù¬ãFáuž©ªcMŸîVÿšW:áõdÝÂ}L“âÝK?ϼ|BóÂú–UvÞ•‹w|›&óyvÓê—šß²CÙvOË*|ð(-´zé>û ‚Û\y–'$*·ñóÓÌ¿å ÌoßoßîËÇ6Éý¯ÝI)–ö÷]³=ž+·ô»@siÿ–R¿‹Âs2š5ª¹rwö¤˜q -¨
-¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë 5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›
+¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë 5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›
endobj
890 0 obj <<
/Type /Font
@@ -9049,14 +9025,14 @@ endobj
/FirstChar 34
/LastChar 125
/Widths 1950 0 R
-/BaseFont /NLBIIA+NimbusMonL-Bold
+/BaseFont /PPUFPB+NimbusMonL-Bold
/FontDescriptor 888 0 R
>> endobj
888 0 obj <<
/Ascent 624
/CapHeight 552
/Descent -126
-/FontName /NLBIIA+NimbusMonL-Bold
+/FontName /PPUFPB+NimbusMonL-Bold
/ItalicAngle 0
/StemV 101
/XHeight 439
@@ -9072,85 +9048,93 @@ endobj
/Length1 1620
/Length2 20127
/Length3 532
-/Length 21035
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø%ìlA ,ŒÌ<
-šþô­¯œtGLz¥ÈéQž7K²;P?8˜Õö¦””õJ>`ˆg:Yánžiü(\
-ü°¾<Ù£ø§6Äbw¡5aÔž_|M<}~¢î½…î?$¤Ë‰…§äuBþéçC(øC­B¼ªùÕi{Ju ¡glŸÏÏìC(»ƒ¢ÈbÓËZÁçjð§fÌÁpC@¶
-¦éÂú”/é„ÐaF)¹ìÉT_Äü AÇDF@’_²– z¿IÂ>^"ò“£œŸpÖj×Ñm¡HNZ¬¹Šù—;Ão{ô«OŠ—©š}¾ŽÈïqM gÀÁõ@‰Î
-vÌó_ŸäsýðKÞ`zŒ—6$Aïܪ“³ÖUª Ô¼qTÉŒ!ÝNë”›Å/˜4ú#pöpò>ÙMBˆÁrêM<õlb®‚‡é‹à\jÑhŽ!··qèš–í:—… u>5±“ª——‡³›G¿:×MÎ{òεÁéKœJC·Ò@µ¾/)qpgŸ”­µí‚ ¨•Šgý´»Û]^ÕÞƒÛ1Ü ½û߬Dþµß™á…°ä]xŠ©9
-b¤H#øÕV h@û€€Æjý)ûƒe{’Ó
-3 á"Å8a¶ÌýhC©Š‚¡|«ßÎ[ÖGÏ3“GDBI‘Z8«µ¯öºÛK
-’wi¡ ´NºóoI^0Õ–ÎÈ!C6פ  AÅjc›a˜LÁýäü>wiúÁЧ('Q_´d¶lAS¬Ôæ‡äaíøîyNM×iÙòD³."KÂ.38°n
-ݱÍAïOÇ4å|cå žä½Ë™à˺_…¤Bcbœp%ÉU™xíŒ`#Ë}Cºûð¥H"¹ºå)çØÑYi#,ج¿ßÁ;QÝqç·Äjí(^&+ MÌøkRÐ,7÷u¾!+o­¹-}iC¼HBbÛ*1'O. Íþ~6'jïý˜ñ+gt5û¢PVÔÿ¤˜¿T?ÚãÔR¨s(S¡šq¹"yV‡ôî@v¨„3ëÔHG¹çòšu´ÉÅQ›8 Ô%âÛV†w>ðÛeã‘[‹}­H}öA÷4OöÖgí
-„7N•{œP¾©3¹¥Œ/Ä[Ö]ªp­Cƒ’½f±eB8|* ÿá´%Q0d’hyŽÏË9€œH7þ5'i}=½ó{LXwÜëaä6Aº„ï5Ëo7F—Aµbñ#¹‰…O[?ˆny= ¯7…³¾ÏÆ_žMSÑÓ<Ÿj²¹O-ÄËOrlºÈ|!•¡ÀºüV„, y©+¥, ßê¹2š_Sûà£#üåž ·${qÛF2<üm=àmûS}ü{/°¥ÖÌ:i­‚ƒ‹\’³¦ææŒ"×îS©ÄÙM>?gЀñ¤kMí!,£sê-Ð@‘œm
-ï™°H¯Ñq<)XÍe.vUÀŒ‹Ææ6¼j÷(OóÈŠ¨ð"AÏ@ ä_ÞžX$#–alxUeh[fdþ.Þ_lÔæ8-®(˜ÙÉë¾—©)ZóÕŸ
-Ôû´Þܼõz2‹÷¤#‚JÇ_N‚aºäYCÏ>\z…„–gĈÏs³Ìjd¨¦!X¸ˆÓ wÜ2mö8Ùp!os´C?yTÿ@[Qc×Üÿq…ÒŽ¥Á=5(æΡm³× ÔIìÑ/Ôa1VGKj]Ø w´Ú}oä¿8A#çÁ°\SêœM,ZkyÀºHí(¨ ·³ÔŠSñçöš]MC~ÌTŸÜ¤Pg}÷p€‡€ J¥'Þ fØ‘Vý"‡øíbÇdsªÝë~£vz-t±~ŸU²ôn5\±ìÕµIýS«Uÿ >¢KóHšÃmµ[»nKYݼ øËÈ|(ÚÍs@w³™ >sϽ°V…–šü ®ÙÞÇ+×Xª‰‘†€9õUW«K8†?é `(zšŒÜ›×Io_eîÁ‘Í>&p×$ÏoLòŠJß´/õý…›R-“ÃOÃÄ,Á‰ þØFáÒÓýâùu.Í­Ž©X€²£ÝF:ûL@¥å߸‰+¸CVçD§›î$2ܘ±­¤‚Tô¦:‡4Oòü?ŒÙì7ØC *™VBÆò6Vjó­šÛ¾§ ÷fÝÆ1÷ídž ¿ô |ÒÞÞ@OBG À§˜«T ˜Ã1=Úuø1&\ÛTĉº(Ð64Ï›§¼ì¥—¿ž6ÇnÚ4~ÆcÅÛ[zFbÆ’RJ»žƒ.¶¡ÖkŽãÃÞDþÈÉ+GâzƒîÔ¹m_C|øþ0/–­Xµ³-`_1+Rå¬Ë¸ƒðžM*&`*ó|ÜTF-ò\<óãT¢
-
-
-à+N‰Ø5ÚNjÔÐY›€¨áàݵiï+Zf;ˆ?Çåe³ÙvWà·kŸÒÅüµ—¢I¹ë´“F4{½*-5 …)<m‰‘·iîúó…sA€fÌTljò‰¹^›]¿w›H.’îŠI†m¸_|óÚ»b \ÝÛè#Úžƒð ž1Êê ×åã–μmœh³fË]­Ú¸¤„ž¯\ÇišÒ}EK¶ õ»›õx}3sŵÈûÔM¿=i‹ƒ)»o)=26¢QžÉªËC†;ß5T]hQ€Ð^šŸmúà|‰Z›!ç˜8ºs±S°È¾J¬f?Ý ëÞìoåCˆ€ßlOŒ‰¯¸1 ]§Uxœ<Šzæ᥀•áç=ˆÎmòò‰¿½PÓ1ú”¢>2x¤iÎ#§·5ž.‰©sV ñº^ñ¼ëÓýªÀ›`õVÙÅ¢UR¸¼ûpœ“åæ41$ûFÐ8ªŸ8 lV{v”ƒîÞw©³î~¯ìýý«&À꾃~èôÓEKå½ây­ Dj”¹÷-vá'†H=~€Œøä“þܦð!UMÌÆ‚qzÝKs"œÏòçžNIZÇ&s™/í}‡•‚ðQE´¶åï¼1àE˜»×AÖö¹›€Ú8!ZŒ%©u4¶7×)-¹¢þxÏ ÌŠi#Ò},V{ 3ê™Lk0Ûd±À1èÙýåÇN@ˆ<E¾=\Ðwö\#·Sä‡ó Ìµì¬ j‰um‚Þ>ñ€ÖXzdöi¢ð»†¢”YµÇÙ¹þÕ‚ÅmË.»ÎÅ)6>NSã"jú¦HËèË­LnE™ƒ¦üÂKh°ï_ŽÆˆ\RÙßC* 5¦ T(´eLjÔ9úÞÓ…eñrWtA…¤ÙlõtŽcKª¿ÔL©ÓšïÃÍCm á‚cÆó7ªÓû:³HAÁÏÑ×$k!å8Õ#[;mñW¨$¥„ÊQã]T”PpÎÊ©j0)¤p)8H‹Ûä—4ÞÌd9ãYVä]mze;ûµª.ò+ÜôÖƼ9+C­…ŒµÍ7ÈÀaÀõñú%B{PçÑó²ŒG>¦ï\8ÞÓ>\ùë
-¾07ÙtîRÝçP{myZí2÷<ijœçâzxÒô £'2ºñÉþD–£,9tÞ±¾vR§ðSpCŠ%è²³O»¢‘χæhÇeUfL†öH)”éßѦ"¥2¦TVÞ¤Vx/>’^Ž³Š$pEÚŸ ºþ<˜÷|š‡+œüäî˜j
-º.F5|EKÖ_kßU­†Ä&“ó"÷•€äûdÎ…#æ›5åØK"20¬.Fí¢Jà(2\࢚z~"‚*X¸×”•›¹-=‰Œ!‹2 ZK …‹3…~`ÊòJ&qðmvpˆ;¢¬¬Õ¼}ÜtЈD½N¸Q/pÏÐ@Øy)diDÿD¡
-ÛIX¨_QW:ÿµ ]úÐÀï9Lœ`]fd„ú1ØñœÖʨó™¢r
-EþØÜlgøÕ_:jûìe ‚¡¡¬
-M q‚8IoÜ•ªÅö›ÍL-Ô…`€ToÞ½*Pvz:N“x ›ÝžÜ™3*IŸeÀ4µô
-;S9Á%]9Ao¢ÁN©‡’p6/€ôJš6:7õ"élÈ2îqœÞ܃A«ñ)Û«Â!F—?+Íõ­ÙV³d$7ÁÌ&áýWW(Þg0 ÎÜ#Úž8¤;ßJì­¯ý‰Ù¡L¹ŒÙOÝ5 oYÖá˜
-AÒà}…a™5‚>ÂÃNFØX4²–€žÞri¸™½‹…:'é‹NÎXªËQ±lC#Ë4’w‰ùŸÈ>ßOºÒLZx¯dTH‘™‡Ø*:ÑP=<Ylc<¢„%V­ù3nË ½H¼!›Å.raìþ“¼ù÷Y:›Îxf‘…H^#ü¡ æh
-ø>@[›CQƒi«m®þ²´!
-ÚÕìΨWtŠã ?oAZdævò6I›¼)’þ‰èRUÛÌ(Á@Ú”µ²âa»¦Ð£ñ Ûå²ÛšÖ/ì¬ý&Å%é¾ACF÷êÏa¶šƒ;öùZjûâÛQBÙ„ãljÎYIN«ä…{Ïy|—hX®t²RML‡WK&q¨aEPjÍ–_ê›Í2ÒÙmYL¡£Ý§ÎŒrêgsÓ¯NãÚ‹+A׃²„7g¨ëÞÊN óké…%¦~aÝ–o¥­~F¼».û#3{9D«Áä1;â´æ ÍôQôÃZÏú8w&_a†¶j¡ã÷q ´r©>Ý}~9ÃQ‡“¹ýñQËöš‚¸¸ÅÒRß
-nº_Ø;úáW„ZÏ(œd ÆÅÕ>¤õ„‹ÁêÍ¢*qöŒ‚#röwQ;£œjÚÆ^kNÿyŠÕzÁ<S€\ìæ¬#
-) ¬¹YQkfb
-<Æê> tjY×rCD[")Q’£#˜Øn]Ìcõ(ð(»CÈ=g}¶F`³k940Œܧk¤ÿe:ä#_tRáY L©£½N‡íAKZ' KLH§£tvH¶ÐSÑe6óSò<ø]©k>¿2 GÇNê#u0UóQŽÅÕòK»/ó<'\`ÛyæÒ5êLZ íèÄn™çšz‹ˆÆL²˜)ÏvŒX¡[M5þÉž„¤´‚o®HõÌLg‡œQäzä<¸±5î6Ýc²±ï.U¨vÉM{bUWåL¼Ù¾Î,mxÙ*û+‚ikX‚â{uõ<„NZ'8ƒ,T¥~ Xè%{2Ñ/f>[µª¦Dîïö|Ý¡±šöœ©.q´Ÿ›l¢”„AMãSæKæí3r,ÁãZ<Ë›¬ïám)œ+h¯zìÏa~¥^Ø‹Yºxà½M67­
-}¾Q@<gäÍd}ßÜ-âãf††Çª§è·à^.@­uz¥@”M|Ý°Ìì4ÒÊ
-à™<=²!>°ë_Â! ¡nÒ q£^c7Nh?–Dbk]z‘Zøù·Íà[ÛX=mÅ›P :žž‰ÍW½G°tC#<áß×V Â'¦ŠÒyÞÄ1ò\ðÎòˆ¿ƒˆ§9&åŒÂT«âÞ°;¯oQ
-Äd²’Ø[EÜ­°¿ÈÇ`n—ÅædþǦiBŠFtù£¿ mŽ<{ töJD|Ï;±Æ&G‚iþco§Àå²-çaA3©±W(æ‚2MYÕô(mò¤ œFã³{gþz&V__éa6ÎÇp›¯ØalĺÃuwðnæc"8¡n‡:Ñ!1w‡Í‘˜Ý¿g•Ã ˆ%ù[ÛÃÞI‘nÓåÙ–~gdº/~û¬ugÉp¡`ÁPþôTiHŸì2\)ÜЙÍàÿ®ºþ0æ‡zx)œE½ Úéq;7,¦ýs¸ƒ,ª‡izÕ­éü*ið¾\~]•mî§Æ Æ K•!ì†ß!ou4›¿›û‹†«ðw<«^UG‰/)cy¯$Ë‹> täCÔž•6rеð‚jåº)×ä; æC'17'IÙŬõ1:Ï–¼pV%¤»Ã
-2°ÅѦyWýö¾¥jÖÎŒUËü«üÂ@¹,íðÊ&©¾JèS"§oóZ²,¢t
-’ú C¡ãa4Ÿ—7C‘ªÜ݃~Z¨‹ˆÃ©µ»*‡‚s· @qp![~_£Œ¿:[8&‹”ŽËNp€0ËtÃ"¤ü4q%¬i¨•F³høð¡<uÖñ¾î7iÞßÐäS)–óãIÌ)¶é¿Õ+[ò5L\Ö*ãÍZóÊgDسö@WÎìÖ1üÊ,o>HÁ81äј=Þü2¶ã³âL˜lƒK¯:ÏÂiåsB¢/]ûP6
-Q+ª''a¯¥¯óm@6úâçòg}»°4ï N–³š¬0ìHñëà´Po|®RÎhkÏ–T…£¿» ”àá€#V‰Y R³ŠÅ·Rßx°îV&£Ìy«úEê¥Äyêî‰;|0üŸ¸Opˆ`Ôæ:5 ×
-dž°Åû€{ò$#ïˆÚrþ÷øúø
-Ažˆ+‰o徑ù^ÄWòó
-þ¤a;åR6¨¹;áD]ëVsGm½˜¤îý‚(Œ3î} ìfˆ¦»ÖÔÊËÅ!’uÒPPÝöF5ñ;êO"•— ni2õˆbg+€ã–¦ÜÛ%çŸoÚˣǦÅ|É) –C¹,Å‹ñìSÑ.”Qƒ—#l )tæúnÙ‡')ó×LMšýLsi|¼n°Q!g ZŠƒp2Äòf;|d·sJ5[èOú»·r•
-¹0>“Q80ƒÁ˜jU¥9Ãüró5½C£öñ²·Ëä—A<Õ¦¡1RÁgó[¼X- ?¼§µebÑ×k^6*Ù J ¬(І¦7Ü1)ºPïNଛ/r§t ªX¥õø&™ ¥ƒÆôÏážµÓfÇH­öõŒ’°.ÛJó9øP>µe't§l†ƒì1M¾#,Çä1¾#Ü­ÕÄš#[ÀN).·E¶/°6~ª§ˆÄ•T1˜ôY¶#ß:a³áI]ï¡‘g=㟗ì26®HZÄ+ØÃîk
-z|~ÝX!ö×½’F`à[m”Ý»”}«SqÁM÷]»&ÃÍÝùԛꚥ‘ü…@ÏHÈúû Ónê
-c—™XúAÒœü.; ®¯˜›'·Œ©½C›ˆ^zºnõâ塳ýæzI‡•
-RÐ%åØWÔ糖Î;ÇOÏØŒI“ëöL%Ç’,úÛ¼F¬>žÜÁ|á™ôaײÍ4˜m?3’V=·_L=Rx;`‚i<’kav`Ä óè·¶²ú0
-pºs*Å"øVŸûå¦ä!¥`˜nƒ³ß+ó+ŽµÐ
-çøx£ƒ®Ñãz#ú€½ãJÿy‘ÃEäºF•“Róª»ÿø†D¯11tü@Ct´Y$Á¼šGj™¯%?¼äX+å•?L¤ÔÛ˜‡Í”_´Ò#(?Êô\˜ã@¨nw"àYl™À<”w„ÙY)ª5avQÿÊ%éömŒ—êÆ5=–AâŒ*$$–-Ò{OcŒËüŒÖ3n¡÷j¦&•3ì£Ç€ÄY+÷U&‡Zg\'ãMnÿ@÷W¢4’: zvlAÚ”‘…‡’>é„Üo¦˜Vü_Ù¹šÇ};*ˆux’ÆC,(¨ƒ|ýÜñ¹Ú÷zw¹
-£fÍ6•9í]ØTÉ°bµ÷áú1K/š&‘9€‡e×¢hœj4Šß.Î[)Z
-dCŽREm46¬8Ó¥N¸ «Ô6<É,ÆÐÍÉÎæi:ýx(¥Ët8ÐËn ÿ`’®!
-¼ë0å ®ÏØ¿îZïܪc~[Q7µê4è©Hšñq‡Ôø°7ò=­³ž‰’ §™òÆú˜“duˆ?ÎÕ+r^9kæÖq槜a^NžbÁ:ÐÞ“ªC=>JÅЕd›dg‡¼]ÕúˆËz@øeaªCšs5z Q/FÐé­Dú÷8È«âX²D›íŽO@Ñ% U÷Méd>kZ|èdü%ÎÐ?,cYÎMw5ÊÃÃP|øTëZBŒåæxM~`Ô•ä×P
-Ïoé†-Ë»ç² ¹ Y¶ñ­Î±‹èÞÛ°ëÙC¼aŸèß7嶸מ
-뜻%CAÌ‚¬UV´‰Maü€¤Ï¹uñçó„áÜêÀ:œð؃CÛ(|#ºÉ& ÇëéòɼÏÈ8GÙx被 Š³p<BÌýÀ«›[¤Êñ+ÇÕ˳ž8b׈×[ÍT|­¥#NùæQߧCW;Gˆ|SmÿFÞÖil±^õãþ™ef C¹‡¸·á¢y JòëL;˜L]¸îÙÙeÂAÚbˆPAIÛdðIÔPîÅ
-×·³÷ŒAÿÞ]ÿ¹:#¥µIä
-ÑÅÛ±åprkBÙûCzÆaÑÓ3ëÌ"!²2ö]3¾v{ÌÆY­»G «Œs» Oå×náR¤C2¾&`ñNƒ§Eƒ“\ÙÍ9È&Bê.üŒ¶Ù· nRV'“BV’äýáú%h:¾.l¶CÑy%4KÉÂTÙfÝ4„T·:ùÔÖ4_'áULšj€žXËÜý¤öiû ÃÆûêç”´c§=`²¨øqªe˜ßC´Ü¥îóÚlméòù
-H¦Ö¼9Gž¸M‡ôº„þP¼¡ïÒ4Š›µ.¾êJøiˆG•Ä$ …hÎX÷lÕ-DÞßÍ›á/c;§Ü?‚Ë¥9‡l®Ñ{Ä­Æ»òni†n½$›B×:õÒ©~’Xv
- w/¼ÞU·O§”~EÁÏAç8Q•|ðŒGÇ=gý9,?YÁ2Ë<må,*]ß»¹5HN”¤mf`!”uåIì¦uþÕÕ>2L"ôÄEñK‡æPüÚ÷AÍí"I1„'{†§³ úº¿¯c¼NøŒß_lbéøûö— m„nĜɫí÷Zäo£‚³|t0ó>ú>S‹Â™ÔRú—°zaI¿ î%ÕA˜">© •N~ú‚×-† ®2-QVçh-‰úó ýÞpܹâÛ/–¹"5vÎf—GWnT66þ8éô^úÞu¾4+k‹O
- Òo)³S™2áØ¢c—¶FäKa·\®ó*‡©‘@èž›XsIÅXðûh‰ðeýÖ8%W6¤¹¤‹»Ü²yÕŠ½¢uoUêJP'mͧésŠêø?¹ÄÆŽÞמ+Ü¿eB*£HH:`rÀL]¿ºH.âØð~}Êη¡>¼üHÇ8š½D ýâ.ºQÞùÎ_]Ì—%×Ïت3©W$@2?d…°Õã¾Â`¾²ß³Þ׆>xÊ:ªÔý°™9•YæÒÊßÞñ˜¥ãë^:?Ü'°‡eIº¼¨-„~ä˦MÕ7W¥_ÓÞàÁ¥MxqÅß)w¾€Ì}®+È Á‘ÄâGu™.­Y6¸D£‰ý}KCîý§WçRPn"8U+Sœ÷ÂøÌûyvÝôL½3ìüî3QÁš\É–ä>¨UHC{ϊѼ•€Q¹!÷Å“÷.¼?;L9§ZšÒE¾é«v¥Ž}03|­˜6þ–ˆ¶9£,whœ-ÇËŸ­×;?zøpÙÍ„y8àŽ9Ë¥H»Ñ<TÒ>HîÍÄû-q˜˜\—1άÄ.5HLUcß|{¨8óŒòZßÔç`äô³ÁPß½Q5åŽèz”=ûŒW0zúU÷Þ r còRˆžÿžDCh-&¦)¬u#Å>"1™k–ôÿ »žÍÌÃá±N”vD#¹¢A窠›`_ÝxXÒÈwgÞ„ÏÙå 솋ÛÈK+´CܦA"Ê
-âc§x~XÃJo(¦cé;‚÷ÿ¨š#1âŽøé}SUx °f=”4+ÿ䎧õZ›…H
-—€_úØî*Ý– ·£ý7<³Y6ªãvl¤ÎݱæŒú‹Ù¸™‡ÈÈc?m·Ò†h¡ˆÕ©Åç•¥RäÍ×”»L|âÊLwõø Ρò°¤¼AçYKr¼Ï¹ÙÖJÑkW½b%òyQ·ŠTæ9æ‹Ló"$N¬½ôž‡9ȯòL¡åùö;û¿ZÆMú›¦Ýj{wAÆILTI¨£%èÔ&ëö…ôâÞ %§½(1ã:«/h•¶µôÕ9óUÖô”‘­Í¡i¬rÝxUæ¸ÂÝPÂ#á61”#,*@Š –üb±·Tx8ÙÄç{ëG79yçÐê°ÀCþ“væ$Põ`Ò匀V–ƒÿþu6®%…Ùqc†¬Ó:†wtÎì•NôwØÒPÄv©*û&<û'ývýЊâ¹!ÔA"OýMBð¼"ðÛQܸ…ÍK) z²>Ç'áØóô-oâŠÌ#°±ÛÓ­ÀD/&Ësg k7/;ô^D÷‡ÞKÉÁ¤ ŸCH-²oS<ÛõCoõšÂÛw˜´øŒª"ØK–_Š­"H‘¬ûVpÆsáõpa¡£_Ì×SÈÚua¯õ°Ü±l|ÚV±{+ wókÎ:¤6= s÷(HfUôRê¸zP¢[E  ïcYÄEùºŽsûr~3§Ÿ°3ŸMÆ?å¦T‚°ÍZ5ÕèR˜±˜rL‰buO[ˆ`×w\ÁU·?‚‹œWà&ó+Дzu(“ Ø!ÌìÅûR% 2ú§8xdßÿó <ÌЃ|Šˆîç }®rw‚RÕ:Mp’òÛBÿÉ]˜RòöÖ„½®íX((gÿ¶Ä?ɸ‹e»¿è­ÚXÄ
-ܯ*ù V}ÒD¦ÿôð¥ÎÈ
-}ˆÒçq=G/¦8õ6ÙüÍ/]Z?ó{P>yêU•œµú}éË2&@žÊå:Þä®þ;TÆ
-݂Ư9ÎÖïSftt7,-–‘hV©©< ®ÙÒ]+,àŒA‡Ø  •;…ÔzEå]þ<Ïßý‹Ìɤ C™Ñ6ïðÖR®{ÒºsŽyZÍÒ+±êÈÜôÄk´ѤFÈZ‰!FÝmP€×:%•éd
-Ü)„lk2'¨ á"€”Öó±âµ|syùͱÕe€\ûÊJ;YýMªI­‘_£ƒ~Æ1bfÓõÝd=–ÙþÅ|SÅ=UkΫ
-S­‚DÍ0
-G7ôæøÆnuÒ{«ýef‚‰@ÆÚJt'D©Ñeèb ÕÓþÿkŸ,Ûš
-ÅGÕkX:gׂ še£¤xu®ôØ\CùqKå1¦g ¡lø 7[Ù²Ì4Òÿ¹[PÞÿøç¥ÏFÔ´²ÿšûI#pŒ"­ªºóöWwxN¥&ÿÊYGúéÆ„¾åoK?\aùt@½=¥¢D#UŠ&ÐmÂ΃:Kó#˜´ÏÙf`ÃN¯Ú¬5}=ÿúfy$V·‹Id”-é%#©¾¯{z²5…رF’oö¾!²’»÷ØIáMØïä†H}ØÝÖR´x`î/Æ]è›Òª^3±Í7é¶ûñâ¬Â^µñŠ
-·(FLH³~å¶ÞÖ@Õ6Jäó¾xÌ0V?K£ÈÕJÑ}gy,‹¨†/ã©$þ¸Ì~“Æp\!#…þö/»-ñæ –Ú3Uv+l•EM ´Dýý_O‰uò!÷¶:) G‚·Ñ é91¬ÄdÐ~í@§q&±ÑŸ<¹¥ËŠ)üÁžjÄÆpîp ãO`6ÿÓaÌ€“Ê ‰bœ›³ƒø*Ln<rüME‰J¬#Å<ÝþŽð»Z–êÞ§é
-Ö/y³¤¥6f,¹yK@ðcõÏ’bÖ3Jca~Äï¬]+)T!¿hê (ò‹gÙ׺Ñ9QÀî/LÆ. |ºy‹ÔOIûè{£dç*ÇU6j—áÅ+”S•ÙÏ=¡ …–› öHL
-ú¼ÌìÝÂYÛ…(tf¦ƒ>•OA‚+«ä¿dWÍXäøkÚ—­ ÞÎÓÒU±?*›¢jžêß_
-+µ¸¹­Cí­u†Æ…¥v‹øò¬WU˜}öÔ“LÂØÏÚ(kœ¾¨RoiÍ^$Hé~ÒøÈz’T ñ׿·xû0­®Åψ_ShúÜ2\o­EŠã¦=U´ž$¸_N Ó–jz͉Q
-Žò2Oa}=AÀmãUv”'·ýÆû9û¨,Yó‹Äg“ˆÐ‰$¥°®ÇªÍ3|Zí-Ä
-ïùnS;ÝŠM‚­fˆðÓ%¸<%kDpu47û95%–T +G“¢æ×*T‹J<Èü«˜t‡'On¬ÄÂ.
-ðž¯ÔÏ´ZÕ׈‚œâ^ž>ñ·!eÖ²ØäÛ¶(¥/J‹@Ëz ¼–F]¢wò¿ÝÓÏõwÁ/…=£ÆhŒcsËtö„t˹¢Æ1|Pú1—ŠR,·²ÖÑï„$8É
-,f¬S¼‚Ô·Nï¡Ó¡›¾¼xœñÏ‚È¥éJ#ìKÛ1íü±SŸä{årsê,<+ö‰ÙöÙœ¼U1*µþôD'î¿ð|ÂBÕF5Ç .‰Õ+‹f¬æ-åuÝÓ±oFã”’zeí­ðÓ„A Ç«á±™—KØ+·,V cšðôŽ­/EþrË<g{³™$ÇÜ-+ÓxYt3É°¯‹çq¬¸”‚û@k{#lŠŠBäƒûO€Ħù%ÛèúC Ýt@AÎ]7DXÒþƒÅuOî­¾[©ÞÌ m_'y…,ÒÈŽAìÊxi
-K› ÀöYt^¬evQ&57Ñ„t9Æ©‘;ØQLV2²ûËI2­U^¹¨%Ô~ŸŒ×ˆzW
-—wyÑ7a﨑Ýâ‚\Ð8Ó}`\%êp‡có'Æü-ú稛ù2ü@/øç0´ âs]1Ñ “ì³ h«Ñˆs.:5üókÔLžQdBöǺs+úof´Ôë§hÖ"³ÍÞ„ôî¥J¬°aÿì·µid´¯<îûöÞŸpÖ=×&¸ùï|A½WKÏÓ}‡õ2yÐ2f:oü0Á¹=}”%4€%³ì~­46¬“âNÑq›äøáõéí”Ú,VÞyš0ÐYjš¿c\êàøªà躮´Cg6Çh¥8=’Š%hU åí™Sî·’|Ì¡)‡{—zBÅŠº¿ð"qج5å§\
-p
-íSß»bò7+֘ߠáænÍwˆ'£#µE°nx‹¢PšL~|ö4KQ¦–!¯jn£ÕªîØãVBGE”}œœ Žý­Ð{ƒéV³”Vã0¾ô.¶Tv‚Ì|` °SU[¸U!&ýø7 >hI£YÉì0…òÇ*껪¦úݳj€í¨ž¨ß`Ù?8sGx9g3ÎîèñÙt÷:n:—SúluHx‹œ›ÍÉPo·«ÃJAüÕh€ß¾ÅW'ˆÃô´B ¶q…¡Jˆ`“ý kaæ®´bg>–MO”¶æB8uk—ÄþÙ7)Çê®Ü¿5GVQ(ë¿P­m-FG*åTA¸¡WK2z)· Ž×?3Ì›QOl
-s¹
-¹ƒ%ÔÕÝÙêjý±Uáòendstream
+/Length 21036
+/Filter /FlateDecode
+>>
+stream
+xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø%ìlA ,ŒÌ<
+o(:¨Ñ_‚ä¤ñOFuØI)Q’¬¥®‰Í:T\+kÀ2ñ´Ò(ÏË2+­Ô»Ð]é¾çAM¾×Q­?A"tto¯$ÏÊAœÇÛwÎB¼ã¢ü1lþUxq¨eÝÒäöt¼d"$ÀÇŒ‡™M ,tEÃ2g§ö“0ACª•ƒÇ“IyàbLżê|c
+ )/úh½0HéZ=`|K›@?ôî3Ob¨cËL<Bß1d÷h•ß$™§”±ù¡î]C¶Y™GOýú!‰ëŠ.=÷«Ý¹½.oÇ°,½ƒšt­¯”3sƒÆÖ®·qbé§0ŠÅ°ÈDY~–iÃøu(Ò˾‰ªæ³?ž cŠÔbdS7sYð§>ádÍíìÉQûcz‹þú7¾cèü¹$ Æ>2Í%—¹ß°%F
+>@í£dJî'¾T¨WÝ– ’ÆÑë«úþ®@Zl—,P* ï™7o6x©bäÀ×ZëíùOרc ‰^à°HY¹ê¶]¼„qGÝx- $v·úyüJŠÑ‹lüwÝ„ze|5lÇ¢‰Û&^^Y†¯d¤å¸=眫Ø'ZðþžQ.,°#p¯ü°Éøù¨~j‡|i¯ÖÍ_)¢é<-ëqHb_Ò»S3‚4~«Ò/²Jú
+ó»kœAUyÑ® D‰<aº/Q߆W}á{N·râ‹0¢ž¦¸ 2üuŠþK!Ìe§óç-õœ_…Éæé&·öŽtºö›)×öÜÑiÞÜ=39^TùyÖVÑúA`›Ë¯“Š×1³[´³Cr!F\YÔT¯É$0¹âv¬]1¹â2õ¦2˜÷¨ÏQï<^™2ÄH‘,Fð«­ЀöÕúSöËö$§f@ÂÝ}7EŠqÂl™ûÑ0†R
+CùV¿·¬žg&>ˆ„’"µpVk_í+t·—$ïÒBhtçß’¼`ª-‘C†<l®I4@‚ŠÕÆ6Ã0;˜‚û;>Èù}îÒôƒ¡OQN¢¾hÉlÙ‚¦X©ÍÉÃÚ-ðÝ󜚮Ӳå‰f]D–„]fp`Ý
+‘ו‡ošDƒŒ ¾”¹yÙÚ<1Þö÷Š3
+9à Ù÷:Å„Ÿ\ÉFlý¹ŽNÁçµ±½F¥1¢{1I#ù#gÐM!Å&Ð!ùf¸¸<:â‘[Ç‚êÞ—dx²UÃü9‰Åm³{¦¨F®Aº/b›ƒÞŸ&ŽiÊù0ÆÊ<É{ –3Á—)t;¾
+I…ÆÄ8á J’«2ðÚÁF–û†t÷+àK‘D:rtËSα£³ÒFX°Y¿ƒw0¢ºãÎo‰Õ"Ú-P¼L>Vš˜ñפ2 Ynîë|CVÞZsZú Ó†x9„ĶU&bNž\@š'üýlNÔÞû1ãWÎèjöE¡¬¨ÿI1©~´Ç)¨¥P#çP&¦B5ãrEò¬é&ÜìPÿgÖ©‘ŽrÏ3ä5ë(h“‹£66q¨ JÄ·­ ï|à·Ë Ç#·û:[‘úìƒîi0žì­ÎÚoœ*3ö8¡|SgrJ_ˆ·¬»TáZ‡%{ÍbË„pøTþÃiK¢`È$Ñò-ž— r
+g}%ž¿<ÿš¦¢§y>ÕdsŸZˆ—ŸäØt‘ùB<*Cuù­ Xò4RWJY¾?Ôse4¿¦öÁGGøË=1nI6ö>â¶dxøÛzÀÛö§úø÷^`K­™u ÒZ¹$gMÍÍE®Ý§R‰³› |~Π;âIךÚCXFçÔ[ "9Û
+%Všy¯Žç½wd`õ\¥
+?>Lîw\_¼__º‚+úˆ—Ï*×5²,Üâ~‡
+ËGBÐ×4$<]q…x\6_ÌI_ϱȸtÓ<< ±ã[ôV(“K—ê£hAÑLÿžƒ«±î«k”“Á™-H¼~„ÈëRtàÆ;ê¬ԧОSŸ«,Ä>x›ºQmMΠà¸ÀöH|’MÇD-2:s»ÁK¾jÍ)yu$–©Ó:ž•([mq!+GŒ™SÞz‚PùÒ†ÞjLñpö«Ys%²Ý¶p¬z.M[›t]Þ§ÀŽKxÀKPų½×ÕêL•ªçLý=à'd{ì-¥?Ö­#†‚­¢E^+#6#– ñ/–“õ­ñ¼ÍTñÖ<ínÀZ‰/”Ú8Y2ÓØ/gÓAÓ›øæ±,dx
+v]šÑØ}a(ôÉ:eÝX!±«AÏ[–Ž×ÊÜ’ÀæƹƣÞ3a‘^£ãxR°šË\ì2ª<2€ÿŒÍmxÕîQžæ‘QáE‚žÈ¿¼=±HF,ÃØðªÊжÌ>Èü]¼¾Ø¨ÍqZ\Q0³“×-|/SS´æ;ª? [B«˜jÜë&BØ’ÆIRòu“$€„ƒƒj°i&ÝY³$——½å£
+ç¨÷i ¼%0¸)xëõdïIG•&Ž¿œÃtɳ6†ž7|¸.&õ
+ -ΈŸçf™ÕÈPMC°3p§î¸eÚìq²áBÞæh‡~ò¨,þ¶¢Æ®¹ÿã
+¥;Kƒ{jPÌCÛf¯¨“Ø£_:©Ãb*¬Ž–Ôº°AïhµûÞÈq‚F΃a¹¦Ô9›X´Öò€)t‘ÚQPAng©§âÏíÿ4»š†ü˜©>¹I¡Îúîá
+-5ù\;³½2>V®±*T# +
+@0‡cz´ëðcL"¸¶©ˆ1tQ mhž7OyÙK/=mŽ1Ü´iüŒÇŠ··ôŒÄŒ%¥”v= \lB­×9Ɔ½‰ü‘“WŽÄõÝ©s;Ú¾†øðýa_ 7,Z±jg[À6¾bV¤ÊY—qá=›TLÀTæù4¸©ŒZä¹xæÇ©D S7Aof„ûoŽ¦¹¶†d¬Å(?# Í”¡4÷Ú7©¯;˜Ác%$P„P|¹Ú“k½T˜dpR(áæÓþ; @UÂŽåo.P
+·?å?«ì:º;rº¶;(œåÒHBÐUQ%Wy¯ÇûcEàÝÚóÌãÁÏbמgo@¦ð­q´ÔDÖèÈ' )øóÁ«ÄhåHø*²ï›#™·ZÏYHá( %Òïg!›µ ß¿ûW{|êõhñGÆq¡ÄL»»o–DTèd·ºãú±‚e6D²]}~Ç¢jé‰
+S(xÚ#oÓÜõç ç‚
+¦cô)E}dðHÓœGNoj<]Sç¬<âu½âyקûU7Áê­²‹E«¤py÷á8'ËÍibHö qT?q::جöì(ݽïRgÝý>^ØûûWM€Õ}ýÐ駋–Ê{ÅóZˆÔ(sï[6ìÂO ‘zü
+I³ÙêéÇ–T©-˜R§5߇›‡þÚ@ÂÇŒçoT§÷uf‘‚‚Ÿ£;?®IÖB,$ÊqªG¶vÚâ¯PIJ •£Æ»¨(¡àœ•SÕ`RHáRp·É/i¼™É6rƳ¬È»ÚôÊvökU;]äW¸é­ysV†$Z k›oÀëãõK„ö Î£ æe*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe fŸvE#Ÿ?Íю˪̘ í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1Õ
+6AdQ›¹Í,>N)¥Ò©ðOã’ÛÍ·o}ŠÓ3U¢ªõ3“ÏŠC…}àp)Æó¿a™FK›ó+ •W1{‘¨íœiNŒZ?¿~Ô<îZÛ×Áˆô~ô}“IU?û
+^ºö*ÕÊ;â˜<\éæjB† :æ‹ãk‡o™ùžËýtaA=« ÓÔ'ŸÔÐH•ÄN!z^“«ÿw¢ëKËÌ´«vߪý'ZÎØS³_-Ÿ!¡ÑÐ9†˜­yƒ±<`–ìÜkÚìƒ8˹‚®UF¡èýÒ¿äâôëO‹¦3xª©‡ì†°b$pãÀfN2rI[ ÷Ð`-IêѸ\\AIëÇz£AÅ ;²;»¬·Ó@sûÑ’Ðë"ø ,méG(;vø™Ùd×"|‘"¦ŠÄ`྅Óé‘«¬óõlýÖ!|t]Œjø0Š–¬¿Ö¾ª0Z )ˆM&çEî+É÷Éœ GÌ7kʱ—Ed`X]ŒÚE•ÀQd¸À'D5õüDU°p¯)+7sZz Ce´–
+Ý)k=g<
+ýÀ”å•LâàÛìàwD#XY«yû¸é ‰zp£^àž¡°óRÈÒˆþ‰B˜D²¼¾Ý_v|˜÷ÕìÆ”¡v’S|*B‰ã˜D#ÑŒ¹N7uˆ'ôx’ÎvïNEy-‡UI 9̽Ç|iýB[}¥­ Ó¨ÜE>T ”;pf4_·Ñ%ÙøN} T…—Äï÷uĘ¿”õ‰¦ûñ,Ri.ï
+„y„ÑŠ<¦ªòÐYtÍþz`Õ4ŠMÇ>f·ÅH3¯ð(±…¼]¨!9‡çߤ–šà›cà
+è°ƒXC#Ä1ž7róѧƒ†1÷‹þØ*:½Ý
+¾¬üš"¨ùᶓ°P ¾¢®tþkºô¡ßs˜8ÁºÌÈ8õc°ã9­•Qæ3EåŠü±¹ÙΆq«¿tÔöÙËCCY^"fDzJ
+ÛnÂ÷Ù'Î{ü®ÒÿŒŒ®AiD–Xg‰¸N
+Ã2k}„‡Œ°±hd7,=½åÒp3{9 uN4Òœ°T—£b ؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ"3±Ut¢¡zx²ØÆx4D K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6?ðÌ"%
+‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý di B´«ÙQ¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8 îÕŸÃl5wìóµ Ô<öÅ·£„²3dz’œVÉ ÷
+ žóø.Ñ°\éd¥(š˜>¯–LãPÊ  Ôš3,¿Ô16še¤³Û²˜BG»OåÔÏæ¦_ƵW‚®e oÎP×½'”@ç×Ò KLýº-/ÞJ[ýŒxw]öG8förˆVƒÉcvÄþh;Ìšé£è‡µŸõ!qîL¾Â mÕBÇïã@håR}ºûür†¢'rû⣖í5qq!Š¥¥¾Üt¿°wô¯µžQ8É@Œ‹«}Hë%‚Õ›E1TâìGäìï¢vF9Õ´½Öœþó«õ‚y¦
+°YN0ÛæxôÞù¾•·Z1#‘pÐG)œïò±ž{+¿ÝªjwÒ±E©áš=P´Þ7±ÙÑ[7û¦“¸NYYÇU¸yd
+¢ˆÉd)$± ¶Š¸[a# :‘ÁÜ.‹ÍÉü7LÓ„(èòGÚyö é안øžwbMŽÓüÇÞNËe?ZÎÂfRc¯PÌeš²ªéQÚ"äI8
+4Æg÷ÎüôL¬¾¾Ò?Âlœá6_±Â؈u‡ëî$àÝÌ;ÇDpBÝu¢Cbî›#13º;Ï
+*‡Kò·¶‡;¼-’"+ܦ˳-ý<ÎÈt_üöYëÎ’áBÁ‚¡$üé©Ò.&>Ùe¸R¸¡3›Áÿ]u7üaÌõñ.R8‹zAµÓãvnXLûçpYTÓôª['ÒøUÒà=|¹üº*ÚÜOAŒ/–*CØ ¿?CÞêh67÷ Wáïx,V½ªŽ_RÆò^/H–}èÈ;‡¨=+mä káÕÊuS®ÉẇNbnN’²‹Y)êctž-yá¬JHw‡d`‹£Mó®úí}KÕ4¬«–!øWù…sYÚá•MS |•Ð§D Nß"æµdYDé
+Á4õ5’KÄó}†#‘.§­¤‹R‹«
+õS—¸­oïV‚•¦x{ì—?]Ž{øjA}øé{¶$õ†BÇÃh>/o†"U¹»ý´P‡SkwUçn0þ€8âàB¶ü¾F;u¶pL)#–à
+}c6!„L¹âP’{ƒá;D¾dçqí¨ˆz`Ë2«f§µ­])ÊFDŠÜ›/˜[öÃð"§Ê^wHZÁ‘³"¯oD{¼_7züä5àb«;ýS@$ú¡W °²ZðDò¢òuÙÙ‡W{fMÞ2ó ¥I*,~…Ä©¹#xÖÖŠìz‰KkVßL™E›)¹‚¢ÞIXbÄSóùÈ»´[N[lº3íLX¬˜üçw^@dqór
+G%vA)ÁÃG¬³¤f‹o¥¿ñ`Ý­LF™óVõ‹ÔK‰óÔÝwø`ø?qŸàÁ¨Í tj@®È<a‹÷÷äIFÞµåüïñõñÚ1*Oîc=÷Sï×Rf•«xh¡«>Îê3cçÈ
+ž(—NÑÄåi¾%¦Še¿€Ù?ó‡ Ÿ›o†`ƒbîª0Ø– õÚ MR¾
+Xá…<§õ0ØC"ôñŸjè(–ŸÚŠeÂÑ_{Ú#‹p7ƒLìÙ5`:ì¥~Áì4«¼„?ãL®Ý8Qó\‡,OÇ™ÒÀ;ŒmhT Î§µVÄ! ¿h¥¦ž;t*ê¿ôŸçq !·Ë,·*¤Z…ΟÐWŸ¼T‘*”„6C‰:(ç›ø9ÖɵQçQÈÔGæǦߑ_<Â9ç×YÛ­ÐÚºMîƒ3u"JL üüÒ¦Q#ÆV_©©…vYTóVKYðçæÄÞU™gÔ»ð¼ òù‘Ïz‘Z(ßC?¢1Ý=žâD®jŠR8€‘%öøg×Èži2v»n›„¸MM¢t QdÂ*l%–¿‡RS7ÌÖgj¿¤‚<ÿWßÊ}#ó9¼ˆ¯†eç^™êgÞÀ Ïõ#²z:Ý¢
+Ha\»¤ÿEH Ü„Ôçì¾f• %bA¯üIÃvÊ¥lPsw‰8º8Ö­æŽÚz1IÝûQgÜûØÍMw­©•—#ŠC$=ꤡ ºí=ŒjâwÔŸD*/ÜÒdêÅÎV
+ž‘õ÷¦ÝÔÆ.3±õƒ¤9ù]v\_17OnS{‡71¼ôtÝêÅËCgû!Ìõ’+Ì\\j·Äž¸,1Èßß62–e€Æ§¥ì¶£þ&kL¿ÜêWÎc½aàJÚQà&AY¸Úãt¼Å+«8•õàZõг…V|Òœ½ÅÆú¡/½99t<g¸`^B?h¸Ç0Àûµ©¢ûOÛâD¥¿¸ÆŽAôÅöŸÐˆ"&üÒÙGZ‘úáMŠ÷1Ó.Ø›ÉÕ
+}É6¡©†þÇÈE…<ÊP&öÌ>sDõbÛ_ÇÜÛWp vµe>‡ÿö²fßé(!‡°~i0bkzì¾ÕIä­ÖÙ²¥©@ œæ‰R&ï…Ãi$|i ׶Π³ùòR¥ñ-f —ºŸ æžæœby,I꾟pXðØ©»›¦Æ)bF°¡K·b¬H‰ÌçubØ<A¨õ¨Y*ÓIÄw7y èÃokSI‡&úÆΤ Kʱ¯¨/ÞQwŽŸž±“&×í1™>JŽ%Yô¶yX}<¹ƒùÂ3éîe›i0Û~4f$­z6n/¾˜z¤ðvÀÓx$×ÂìÀˆæÑnmeõaàtçTŠEð­*>÷ËMÉCJÁ0Ýg¿WæWk¡0[(ÃL(”ÂÁÒ/;í:1J ÛÙÞ¯£ùþŽŠ's
+†‚˜!Y5ª¬h›Âø
+’9„©²Íºi=ÿ¨nuþò©­'h¾N«˜4Õ 7<±–¹ûIíÓö†÷Õ=Î)iÇN{À$dQñãTË0¿‡h¹KÝçµÙÚÒ9äóÌèÍï@¢ËG¢ $éðfKvHÀÑ:ÓÝ&îûAoà `žŽ“DGO?Ìd¨ö3ìŒ Â̪i¢ì'Y"-°ö-¸™¸O-õÂ5¾4¡Ã­š6rMŸ4Éì’‰üË¢¸U9F4Ò±SÑU-ÚÆ
+¡à£"Ð,‘gÏKîD~^ººÓÜÉ/Zn\Æ$ÿM­Œù–1ÄŒ)Á×BoÅ£E[âcQóh¨X*úêÊÒO>0”ëw+ÇœðaÚ¨F~¶zñyþþ{ ‡gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤‹PX,Gæ(xõš2œS`º faje‰ªh.,w¤á«7
+cLÇý2 Ža®
+L­ysŽ<q›é;u %ý¡xCߤi67k]|Õ•ðÓ*‰I
+Ñœ±îÙª Zˆ¼¿›7Ã_ÆvN¹—Ks6Ù\£÷ˆ[wåÝ4
+Ò ÝzI6…®uê+¤S9ü$±ì
+³î^x½«nŸN)ýŠ‚Ÿƒ.Îq:¢:+ùáŽ{ÎúsX~²‚e–yÚÊYTº¾ws!kœ(IÛÌÀB(ëÊ#’ØMëü««}d˜D2è9 ‰‹â—'Ì¡ø´ïƒšÛE’,6bOö O;fôu-~_Çxð¿7¾ØÄ(Òñ÷í/Ú݈9?’WÛïµÈßFgùè`æ}ô}4*¦
+…3© ¤ô1.aõÂ’ AÜÿJ&ªƒ0E|R*ü(ô¯[ \eZ¢¬ ÏÑZõçú½á¸sÅ%¶_,sEjìœÌ.®Ü¨llüqÒé;¼ô½ë|i*VÖŸ
+¸Kþ­Óp’¹«³>ú±ägWüD³É÷?æKåÖôm#|žZ¡£ ¢Ieí "b0G`½t¢n¢J¯q¨ÜÜPé¢G08mÜ8Ùªç µÝ¯Ýã¤ßRf§2e±;$D/Æ&.mÈ—(Ân¹\çU"S#Ð!=7±æ
+’Š±à÷+ÐáËú­qJ®lHsIw¹eòª zDëÞªÔ• NÚšO%ÒçÕñr‰½¯=W¸Ë„TF%:uÀ䀙2º,~u‘\ıáýú”oC}xù‘Žq"4{‰
+@ûÅ#\t£¼ó¿º™/K®Ÿ±UgR¯H€d~È
+a«Ç|…Á|e¿g½¯ }ð”uT©ûa3s+³Ì¥•¿½ã1KÇ×1¼tþ~¸O`Ë’tyQ[ýÈ—M!›ªo®J¿¦½Á'‚K›ð⊿Sî|ÿ˜û\WAƒ#‰Å9Žê2]2Z³lp‰Fûû–†ÜûO¯†O &¤ ÜDpªV¦8ï…ñ™÷óìº è™zgØùÝg¢‚5¹’-É}P«†öž/£y+¢rC*î‹#&ï]:x"v˜rNµ4¥‹|ÓWíJû`føZ1mü-msFYîÐ:8[Ž–?[¯+v~ôðá²› ó&pÀs–K‘v£y¨¤}Üšÿˆ÷[â01%¸.cœY‰]j˜ª:Ç¿ùö:Qqæ!åµ¾©ÏÁÈégƒ¡¾{£6jÊÑõ({ö;¯`ôô«î½A$äÆä¥=ÿ7<‰†ÐZLLSXëFŠ}Db62×,èÿv;=›#˜‡Ãc(íˆFrEƒÎUA7Á¾ºñ°¤‘ïμ Ÿ³ËØ 0
+ ·‘—Vh/†¸MƒD:•ÄÇNñü°†•:#Þþ>PLÇÒwïÿQ5GbÄñ Òû¦ªð@` Ìz(iVþÉOëµ6 ‘
+³ãÆ Y§u ïèœÙ+èï°9¤- ˆíRUöMxöOþúíú¡ÅsC¨3‚Džú›„àyEà·£¸q ›—Rôd}ŽO± æé[ÞÄ™G`c·§;[‰^L–çÎ(Ön^v轈î½—’‚IA?‡Zdߦx¶ë‡0Þê5/„·ï0iñUE°—,¿"7ZE"Y÷­à ŒçÂëáÂBG¾8˜¯§µ#êÂ^ êa¹bÙø´­b÷VîæלuHmzæî
+P̪è¥Ôqõ D·Š@ÞDzˆ‹òuçöÿäüfN?ag>-šŒÊM©a7šµjª)Ð¥0c1å˜Åêž&¶Á0®ï¸‚«n9¯ÀMæW )õêP&°C˜Ù‹÷¥J@eôOqðȾÿçx˜¡ù3ÜÏú\åušà$å·=„þ’»:0¥äí ¬ {]Û7°PPÎþm1ˆ’=pËvÑ18Zµ±ˆÀºrG»%±6.«ßÌ¢8Î8П«woZKÉ9'çêí#úG—ïj²X+§ÃšP8†»Œݸ¼0J…®D“-ýf¸=_U0óA­ú¤‰Lÿé-àK‘ú¥Ïã&zŽ^Lqêm²ù›_º´~æ9ö$ |òÔ«*9k+ôûÒ—eL€<•Ëu¼É]ý v¨Œº_rœ!¬ß§Ìèèn"X[,#ѬR;Ry\³¥»VXÀƒ±AA+w
+©õŠÊ»üyž+¾û™%’I†2£mÞá­¥\÷¤uçó:µš¥WbÕ‘¹éˆ×h'¢IµCŒºÛ 
+JÎtŒa½µ~öB¿çn 8b¦”W»VŽn$èÍñ)4Üê¤÷VûËÌŒ;µ•èN ‰R£ËÐŪ§ýÿ×>Y¶5( QD‰!%ÝHîfà¨Ñ9º‘n i’"]Ò-Ý1ºKÝݵ÷þ‡÷Û}îùçÃyžã•”4|œ"ïñ`Ûý]_€ßÿ¼Ý²í\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ }Ëß–~¸
+Âòé€z{JE‰FªM Û„u–æG0i ž³ÍÀ†^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
+±5b$ßì}Cd%#vﱓ*š°ßÉ ‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
+b›oÒm÷ãÅY…½jãnQŒ˜fýÊm½­ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;( _ÆSI0ü+p˜ý&á¸$BF
+ý1ì_v#ZâÍ,µgªìVØ
+*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚNã0Lb£?yrK—Søƒ=ÕˆáÜá@Æ žÀlþ ¦Ã<˜'•AÅ87gñU˜
+Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓà¬KÏýØIC`­” ¿¸9Âò§é¸ˆ ßcZ”Âh.RÕŒI8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~ ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@ -7쑘ôy™Ù7º!„³¶ QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë #.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.HÒý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh= Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû÷söQY²æ‰Ï&¡I(Ja]U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x9øW+0éOžÜX‰3„\
+‚¾¡ÉzŒ:s[­+ž:[´‚r 7À«_ó熈ÑFÂ2Õ:¨Ù˜-Aè
+œÆâO­Œ,Eß÷;XM«âU†æüìeçÎ&¾¸cë2“.D£T«h8&Ëe7nV"ÎCøpÁ¨Ö# }&_ot-ç2ÃæXL¦ºŠðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”–õx-ºDïä»3¦Ÿëï"‚_
+{8þFÑÇæ–éì é–sEcø ôc/ ¥Xne­£ß Ip’XÌ,X§x©oÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ªjŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,ৠƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I¹[V¦;ñ²è2f’a_ÏãX;q)ö&Öö4FØ…È÷Ÿ
+=X¤9ƒ:Ø•ñÒ
+†*Nñ(ßc“À“
+ÎQÓp/6è~
+ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ 2©”pmPkDÉ Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5¿¯ÅL|yÿ1ª5u‡Êëñ÷Òc9„ÍrU ¶óBDøò3TyÈ嘙 SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘Pu aÛ›”Ë tòÍ|T\ÅL,pÈBHðì9çÑô)8H-úäjj*ê=êOŽ
+Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñûZ¢Aÿ6Ñ®–B][¢µš×´B©®¦Ö
+åUÔwUMõ»gÕ"&
+C•Á&ûA×"4ÂÌ]iÅ Î|,›ž(mÍ…pêÖ.‰ý³oRŽÕ] ¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØærðk®–-!OõŽž1t¿9~‚ó–‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq À¶]qL÷‡ Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿‡OFÙ2ö
+# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ± ¨wŠlNþj sßÑ8v<o¸ÞâÖ²ãU8^ë|Wš
+ÆúÁÿ%ž†ëÿ öÿÿsK¨«»³#ÔÕûÿ
endobj
884 0 obj <<
/Type /Font
@@ -9159,14 +9143,14 @@ endobj
/FirstChar 2
/LastChar 151
/Widths 1951 0 R
-/BaseFont /RWLLBB+URWPalladioL-Ital
+/BaseFont /VJFHWR+URWPalladioL-Ital
/FontDescriptor 882 0 R
>> endobj
882 0 obj <<
/Ascent 722
/CapHeight 693
/Descent -261
-/FontName /RWLLBB+URWPalladioL-Ital
+/FontName /VJFHWR+URWPalladioL-Ital
/ItalicAngle -9.5
/StemV 78
/XHeight 482
@@ -9187,7 +9171,7 @@ endobj
>>
stream
xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)Mlpdd"@C's[QC' 7@h ˜™L\\\pd
-ŠšRò
+ŠšRò
üªm{|ÓÂv¸* Þk‚駹?ÛÜ—Ní>ö¥©F{1­(zR€—ùøÞ$T}¨›ä4 z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
üÐIí|ŒRëc1:QA¾Õžž‘'?=R Ž õÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦· ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
쿵$ œÉ„®'~
@@ -9268,7 +9252,7 @@ i¿5xÑ@>,Ïu> w?tiÓ¶0ûôIÏä#%(ù‰ö
^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P¸¸&&êåî$+Nȶp®Ô ~I(–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž“¬ÿ°Ë_hg
‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
-oò]ç }£¯9B‘7õ· öœH{È­’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2 Ún“ R ɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤Ëq ¸ŠÖˆÕ"™[Ø m¥cA¸¶¹"t8Q+PK¥ìó÷Ñ”¶ëÛãh_“ ®$+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝåûm®Ý‘(ãŸÄ"Þïòwnúê›»ÉÕ”^«¦
+oò]ç }£¯9B‘7õ· öœH{È­’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2 Ún“ R ɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤Ëq ¸ŠÖˆÕ"™[Ø m¥cA¸¶¹"t8Q+PK¥ìó÷Ñ”¶ëÛãh_“ ®$+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝåûm®Ý‘(ãŸÄ"Þïòwnúê›»ÉÕ”^«¦
endobj
868 0 obj <<
/Type /Font
@@ -9277,14 +9261,14 @@ endobj
/FirstChar 33
/LastChar 125
/Widths 1952 0 R
-/BaseFont /MSGWNQ+NimbusMonL-Regu
+/BaseFont /CLYKUW+NimbusMonL-Regu
/FontDescriptor 866 0 R
>> endobj
866 0 obj <<
/Ascent 625
/CapHeight 557
/Descent -147
-/FontName /MSGWNQ+NimbusMonL-Regu
+/FontName /CLYKUW+NimbusMonL-Regu
/ItalicAngle 0
/StemV 41
/XHeight 426
@@ -9307,7 +9291,7 @@ stream
xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kTªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ 4q9Ø‹›¸yZ@s€8Ð ÀÆ`ýúõ+%@ÌÁÑËdiå
 ùËAKOÏð_–\
ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.
-`abû·Wÿ²kØ›mAöÀ¿šþ«
+`abû·Wÿ²kØ›mAöÀ¿šþ«
™**À)—PHW£B¢ªU³m·WÛÔOrí]VÉ• $«ùqyĤ"õÂzŒf<0ëûë£Îðf}/Ÿí¤>bêFè,VØUd‹ÕƒæÔJlNÍo’©+¬OXÏ1Ï-¼§c-NÂ1ipÝ›í\AÖ
úêì`uvdé,RHžê$žkK‚>&Y ¤ºÛ”OØ&â„o™kâÆœm§Ù WëÙÉ
¨œ/û«Ð[BÒó´`Ûtä¯äÍN¿GfáĈHªýmVéDÇÏ“Ÿ”Ä÷¦Y_kÉóÍ+èü1pÇÒ¨åÁ³ñÂjD•jÊ
@@ -9369,7 +9353,7 @@ MIª\ÂuTØjGI-gýÂÓ–GâydføæÅxÃÃ,oÛ.رÌ*_ùSÕúƒóØCkëÚ™­¨·>]ÙrÿÅ:K¥ÓS%œx
¿n$rÝ XðD˜t ÎõÓ…”2§—n„sÞmOÆ„ ˆ;²ÃßshuåU9ñÖ&;y-sõP~K*ªÅz4rnp´}ª÷œõ)RB—+«å—>¢cI£Ž¹w× éhz€Ì\mm £MúHþ×<×|Ìï­&‰ Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5½·x¯'_Ë
c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘ Çi†Ï±m$hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'žWùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ‹Œ:…‘XF.ÿ§Òfb1\ÄñSÙ£Ö®TÁIS ÒŽã{9.´ v´ôPš_$ ƒºÃ™.T€Áj”¤RÚ.zàÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4 *+9‚3£
cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷5ØI*·[ÔrHîD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ }hë …
-¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW ä­ë6Å͆ÇIjË‚¶{Al ¸¸ ²œís è¹”Lª £ÈàýÞùqœöÇ=*Y€þK
+¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW ä­ë6Å͆ÇIjË‚¶{Al ¸¸ ²œís è¹”Lª £ÈàýÞùqœöÇ=*Y€þK
endobj
751 0 obj <<
/Type /Font
@@ -9378,14 +9362,14 @@ endobj
/FirstChar 40
/LastChar 90
/Widths 1953 0 R
-/BaseFont /CEXQRI+URWPalladioL-Roma-Slant_167
+/BaseFont /ANLWPX+URWPalladioL-Roma-Slant_167
/FontDescriptor 749 0 R
>> endobj
749 0 obj <<
/Ascent 715
/CapHeight 680
/Descent -282
-/FontName /CEXQRI+URWPalladioL-Roma-Slant_167
+/FontName /ANLWPX+URWPalladioL-Roma-Slant_167
/ItalicAngle -9
/StemV 84
/XHeight 469
@@ -9401,18 +9385,17 @@ endobj
/Length1 862
/Length2 1251
/Length3 532
-/Length 1862
+/Length 1861
/Filter /FlateDecode
>>
stream
-xÚíUkTgnõJÀ+Å €¸
-æ2M°HZ TP¤2&“d ÉÀ$Ñ*°@Á¢* @¥•Òz-+Šž
-rÓ(š€`E.º‚î
-1,Å{ð! ŠòX¡&,‰™Z!B`9Œí€d„¯
-‚PŒÉÞ•†Á3æ‚`¢”¾Ërá³d" @O2Õƒ>C rD xˆ‚/„DOã°Lð®<¾i#”€u,'Àýõ\§I„ÈÔ±0@}«ž®Á·5ž†¨€*™Jq!þ¾ùŠ|g³Ïd|T€ÈD
-ÍiË”©I¸”6™Ý3“÷Ï*ýˆLgOÿ˜—ÎéX¶ríð‡–§ŠBXù£‰æ¦Ô}[»Aug¤fã¢WÙ›ž\eÛæóë±pÓ‹¸‚‰m}¦=F®¦S{Šð~a½ê{éë-Ž›_xáŠö‚–ìOÒ éº®”xÑõ;ï.V]Pž¿ì㢡®Ñ6¦ÊD”„øÁÄUóO]ïW7Ô·×MdDõÈ'c¡[úꙘð±ÿ`¥ÏpUYóÓЀ_“è
-á~Ö³_P^¥¶=3«Ó©ìËÃØÕOGŽZè^-ãå´ôr{l4ãînlZÍe@# Èô^Óe·r­püøï*ï¦yƒaúÔo«Q½ÁíC«G?Ýh\óR\øxYB†¶¯„MLqÛ8Ëh:h˼­¬ ×gÿ5xu±!#}bÇÒÂÞ‹õ•«7pC›î2ö,kx‘êjü&»šç4Û¡´sòhÀ^ÞWj*êþ€¢XQÞgKêgò‡>-I95Ž×=ÞªÌ;ŸŸ’¬=OÍ~X†–†ë<­*ˆ¥í §äm àxûæÚó‘×ÿ¾Ûwgë¼Ñ·àÝçŠ5ÆY æ‹­oÜô/ï·ÖMž¬iºÖïÝ˺`¡Ü.i6ÿiR³¥!$m +Øk>ê¹ uÌÛ9ØV´ÂÖn^®ý:ŠPAŒm˜ >¤ß[¶¾Çkði.“UØ°•#Õ?%süáëømÆsãúîl²5ÖÕm;x³5=,1Ði¼E•qÈðt᪖6Ò¾Õ¹ÜûœýŸ³™uk-f§U$
-®FŸóÄ’6+Ûw冘uhÄEs£:ò+…ïYQÿÇðÿÿ ð«Â¨ÂbÿvþFendstream
+xÚíUkTgnõJÀ+Å€€¸
+æ2@ Š&X4–;((R’ $˜$ \(PÁ Bå"Pi¥´^€–‹ÁŠ‚g¹iL@°rÕtÐc—þÜýµggþÌû<Ï÷~Ï<ïwÎgfâáM ³‘ ØŠ ¤N®Þ‡@2
+¸"l®”úÂËæ\a6O"XÉ2ÅŸÇ¢ ƒù0@
+ø“‰d2ˆ ±÷ÝWÀŠÍ¾²6O P¨¶
+ ÅKg‹ÿ]Íáa#ƒa)ÌÂõv#,‡¤¼êäŠØ/Îßùá#’Ö˶Ju¯f³_ml>ãM=çi,.-V^=!LJ*ô÷³Né¢W 2ÜÒ¿š.ѽx5­¨Ü/+žÚDìñÆG&¦ÉÖ¼¶2eÊÞ.øFiHkBývÛöÞémqm:çØ*ÆáósƒÝÚ-½NZšn¶ë½ 9ðá&|äÀ“έ“µqy7v²&nßwazàEÎiæ
+Ž£vÐ44ûÀ‰P(¬<Gè-÷TÊcúìùõîéMþҧƩ¦)fÏ[½Ë¥3i±†Ñ¿Ý
+ÓÄßMË(žùÚ] ×d̸>pGžtCIÊŒßÛhìbÔöÈšûjs›•›ì“`ò õªK#µí!üR¦¼Qin.‹}Q…Ôäïyþ}ýιøŒâ—Õ§=+­—kw×뺻îõ:e¾,ÔrëÐH£¸J®ÎÊj¹'ÆHøáq›Žî;{KÅ >Ð1øîkÏ€\†;äüZ#£exðøõ0Š–©¬ËÎÈü«ƒ¯˜«Ë׊J,6‰J.Å%ÒúU7;»ÀªñŒ#9±ÌIfš^nðµGŽ·¯²lÞ(«Óë©9+“÷ékö+³¢ô&²Jq sF{63=Ã#ÀÍÓïK¸#ÍyIîÏÕê¾Ïʳ;ƶ$Œùª“™'Z_NXM‰Æ½µi—ºJýR Í#áK Ž63šôò³ëUL’Ó~“áwѧ‹[˜œÍšJ=÷Ó—qƒ¿O~¿±(„ðS´åЄrk_öL܈«ÁÉ2îs¥{Cu™± ±×~Ü.©'$çˆÊ’Ú•kžâoZvÞ÷€b—u4|ÌÄCC×½\vÅA;!A æºl¡,dv‡N„æü³R1-l5¢~ê‘®éݺcÏäÇÚ— ¼FNíøIM±”´~WãÃ|0]}`ӛ̃Ï;ú¹Ÿ„þMwÖOý*<oþè°ú¸Ê]Ö'¿Œû0¿Qúƒà÷¿ •N†¯Ï¿vK~MNt&´N´öß*²¥*Ž=œT^¯¼1&i¸é`.#)oS$œÉbû—æù^üQíɺ¢²x\ÕÔØS7Ÿ8(Zƒî)ª>¥Í£œgÎã“•¥þ´Ï½÷ýGsNÒ_üýéMb÷ ºV©Q™/£*ejºD«õÍV¬ö!÷A=Ùœ•%ƒR½F²¯™
endobj
689 0 obj <<
/Type /Font
@@ -9421,14 +9404,14 @@ endobj
/FirstChar 13
/LastChar 110
/Widths 1955 0 R
-/BaseFont /HGAPIH+CMSY10
+/BaseFont /GTAJFT+CMSY10
/FontDescriptor 687 0 R
>> endobj
687 0 obj <<
/Ascent 750
/CapHeight 683
/Descent -194
-/FontName /HGAPIH+CMSY10
+/FontName /GTAJFT+CMSY10
/ItalicAngle -14.035
/StemV 85
/XHeight 431
@@ -9453,7 +9436,7 @@ endobj
>>
stream
xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼••±¹­4¢­µ௙š„DÈhàhnk#làä¨Â@#
-Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'/"ª¨,Bõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F
+Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'+ %%$Kõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F
4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã
¥$T³ØÄ^×âs:‰¿„³Ót»©È i+3«0€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
ë³ü>Ëä1os´˜™(ÏÂß_Ø⟣
@@ -9542,7 +9525,7 @@ Z¦Ûæûa„Ék6kUqèL£%hp—´rÛ° ÍèE–r:-ÃdÆÊHP:ì‡2;P®…ÓêF{Ư<Q,JšãÁ~ +¡h[ÅRN]~¾
»áY€»}€cù‡Câˤêðq£þ¤ÂeSê]èûgÚò6\LÀž/*X«–Ü>ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
\jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8èÄЗ|- µÂ¸ÅæßËlÏB@\ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&m iÀ槻ÁLÝ¢»?a|ÿ¤þë™ ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN
iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB™E‹¤»
-èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç }~Ü‹{Á47 ŒCS
+èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç }~Ü‹{Á47 ŒCS
endobj
686 0 obj <<
/Type /Font
@@ -9551,14 +9534,14 @@ endobj
/FirstChar 2
/LastChar 216
/Widths 1956 0 R
-/BaseFont /PEFRTE+URWPalladioL-Roma
+/BaseFont /NAKKCN+URWPalladioL-Roma
/FontDescriptor 684 0 R
>> endobj
684 0 obj <<
/Ascent 715
/CapHeight 680
/Descent -282
-/FontName /PEFRTE+URWPalladioL-Roma
+/FontName /NAKKCN+URWPalladioL-Roma
/ItalicAngle 0
/StemV 84
/XHeight 469
@@ -9578,7 +9561,7 @@ endobj
/Filter /FlateDecode
>>
stream
-xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc ;iA;kc‚3 )©£‰³…­°³ 'š‰1°‰##)½‡£…™¹3ùõYþ !0ôøÏÏN' 3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨ ìMm,œœ~Þ ,œÌ lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì ~²Ê ‹þOgsçr;Yü¸ ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹ MŒ-œì­ <~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfa E÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìG zZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk [“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:I1Q%ªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þ ˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓ çW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
+xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc ;iA;kc‚3 )©£‰³…­°³ 'š‰1°‰##)½‡£…™¹3ùõYþ !0ôøÏÏN' 3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨ ìMm,œœ~Þ ,œÌ lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì ~²Ê ‹þOgsçr;Yü¸ ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹ MŒ-œì­ <~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfa E÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìG zZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk [“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:iaM1!ªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þ ˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓ çW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
Šº%`¸3LŽ7)ü‰] üQHžíá|ÒâP»š
ÿ\%ý}þ54>:2Ü{Ú„M•IÊå
KåïƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ Îk“T $f}QìŒ}}œ7Ãë–aI­zQ£Ø`{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó<M`IÍÍÍLÕ‘˜‡‰ŠŒDa_gÁ¡Ãœá½]é–§ 9ç8sêÓšÆô e¬bô:miØ*N±«z|+hytHOÛV77Ùa‰
@@ -9677,7 +9660,7 @@ Iö×~pºóE¦f}^!˜tQ°Ù’‹ƒEäì>‰ n|'ÆV²5D9_äå‹7â̬FJvõ˜2È­ÛŒ’ý;Û£K¿>Z&ú‰Àš¤þØɉ,
y‘üP'càÜ^M#R°·ñÃ4 {LJ B«œ»×ën¾HïŸMc–9|þ*S5ïV®ñKãÁ“üvÚJ¦‰‡’à°áR‹ÁPKw©ä;ÉͳðåH-ºOÖ²ÉâØÉ*Wü—¼éýšö•p…+èó®a7AÔºº;˜âR·~4ÿÕ|S®‘mƒ®W•~ ©Ãâ‡}DL×WF5J‰åéØ|¨i÷>#\2®˜
šÒ30D”€`Ÿ†§¾ç4}&1xÒ¤Ö¥ ÎdP•Ý‹$ȾCO‡Ù’jÛvëö?`C&W'aÔCJ•I'sŠFðìM˼k©¡¨»°+X ŠcAÐÀ«á¥£ùr!<s%!ÈbˆÀNÑ* d3³Ê6†Ø0´+3ïÍNYÀ8îj•ÛP³7Þ¨VäÎc=$0€Ž9€òõ «£…WCÒ¸1å Ô²9L±ž±~óŸ –äWÚyüInÐäöÀ'¼I3 ú]`+ò7vÃÝ!’ÔËö—k«Zœ–(&4¨j„¸`é+àpôxÿÅë«SüWâ$åM7ƒ[IZÒýš®ê~‚VƒÍ:Ø\é«…Œ€Øy_à£öý
.ÈëÃ6‹û¯™ÅSßcŽ¾Q&É5 fd
-ön’“,6"”@K;\ÿŸÁüø¯
+ön’“,6"”@K;\ÿŸÁüø¯
endobj
662 0 obj <<
/Type /Font
@@ -9686,14 +9669,14 @@ endobj
/FirstChar 2
/LastChar 151
/Widths 1957 0 R
-/BaseFont /UUJGFS+URWPalladioL-Bold
+/BaseFont /LADZGC+URWPalladioL-Bold
/FontDescriptor 660 0 R
>> endobj
660 0 obj <<
/Ascent 708
/CapHeight 672
/Descent -266
-/FontName /UUJGFS+URWPalladioL-Bold
+/FontName /LADZGC+URWPalladioL-Bold
/ItalicAngle 0
/StemV 123
/XHeight 471
@@ -11030,7 +11013,7 @@ endobj
/Count -4
>> endobj
1964 0 obj <<
-/Names [(Access_Control_Lists) 1498 0 R (Bv9ARM.ch01) 879 0 R (Bv9ARM.ch02) 928 0 R (Bv9ARM.ch03) 945 0 R (Bv9ARM.ch04) 994 0 R (Bv9ARM.ch05) 1082 0 R (Bv9ARM.ch06) 1093 0 R (Bv9ARM.ch07) 1497 0 R (Bv9ARM.ch08) 1523 0 R (Bv9ARM.ch09) 1538 0 R (Bv9ARM.ch10) 1759 0 R (Configuration_File_Grammar) 1118 0 R (DNSSEC) 1061 0 R (Doc-Start) 659 0 R (Setting_TTLs) 1468 0 R (acache) 935 0 R (access_control) 1248 0 R (acl) 1126 0 R (address_match_lists) 1099 0 R (admin_tools) 968 0 R (appendix.A) 574 0 R (appendix.B) 610 0 R (bibliography) 1547 0 R (boolean_options) 1010 0 R (builtin) 1322 0 R (chapter*.1) 694 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 530 0 R (chapter.8) 554 0 R (cite.RFC1033) 1674 0 R (cite.RFC1034) 1559 0 R (cite.RFC1035) 1561 0 R (cite.RFC1101) 1656 0 R (cite.RFC1123) 1658 0 R (cite.RFC1183) 1618 0 R (cite.RFC1464) 1696 0 R (cite.RFC1535) 1604 0 R (cite.RFC1536) 1606 0 R (cite.RFC1537) 1676 0 R (cite.RFC1591) 1660 0 R (cite.RFC1706) 1620 0 R (cite.RFC1712) 1716 0 R (cite.RFC1713) 1698 0 R (cite.RFC1794) 1700 0 R (cite.RFC1876) 1622 0 R (cite.RFC1912) 1678 0 R (cite.RFC1982) 1608 0 R (cite.RFC1995) 1566 0 R (cite.RFC1996) 1568 0 R (cite.RFC2010) 1680 0 R (cite.RFC2052) 1624 0 R (cite.RFC2065) 1728 0 R (cite.RFC2136) 1570 0 R (cite.RFC2137) 1730 0 R (cite.RFC2163) 1626 0 R (cite.RFC2168) 1628 0 R (cite.RFC2181) 1572 0 R (cite.RFC2219) 1682 0 R (cite.RFC2230) 1630 0 R (cite.RFC2240) 1702 0 R (cite.RFC2308) 1574 0 R (cite.RFC2317) 1662 0 R (cite.RFC2345) 1704 0 R (cite.RFC2352) 1706 0 R (cite.RFC2535) 1732 0 R (cite.RFC2536) 1632 0 R (cite.RFC2537) 1634 0 R (cite.RFC2538) 1636 0 R (cite.RFC2539) 1638 0 R (cite.RFC2540) 1640 0 R (cite.RFC2671) 1576 0 R (cite.RFC2672) 1578 0 R (cite.RFC2673) 1718 0 R (cite.RFC2782) 1642 0 R (cite.RFC2825) 1686 0 R (cite.RFC2826) 1664 0 R (cite.RFC2845) 1580 0 R (cite.RFC2874) 1720 0 R (cite.RFC2915) 1644 0 R (cite.RFC2929) 1666 0 R (cite.RFC2930) 1582 0 R (cite.RFC2931) 1584 0 R (cite.RFC3007) 1586 0 R (cite.RFC3008) 1734 0 R (cite.RFC3071) 1708 0 R (cite.RFC3090) 1736 0 R (cite.RFC3110) 1646 0 R (cite.RFC3123) 1648 0 R (cite.RFC3225) 1592 0 R (cite.RFC3258) 1710 0 R (cite.RFC3445) 1738 0 R (cite.RFC3490) 1688 0 R (cite.RFC3491) 1690 0 R (cite.RFC3492) 1692 0 R (cite.RFC3596) 1650 0 R (cite.RFC3597) 1652 0 R (cite.RFC3645) 1588 0 R (cite.RFC3655) 1740 0 R (cite.RFC3658) 1742 0 R (cite.RFC3755) 1744 0 R (cite.RFC3757) 1746 0 R (cite.RFC3833) 1594 0 R (cite.RFC3845) 1748 0 R (cite.RFC3901) 1712 0 R (cite.RFC4033) 1596 0 R (cite.RFC4034) 1598 0 R (cite.RFC4035) 1600 0 R (cite.RFC4074) 1610 0 R (cite.RFC974) 1563 0 R (cite.id2500874) 1753 0 R (configuration_file_elements) 1094 0 R (controls_statement_definition_and_usage) 981 0 R (diagnostic_tools) 916 0 R (dynamic_update) 1004 0 R (dynamic_update_policies) 1056 0 R (dynamic_update_security) 1252 0 R (empty) 1324 0 R (historical_dns_information) 1540 0 R (id2466552) 880 0 R (id2466576) 881 0 R (id2467377) 1095 0 R (id2467534) 885 0 R (id2467544) 886 0 R (id2467716) 898 0 R (id2467737) 899 0 R (id2467771) 900 0 R (id2467856) 903 0 R (id2467948) 896 0 R (id2470253) 910 0 R (id2470277) 913 0 R (id2470375) 914 0 R (id2470396) 915 0 R (id2470426) 921 0 R (id2470530) 922 0 R (id2470556) 923 0 R (id2470590) 929 0 R (id2470617) 930 0 R (id2470630) 931 0 R (id2470724) 934 0 R (id2470734) 940 0 R (id2470766) 947 0 R (id2470782) 948 0 R (id2470805) 954 0 R (id2470822) 955 0 R (id2471159) 958 0 R (id2471164) 959 0 R (id2472979) 986 0 R (id2472990) 987 0 R (id2473374) 1019 0 R (id2473393) 1020 0 R (id2473828) 1036 0 R (id2473845) 1037 0 R (id2473883) 1042 0 R (id2473901) 1043 0 R (id2473912) 1044 0 R (id2474023) 1045 0 R (id2474149) 1046 0 R (id2474265) 1052 0 R (id2474279) 1053 0 R (id2474328) 1054 0 R (id2474465) 1062 0 R (id2474534) 1063 0 R (id2474613) 1068 0 R (id2474759) 1073 0 R (id2474889) 1075 0 R (id2474910) 1076 0 R (id2475012) 1083 0 R (id2476222) 1104 0 R (id2476250) 1109 0 R (id2476361) 1110 0 R (id2476444) 1111 0 R (id2476474) 1112 0 R (id2476549) 1119 0 R (id2476965) 1125 0 R (id2477076) 1127 0 R (id2477291) 1129 0 R (id2477652) 1136 0 R (id2477669) 1137 0 R (id2477692) 1138 0 R (id2477716) 1144 0 R (id2477943) 1148 0 R (id2478069) 1149 0 R (id2478121) 1155 0 R (id2478746) 1166 0 R (id2479514) 1172 0 R (id2479576) 1177 0 R (id2479965) 1179 0 R (id2480039) 1184 0 R (id2480103) 1187 0 R (id2480215) 1188 0 R (id2480230) 1189 0 R (id2482243) 1214 0 R (id2484179) 1240 0 R (id2484237) 1242 0 R (id2484737) 1257 0 R (id2485670) 1276 0 R (id2485798) 1278 0 R (id2486357) 1286 0 R (id2486856) 1305 0 R (id2488061) 1334 0 R (id2489252) 1352 0 R (id2489303) 1353 0 R (id2489453) 1355 0 R (id2490790) 1372 0 R (id2490797) 1373 0 R (id2490803) 1374 0 R (id2491293) 1382 0 R (id2491395) 1383 0 R (id2492864) 1431 0 R (id2493121) 1437 0 R (id2493139) 1438 0 R (id2493159) 1441 0 R (id2493396) 1443 0 R (id2494496) 1454 0 R (id2494624) 1456 0 R (id2494645) 1457 0 R (id2495076) 1463 0 R (id2495212) 1465 0 R (id2495230) 1466 0 R (id2495703) 1469 0 R (id2495828) 1475 0 R (id2495843) 1476 0 R (id2495955) 1478 0 R (id2495977) 1479 0 R (id2496038) 1484 0 R (id2496107) 1485 0 R (id2496144) 1486 0 R (id2496205) 1487 0 R (id2496821) 1508 0 R (id2496902) 1509 0 R (id2497030) 1510 0 R (id2497110) 1524 0 R (id2497115) 1525 0 R (id2497264) 1526 0 R (id2497281) 1527 0 R (id2497411) 1539 0 R (id2497582) 1546 0 R (id2497770) 1551 0 R (id2497772) 1557 0 R (id2497781) 1562 0 R (id2497804) 1558 0 R (id2497828) 1560 0 R (id2497864) 1571 0 R (id2497891) 1573 0 R (id2497916) 1565 0 R (id2497941) 1567 0 R (id2497964) 1569 0 R (id2498020) 1575 0 R (id2498046) 1577 0 R (id2498073) 1579 0 R (id2498135) 1581 0 R (id2498165) 1583 0 R (id2498195) 1585 0 R (id2498221) 1587 0 R (id2498296) 1590 0 R (id2498304) 1591 0 R (id2498330) 1593 0 R (id2498366) 1595 0 R (id2498432) 1597 0 R (id2498497) 1599 0 R (id2498562) 1602 0 R (id2498570) 1603 0 R (id2498596) 1605 0 R (id2498664) 1607 0 R (id2498699) 1609 0 R (id2498740) 1616 0 R (id2498745) 1617 0 R (id2498803) 1619 0 R (id2498840) 1627 0 R (id2498875) 1621 0 R (id2498930) 1623 0 R (id2498968) 1625 0 R (id2498994) 1629 0 R (id2499019) 1631 0 R (id2499046) 1633 0 R (id2499073) 1635 0 R (id2499112) 1637 0 R (id2499142) 1639 0 R (id2499172) 1641 0 R (id2499214) 1643 0 R (id2499248) 1645 0 R (id2499274) 1647 0 R (id2499298) 1649 0 R (id2499355) 1651 0 R (id2499380) 1654 0 R (id2499387) 1655 0 R (id2499413) 1657 0 R (id2499435) 1659 0 R (id2499459) 1661 0 R (id2499505) 1663 0 R (id2499528) 1665 0 R (id2499578) 1672 0 R (id2499654) 1673 0 R (id2499677) 1675 0 R (id2499704) 1677 0 R (id2499731) 1679 0 R (id2499767) 1681 0 R (id2499808) 1684 0 R (id2499813) 1685 0 R (id2499845) 1687 0 R (id2499891) 1689 0 R (id2499926) 1691 0 R (id2499953) 1694 0 R (id2499971) 1695 0 R (id2500061) 1697 0 R (id2500087) 1699 0 R (id2500113) 1701 0 R (id2500136) 1703 0 R (id2500182) 1705 0 R (id2500205) 1707 0 R (id2500232) 1709 0 R (id2500258) 1711 0 R (id2500295) 1714 0 R (id2500301) 1715 0 R (id2500359) 1717 0 R (id2500386) 1719 0 R (id2500422) 1726 0 R (id2500434) 1727 0 R (id2500473) 1729 0 R (id2500500) 1731 0 R (id2500530) 1733 0 R (id2500555) 1735 0 R (id2500582) 1737 0 R (id2500686) 1739 0 R (id2500723) 1741 0 R (id2500749) 1743 0 R (id2500776) 1745 0 R (id2500821) 1747 0 R (id2500862) 1750 0 R (id2500872) 1752 0 R (id2500874) 1754 0 R (incremental_zone_transfers) 1016 0 R (internet_drafts) 1749 0 R (ipv6addresses) 1077 0 R (journal) 1005 0 R (lwresd) 1084 0 R (man.dig) 1760 0 R (man.dnssec-keygen) 1809 0 R (man.dnssec-signzone) 1826 0 R (man.host) 1793 0 R (man.named) 1875 0 R (man.named-checkconf) 1846 0 R (man.named-checkzone) 1859 0 R (man.rndc) 1897 0 R (man.rndc-confgen) 1930 0 R (man.rndc.conf) 1910 0 R (notify) 995 0 R (options) 1203 0 R (page.1) 658 0 R (page.10) 920 0 R (page.100) 1779 0 R (page.101) 1783 0 R (page.102) 1788 0 R (page.103) 1800 0 R (page.104) 1805 0 R (page.105) 1817 0 R (page.106) 1822 0 R (page.107) 1833 0 R (page.108) 1838 0 R (page.109) 1843 0 R (page.11) 927 0 R (page.110) 1855 0 R (page.111) 1867 0 R (page.112) 1871 0 R (page.113) 1882 0 R (page.114) 1887 0 R (page.115) 1892 0 R (page.116) 1905 0 R (page.117) 1915 0 R (page.118) 1922 0 R (page.119) 1929 0 R (page.12) 939 0 R (page.120) 1938 0 R (page.13) 944 0 R (page.14) 953 0 R (page.15) 964 0 R (page.16) 972 0 R (page.17) 979 0 R (page.18) 985 0 R (page.19) 993 0 R (page.2) 683 0 R (page.20) 1015 0 R (page.21) 1025 0 R (page.22) 1030 0 R (page.23) 1034 0 R (page.24) 1041 0 R (page.25) 1050 0 R (page.26) 1060 0 R (page.27) 1067 0 R (page.28) 1072 0 R (page.29) 1081 0 R (page.3) 693 0 R (page.30) 1088 0 R (page.31) 1092 0 R (page.32) 1103 0 R (page.33) 1108 0 R (page.34) 1117 0 R (page.35) 1124 0 R (page.36) 1133 0 R (page.37) 1143 0 R (page.38) 1154 0 R (page.39) 1159 0 R (page.4) 748 0 R (page.40) 1165 0 R (page.41) 1171 0 R (page.42) 1176 0 R (page.43) 1183 0 R (page.44) 1194 0 R (page.45) 1198 0 R (page.46) 1202 0 R (page.47) 1207 0 R (page.48) 1213 0 R (page.49) 1219 0 R (page.5) 812 0 R (page.50) 1225 0 R (page.51) 1235 0 R (page.52) 1239 0 R (page.53) 1247 0 R (page.54) 1256 0 R (page.55) 1262 0 R (page.56) 1267 0 R (page.57) 1271 0 R (page.58) 1275 0 R (page.59) 1283 0 R (page.6) 874 0 R (page.60) 1290 0 R (page.61) 1295 0 R (page.62) 1303 0 R (page.63) 1311 0 R (page.64) 1318 0 R (page.65) 1329 0 R (page.66) 1333 0 R (page.67) 1339 0 R (page.68) 1345 0 R (page.69) 1351 0 R (page.7) 878 0 R (page.70) 1359 0 R (page.71) 1363 0 R (page.72) 1367 0 R (page.73) 1371 0 R (page.74) 1380 0 R (page.75) 1394 0 R (page.76) 1406 0 R (page.77) 1428 0 R (page.78) 1436 0 R (page.79) 1448 0 R (page.8) 895 0 R (page.80) 1453 0 R (page.81) 1462 0 R (page.82) 1474 0 R (page.83) 1483 0 R (page.84) 1492 0 R (page.85) 1496 0 R (page.86) 1503 0 R (page.87) 1514 0 R (page.88) 1518 0 R (page.89) 1522 0 R (page.9) 909 0 R (page.90) 1533 0 R (page.91) 1537 0 R (page.92) 1545 0 R (page.93) 1555 0 R (page.94) 1614 0 R (page.95) 1670 0 R (page.96) 1724 0 R (page.97) 1758 0 R (page.98) 1768 0 R (page.99) 1774 0 R (proposed_standards) 1021 0 R (query_address) 1258 0 R (rfcs) 905 0 R (rndc) 1139 0 R (root_delegation_only) 1390 0 R (rrset_ordering) 960 0 R (sample_configuration) 946 0 R (section*.10) 1683 0 R (section*.11) 1693 0 R (section*.12) 1713 0 R (section*.13) 1725 0 R (section*.14) 1751 0 R (section*.15) 1761 0 R (section*.16) 1762 0 R (section*.17) 1763 0 R (section*.18) 1769 0 R (section*.19) 1770 0 R (section*.2) 1550 0 R (section*.20) 1775 0 R (section*.21) 1784 0 R (section*.22) 1789 0 R (section*.23) 1790 0 R (section*.24) 1791 0 R (section*.25) 1792 0 R (section*.26) 1794 0 R (section*.27) 1795 0 R (section*.28) 1796 0 R (section*.29) 1806 0 R (section*.3) 1556 0 R (section*.30) 1807 0 R (section*.31) 1808 0 R (section*.32) 1810 0 R (section*.33) 1811 0 R (section*.34) 1812 0 R (section*.35) 1813 0 R (section*.36) 1818 0 R (section*.37) 1823 0 R (section*.38) 1824 0 R (section*.39) 1825 0 R (section*.4) 1564 0 R (section*.40) 1827 0 R (section*.41) 1828 0 R (section*.42) 1829 0 R (section*.43) 1834 0 R (section*.44) 1839 0 R (section*.45) 1844 0 R (section*.46) 1845 0 R (section*.47) 1847 0 R (section*.48) 1848 0 R (section*.49) 1849 0 R (section*.5) 1589 0 R (section*.50) 1850 0 R (section*.51) 1856 0 R (section*.52) 1857 0 R (section*.53) 1858 0 R (section*.54) 1860 0 R (section*.55) 1861 0 R (section*.56) 1862 0 R (section*.57) 1863 0 R (section*.58) 1872 0 R (section*.59) 1873 0 R (section*.6) 1601 0 R (section*.60) 1874 0 R (section*.61) 1876 0 R (section*.62) 1877 0 R (section*.63) 1878 0 R (section*.64) 1883 0 R (section*.65) 1888 0 R (section*.66) 1893 0 R (section*.67) 1894 0 R (section*.68) 1895 0 R (section*.69) 1896 0 R (section*.7) 1615 0 R (section*.70) 1898 0 R (section*.71) 1899 0 R (section*.72) 1900 0 R (section*.73) 1906 0 R (section*.74) 1907 0 R (section*.75) 1908 0 R (section*.76) 1909 0 R (section*.77) 1911 0 R (section*.78) 1916 0 R (section*.79) 1917 0 R (section*.8) 1653 0 R (section*.80) 1918 0 R (section*.81) 1923 0 R (section*.82) 1924 0 R (section*.83) 1925 0 R (section*.84) 1931 0 R (section*.85) 1932 0 R (section*.86) 1933 0 R (section*.87) 1934 0 R (section*.88) 1939 0 R (section*.89) 1940 0 R (section*.9) 1671 0 R (section*.90) 1941 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 478 0 R (section.7.1) 534 0 R (section.7.2) 538 0 R (section.7.3) 550 0 R (section.8.1) 558 0 R (section.8.2) 566 0 R (section.8.3) 570 0 R (section.A.1) 578 0 R (section.A.2) 586 0 R (section.A.3) 594 0 R (section.B.1) 614 0 R (section.B.10) 650 0 R (section.B.2) 618 0 R (section.B.3) 622 0 R (section.B.4) 626 0 R (section.B.5) 630 0 R (section.B.6) 634 0 R (section.B.7) 638 0 R (section.B.8) 642 0 R (section.B.9) 646 0 R (server_resource_limits) 1284 0 R (server_statement_definition_and_usage) 1231 0 R (server_statement_grammar) 1340 0 R (statsfile) 1209 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.7.2.1) 542 0 R (subsection.7.2.2) 546 0 R (subsection.8.1.1) 562 0 R (subsection.A.1.1) 582 0 R (subsection.A.2.1) 590 0 R (subsection.A.3.1) 598 0 R (subsection.A.3.2) 602 0 R (subsection.A.3.3) 606 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.24.1) 462 0 R (subsubsection.6.2.24.2) 466 0 R (subsubsection.6.2.24.3) 470 0 R (subsubsection.6.2.24.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (table.1.1) 887 0 R (table.1.2) 897 0 R (table.3.1) 956 0 R (table.3.2) 988 0 R (table.6.1) 1096 0 R (table.6.10) 1432 0 R (table.6.11) 1442 0 R (table.6.12) 1444 0 R (table.6.13) 1455 0 R (table.6.14) 1458 0 R (table.6.15) 1464 0 R (table.6.16) 1467 0 R (table.6.17) 1470 0 R (table.6.18) 1477 0 R (table.6.19) 1488 0 R (table.6.2) 1120 0 R (table.6.3) 1128 0 R (table.6.4) 1167 0 R (table.6.5) 1178 0 R (table.6.6) 1215 0 R (table.6.7) 1306 0 R (table.6.8) 1335 0 R (table.6.9) 1375 0 R (the_category_phrase) 1161 0 R (the_sortlist_statement) 1296 0 R (topology) 1291 0 R (tsig) 1035 0 R (tuning) 1307 0 R (types_of_resource_records_and_when_to_use_them) 904 0 R (view_statement_grammar) 1325 0 R (zone_statement_grammar) 1243 0 R (zone_transfers) 1011 0 R (zonefile_format) 1314 0 R]
+/Names [(Access_Control_Lists) 1498 0 R (Bv9ARM.ch01) 879 0 R (Bv9ARM.ch02) 928 0 R (Bv9ARM.ch03) 945 0 R (Bv9ARM.ch04) 994 0 R (Bv9ARM.ch05) 1082 0 R (Bv9ARM.ch06) 1093 0 R (Bv9ARM.ch07) 1497 0 R (Bv9ARM.ch08) 1523 0 R (Bv9ARM.ch09) 1538 0 R (Bv9ARM.ch10) 1759 0 R (Configuration_File_Grammar) 1118 0 R (DNSSEC) 1061 0 R (Doc-Start) 659 0 R (Setting_TTLs) 1468 0 R (acache) 935 0 R (access_control) 1248 0 R (acl) 1126 0 R (address_match_lists) 1099 0 R (admin_tools) 968 0 R (appendix.A) 574 0 R (appendix.B) 610 0 R (bibliography) 1547 0 R (boolean_options) 1010 0 R (builtin) 1322 0 R (chapter*.1) 694 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 530 0 R (chapter.8) 554 0 R (cite.RFC1033) 1674 0 R (cite.RFC1034) 1559 0 R (cite.RFC1035) 1561 0 R (cite.RFC1101) 1656 0 R (cite.RFC1123) 1658 0 R (cite.RFC1183) 1618 0 R (cite.RFC1464) 1696 0 R (cite.RFC1535) 1604 0 R (cite.RFC1536) 1606 0 R (cite.RFC1537) 1676 0 R (cite.RFC1591) 1660 0 R (cite.RFC1706) 1620 0 R (cite.RFC1712) 1716 0 R (cite.RFC1713) 1698 0 R (cite.RFC1794) 1700 0 R (cite.RFC1876) 1622 0 R (cite.RFC1912) 1678 0 R (cite.RFC1982) 1608 0 R (cite.RFC1995) 1566 0 R (cite.RFC1996) 1568 0 R (cite.RFC2010) 1680 0 R (cite.RFC2052) 1624 0 R (cite.RFC2065) 1728 0 R (cite.RFC2136) 1570 0 R (cite.RFC2137) 1730 0 R (cite.RFC2163) 1626 0 R (cite.RFC2168) 1628 0 R (cite.RFC2181) 1572 0 R (cite.RFC2219) 1682 0 R (cite.RFC2230) 1630 0 R (cite.RFC2240) 1702 0 R (cite.RFC2308) 1574 0 R (cite.RFC2317) 1662 0 R (cite.RFC2345) 1704 0 R (cite.RFC2352) 1706 0 R (cite.RFC2535) 1732 0 R (cite.RFC2536) 1632 0 R (cite.RFC2537) 1634 0 R (cite.RFC2538) 1636 0 R (cite.RFC2539) 1638 0 R (cite.RFC2540) 1640 0 R (cite.RFC2671) 1576 0 R (cite.RFC2672) 1578 0 R (cite.RFC2673) 1718 0 R (cite.RFC2782) 1642 0 R (cite.RFC2825) 1686 0 R (cite.RFC2826) 1664 0 R (cite.RFC2845) 1580 0 R (cite.RFC2874) 1720 0 R (cite.RFC2915) 1644 0 R (cite.RFC2929) 1666 0 R (cite.RFC2930) 1582 0 R (cite.RFC2931) 1584 0 R (cite.RFC3007) 1586 0 R (cite.RFC3008) 1734 0 R (cite.RFC3071) 1708 0 R (cite.RFC3090) 1736 0 R (cite.RFC3110) 1646 0 R (cite.RFC3123) 1648 0 R (cite.RFC3225) 1592 0 R (cite.RFC3258) 1710 0 R (cite.RFC3445) 1738 0 R (cite.RFC3490) 1688 0 R (cite.RFC3491) 1690 0 R (cite.RFC3492) 1692 0 R (cite.RFC3596) 1650 0 R (cite.RFC3597) 1652 0 R (cite.RFC3645) 1588 0 R (cite.RFC3655) 1740 0 R (cite.RFC3658) 1742 0 R (cite.RFC3755) 1744 0 R (cite.RFC3757) 1746 0 R (cite.RFC3833) 1594 0 R (cite.RFC3845) 1748 0 R (cite.RFC3901) 1712 0 R (cite.RFC4033) 1596 0 R (cite.RFC4034) 1598 0 R (cite.RFC4035) 1600 0 R (cite.RFC4074) 1610 0 R (cite.RFC974) 1563 0 R (cite.id2500881) 1753 0 R (configuration_file_elements) 1094 0 R (controls_statement_definition_and_usage) 981 0 R (diagnostic_tools) 916 0 R (dynamic_update) 1004 0 R (dynamic_update_policies) 1056 0 R (dynamic_update_security) 1252 0 R (empty) 1324 0 R (historical_dns_information) 1540 0 R (id2466555) 880 0 R (id2466579) 881 0 R (id2467538) 885 0 R (id2467547) 886 0 R (id2467719) 898 0 R (id2467740) 899 0 R (id2467774) 900 0 R (id2467859) 903 0 R (id2467952) 896 0 R (id2470257) 910 0 R (id2470280) 913 0 R (id2470378) 914 0 R (id2470400) 915 0 R (id2470429) 921 0 R (id2470533) 922 0 R (id2470560) 923 0 R (id2470594) 929 0 R (id2470620) 930 0 R (id2470633) 931 0 R (id2470727) 934 0 R (id2470738) 940 0 R (id2470770) 947 0 R (id2470786) 948 0 R (id2470808) 954 0 R (id2470825) 955 0 R (id2471162) 958 0 R (id2471168) 959 0 R (id2473118) 986 0 R (id2473130) 987 0 R (id2473514) 1019 0 R (id2473532) 1020 0 R (id2473968) 1036 0 R (id2473985) 1037 0 R (id2474023) 1042 0 R (id2474041) 1043 0 R (id2474120) 1044 0 R (id2474163) 1045 0 R (id2474220) 1046 0 R (id2474405) 1052 0 R (id2474419) 1053 0 R (id2474468) 1054 0 R (id2474604) 1062 0 R (id2474674) 1063 0 R (id2474753) 1068 0 R (id2474899) 1073 0 R (id2475029) 1075 0 R (id2475050) 1076 0 R (id2475152) 1083 0 R (id2475299) 1095 0 R (id2476226) 1104 0 R (id2476253) 1109 0 R (id2476364) 1110 0 R (id2476448) 1111 0 R (id2476477) 1112 0 R (id2476552) 1119 0 R (id2476968) 1125 0 R (id2477079) 1127 0 R (id2477294) 1129 0 R (id2477655) 1136 0 R (id2477672) 1137 0 R (id2477696) 1138 0 R (id2477719) 1144 0 R (id2477946) 1148 0 R (id2478072) 1149 0 R (id2478124) 1155 0 R (id2478749) 1166 0 R (id2479517) 1172 0 R (id2479579) 1177 0 R (id2479969) 1179 0 R (id2480110) 1184 0 R (id2480174) 1187 0 R (id2480218) 1188 0 R (id2480233) 1189 0 R (id2482519) 1214 0 R (id2484182) 1240 0 R (id2484241) 1242 0 R (id2484740) 1257 0 R (id2485673) 1276 0 R (id2485801) 1278 0 R (id2486292) 1286 0 R (id2486791) 1305 0 R (id2488000) 1334 0 R (id2489258) 1352 0 R (id2489309) 1353 0 R (id2489460) 1355 0 R (id2490796) 1372 0 R (id2490804) 1373 0 R (id2490809) 1374 0 R (id2491300) 1382 0 R (id2491401) 1383 0 R (id2492802) 1431 0 R (id2493059) 1437 0 R (id2493077) 1438 0 R (id2493097) 1441 0 R (id2493334) 1443 0 R (id2494365) 1454 0 R (id2494562) 1456 0 R (id2494583) 1457 0 R (id2495014) 1463 0 R (id2495150) 1465 0 R (id2495169) 1466 0 R (id2495641) 1469 0 R (id2495766) 1475 0 R (id2495781) 1476 0 R (id2495961) 1478 0 R (id2495984) 1479 0 R (id2496113) 1484 0 R (id2496182) 1485 0 R (id2496218) 1486 0 R (id2496280) 1487 0 R (id2496827) 1508 0 R (id2496908) 1509 0 R (id2496968) 1510 0 R (id2497116) 1524 0 R (id2497122) 1525 0 R (id2497202) 1526 0 R (id2497219) 1527 0 R (id2497417) 1539 0 R (id2497521) 1546 0 R (id2497708) 1551 0 R (id2497710) 1557 0 R (id2497719) 1562 0 R (id2497811) 1558 0 R (id2497834) 1560 0 R (id2497870) 1571 0 R (id2497897) 1573 0 R (id2497923) 1565 0 R (id2497947) 1567 0 R (id2497971) 1569 0 R (id2498026) 1575 0 R (id2498053) 1577 0 R (id2498080) 1579 0 R (id2498141) 1581 0 R (id2498171) 1583 0 R (id2498201) 1585 0 R (id2498228) 1587 0 R (id2498302) 1590 0 R (id2498310) 1591 0 R (id2498337) 1593 0 R (id2498373) 1595 0 R (id2498438) 1597 0 R (id2498503) 1599 0 R (id2498568) 1602 0 R (id2498577) 1603 0 R (id2498602) 1605 0 R (id2498670) 1607 0 R (id2498706) 1609 0 R (id2498746) 1616 0 R (id2498752) 1617 0 R (id2498809) 1619 0 R (id2498846) 1627 0 R (id2498882) 1621 0 R (id2498936) 1623 0 R (id2498974) 1625 0 R (id2499000) 1629 0 R (id2499026) 1631 0 R (id2499052) 1633 0 R (id2499079) 1635 0 R (id2499118) 1637 0 R (id2499148) 1639 0 R (id2499178) 1641 0 R (id2499221) 1643 0 R (id2499254) 1645 0 R (id2499281) 1647 0 R (id2499304) 1649 0 R (id2499362) 1651 0 R (id2499386) 1654 0 R (id2499394) 1655 0 R (id2499419) 1657 0 R (id2499442) 1659 0 R (id2499465) 1661 0 R (id2499511) 1663 0 R (id2499534) 1665 0 R (id2499653) 1672 0 R (id2499660) 1673 0 R (id2499684) 1675 0 R (id2499710) 1677 0 R (id2499737) 1679 0 R (id2499773) 1681 0 R (id2499814) 1684 0 R (id2499819) 1685 0 R (id2499851) 1687 0 R (id2499897) 1689 0 R (id2499932) 1691 0 R (id2499959) 1694 0 R (id2499977) 1695 0 R (id2500068) 1697 0 R (id2500093) 1699 0 R (id2500119) 1701 0 R (id2500142) 1703 0 R (id2500188) 1705 0 R (id2500212) 1707 0 R (id2500238) 1709 0 R (id2500264) 1711 0 R (id2500301) 1714 0 R (id2500308) 1715 0 R (id2500365) 1717 0 R (id2500392) 1719 0 R (id2500428) 1726 0 R (id2500440) 1727 0 R (id2500480) 1729 0 R (id2500506) 1731 0 R (id2500536) 1733 0 R (id2500562) 1735 0 R (id2500588) 1737 0 R (id2500693) 1739 0 R (id2500729) 1741 0 R (id2500756) 1743 0 R (id2500782) 1745 0 R (id2500827) 1747 0 R (id2500869) 1750 0 R (id2500878) 1752 0 R (id2500881) 1754 0 R (incremental_zone_transfers) 1016 0 R (internet_drafts) 1749 0 R (ipv6addresses) 1077 0 R (journal) 1005 0 R (lwresd) 1084 0 R (man.dig) 1760 0 R (man.dnssec-keygen) 1809 0 R (man.dnssec-signzone) 1826 0 R (man.host) 1793 0 R (man.named) 1875 0 R (man.named-checkconf) 1846 0 R (man.named-checkzone) 1859 0 R (man.rndc) 1897 0 R (man.rndc-confgen) 1930 0 R (man.rndc.conf) 1910 0 R (notify) 995 0 R (options) 1203 0 R (page.1) 658 0 R (page.10) 920 0 R (page.100) 1779 0 R (page.101) 1783 0 R (page.102) 1788 0 R (page.103) 1800 0 R (page.104) 1805 0 R (page.105) 1817 0 R (page.106) 1822 0 R (page.107) 1833 0 R (page.108) 1838 0 R (page.109) 1843 0 R (page.11) 927 0 R (page.110) 1855 0 R (page.111) 1867 0 R (page.112) 1871 0 R (page.113) 1882 0 R (page.114) 1887 0 R (page.115) 1892 0 R (page.116) 1905 0 R (page.117) 1915 0 R (page.118) 1922 0 R (page.119) 1929 0 R (page.12) 939 0 R (page.120) 1938 0 R (page.13) 944 0 R (page.14) 953 0 R (page.15) 964 0 R (page.16) 972 0 R (page.17) 979 0 R (page.18) 985 0 R (page.19) 993 0 R (page.2) 683 0 R (page.20) 1015 0 R (page.21) 1025 0 R (page.22) 1030 0 R (page.23) 1034 0 R (page.24) 1041 0 R (page.25) 1050 0 R (page.26) 1060 0 R (page.27) 1067 0 R (page.28) 1072 0 R (page.29) 1081 0 R (page.3) 693 0 R (page.30) 1088 0 R (page.31) 1092 0 R (page.32) 1103 0 R (page.33) 1108 0 R (page.34) 1117 0 R (page.35) 1124 0 R (page.36) 1133 0 R (page.37) 1143 0 R (page.38) 1154 0 R (page.39) 1159 0 R (page.4) 748 0 R (page.40) 1165 0 R (page.41) 1171 0 R (page.42) 1176 0 R (page.43) 1183 0 R (page.44) 1194 0 R (page.45) 1198 0 R (page.46) 1202 0 R (page.47) 1207 0 R (page.48) 1213 0 R (page.49) 1219 0 R (page.5) 812 0 R (page.50) 1225 0 R (page.51) 1235 0 R (page.52) 1239 0 R (page.53) 1247 0 R (page.54) 1256 0 R (page.55) 1262 0 R (page.56) 1267 0 R (page.57) 1271 0 R (page.58) 1275 0 R (page.59) 1283 0 R (page.6) 874 0 R (page.60) 1290 0 R (page.61) 1295 0 R (page.62) 1303 0 R (page.63) 1311 0 R (page.64) 1318 0 R (page.65) 1329 0 R (page.66) 1333 0 R (page.67) 1339 0 R (page.68) 1345 0 R (page.69) 1351 0 R (page.7) 878 0 R (page.70) 1359 0 R (page.71) 1363 0 R (page.72) 1367 0 R (page.73) 1371 0 R (page.74) 1380 0 R (page.75) 1394 0 R (page.76) 1406 0 R (page.77) 1428 0 R (page.78) 1436 0 R (page.79) 1448 0 R (page.8) 895 0 R (page.80) 1453 0 R (page.81) 1462 0 R (page.82) 1474 0 R (page.83) 1483 0 R (page.84) 1492 0 R (page.85) 1496 0 R (page.86) 1503 0 R (page.87) 1514 0 R (page.88) 1518 0 R (page.89) 1522 0 R (page.9) 909 0 R (page.90) 1533 0 R (page.91) 1537 0 R (page.92) 1545 0 R (page.93) 1555 0 R (page.94) 1614 0 R (page.95) 1670 0 R (page.96) 1724 0 R (page.97) 1758 0 R (page.98) 1768 0 R (page.99) 1774 0 R (proposed_standards) 1021 0 R (query_address) 1258 0 R (rfcs) 905 0 R (rndc) 1139 0 R (root_delegation_only) 1390 0 R (rrset_ordering) 960 0 R (sample_configuration) 946 0 R (section*.10) 1683 0 R (section*.11) 1693 0 R (section*.12) 1713 0 R (section*.13) 1725 0 R (section*.14) 1751 0 R (section*.15) 1761 0 R (section*.16) 1762 0 R (section*.17) 1763 0 R (section*.18) 1769 0 R (section*.19) 1770 0 R (section*.2) 1550 0 R (section*.20) 1775 0 R (section*.21) 1784 0 R (section*.22) 1789 0 R (section*.23) 1790 0 R (section*.24) 1791 0 R (section*.25) 1792 0 R (section*.26) 1794 0 R (section*.27) 1795 0 R (section*.28) 1796 0 R (section*.29) 1806 0 R (section*.3) 1556 0 R (section*.30) 1807 0 R (section*.31) 1808 0 R (section*.32) 1810 0 R (section*.33) 1811 0 R (section*.34) 1812 0 R (section*.35) 1813 0 R (section*.36) 1818 0 R (section*.37) 1823 0 R (section*.38) 1824 0 R (section*.39) 1825 0 R (section*.4) 1564 0 R (section*.40) 1827 0 R (section*.41) 1828 0 R (section*.42) 1829 0 R (section*.43) 1834 0 R (section*.44) 1839 0 R (section*.45) 1844 0 R (section*.46) 1845 0 R (section*.47) 1847 0 R (section*.48) 1848 0 R (section*.49) 1849 0 R (section*.5) 1589 0 R (section*.50) 1850 0 R (section*.51) 1856 0 R (section*.52) 1857 0 R (section*.53) 1858 0 R (section*.54) 1860 0 R (section*.55) 1861 0 R (section*.56) 1862 0 R (section*.57) 1863 0 R (section*.58) 1872 0 R (section*.59) 1873 0 R (section*.6) 1601 0 R (section*.60) 1874 0 R (section*.61) 1876 0 R (section*.62) 1877 0 R (section*.63) 1878 0 R (section*.64) 1883 0 R (section*.65) 1888 0 R (section*.66) 1893 0 R (section*.67) 1894 0 R (section*.68) 1895 0 R (section*.69) 1896 0 R (section*.7) 1615 0 R (section*.70) 1898 0 R (section*.71) 1899 0 R (section*.72) 1900 0 R (section*.73) 1906 0 R (section*.74) 1907 0 R (section*.75) 1908 0 R (section*.76) 1909 0 R (section*.77) 1911 0 R (section*.78) 1916 0 R (section*.79) 1917 0 R (section*.8) 1653 0 R (section*.80) 1918 0 R (section*.81) 1923 0 R (section*.82) 1924 0 R (section*.83) 1925 0 R (section*.84) 1931 0 R (section*.85) 1932 0 R (section*.86) 1933 0 R (section*.87) 1934 0 R (section*.88) 1939 0 R (section*.89) 1940 0 R (section*.9) 1671 0 R (section*.90) 1941 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 478 0 R (section.7.1) 534 0 R (section.7.2) 538 0 R (section.7.3) 550 0 R (section.8.1) 558 0 R (section.8.2) 566 0 R (section.8.3) 570 0 R (section.A.1) 578 0 R (section.A.2) 586 0 R (section.A.3) 594 0 R (section.B.1) 614 0 R (section.B.10) 650 0 R (section.B.2) 618 0 R (section.B.3) 622 0 R (section.B.4) 626 0 R (section.B.5) 630 0 R (section.B.6) 634 0 R (section.B.7) 638 0 R (section.B.8) 642 0 R (section.B.9) 646 0 R (server_resource_limits) 1284 0 R (server_statement_definition_and_usage) 1231 0 R (server_statement_grammar) 1340 0 R (statsfile) 1209 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.7.2.1) 542 0 R (subsection.7.2.2) 546 0 R (subsection.8.1.1) 562 0 R (subsection.A.1.1) 582 0 R (subsection.A.2.1) 590 0 R (subsection.A.3.1) 598 0 R (subsection.A.3.2) 602 0 R (subsection.A.3.3) 606 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.24.1) 462 0 R (subsubsection.6.2.24.2) 466 0 R (subsubsection.6.2.24.3) 470 0 R (subsubsection.6.2.24.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (table.1.1) 887 0 R (table.1.2) 897 0 R (table.3.1) 956 0 R (table.3.2) 988 0 R (table.6.1) 1096 0 R (table.6.10) 1432 0 R (table.6.11) 1442 0 R (table.6.12) 1444 0 R (table.6.13) 1455 0 R (table.6.14) 1458 0 R (table.6.15) 1464 0 R (table.6.16) 1467 0 R (table.6.17) 1470 0 R (table.6.18) 1477 0 R (table.6.19) 1488 0 R (table.6.2) 1120 0 R (table.6.3) 1128 0 R (table.6.4) 1167 0 R (table.6.5) 1178 0 R (table.6.6) 1215 0 R (table.6.7) 1306 0 R (table.6.8) 1335 0 R (table.6.9) 1375 0 R (the_category_phrase) 1161 0 R (the_sortlist_statement) 1296 0 R (topology) 1291 0 R (tsig) 1035 0 R (tuning) 1307 0 R (types_of_resource_records_and_when_to_use_them) 904 0 R (view_statement_grammar) 1325 0 R (zone_statement_grammar) 1243 0 R (zone_transfers) 1011 0 R (zonefile_format) 1314 0 R]
/Limits [(Access_Control_Lists) (zonefile_format)]
>> endobj
1965 0 obj <<
@@ -11049,7 +11032,7 @@ endobj
>> endobj
1968 0 obj <<
/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20100121064739Z)
+/CreationDate (D:20100301013335Z)
/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
>> endobj
xref
@@ -11060,652 +11043,652 @@ xref
0000000004 00000 f
0000000000 00000 f
0000000009 00000 n
-0000067235 00000 n
-0000679170 00000 n
+0000067237 00000 n
+0000679319 00000 n
0000000054 00000 n
0000000086 00000 n
-0000067359 00000 n
-0000679098 00000 n
+0000067361 00000 n
+0000679247 00000 n
0000000133 00000 n
0000000173 00000 n
-0000067484 00000 n
-0000679012 00000 n
+0000067486 00000 n
+0000679161 00000 n
0000000221 00000 n
0000000273 00000 n
-0000067609 00000 n
-0000678926 00000 n
+0000067611 00000 n
+0000679075 00000 n
0000000321 00000 n
0000000377 00000 n
-0000071872 00000 n
-0000678816 00000 n
+0000071874 00000 n
+0000678965 00000 n
0000000425 00000 n
0000000478 00000 n
-0000071997 00000 n
-0000678742 00000 n
+0000071999 00000 n
+0000678891 00000 n
0000000531 00000 n
0000000572 00000 n
-0000072122 00000 n
-0000678655 00000 n
+0000072124 00000 n
+0000678804 00000 n
0000000625 00000 n
0000000674 00000 n
-0000072247 00000 n
-0000678568 00000 n
+0000072249 00000 n
+0000678717 00000 n
0000000727 00000 n
0000000757 00000 n
-0000076525 00000 n
-0000678444 00000 n
+0000076527 00000 n
+0000678593 00000 n
0000000810 00000 n
0000000861 00000 n
-0000076650 00000 n
-0000678370 00000 n
+0000076652 00000 n
+0000678519 00000 n
0000000919 00000 n
0000000964 00000 n
-0000076775 00000 n
-0000678283 00000 n
+0000076777 00000 n
+0000678432 00000 n
0000001022 00000 n
0000001062 00000 n
-0000076900 00000 n
-0000678209 00000 n
+0000076902 00000 n
+0000678358 00000 n
0000001120 00000 n
0000001162 00000 n
-0000079872 00000 n
-0000678085 00000 n
+0000079874 00000 n
+0000678234 00000 n
0000001215 00000 n
0000001260 00000 n
-0000079997 00000 n
-0000678024 00000 n
+0000079999 00000 n
+0000678173 00000 n
0000001318 00000 n
0000001355 00000 n
-0000080122 00000 n
-0000677950 00000 n
+0000080124 00000 n
+0000678099 00000 n
0000001408 00000 n
0000001463 00000 n
-0000083050 00000 n
-0000677825 00000 n
+0000083052 00000 n
+0000677974 00000 n
0000001509 00000 n
0000001556 00000 n
-0000083175 00000 n
-0000677751 00000 n
+0000083177 00000 n
+0000677900 00000 n
0000001604 00000 n
0000001648 00000 n
-0000083300 00000 n
-0000677664 00000 n
+0000083302 00000 n
+0000677813 00000 n
0000001696 00000 n
0000001735 00000 n
-0000083425 00000 n
-0000677577 00000 n
+0000083427 00000 n
+0000677726 00000 n
0000001783 00000 n
0000001825 00000 n
-0000083549 00000 n
-0000677490 00000 n
+0000083551 00000 n
+0000677639 00000 n
0000001873 00000 n
0000001936 00000 n
-0000084632 00000 n
-0000677416 00000 n
+0000084634 00000 n
+0000677565 00000 n
0000001984 00000 n
0000002034 00000 n
-0000086335 00000 n
-0000677288 00000 n
+0000086337 00000 n
+0000677437 00000 n
0000002080 00000 n
0000002126 00000 n
-0000086459 00000 n
-0000677175 00000 n
+0000086461 00000 n
+0000677324 00000 n
0000002174 00000 n
0000002218 00000 n
-0000086584 00000 n
-0000677099 00000 n
+0000086586 00000 n
+0000677248 00000 n
0000002271 00000 n
0000002323 00000 n
-0000086709 00000 n
-0000677022 00000 n
+0000086711 00000 n
+0000677171 00000 n
0000002377 00000 n
0000002436 00000 n
-0000089237 00000 n
-0000676931 00000 n
+0000089239 00000 n
+0000677080 00000 n
0000002485 00000 n
0000002523 00000 n
-0000089489 00000 n
-0000676814 00000 n
+0000089491 00000 n
+0000676963 00000 n
0000002572 00000 n
0000002618 00000 n
-0000089615 00000 n
-0000676696 00000 n
+0000089617 00000 n
+0000676845 00000 n
0000002672 00000 n
0000002739 00000 n
-0000092837 00000 n
-0000676617 00000 n
+0000092839 00000 n
+0000676766 00000 n
0000002798 00000 n
0000002842 00000 n
-0000092963 00000 n
-0000676538 00000 n
+0000092965 00000 n
+0000676687 00000 n
0000002901 00000 n
0000002949 00000 n
-0000103401 00000 n
-0000676459 00000 n
+0000103403 00000 n
+0000676608 00000 n
0000003003 00000 n
0000003036 00000 n
-0000108371 00000 n
-0000676327 00000 n
+0000108373 00000 n
+0000676476 00000 n
0000003083 00000 n
0000003126 00000 n
-0000108497 00000 n
-0000676248 00000 n
+0000108499 00000 n
+0000676397 00000 n
0000003175 00000 n
0000003205 00000 n
-0000108623 00000 n
-0000676116 00000 n
+0000108625 00000 n
+0000676265 00000 n
0000003254 00000 n
0000003292 00000 n
-0000108750 00000 n
-0000676051 00000 n
+0000108752 00000 n
+0000676200 00000 n
0000003346 00000 n
0000003388 00000 n
-0000113043 00000 n
-0000675958 00000 n
+0000113045 00000 n
+0000676107 00000 n
0000003437 00000 n
0000003496 00000 n
-0000113170 00000 n
-0000675826 00000 n
+0000113172 00000 n
+0000675975 00000 n
0000003545 00000 n
0000003578 00000 n
-0000113299 00000 n
-0000675761 00000 n
+0000113301 00000 n
+0000675910 00000 n
0000003632 00000 n
0000003681 00000 n
-0000120671 00000 n
-0000675629 00000 n
+0000120673 00000 n
+0000675778 00000 n
0000003730 00000 n
0000003758 00000 n
-0000120798 00000 n
-0000675511 00000 n
+0000120800 00000 n
+0000675660 00000 n
0000003812 00000 n
0000003881 00000 n
-0000120927 00000 n
-0000675432 00000 n
+0000120929 00000 n
+0000675581 00000 n
0000003940 00000 n
0000003988 00000 n
-0000123823 00000 n
-0000675353 00000 n
+0000123825 00000 n
+0000675502 00000 n
0000004047 00000 n
0000004092 00000 n
-0000123952 00000 n
-0000675260 00000 n
+0000123954 00000 n
+0000675409 00000 n
0000004146 00000 n
0000004214 00000 n
-0000124081 00000 n
-0000675167 00000 n
+0000124083 00000 n
+0000675316 00000 n
0000004268 00000 n
0000004338 00000 n
-0000124210 00000 n
-0000675074 00000 n
+0000124212 00000 n
+0000675223 00000 n
0000004392 00000 n
0000004455 00000 n
-0000124338 00000 n
-0000674981 00000 n
+0000124340 00000 n
+0000675130 00000 n
0000004509 00000 n
0000004564 00000 n
-0000128005 00000 n
-0000674902 00000 n
+0000128007 00000 n
+0000675051 00000 n
0000004618 00000 n
0000004650 00000 n
-0000128134 00000 n
-0000674809 00000 n
+0000128136 00000 n
+0000674958 00000 n
0000004699 00000 n
0000004727 00000 n
-0000128263 00000 n
-0000674716 00000 n
+0000128265 00000 n
+0000674865 00000 n
0000004776 00000 n
0000004808 00000 n
-0000131869 00000 n
-0000674584 00000 n
+0000131871 00000 n
+0000674733 00000 n
0000004857 00000 n
0000004887 00000 n
-0000131998 00000 n
-0000674505 00000 n
+0000132000 00000 n
+0000674654 00000 n
0000004941 00000 n
0000004982 00000 n
-0000132126 00000 n
-0000674412 00000 n
+0000132128 00000 n
+0000674561 00000 n
0000005036 00000 n
0000005078 00000 n
-0000135588 00000 n
-0000674333 00000 n
+0000135590 00000 n
+0000674482 00000 n
0000005132 00000 n
0000005177 00000 n
-0000138662 00000 n
-0000674215 00000 n
+0000138664 00000 n
+0000674364 00000 n
0000005226 00000 n
0000005272 00000 n
-0000138791 00000 n
-0000674136 00000 n
+0000138793 00000 n
+0000674285 00000 n
0000005326 00000 n
0000005386 00000 n
-0000138919 00000 n
-0000674057 00000 n
+0000138921 00000 n
+0000674206 00000 n
0000005440 00000 n
0000005509 00000 n
-0000141400 00000 n
-0000673924 00000 n
+0000141402 00000 n
+0000674073 00000 n
0000005556 00000 n
0000005609 00000 n
-0000141529 00000 n
-0000673845 00000 n
+0000141531 00000 n
+0000673994 00000 n
0000005658 00000 n
0000005714 00000 n
-0000141658 00000 n
-0000673766 00000 n
+0000141660 00000 n
+0000673915 00000 n
0000005763 00000 n
0000005812 00000 n
-0000145842 00000 n
-0000673633 00000 n
+0000145844 00000 n
+0000673782 00000 n
0000005859 00000 n
0000005911 00000 n
-0000145971 00000 n
-0000673515 00000 n
+0000145973 00000 n
+0000673664 00000 n
0000005960 00000 n
0000006011 00000 n
-0000150578 00000 n
-0000673397 00000 n
+0000150580 00000 n
+0000673546 00000 n
0000006065 00000 n
0000006110 00000 n
-0000150705 00000 n
-0000673318 00000 n
+0000150707 00000 n
+0000673467 00000 n
0000006169 00000 n
0000006203 00000 n
-0000154163 00000 n
-0000673239 00000 n
+0000154165 00000 n
+0000673388 00000 n
0000006262 00000 n
0000006310 00000 n
-0000154292 00000 n
-0000673121 00000 n
+0000154294 00000 n
+0000673270 00000 n
0000006364 00000 n
0000006404 00000 n
-0000154421 00000 n
-0000673042 00000 n
+0000154423 00000 n
+0000673191 00000 n
0000006463 00000 n
0000006497 00000 n
-0000154550 00000 n
-0000672963 00000 n
+0000154552 00000 n
+0000673112 00000 n
0000006556 00000 n
0000006604 00000 n
-0000158541 00000 n
-0000672830 00000 n
+0000158543 00000 n
+0000672979 00000 n
0000006653 00000 n
0000006703 00000 n
-0000161811 00000 n
-0000672751 00000 n
+0000161813 00000 n
+0000672900 00000 n
0000006757 00000 n
0000006804 00000 n
-0000161940 00000 n
-0000672658 00000 n
+0000161942 00000 n
+0000672807 00000 n
0000006858 00000 n
0000006918 00000 n
-0000162198 00000 n
-0000672565 00000 n
+0000162200 00000 n
+0000672714 00000 n
0000006972 00000 n
0000007024 00000 n
-0000162327 00000 n
-0000672472 00000 n
+0000162329 00000 n
+0000672621 00000 n
0000007078 00000 n
0000007143 00000 n
-0000166928 00000 n
-0000672379 00000 n
+0000166930 00000 n
+0000672528 00000 n
0000007197 00000 n
0000007248 00000 n
-0000167054 00000 n
-0000672286 00000 n
+0000167056 00000 n
+0000672435 00000 n
0000007302 00000 n
0000007366 00000 n
-0000167183 00000 n
-0000672193 00000 n
+0000167185 00000 n
+0000672342 00000 n
0000007420 00000 n
0000007467 00000 n
-0000170945 00000 n
-0000672100 00000 n
+0000170947 00000 n
+0000672249 00000 n
0000007521 00000 n
0000007581 00000 n
-0000171074 00000 n
-0000672007 00000 n
+0000171076 00000 n
+0000672156 00000 n
0000007635 00000 n
0000007686 00000 n
-0000171203 00000 n
-0000671875 00000 n
+0000171205 00000 n
+0000672024 00000 n
0000007741 00000 n
0000007806 00000 n
-0000175735 00000 n
-0000671796 00000 n
+0000175737 00000 n
+0000671945 00000 n
0000007866 00000 n
0000007913 00000 n
-0000182174 00000 n
-0000671703 00000 n
+0000182176 00000 n
+0000671852 00000 n
0000007973 00000 n
0000008021 00000 n
-0000185653 00000 n
-0000671624 00000 n
+0000185655 00000 n
+0000671773 00000 n
0000008081 00000 n
0000008135 00000 n
-0000189114 00000 n
-0000671531 00000 n
+0000189116 00000 n
+0000671680 00000 n
0000008190 00000 n
0000008240 00000 n
-0000191939 00000 n
-0000671438 00000 n
+0000191941 00000 n
+0000671587 00000 n
0000008295 00000 n
0000008358 00000 n
-0000192068 00000 n
-0000671345 00000 n
+0000192070 00000 n
+0000671494 00000 n
0000008413 00000 n
0000008465 00000 n
-0000192197 00000 n
-0000671252 00000 n
+0000192199 00000 n
+0000671401 00000 n
0000008520 00000 n
0000008585 00000 n
-0000192326 00000 n
-0000671159 00000 n
+0000192328 00000 n
+0000671308 00000 n
0000008640 00000 n
0000008692 00000 n
-0000198793 00000 n
-0000671026 00000 n
+0000198795 00000 n
+0000671175 00000 n
0000008747 00000 n
0000008812 00000 n
-0000206888 00000 n
-0000670947 00000 n
+0000206890 00000 n
+0000671096 00000 n
0000008872 00000 n
0000008916 00000 n
-0000224498 00000 n
-0000670854 00000 n
+0000224500 00000 n
+0000671003 00000 n
0000008976 00000 n
0000009015 00000 n
-0000224627 00000 n
-0000670761 00000 n
+0000224629 00000 n
+0000670910 00000 n
0000009075 00000 n
0000009122 00000 n
-0000229140 00000 n
-0000670668 00000 n
+0000229142 00000 n
+0000670817 00000 n
0000009182 00000 n
0000009225 00000 n
-0000232242 00000 n
-0000670575 00000 n
+0000232244 00000 n
+0000670724 00000 n
0000009285 00000 n
0000009324 00000 n
-0000232371 00000 n
-0000670482 00000 n
+0000232373 00000 n
+0000670631 00000 n
0000009384 00000 n
0000009426 00000 n
-0000239620 00000 n
-0000670389 00000 n
+0000239622 00000 n
+0000670538 00000 n
0000009486 00000 n
0000009529 00000 n
-0000247388 00000 n
-0000670296 00000 n
+0000247390 00000 n
+0000670445 00000 n
0000009589 00000 n
0000009632 00000 n
-0000247517 00000 n
-0000670203 00000 n
+0000247519 00000 n
+0000670352 00000 n
0000009692 00000 n
0000009753 00000 n
-0000251446 00000 n
-0000670110 00000 n
+0000251448 00000 n
+0000670259 00000 n
0000009814 00000 n
0000009866 00000 n
-0000251575 00000 n
-0000670017 00000 n
+0000251577 00000 n
+0000670166 00000 n
0000009927 00000 n
0000009980 00000 n
-0000254642 00000 n
-0000669924 00000 n
+0000254644 00000 n
+0000670073 00000 n
0000010041 00000 n
0000010079 00000 n
-0000258713 00000 n
-0000669831 00000 n
+0000258715 00000 n
+0000669980 00000 n
0000010140 00000 n
0000010192 00000 n
-0000261945 00000 n
-0000669738 00000 n
+0000262092 00000 n
+0000669887 00000 n
0000010253 00000 n
0000010297 00000 n
-0000262202 00000 n
-0000669645 00000 n
+0000262349 00000 n
+0000669794 00000 n
0000010358 00000 n
0000010394 00000 n
-0000271167 00000 n
-0000669552 00000 n
+0000271322 00000 n
+0000669701 00000 n
0000010455 00000 n
0000010518 00000 n
-0000271296 00000 n
-0000669459 00000 n
+0000271451 00000 n
+0000669608 00000 n
0000010579 00000 n
0000010629 00000 n
-0000277445 00000 n
-0000669366 00000 n
+0000277600 00000 n
+0000669515 00000 n
0000010690 00000 n
0000010739 00000 n
-0000277703 00000 n
-0000669287 00000 n
+0000277858 00000 n
+0000669436 00000 n
0000010800 00000 n
0000010856 00000 n
-0000281169 00000 n
-0000669194 00000 n
+0000281324 00000 n
+0000669343 00000 n
0000010911 00000 n
0000010962 00000 n
-0000281298 00000 n
-0000669101 00000 n
+0000281453 00000 n
+0000669250 00000 n
0000011017 00000 n
0000011081 00000 n
-0000289908 00000 n
-0000669008 00000 n
+0000290063 00000 n
+0000669157 00000 n
0000011136 00000 n
0000011193 00000 n
-0000290037 00000 n
-0000668915 00000 n
+0000290192 00000 n
+0000669064 00000 n
0000011248 00000 n
0000011318 00000 n
-0000290165 00000 n
-0000668822 00000 n
+0000290320 00000 n
+0000668971 00000 n
0000011373 00000 n
0000011422 00000 n
-0000290294 00000 n
-0000668729 00000 n
+0000290449 00000 n
+0000668878 00000 n
0000011477 00000 n
0000011539 00000 n
-0000292540 00000 n
-0000668636 00000 n
+0000292695 00000 n
+0000668785 00000 n
0000011594 00000 n
0000011643 00000 n
-0000298725 00000 n
-0000668518 00000 n
+0000298880 00000 n
+0000668667 00000 n
0000011698 00000 n
0000011760 00000 n
-0000298853 00000 n
-0000668439 00000 n
+0000299008 00000 n
+0000668588 00000 n
0000011820 00000 n
0000011859 00000 n
-0000303880 00000 n
-0000668346 00000 n
+0000304035 00000 n
+0000668495 00000 n
0000011919 00000 n
0000011953 00000 n
-0000304009 00000 n
-0000668253 00000 n
+0000304164 00000 n
+0000668402 00000 n
0000012013 00000 n
0000012054 00000 n
-0000319667 00000 n
-0000668174 00000 n
+0000319822 00000 n
+0000668323 00000 n
0000012114 00000 n
0000012166 00000 n
-0000323570 00000 n
-0000668056 00000 n
+0000323725 00000 n
+0000668205 00000 n
0000012215 00000 n
0000012248 00000 n
-0000323699 00000 n
-0000667938 00000 n
+0000323854 00000 n
+0000668087 00000 n
0000012302 00000 n
0000012374 00000 n
-0000323826 00000 n
-0000667859 00000 n
+0000323981 00000 n
+0000668008 00000 n
0000012433 00000 n
0000012477 00000 n
-0000331369 00000 n
-0000667780 00000 n
+0000331524 00000 n
+0000667929 00000 n
0000012536 00000 n
0000012589 00000 n
-0000335141 00000 n
-0000667687 00000 n
+0000335296 00000 n
+0000667836 00000 n
0000012643 00000 n
0000012693 00000 n
-0000335399 00000 n
-0000667594 00000 n
+0000335554 00000 n
+0000667743 00000 n
0000012747 00000 n
0000012785 00000 n
-0000338645 00000 n
-0000667501 00000 n
+0000338800 00000 n
+0000667650 00000 n
0000012839 00000 n
0000012888 00000 n
-0000338903 00000 n
-0000667369 00000 n
+0000339058 00000 n
+0000667518 00000 n
0000012942 00000 n
0000012994 00000 n
-0000339032 00000 n
-0000667290 00000 n
+0000339187 00000 n
+0000667439 00000 n
0000013053 00000 n
0000013105 00000 n
-0000341860 00000 n
-0000667197 00000 n
+0000342015 00000 n
+0000667346 00000 n
0000013164 00000 n
0000013217 00000 n
-0000341989 00000 n
-0000667118 00000 n
+0000342144 00000 n
+0000667267 00000 n
0000013276 00000 n
0000013325 00000 n
-0000342118 00000 n
-0000667025 00000 n
+0000342273 00000 n
+0000667174 00000 n
0000013379 00000 n
0000013459 00000 n
-0000346156 00000 n
-0000666946 00000 n
+0000346311 00000 n
+0000667095 00000 n
0000013513 00000 n
0000013562 00000 n
-0000348053 00000 n
-0000666813 00000 n
+0000348208 00000 n
+0000666962 00000 n
0000013609 00000 n
0000013661 00000 n
-0000348182 00000 n
-0000666734 00000 n
+0000348337 00000 n
+0000666883 00000 n
0000013710 00000 n
0000013754 00000 n
-0000352288 00000 n
-0000666602 00000 n
+0000352443 00000 n
+0000666751 00000 n
0000013803 00000 n
0000013844 00000 n
-0000352417 00000 n
-0000666523 00000 n
+0000352572 00000 n
+0000666672 00000 n
0000013898 00000 n
0000013946 00000 n
-0000352546 00000 n
-0000666444 00000 n
+0000352701 00000 n
+0000666593 00000 n
0000014000 00000 n
0000014051 00000 n
-0000352675 00000 n
-0000666365 00000 n
+0000352830 00000 n
+0000666514 00000 n
0000014100 00000 n
0000014147 00000 n
-0000356940 00000 n
-0000666232 00000 n
+0000357095 00000 n
+0000666381 00000 n
0000014194 00000 n
0000014231 00000 n
-0000357069 00000 n
-0000666114 00000 n
+0000357224 00000 n
+0000666263 00000 n
0000014280 00000 n
0000014319 00000 n
-0000357198 00000 n
-0000666049 00000 n
+0000357353 00000 n
+0000666198 00000 n
0000014373 00000 n
0000014451 00000 n
-0000357327 00000 n
-0000665956 00000 n
+0000357482 00000 n
+0000666105 00000 n
0000014500 00000 n
0000014567 00000 n
-0000357456 00000 n
-0000665877 00000 n
+0000357611 00000 n
+0000666026 00000 n
0000014616 00000 n
0000014661 00000 n
-0000360895 00000 n
-0000665744 00000 n
+0000361050 00000 n
+0000665893 00000 n
0000014709 00000 n
0000014741 00000 n
-0000361024 00000 n
-0000665626 00000 n
+0000361179 00000 n
+0000665775 00000 n
0000014790 00000 n
0000014829 00000 n
-0000361153 00000 n
-0000665561 00000 n
+0000361308 00000 n
+0000665710 00000 n
0000014883 00000 n
0000014944 00000 n
-0000364834 00000 n
-0000665429 00000 n
+0000364989 00000 n
+0000665578 00000 n
0000014993 00000 n
0000015050 00000 n
-0000364963 00000 n
-0000665364 00000 n
+0000365118 00000 n
+0000665513 00000 n
0000015104 00000 n
0000015153 00000 n
-0000365092 00000 n
-0000665246 00000 n
+0000365247 00000 n
+0000665395 00000 n
0000015202 00000 n
0000015264 00000 n
-0000365221 00000 n
-0000665167 00000 n
+0000365376 00000 n
+0000665316 00000 n
0000015318 00000 n
0000015373 00000 n
-0000389244 00000 n
-0000665074 00000 n
+0000389399 00000 n
+0000665223 00000 n
0000015427 00000 n
0000015468 00000 n
-0000389373 00000 n
-0000664995 00000 n
+0000389528 00000 n
+0000665144 00000 n
0000015522 00000 n
0000015574 00000 n
-0000392103 00000 n
-0000664875 00000 n
+0000392258 00000 n
+0000665024 00000 n
0000015622 00000 n
0000015656 00000 n
-0000392232 00000 n
-0000664796 00000 n
+0000392387 00000 n
+0000664945 00000 n
0000015705 00000 n
0000015732 00000 n
-0000410371 00000 n
-0000664703 00000 n
+0000410526 00000 n
+0000664852 00000 n
0000015781 00000 n
0000015809 00000 n
-0000417904 00000 n
-0000664610 00000 n
+0000418059 00000 n
+0000664759 00000 n
0000015858 00000 n
0000015895 00000 n
-0000424222 00000 n
-0000664517 00000 n
+0000424377 00000 n
+0000664666 00000 n
0000015944 00000 n
0000015983 00000 n
-0000433742 00000 n
-0000664424 00000 n
+0000433897 00000 n
+0000664573 00000 n
0000016032 00000 n
0000016071 00000 n
-0000436629 00000 n
-0000664331 00000 n
+0000436784 00000 n
+0000664480 00000 n
0000016120 00000 n
0000016159 00000 n
-0000443022 00000 n
-0000664238 00000 n
+0000443177 00000 n
+0000664387 00000 n
0000016208 00000 n
0000016237 00000 n
-0000452411 00000 n
-0000664145 00000 n
+0000452566 00000 n
+0000664294 00000 n
0000016286 00000 n
0000016314 00000 n
-0000456051 00000 n
-0000664052 00000 n
+0000456206 00000 n
+0000664201 00000 n
0000016363 00000 n
0000016396 00000 n
-0000465449 00000 n
-0000663973 00000 n
+0000465604 00000 n
+0000664122 00000 n
0000016446 00000 n
0000016483 00000 n
0000016852 00000 n
@@ -11714,10 +11697,10 @@ xref
0000016536 00000 n
0000024677 00000 n
0000024740 00000 n
-0000659836 00000 n
-0000633893 00000 n
-0000659662 00000 n
-0000660861 00000 n
+0000659985 00000 n
+0000634042 00000 n
+0000659811 00000 n
+0000661010 00000 n
0000019837 00000 n
0000020054 00000 n
0000020123 00000 n
@@ -11734,1302 +11717,1302 @@ xref
0000021460 00000 n
0000021769 00000 n
0000021929 00000 n
-0000026167 00000 n
-0000025982 00000 n
+0000026169 00000 n
+0000025984 00000 n
0000024903 00000 n
-0000026104 00000 n
-0000632681 00000 n
-0000606202 00000 n
-0000632507 00000 n
-0000605517 00000 n
-0000603371 00000 n
-0000605353 00000 n
-0000037873 00000 n
-0000029223 00000 n
-0000026252 00000 n
-0000037747 00000 n
-0000037810 00000 n
-0000029757 00000 n
-0000029911 00000 n
-0000030068 00000 n
-0000030225 00000 n
-0000030381 00000 n
-0000030538 00000 n
-0000030700 00000 n
-0000030861 00000 n
-0000031022 00000 n
-0000031184 00000 n
-0000031351 00000 n
-0000031518 00000 n
-0000031683 00000 n
-0000031845 00000 n
-0000032011 00000 n
-0000032172 00000 n
-0000032327 00000 n
-0000032484 00000 n
-0000032640 00000 n
-0000032797 00000 n
-0000032954 00000 n
-0000033111 00000 n
-0000033265 00000 n
-0000033421 00000 n
-0000033583 00000 n
-0000033745 00000 n
-0000033901 00000 n
-0000034058 00000 n
-0000034220 00000 n
-0000034387 00000 n
-0000034553 00000 n
-0000034714 00000 n
-0000034869 00000 n
-0000035026 00000 n
-0000035183 00000 n
-0000035345 00000 n
-0000035502 00000 n
-0000035659 00000 n
-0000035821 00000 n
-0000035978 00000 n
-0000036140 00000 n
-0000036307 00000 n
-0000036473 00000 n
-0000036635 00000 n
-0000036797 00000 n
-0000036959 00000 n
-0000037120 00000 n
-0000037282 00000 n
-0000037437 00000 n
-0000037592 00000 n
-0000051262 00000 n
-0000041209 00000 n
-0000037958 00000 n
-0000051199 00000 n
-0000602820 00000 n
-0000585739 00000 n
-0000602636 00000 n
-0000041799 00000 n
-0000041962 00000 n
-0000042124 00000 n
-0000042287 00000 n
-0000042445 00000 n
-0000042608 00000 n
-0000042771 00000 n
-0000042926 00000 n
-0000043084 00000 n
-0000043242 00000 n
-0000043398 00000 n
-0000043556 00000 n
-0000043719 00000 n
-0000043887 00000 n
-0000044055 00000 n
-0000044218 00000 n
-0000044386 00000 n
-0000044554 00000 n
-0000044712 00000 n
-0000044875 00000 n
-0000045038 00000 n
-0000045200 00000 n
-0000045362 00000 n
-0000045525 00000 n
-0000045687 00000 n
-0000045849 00000 n
-0000046012 00000 n
-0000046175 00000 n
-0000046338 00000 n
-0000046507 00000 n
-0000046676 00000 n
-0000046845 00000 n
-0000047008 00000 n
-0000047172 00000 n
-0000047336 00000 n
-0000047499 00000 n
-0000047663 00000 n
-0000047827 00000 n
-0000047995 00000 n
-0000048164 00000 n
-0000048333 00000 n
-0000048502 00000 n
-0000048671 00000 n
-0000048840 00000 n
-0000049009 00000 n
-0000049178 00000 n
-0000049347 00000 n
-0000049517 00000 n
-0000049687 00000 n
-0000049856 00000 n
-0000050026 00000 n
-0000050196 00000 n
-0000050364 00000 n
-0000050533 00000 n
-0000050703 00000 n
-0000050870 00000 n
-0000051037 00000 n
-0000064310 00000 n
-0000054845 00000 n
-0000051360 00000 n
-0000064247 00000 n
-0000055419 00000 n
-0000055582 00000 n
-0000055745 00000 n
-0000055908 00000 n
-0000056071 00000 n
-0000056233 00000 n
-0000056396 00000 n
-0000056559 00000 n
-0000056727 00000 n
-0000056893 00000 n
-0000057061 00000 n
-0000057229 00000 n
-0000057386 00000 n
-0000057548 00000 n
-0000057715 00000 n
-0000057882 00000 n
-0000058044 00000 n
-0000058206 00000 n
-0000058368 00000 n
-0000058530 00000 n
-0000058697 00000 n
-0000058864 00000 n
-0000059031 00000 n
-0000059193 00000 n
-0000059355 00000 n
-0000059510 00000 n
-0000059667 00000 n
-0000059824 00000 n
-0000059986 00000 n
-0000060148 00000 n
-0000060305 00000 n
-0000060460 00000 n
-0000060617 00000 n
-0000060778 00000 n
-0000060935 00000 n
-0000061092 00000 n
-0000061247 00000 n
-0000061404 00000 n
-0000061566 00000 n
-0000061723 00000 n
-0000061885 00000 n
-0000062041 00000 n
-0000062203 00000 n
-0000062365 00000 n
-0000062527 00000 n
-0000062683 00000 n
-0000062840 00000 n
-0000062997 00000 n
-0000063154 00000 n
-0000063310 00000 n
-0000063467 00000 n
-0000063624 00000 n
-0000063781 00000 n
-0000584773 00000 n
-0000564806 00000 n
-0000584600 00000 n
-0000063937 00000 n
-0000064092 00000 n
-0000064755 00000 n
-0000064570 00000 n
-0000064421 00000 n
-0000064692 00000 n
-0000067860 00000 n
-0000067050 00000 n
-0000064796 00000 n
-0000067172 00000 n
-0000067296 00000 n
-0000067421 00000 n
-0000067546 00000 n
-0000563917 00000 n
-0000542586 00000 n
-0000563743 00000 n
-0000067671 00000 n
-0000067734 00000 n
-0000067797 00000 n
-0000541812 00000 n
-0000524265 00000 n
-0000541639 00000 n
-0000660979 00000 n
-0000072371 00000 n
-0000071189 00000 n
-0000067984 00000 n
-0000071683 00000 n
-0000071746 00000 n
-0000071809 00000 n
-0000071934 00000 n
-0000072059 00000 n
-0000072184 00000 n
-0000071339 00000 n
-0000071532 00000 n
-0000072309 00000 n
-0000323763 00000 n
-0000365285 00000 n
-0000077025 00000 n
-0000075989 00000 n
-0000072495 00000 n
-0000076462 00000 n
-0000076587 00000 n
-0000076139 00000 n
-0000076301 00000 n
-0000076712 00000 n
-0000076837 00000 n
-0000076962 00000 n
-0000092900 00000 n
-0000080247 00000 n
-0000079687 00000 n
-0000077149 00000 n
-0000079809 00000 n
-0000079934 00000 n
-0000080059 00000 n
-0000080184 00000 n
-0000083674 00000 n
-0000082533 00000 n
-0000080358 00000 n
-0000082987 00000 n
-0000083112 00000 n
-0000083237 00000 n
-0000083362 00000 n
-0000083487 00000 n
-0000082683 00000 n
-0000082835 00000 n
-0000083611 00000 n
-0000277767 00000 n
-0000084757 00000 n
-0000084447 00000 n
-0000083759 00000 n
-0000084569 00000 n
-0000084694 00000 n
-0000086835 00000 n
-0000086150 00000 n
-0000084855 00000 n
-0000086272 00000 n
-0000086397 00000 n
-0000086521 00000 n
-0000086646 00000 n
-0000086772 00000 n
-0000661097 00000 n
-0000089740 00000 n
-0000088872 00000 n
-0000086933 00000 n
-0000089174 00000 n
-0000089300 00000 n
-0000089363 00000 n
-0000089426 00000 n
-0000089014 00000 n
-0000089552 00000 n
-0000089678 00000 n
-0000262009 00000 n
-0000093089 00000 n
-0000092652 00000 n
-0000089851 00000 n
-0000092774 00000 n
-0000523609 00000 n
-0000512024 00000 n
-0000523432 00000 n
-0000093026 00000 n
-0000096906 00000 n
-0000096721 00000 n
-0000093213 00000 n
-0000096843 00000 n
-0000511485 00000 n
-0000501742 00000 n
-0000511308 00000 n
-0000101367 00000 n
-0000100976 00000 n
-0000097069 00000 n
-0000101304 00000 n
-0000101118 00000 n
-0000162391 00000 n
-0000103653 00000 n
-0000103216 00000 n
-0000101504 00000 n
-0000103338 00000 n
-0000103464 00000 n
-0000103527 00000 n
-0000103590 00000 n
-0000106344 00000 n
-0000108877 00000 n
-0000106193 00000 n
-0000103777 00000 n
-0000108308 00000 n
-0000108434 00000 n
-0000108560 00000 n
-0000107986 00000 n
-0000108147 00000 n
-0000500883 00000 n
-0000491510 00000 n
-0000500710 00000 n
-0000490946 00000 n
-0000481859 00000 n
-0000490771 00000 n
-0000108686 00000 n
-0000108813 00000 n
-0000661215 00000 n
-0000107815 00000 n
-0000107873 00000 n
-0000107963 00000 n
-0000206952 00000 n
-0000239684 00000 n
-0000113428 00000 n
-0000112494 00000 n
-0000109031 00000 n
-0000112978 00000 n
-0000113106 00000 n
-0000112650 00000 n
-0000112816 00000 n
-0000113234 00000 n
-0000113363 00000 n
-0000369310 00000 n
-0000116920 00000 n
-0000116540 00000 n
-0000113579 00000 n
-0000116855 00000 n
-0000116687 00000 n
-0000118154 00000 n
-0000117963 00000 n
-0000117045 00000 n
-0000118089 00000 n
-0000121056 00000 n
-0000120480 00000 n
-0000118253 00000 n
-0000120606 00000 n
-0000120733 00000 n
-0000120862 00000 n
-0000120991 00000 n
-0000124467 00000 n
-0000123632 00000 n
-0000121194 00000 n
-0000123758 00000 n
-0000123887 00000 n
-0000124016 00000 n
-0000124145 00000 n
-0000124273 00000 n
-0000124402 00000 n
-0000128391 00000 n
-0000127623 00000 n
-0000124605 00000 n
-0000127940 00000 n
-0000127770 00000 n
-0000128069 00000 n
-0000128198 00000 n
-0000128327 00000 n
-0000661339 00000 n
-0000319731 00000 n
-0000132255 00000 n
-0000131678 00000 n
-0000128503 00000 n
-0000131804 00000 n
-0000131933 00000 n
-0000132061 00000 n
-0000132190 00000 n
-0000135717 00000 n
-0000135397 00000 n
-0000132393 00000 n
-0000135523 00000 n
-0000135652 00000 n
-0000139048 00000 n
-0000138289 00000 n
-0000135829 00000 n
-0000138597 00000 n
-0000138726 00000 n
-0000138436 00000 n
-0000138855 00000 n
-0000138983 00000 n
-0000365027 00000 n
-0000141787 00000 n
-0000141209 00000 n
-0000139215 00000 n
-0000141335 00000 n
-0000141464 00000 n
-0000141593 00000 n
-0000141722 00000 n
-0000142227 00000 n
-0000142036 00000 n
-0000141886 00000 n
-0000142162 00000 n
-0000146229 00000 n
-0000145463 00000 n
-0000142269 00000 n
-0000145777 00000 n
-0000145906 00000 n
-0000146034 00000 n
-0000146099 00000 n
-0000146164 00000 n
-0000145610 00000 n
-0000661464 00000 n
-0000150641 00000 n
-0000150833 00000 n
-0000150387 00000 n
-0000146328 00000 n
-0000150513 00000 n
-0000150768 00000 n
-0000154679 00000 n
-0000153972 00000 n
-0000150958 00000 n
-0000154098 00000 n
-0000154227 00000 n
-0000154356 00000 n
-0000154485 00000 n
-0000154614 00000 n
-0000157550 00000 n
-0000158800 00000 n
-0000157424 00000 n
-0000154804 00000 n
-0000158476 00000 n
-0000158605 00000 n
-0000158670 00000 n
-0000158735 00000 n
-0000162455 00000 n
-0000161620 00000 n
-0000158955 00000 n
-0000161746 00000 n
-0000161875 00000 n
-0000162003 00000 n
-0000162068 00000 n
-0000162133 00000 n
-0000162262 00000 n
-0000167312 00000 n
-0000166397 00000 n
-0000162567 00000 n
-0000166863 00000 n
-0000166553 00000 n
-0000166704 00000 n
-0000166991 00000 n
-0000167118 00000 n
-0000167247 00000 n
-0000468049 00000 n
-0000171332 00000 n
-0000170190 00000 n
-0000167450 00000 n
-0000170880 00000 n
-0000171009 00000 n
-0000170355 00000 n
-0000170507 00000 n
-0000170694 00000 n
-0000171138 00000 n
-0000171267 00000 n
-0000661589 00000 n
-0000175864 00000 n
-0000175544 00000 n
-0000171457 00000 n
-0000175670 00000 n
-0000175799 00000 n
-0000179053 00000 n
-0000178674 00000 n
-0000175989 00000 n
-0000178988 00000 n
-0000178821 00000 n
-0000182238 00000 n
-0000182433 00000 n
-0000181983 00000 n
-0000179165 00000 n
-0000182109 00000 n
-0000182303 00000 n
-0000182368 00000 n
-0000185782 00000 n
-0000185462 00000 n
-0000182545 00000 n
-0000185588 00000 n
-0000185717 00000 n
-0000189243 00000 n
-0000188793 00000 n
-0000185894 00000 n
-0000188919 00000 n
-0000188984 00000 n
-0000189049 00000 n
-0000189178 00000 n
-0000192455 00000 n
-0000191412 00000 n
-0000189355 00000 n
-0000191874 00000 n
-0000192003 00000 n
-0000191568 00000 n
-0000191721 00000 n
-0000192132 00000 n
-0000192261 00000 n
-0000192390 00000 n
-0000661714 00000 n
-0000194043 00000 n
-0000193852 00000 n
-0000192567 00000 n
-0000193978 00000 n
-0000195559 00000 n
-0000195368 00000 n
-0000194142 00000 n
-0000195494 00000 n
-0000198922 00000 n
-0000198602 00000 n
-0000195658 00000 n
-0000198728 00000 n
-0000198857 00000 n
-0000203016 00000 n
-0000202648 00000 n
-0000199047 00000 n
-0000202951 00000 n
-0000202795 00000 n
-0000277509 00000 n
-0000207147 00000 n
-0000206697 00000 n
-0000203128 00000 n
-0000206823 00000 n
-0000207017 00000 n
-0000207082 00000 n
-0000211325 00000 n
-0000210959 00000 n
-0000207259 00000 n
-0000211260 00000 n
-0000211106 00000 n
-0000661839 00000 n
-0000216411 00000 n
-0000215278 00000 n
-0000211450 00000 n
-0000216346 00000 n
-0000215461 00000 n
-0000215617 00000 n
-0000215802 00000 n
-0000215976 00000 n
-0000216161 00000 n
-0000281362 00000 n
-0000220635 00000 n
-0000220444 00000 n
-0000216604 00000 n
-0000220570 00000 n
-0000224755 00000 n
-0000224116 00000 n
-0000220747 00000 n
-0000224433 00000 n
-0000224562 00000 n
-0000224263 00000 n
-0000224691 00000 n
-0000292604 00000 n
-0000229269 00000 n
-0000228403 00000 n
-0000224867 00000 n
-0000229075 00000 n
-0000229204 00000 n
-0000228568 00000 n
-0000228734 00000 n
-0000228904 00000 n
-0000352739 00000 n
-0000232499 00000 n
-0000232051 00000 n
-0000229437 00000 n
-0000232177 00000 n
-0000232306 00000 n
-0000232435 00000 n
-0000235872 00000 n
-0000235681 00000 n
-0000232624 00000 n
-0000235807 00000 n
-0000661964 00000 n
-0000239749 00000 n
-0000239429 00000 n
-0000236040 00000 n
-0000239555 00000 n
-0000243306 00000 n
-0000243115 00000 n
-0000239904 00000 n
-0000243241 00000 n
-0000247646 00000 n
-0000246832 00000 n
-0000243474 00000 n
-0000247323 00000 n
-0000247452 00000 n
-0000246988 00000 n
-0000247581 00000 n
-0000247149 00000 n
-0000251703 00000 n
-0000251079 00000 n
-0000247800 00000 n
-0000251381 00000 n
-0000251510 00000 n
-0000251226 00000 n
-0000251639 00000 n
-0000254771 00000 n
-0000254451 00000 n
-0000251828 00000 n
-0000254577 00000 n
-0000254706 00000 n
-0000258842 00000 n
-0000258175 00000 n
-0000254925 00000 n
-0000258648 00000 n
-0000258777 00000 n
-0000258331 00000 n
-0000258493 00000 n
-0000662089 00000 n
-0000262331 00000 n
-0000261563 00000 n
-0000259010 00000 n
-0000261880 00000 n
+0000026106 00000 n
+0000632830 00000 n
+0000606351 00000 n
+0000632656 00000 n
+0000605666 00000 n
+0000603521 00000 n
+0000605502 00000 n
+0000037875 00000 n
+0000029225 00000 n
+0000026254 00000 n
+0000037749 00000 n
+0000037812 00000 n
+0000029759 00000 n
+0000029913 00000 n
+0000030070 00000 n
+0000030227 00000 n
+0000030383 00000 n
+0000030540 00000 n
+0000030702 00000 n
+0000030863 00000 n
+0000031024 00000 n
+0000031186 00000 n
+0000031353 00000 n
+0000031520 00000 n
+0000031685 00000 n
+0000031847 00000 n
+0000032013 00000 n
+0000032174 00000 n
+0000032329 00000 n
+0000032486 00000 n
+0000032642 00000 n
+0000032799 00000 n
+0000032956 00000 n
+0000033113 00000 n
+0000033267 00000 n
+0000033423 00000 n
+0000033585 00000 n
+0000033747 00000 n
+0000033903 00000 n
+0000034060 00000 n
+0000034222 00000 n
+0000034389 00000 n
+0000034555 00000 n
+0000034716 00000 n
+0000034871 00000 n
+0000035028 00000 n
+0000035185 00000 n
+0000035347 00000 n
+0000035504 00000 n
+0000035661 00000 n
+0000035823 00000 n
+0000035980 00000 n
+0000036142 00000 n
+0000036309 00000 n
+0000036475 00000 n
+0000036637 00000 n
+0000036799 00000 n
+0000036961 00000 n
+0000037122 00000 n
+0000037284 00000 n
+0000037439 00000 n
+0000037594 00000 n
+0000051264 00000 n
+0000041211 00000 n
+0000037960 00000 n
+0000051201 00000 n
+0000602970 00000 n
+0000585889 00000 n
+0000602786 00000 n
+0000041801 00000 n
+0000041964 00000 n
+0000042126 00000 n
+0000042289 00000 n
+0000042447 00000 n
+0000042610 00000 n
+0000042773 00000 n
+0000042928 00000 n
+0000043086 00000 n
+0000043244 00000 n
+0000043400 00000 n
+0000043558 00000 n
+0000043721 00000 n
+0000043889 00000 n
+0000044057 00000 n
+0000044220 00000 n
+0000044388 00000 n
+0000044556 00000 n
+0000044714 00000 n
+0000044877 00000 n
+0000045040 00000 n
+0000045202 00000 n
+0000045364 00000 n
+0000045527 00000 n
+0000045689 00000 n
+0000045851 00000 n
+0000046014 00000 n
+0000046177 00000 n
+0000046340 00000 n
+0000046509 00000 n
+0000046678 00000 n
+0000046847 00000 n
+0000047010 00000 n
+0000047174 00000 n
+0000047338 00000 n
+0000047501 00000 n
+0000047665 00000 n
+0000047829 00000 n
+0000047997 00000 n
+0000048166 00000 n
+0000048335 00000 n
+0000048504 00000 n
+0000048673 00000 n
+0000048842 00000 n
+0000049011 00000 n
+0000049180 00000 n
+0000049349 00000 n
+0000049519 00000 n
+0000049689 00000 n
+0000049858 00000 n
+0000050028 00000 n
+0000050198 00000 n
+0000050366 00000 n
+0000050535 00000 n
+0000050705 00000 n
+0000050872 00000 n
+0000051039 00000 n
+0000064312 00000 n
+0000054847 00000 n
+0000051362 00000 n
+0000064249 00000 n
+0000055421 00000 n
+0000055584 00000 n
+0000055747 00000 n
+0000055910 00000 n
+0000056073 00000 n
+0000056235 00000 n
+0000056398 00000 n
+0000056561 00000 n
+0000056729 00000 n
+0000056895 00000 n
+0000057063 00000 n
+0000057231 00000 n
+0000057388 00000 n
+0000057550 00000 n
+0000057717 00000 n
+0000057884 00000 n
+0000058046 00000 n
+0000058208 00000 n
+0000058370 00000 n
+0000058532 00000 n
+0000058699 00000 n
+0000058866 00000 n
+0000059033 00000 n
+0000059195 00000 n
+0000059357 00000 n
+0000059512 00000 n
+0000059669 00000 n
+0000059826 00000 n
+0000059988 00000 n
+0000060150 00000 n
+0000060307 00000 n
+0000060462 00000 n
+0000060619 00000 n
+0000060780 00000 n
+0000060937 00000 n
+0000061094 00000 n
+0000061249 00000 n
+0000061406 00000 n
+0000061568 00000 n
+0000061725 00000 n
+0000061887 00000 n
+0000062043 00000 n
+0000062205 00000 n
+0000062367 00000 n
+0000062529 00000 n
+0000062685 00000 n
+0000062842 00000 n
+0000062999 00000 n
+0000063156 00000 n
+0000063312 00000 n
+0000063469 00000 n
+0000063626 00000 n
+0000063783 00000 n
+0000584923 00000 n
+0000564956 00000 n
+0000584750 00000 n
+0000063939 00000 n
+0000064094 00000 n
+0000064757 00000 n
+0000064572 00000 n
+0000064423 00000 n
+0000064694 00000 n
+0000067862 00000 n
+0000067052 00000 n
+0000064798 00000 n
+0000067174 00000 n
+0000067298 00000 n
+0000067423 00000 n
+0000067548 00000 n
+0000564067 00000 n
+0000542735 00000 n
+0000563893 00000 n
+0000067673 00000 n
+0000067736 00000 n
+0000067799 00000 n
+0000541961 00000 n
+0000524414 00000 n
+0000541788 00000 n
+0000661128 00000 n
+0000072373 00000 n
+0000071191 00000 n
+0000067986 00000 n
+0000071685 00000 n
+0000071748 00000 n
+0000071811 00000 n
+0000071936 00000 n
+0000072061 00000 n
+0000072186 00000 n
+0000071341 00000 n
+0000071534 00000 n
+0000072311 00000 n
+0000323918 00000 n
+0000365440 00000 n
+0000077027 00000 n
+0000075991 00000 n
+0000072497 00000 n
+0000076464 00000 n
+0000076589 00000 n
+0000076141 00000 n
+0000076303 00000 n
+0000076714 00000 n
+0000076839 00000 n
+0000076964 00000 n
+0000092902 00000 n
+0000080249 00000 n
+0000079689 00000 n
+0000077151 00000 n
+0000079811 00000 n
+0000079936 00000 n
+0000080061 00000 n
+0000080186 00000 n
+0000083676 00000 n
+0000082535 00000 n
+0000080360 00000 n
+0000082989 00000 n
+0000083114 00000 n
+0000083239 00000 n
+0000083364 00000 n
+0000083489 00000 n
+0000082685 00000 n
+0000082837 00000 n
+0000083613 00000 n
+0000277922 00000 n
+0000084759 00000 n
+0000084449 00000 n
+0000083761 00000 n
+0000084571 00000 n
+0000084696 00000 n
+0000086837 00000 n
+0000086152 00000 n
+0000084857 00000 n
+0000086274 00000 n
+0000086399 00000 n
+0000086523 00000 n
+0000086648 00000 n
+0000086774 00000 n
+0000661246 00000 n
+0000089742 00000 n
+0000088874 00000 n
+0000086935 00000 n
+0000089176 00000 n
+0000089302 00000 n
+0000089365 00000 n
+0000089428 00000 n
+0000089016 00000 n
+0000089554 00000 n
+0000089680 00000 n
+0000262156 00000 n
+0000093091 00000 n
+0000092654 00000 n
+0000089853 00000 n
+0000092776 00000 n
+0000523758 00000 n
+0000512176 00000 n
+0000523581 00000 n
+0000093028 00000 n
+0000096908 00000 n
+0000096723 00000 n
+0000093215 00000 n
+0000096845 00000 n
+0000511637 00000 n
+0000501895 00000 n
+0000511460 00000 n
+0000101369 00000 n
+0000100978 00000 n
+0000097071 00000 n
+0000101306 00000 n
+0000101120 00000 n
+0000162393 00000 n
+0000103655 00000 n
+0000103218 00000 n
+0000101506 00000 n
+0000103340 00000 n
+0000103466 00000 n
+0000103529 00000 n
+0000103592 00000 n
+0000106346 00000 n
+0000108879 00000 n
+0000106195 00000 n
+0000103779 00000 n
+0000108310 00000 n
+0000108436 00000 n
+0000108562 00000 n
+0000107988 00000 n
+0000108149 00000 n
+0000501036 00000 n
+0000491663 00000 n
+0000500863 00000 n
+0000491099 00000 n
+0000482013 00000 n
+0000490924 00000 n
+0000108688 00000 n
+0000108815 00000 n
+0000661364 00000 n
+0000107817 00000 n
+0000107875 00000 n
+0000107965 00000 n
+0000206954 00000 n
+0000239686 00000 n
+0000113430 00000 n
+0000112496 00000 n
+0000109033 00000 n
+0000112980 00000 n
+0000113108 00000 n
+0000112652 00000 n
+0000112818 00000 n
+0000113236 00000 n
+0000113365 00000 n
+0000369465 00000 n
+0000116922 00000 n
+0000116542 00000 n
+0000113581 00000 n
+0000116857 00000 n
+0000116689 00000 n
+0000118156 00000 n
+0000117965 00000 n
+0000117047 00000 n
+0000118091 00000 n
+0000121058 00000 n
+0000120482 00000 n
+0000118255 00000 n
+0000120608 00000 n
+0000120735 00000 n
+0000120864 00000 n
+0000120993 00000 n
+0000124469 00000 n
+0000123634 00000 n
+0000121196 00000 n
+0000123760 00000 n
+0000123889 00000 n
+0000124018 00000 n
+0000124147 00000 n
+0000124275 00000 n
+0000124404 00000 n
+0000128393 00000 n
+0000127625 00000 n
+0000124607 00000 n
+0000127942 00000 n
+0000127772 00000 n
+0000128071 00000 n
+0000128200 00000 n
+0000128329 00000 n
+0000661488 00000 n
+0000319886 00000 n
+0000132257 00000 n
+0000131680 00000 n
+0000128505 00000 n
+0000131806 00000 n
+0000131935 00000 n
+0000132063 00000 n
+0000132192 00000 n
+0000135719 00000 n
+0000135399 00000 n
+0000132395 00000 n
+0000135525 00000 n
+0000135654 00000 n
+0000139050 00000 n
+0000138291 00000 n
+0000135831 00000 n
+0000138599 00000 n
+0000138728 00000 n
+0000138438 00000 n
+0000138857 00000 n
+0000138985 00000 n
+0000365182 00000 n
+0000141789 00000 n
+0000141211 00000 n
+0000139217 00000 n
+0000141337 00000 n
+0000141466 00000 n
+0000141595 00000 n
+0000141724 00000 n
+0000142229 00000 n
+0000142038 00000 n
+0000141888 00000 n
+0000142164 00000 n
+0000146231 00000 n
+0000145465 00000 n
+0000142271 00000 n
+0000145779 00000 n
+0000145908 00000 n
+0000146036 00000 n
+0000146101 00000 n
+0000146166 00000 n
+0000145612 00000 n
+0000661613 00000 n
+0000150643 00000 n
+0000150835 00000 n
+0000150389 00000 n
+0000146330 00000 n
+0000150515 00000 n
+0000150770 00000 n
+0000154681 00000 n
+0000153974 00000 n
+0000150960 00000 n
+0000154100 00000 n
+0000154229 00000 n
+0000154358 00000 n
+0000154487 00000 n
+0000154616 00000 n
+0000157552 00000 n
+0000158802 00000 n
+0000157426 00000 n
+0000154806 00000 n
+0000158478 00000 n
+0000158607 00000 n
+0000158672 00000 n
+0000158737 00000 n
+0000162457 00000 n
+0000161622 00000 n
+0000158957 00000 n
+0000161748 00000 n
+0000161877 00000 n
+0000162005 00000 n
+0000162070 00000 n
+0000162135 00000 n
+0000162264 00000 n
+0000167314 00000 n
+0000166399 00000 n
+0000162569 00000 n
+0000166865 00000 n
+0000166555 00000 n
+0000166706 00000 n
+0000166993 00000 n
+0000167120 00000 n
+0000167249 00000 n
+0000468204 00000 n
+0000171334 00000 n
+0000170192 00000 n
+0000167452 00000 n
+0000170882 00000 n
+0000171011 00000 n
+0000170357 00000 n
+0000170509 00000 n
+0000170696 00000 n
+0000171140 00000 n
+0000171269 00000 n
+0000661738 00000 n
+0000175866 00000 n
+0000175546 00000 n
+0000171459 00000 n
+0000175672 00000 n
+0000175801 00000 n
+0000179055 00000 n
+0000178676 00000 n
+0000175991 00000 n
+0000178990 00000 n
+0000178823 00000 n
+0000182240 00000 n
+0000182435 00000 n
+0000181985 00000 n
+0000179167 00000 n
+0000182111 00000 n
+0000182305 00000 n
+0000182370 00000 n
+0000185784 00000 n
+0000185464 00000 n
+0000182547 00000 n
+0000185590 00000 n
+0000185719 00000 n
+0000189245 00000 n
+0000188795 00000 n
+0000185896 00000 n
+0000188921 00000 n
+0000188986 00000 n
+0000189051 00000 n
+0000189180 00000 n
+0000192457 00000 n
+0000191414 00000 n
+0000189357 00000 n
+0000191876 00000 n
+0000192005 00000 n
+0000191570 00000 n
+0000191723 00000 n
+0000192134 00000 n
+0000192263 00000 n
+0000192392 00000 n
+0000661863 00000 n
+0000194045 00000 n
+0000193854 00000 n
+0000192569 00000 n
+0000193980 00000 n
+0000195561 00000 n
+0000195370 00000 n
+0000194144 00000 n
+0000195496 00000 n
+0000198924 00000 n
+0000198604 00000 n
+0000195660 00000 n
+0000198730 00000 n
+0000198859 00000 n
+0000203018 00000 n
+0000202650 00000 n
+0000199049 00000 n
+0000202953 00000 n
+0000202797 00000 n
+0000277664 00000 n
+0000207149 00000 n
+0000206699 00000 n
+0000203130 00000 n
+0000206825 00000 n
+0000207019 00000 n
+0000207084 00000 n
+0000211327 00000 n
+0000210961 00000 n
+0000207261 00000 n
+0000211262 00000 n
+0000211108 00000 n
+0000661988 00000 n
+0000216413 00000 n
+0000215280 00000 n
+0000211452 00000 n
+0000216348 00000 n
+0000215463 00000 n
+0000215619 00000 n
+0000215804 00000 n
+0000215978 00000 n
+0000216163 00000 n
+0000281517 00000 n
+0000220637 00000 n
+0000220446 00000 n
+0000216606 00000 n
+0000220572 00000 n
+0000224757 00000 n
+0000224118 00000 n
+0000220749 00000 n
+0000224435 00000 n
+0000224564 00000 n
+0000224265 00000 n
+0000224693 00000 n
+0000292759 00000 n
+0000229271 00000 n
+0000228405 00000 n
+0000224869 00000 n
+0000229077 00000 n
+0000229206 00000 n
+0000228570 00000 n
+0000228736 00000 n
+0000228906 00000 n
+0000352894 00000 n
+0000232501 00000 n
+0000232053 00000 n
+0000229439 00000 n
+0000232179 00000 n
+0000232308 00000 n
+0000232437 00000 n
+0000235874 00000 n
+0000235683 00000 n
+0000232626 00000 n
+0000235809 00000 n
+0000662113 00000 n
+0000239751 00000 n
+0000239431 00000 n
+0000236042 00000 n
+0000239557 00000 n
+0000243308 00000 n
+0000243117 00000 n
+0000239906 00000 n
+0000243243 00000 n
+0000247648 00000 n
+0000246834 00000 n
+0000243476 00000 n
+0000247325 00000 n
+0000247454 00000 n
+0000246990 00000 n
+0000247583 00000 n
+0000247151 00000 n
+0000251705 00000 n
+0000251081 00000 n
+0000247802 00000 n
+0000251383 00000 n
+0000251512 00000 n
+0000251228 00000 n
+0000251641 00000 n
+0000254773 00000 n
+0000254453 00000 n
+0000251830 00000 n
+0000254579 00000 n
+0000254708 00000 n
+0000258844 00000 n
+0000258177 00000 n
+0000254927 00000 n
+0000258650 00000 n
+0000258779 00000 n
+0000258333 00000 n
+0000258495 00000 n
+0000662238 00000 n
+0000262477 00000 n
0000261710 00000 n
-0000262072 00000 n
-0000262137 00000 n
-0000262266 00000 n
-0000267036 00000 n
-0000266492 00000 n
-0000262512 00000 n
-0000266971 00000 n
-0000266648 00000 n
-0000266809 00000 n
-0000346220 00000 n
-0000271424 00000 n
-0000270788 00000 n
-0000267203 00000 n
-0000271102 00000 n
-0000481504 00000 n
-0000479505 00000 n
-0000481339 00000 n
-0000271231 00000 n
-0000270935 00000 n
-0000271359 00000 n
-0000290229 00000 n
-0000274182 00000 n
-0000273991 00000 n
-0000271550 00000 n
-0000274117 00000 n
-0000277831 00000 n
-0000277254 00000 n
-0000274349 00000 n
-0000277380 00000 n
-0000277574 00000 n
-0000277639 00000 n
-0000281427 00000 n
-0000280978 00000 n
-0000277930 00000 n
-0000281104 00000 n
-0000281233 00000 n
-0000662214 00000 n
-0000286436 00000 n
-0000285904 00000 n
-0000281539 00000 n
-0000286371 00000 n
-0000286060 00000 n
-0000286211 00000 n
-0000290423 00000 n
-0000289542 00000 n
-0000286535 00000 n
-0000289843 00000 n
-0000289972 00000 n
-0000290100 00000 n
-0000289689 00000 n
-0000290358 00000 n
-0000292669 00000 n
-0000292349 00000 n
-0000290535 00000 n
-0000292475 00000 n
-0000294153 00000 n
-0000293962 00000 n
-0000292781 00000 n
-0000294088 00000 n
-0000295518 00000 n
-0000295327 00000 n
-0000294252 00000 n
-0000295453 00000 n
-0000299111 00000 n
-0000298534 00000 n
-0000295617 00000 n
-0000298660 00000 n
-0000298789 00000 n
-0000298916 00000 n
-0000298981 00000 n
-0000299046 00000 n
-0000662339 00000 n
-0000304138 00000 n
-0000302469 00000 n
-0000299223 00000 n
-0000303815 00000 n
-0000302670 00000 n
-0000303944 00000 n
-0000304073 00000 n
-0000302837 00000 n
-0000302999 00000 n
-0000303161 00000 n
-0000303323 00000 n
-0000303485 00000 n
-0000303655 00000 n
-0000468016 00000 n
-0000309282 00000 n
-0000307704 00000 n
-0000304250 00000 n
-0000309217 00000 n
-0000307914 00000 n
-0000308077 00000 n
-0000308238 00000 n
-0000308399 00000 n
-0000308561 00000 n
-0000308724 00000 n
-0000308887 00000 n
-0000309050 00000 n
-0000315518 00000 n
-0000312264 00000 n
-0000309407 00000 n
-0000315453 00000 n
-0000312564 00000 n
-0000312734 00000 n
-0000312896 00000 n
-0000313058 00000 n
-0000313220 00000 n
-0000313381 00000 n
-0000313544 00000 n
-0000313698 00000 n
-0000313851 00000 n
-0000314013 00000 n
-0000314175 00000 n
-0000314336 00000 n
-0000314498 00000 n
-0000314660 00000 n
-0000314822 00000 n
-0000314984 00000 n
-0000315137 00000 n
-0000315300 00000 n
-0000319925 00000 n
-0000319129 00000 n
-0000315643 00000 n
-0000319602 00000 n
-0000319285 00000 n
-0000319448 00000 n
-0000319796 00000 n
-0000319860 00000 n
-0000324215 00000 n
-0000323018 00000 n
-0000320050 00000 n
-0000323505 00000 n
-0000323634 00000 n
-0000323890 00000 n
-0000323174 00000 n
-0000323344 00000 n
-0000323955 00000 n
-0000324020 00000 n
-0000324085 00000 n
-0000324150 00000 n
-0000327541 00000 n
-0000327350 00000 n
-0000324340 00000 n
-0000327476 00000 n
-0000662464 00000 n
-0000331627 00000 n
-0000331048 00000 n
-0000327627 00000 n
-0000331174 00000 n
-0000331239 00000 n
-0000331304 00000 n
-0000331433 00000 n
-0000331497 00000 n
-0000331562 00000 n
-0000335658 00000 n
-0000334820 00000 n
-0000331752 00000 n
-0000334946 00000 n
-0000335011 00000 n
-0000335076 00000 n
-0000335205 00000 n
-0000335270 00000 n
-0000335335 00000 n
-0000335463 00000 n
-0000335528 00000 n
-0000335593 00000 n
-0000339159 00000 n
-0000338454 00000 n
-0000335783 00000 n
-0000338580 00000 n
-0000338709 00000 n
-0000338773 00000 n
-0000338838 00000 n
-0000338967 00000 n
-0000339094 00000 n
-0000342376 00000 n
-0000341669 00000 n
-0000339367 00000 n
-0000341795 00000 n
-0000341924 00000 n
-0000342053 00000 n
-0000342182 00000 n
-0000342247 00000 n
-0000342312 00000 n
-0000346285 00000 n
-0000345965 00000 n
-0000342557 00000 n
-0000346091 00000 n
-0000348311 00000 n
-0000347862 00000 n
-0000346410 00000 n
-0000347988 00000 n
-0000348117 00000 n
-0000348246 00000 n
-0000662589 00000 n
-0000352804 00000 n
-0000351860 00000 n
-0000348423 00000 n
-0000352223 00000 n
-0000479184 00000 n
-0000469971 00000 n
-0000478998 00000 n
-0000352007 00000 n
-0000352352 00000 n
-0000352481 00000 n
-0000352610 00000 n
-0000353844 00000 n
-0000353653 00000 n
-0000353039 00000 n
-0000353779 00000 n
-0000354271 00000 n
-0000354080 00000 n
-0000353930 00000 n
-0000354206 00000 n
-0000357584 00000 n
-0000356358 00000 n
-0000354313 00000 n
-0000356875 00000 n
-0000357004 00000 n
-0000357133 00000 n
-0000357262 00000 n
-0000357391 00000 n
-0000357520 00000 n
-0000356514 00000 n
-0000356686 00000 n
-0000358038 00000 n
-0000357847 00000 n
-0000357697 00000 n
-0000357973 00000 n
-0000361282 00000 n
-0000360704 00000 n
-0000358080 00000 n
-0000360830 00000 n
-0000360959 00000 n
-0000361088 00000 n
-0000361217 00000 n
-0000662714 00000 n
-0000365477 00000 n
-0000364259 00000 n
-0000361368 00000 n
-0000364769 00000 n
-0000364898 00000 n
-0000365156 00000 n
-0000364415 00000 n
-0000364594 00000 n
-0000365349 00000 n
-0000365413 00000 n
-0000372362 00000 n
-0000368534 00000 n
-0000365629 00000 n
-0000368660 00000 n
-0000368725 00000 n
-0000368790 00000 n
-0000368855 00000 n
-0000368920 00000 n
-0000368985 00000 n
-0000369050 00000 n
-0000369115 00000 n
-0000369180 00000 n
-0000369245 00000 n
-0000369375 00000 n
-0000369440 00000 n
-0000369505 00000 n
-0000369570 00000 n
-0000369635 00000 n
-0000369700 00000 n
-0000369765 00000 n
-0000369830 00000 n
-0000369895 00000 n
-0000369960 00000 n
-0000370025 00000 n
-0000370090 00000 n
-0000370155 00000 n
-0000370220 00000 n
-0000370285 00000 n
-0000370350 00000 n
-0000370415 00000 n
-0000370480 00000 n
-0000370545 00000 n
-0000370610 00000 n
-0000370675 00000 n
-0000370740 00000 n
-0000370805 00000 n
-0000370870 00000 n
-0000370934 00000 n
-0000370999 00000 n
-0000371064 00000 n
-0000371129 00000 n
-0000371194 00000 n
-0000371259 00000 n
-0000371324 00000 n
-0000371389 00000 n
-0000371454 00000 n
-0000371519 00000 n
-0000371584 00000 n
-0000371649 00000 n
-0000371714 00000 n
-0000371779 00000 n
-0000371844 00000 n
-0000371909 00000 n
-0000371974 00000 n
-0000372039 00000 n
-0000372104 00000 n
-0000372169 00000 n
-0000372234 00000 n
-0000372298 00000 n
-0000379008 00000 n
-0000375444 00000 n
-0000372474 00000 n
-0000375570 00000 n
-0000375635 00000 n
-0000375700 00000 n
-0000375765 00000 n
-0000375830 00000 n
-0000375895 00000 n
-0000375960 00000 n
-0000376025 00000 n
-0000376090 00000 n
-0000376155 00000 n
-0000376220 00000 n
-0000376285 00000 n
-0000376349 00000 n
-0000376414 00000 n
-0000376479 00000 n
-0000376544 00000 n
-0000376609 00000 n
-0000376674 00000 n
-0000376739 00000 n
-0000376804 00000 n
-0000376869 00000 n
-0000376934 00000 n
-0000376999 00000 n
-0000377064 00000 n
-0000377128 00000 n
-0000377193 00000 n
-0000377258 00000 n
-0000377323 00000 n
-0000377388 00000 n
-0000377453 00000 n
-0000377518 00000 n
-0000377583 00000 n
-0000377648 00000 n
-0000377713 00000 n
-0000377778 00000 n
-0000377843 00000 n
-0000377908 00000 n
-0000377973 00000 n
-0000378038 00000 n
-0000378103 00000 n
-0000378167 00000 n
-0000378231 00000 n
-0000378295 00000 n
-0000378360 00000 n
-0000378425 00000 n
-0000378490 00000 n
-0000378555 00000 n
-0000378620 00000 n
-0000378685 00000 n
-0000378750 00000 n
-0000378815 00000 n
-0000378880 00000 n
-0000378944 00000 n
-0000385183 00000 n
-0000381745 00000 n
-0000379120 00000 n
-0000381871 00000 n
-0000381936 00000 n
-0000382001 00000 n
-0000382066 00000 n
-0000382131 00000 n
-0000382196 00000 n
-0000382261 00000 n
-0000382326 00000 n
-0000382391 00000 n
-0000382456 00000 n
-0000382521 00000 n
-0000382586 00000 n
-0000382651 00000 n
-0000382716 00000 n
-0000382781 00000 n
-0000382846 00000 n
-0000382911 00000 n
-0000382976 00000 n
-0000383041 00000 n
-0000383106 00000 n
-0000383171 00000 n
-0000383236 00000 n
-0000383301 00000 n
-0000383366 00000 n
-0000383431 00000 n
-0000383496 00000 n
-0000383561 00000 n
-0000383626 00000 n
-0000383691 00000 n
-0000383756 00000 n
-0000383821 00000 n
-0000383886 00000 n
-0000383951 00000 n
-0000384016 00000 n
-0000384080 00000 n
-0000384145 00000 n
-0000384210 00000 n
-0000384275 00000 n
-0000384340 00000 n
-0000384405 00000 n
-0000384470 00000 n
-0000384535 00000 n
-0000384600 00000 n
-0000384665 00000 n
-0000384730 00000 n
-0000384795 00000 n
-0000384860 00000 n
-0000384925 00000 n
-0000384990 00000 n
-0000385055 00000 n
-0000385119 00000 n
-0000389762 00000 n
-0000387498 00000 n
-0000385295 00000 n
-0000387624 00000 n
-0000387689 00000 n
-0000387754 00000 n
-0000387819 00000 n
-0000387884 00000 n
-0000387949 00000 n
-0000388014 00000 n
-0000388079 00000 n
-0000388144 00000 n
-0000388209 00000 n
-0000388274 00000 n
-0000388339 00000 n
-0000388404 00000 n
-0000388469 00000 n
-0000388531 00000 n
-0000388595 00000 n
-0000388660 00000 n
-0000388724 00000 n
-0000388789 00000 n
-0000388854 00000 n
-0000388919 00000 n
-0000388984 00000 n
-0000389049 00000 n
-0000389114 00000 n
-0000389179 00000 n
-0000389308 00000 n
-0000389437 00000 n
-0000389502 00000 n
-0000389567 00000 n
-0000389632 00000 n
-0000389697 00000 n
-0000392556 00000 n
-0000391912 00000 n
-0000389887 00000 n
-0000392038 00000 n
-0000392167 00000 n
-0000392296 00000 n
-0000392361 00000 n
-0000392426 00000 n
-0000392491 00000 n
-0000662839 00000 n
-0000396894 00000 n
-0000396574 00000 n
-0000392668 00000 n
-0000396700 00000 n
-0000396765 00000 n
-0000396830 00000 n
-0000400491 00000 n
-0000400236 00000 n
-0000397046 00000 n
-0000400362 00000 n
-0000400427 00000 n
-0000403738 00000 n
-0000403547 00000 n
-0000400629 00000 n
-0000403673 00000 n
-0000407521 00000 n
-0000407265 00000 n
-0000403863 00000 n
-0000407391 00000 n
-0000407456 00000 n
-0000410695 00000 n
-0000409920 00000 n
-0000407659 00000 n
-0000410046 00000 n
-0000410111 00000 n
-0000410176 00000 n
-0000410241 00000 n
-0000410306 00000 n
-0000410435 00000 n
-0000410500 00000 n
-0000410565 00000 n
-0000410630 00000 n
-0000415163 00000 n
-0000414972 00000 n
-0000410833 00000 n
-0000415098 00000 n
-0000662964 00000 n
-0000418292 00000 n
-0000417519 00000 n
-0000415301 00000 n
-0000417645 00000 n
-0000417710 00000 n
-0000417775 00000 n
-0000417839 00000 n
-0000417968 00000 n
-0000418033 00000 n
-0000418097 00000 n
-0000418162 00000 n
-0000418227 00000 n
-0000421683 00000 n
-0000421427 00000 n
-0000418430 00000 n
-0000421553 00000 n
-0000421618 00000 n
-0000424546 00000 n
-0000423836 00000 n
-0000421821 00000 n
-0000423962 00000 n
-0000424027 00000 n
-0000424092 00000 n
-0000424157 00000 n
-0000424286 00000 n
-0000424351 00000 n
-0000424416 00000 n
-0000424481 00000 n
-0000428225 00000 n
-0000427969 00000 n
-0000424697 00000 n
-0000428095 00000 n
-0000428160 00000 n
-0000431662 00000 n
-0000431406 00000 n
-0000428350 00000 n
-0000431532 00000 n
-0000431597 00000 n
-0000434131 00000 n
-0000433423 00000 n
-0000431800 00000 n
-0000433549 00000 n
-0000433614 00000 n
-0000433679 00000 n
-0000433806 00000 n
-0000433871 00000 n
-0000433936 00000 n
-0000434001 00000 n
-0000434066 00000 n
-0000663089 00000 n
-0000437017 00000 n
-0000436243 00000 n
-0000434282 00000 n
-0000436369 00000 n
-0000436434 00000 n
-0000436499 00000 n
-0000436564 00000 n
-0000436692 00000 n
-0000436757 00000 n
-0000436822 00000 n
-0000436887 00000 n
-0000436952 00000 n
-0000440374 00000 n
-0000440183 00000 n
-0000437155 00000 n
-0000440309 00000 n
-0000443345 00000 n
-0000442636 00000 n
-0000440499 00000 n
-0000442762 00000 n
-0000442827 00000 n
-0000442892 00000 n
-0000442957 00000 n
-0000443085 00000 n
-0000443150 00000 n
-0000443215 00000 n
-0000443280 00000 n
-0000446857 00000 n
-0000446601 00000 n
-0000443496 00000 n
-0000446727 00000 n
-0000446792 00000 n
-0000449734 00000 n
-0000449478 00000 n
-0000447065 00000 n
-0000449604 00000 n
-0000449669 00000 n
-0000452735 00000 n
-0000451960 00000 n
-0000449942 00000 n
-0000452086 00000 n
-0000452151 00000 n
-0000452216 00000 n
-0000452281 00000 n
-0000452346 00000 n
-0000452475 00000 n
-0000452540 00000 n
-0000452605 00000 n
-0000452670 00000 n
-0000663214 00000 n
-0000456244 00000 n
-0000455601 00000 n
-0000452886 00000 n
-0000455727 00000 n
-0000455792 00000 n
-0000455857 00000 n
-0000455922 00000 n
-0000455987 00000 n
-0000456115 00000 n
-0000456180 00000 n
-0000459805 00000 n
-0000459419 00000 n
-0000456408 00000 n
-0000459545 00000 n
-0000459610 00000 n
-0000459675 00000 n
-0000459740 00000 n
-0000462158 00000 n
-0000461773 00000 n
-0000459930 00000 n
-0000461899 00000 n
-0000461964 00000 n
-0000462029 00000 n
-0000462094 00000 n
-0000465838 00000 n
-0000465258 00000 n
-0000462309 00000 n
-0000465384 00000 n
-0000465513 00000 n
-0000465578 00000 n
-0000465643 00000 n
-0000465708 00000 n
-0000465773 00000 n
-0000467865 00000 n
-0000467479 00000 n
-0000465976 00000 n
-0000467605 00000 n
-0000467670 00000 n
-0000467735 00000 n
-0000467800 00000 n
-0000468082 00000 n
-0000479426 00000 n
-0000481751 00000 n
-0000481720 00000 n
-0000491245 00000 n
-0000501302 00000 n
-0000511771 00000 n
-0000523978 00000 n
-0000542255 00000 n
-0000564344 00000 n
-0000585354 00000 n
-0000603172 00000 n
-0000606004 00000 n
-0000605774 00000 n
-0000633262 00000 n
-0000660371 00000 n
-0000663339 00000 n
-0000663462 00000 n
-0000663588 00000 n
-0000663714 00000 n
-0000663804 00000 n
-0000663896 00000 n
-0000679280 00000 n
-0000696733 00000 n
-0000696774 00000 n
-0000696814 00000 n
-0000696948 00000 n
+0000259012 00000 n
+0000262027 00000 n
+0000261857 00000 n
+0000262219 00000 n
+0000262284 00000 n
+0000262412 00000 n
+0000267096 00000 n
+0000266552 00000 n
+0000262658 00000 n
+0000267031 00000 n
+0000266708 00000 n
+0000266869 00000 n
+0000346375 00000 n
+0000271579 00000 n
+0000270943 00000 n
+0000267263 00000 n
+0000271257 00000 n
+0000481658 00000 n
+0000479660 00000 n
+0000481493 00000 n
+0000271386 00000 n
+0000271090 00000 n
+0000271515 00000 n
+0000290384 00000 n
+0000274337 00000 n
+0000274146 00000 n
+0000271705 00000 n
+0000274272 00000 n
+0000277986 00000 n
+0000277409 00000 n
+0000274504 00000 n
+0000277535 00000 n
+0000277729 00000 n
+0000277794 00000 n
+0000281582 00000 n
+0000281133 00000 n
+0000278085 00000 n
+0000281259 00000 n
+0000281388 00000 n
+0000662363 00000 n
+0000286591 00000 n
+0000286059 00000 n
+0000281694 00000 n
+0000286526 00000 n
+0000286215 00000 n
+0000286366 00000 n
+0000290578 00000 n
+0000289697 00000 n
+0000286690 00000 n
+0000289998 00000 n
+0000290127 00000 n
+0000290255 00000 n
+0000289844 00000 n
+0000290513 00000 n
+0000292824 00000 n
+0000292504 00000 n
+0000290690 00000 n
+0000292630 00000 n
+0000294308 00000 n
+0000294117 00000 n
+0000292936 00000 n
+0000294243 00000 n
+0000295673 00000 n
+0000295482 00000 n
+0000294407 00000 n
+0000295608 00000 n
+0000299266 00000 n
+0000298689 00000 n
+0000295772 00000 n
+0000298815 00000 n
+0000298944 00000 n
+0000299071 00000 n
+0000299136 00000 n
+0000299201 00000 n
+0000662488 00000 n
+0000304293 00000 n
+0000302624 00000 n
+0000299378 00000 n
+0000303970 00000 n
+0000302825 00000 n
+0000304099 00000 n
+0000304228 00000 n
+0000302992 00000 n
+0000303154 00000 n
+0000303316 00000 n
+0000303478 00000 n
+0000303640 00000 n
+0000303810 00000 n
+0000468171 00000 n
+0000309437 00000 n
+0000307859 00000 n
+0000304405 00000 n
+0000309372 00000 n
+0000308069 00000 n
+0000308232 00000 n
+0000308393 00000 n
+0000308554 00000 n
+0000308716 00000 n
+0000308879 00000 n
+0000309042 00000 n
+0000309205 00000 n
+0000315673 00000 n
+0000312419 00000 n
+0000309562 00000 n
+0000315608 00000 n
+0000312719 00000 n
+0000312889 00000 n
+0000313051 00000 n
+0000313213 00000 n
+0000313375 00000 n
+0000313536 00000 n
+0000313699 00000 n
+0000313853 00000 n
+0000314006 00000 n
+0000314168 00000 n
+0000314330 00000 n
+0000314491 00000 n
+0000314653 00000 n
+0000314815 00000 n
+0000314977 00000 n
+0000315139 00000 n
+0000315292 00000 n
+0000315455 00000 n
+0000320080 00000 n
+0000319284 00000 n
+0000315798 00000 n
+0000319757 00000 n
+0000319440 00000 n
+0000319603 00000 n
+0000319951 00000 n
+0000320015 00000 n
+0000324370 00000 n
+0000323173 00000 n
+0000320205 00000 n
+0000323660 00000 n
+0000323789 00000 n
+0000324045 00000 n
+0000323329 00000 n
+0000323499 00000 n
+0000324110 00000 n
+0000324175 00000 n
+0000324240 00000 n
+0000324305 00000 n
+0000327696 00000 n
+0000327505 00000 n
+0000324495 00000 n
+0000327631 00000 n
+0000662613 00000 n
+0000331782 00000 n
+0000331203 00000 n
+0000327782 00000 n
+0000331329 00000 n
+0000331394 00000 n
+0000331459 00000 n
+0000331588 00000 n
+0000331652 00000 n
+0000331717 00000 n
+0000335813 00000 n
+0000334975 00000 n
+0000331907 00000 n
+0000335101 00000 n
+0000335166 00000 n
+0000335231 00000 n
+0000335360 00000 n
+0000335425 00000 n
+0000335490 00000 n
+0000335618 00000 n
+0000335683 00000 n
+0000335748 00000 n
+0000339314 00000 n
+0000338609 00000 n
+0000335938 00000 n
+0000338735 00000 n
+0000338864 00000 n
+0000338928 00000 n
+0000338993 00000 n
+0000339122 00000 n
+0000339249 00000 n
+0000342531 00000 n
+0000341824 00000 n
+0000339522 00000 n
+0000341950 00000 n
+0000342079 00000 n
+0000342208 00000 n
+0000342337 00000 n
+0000342402 00000 n
+0000342467 00000 n
+0000346440 00000 n
+0000346120 00000 n
+0000342712 00000 n
+0000346246 00000 n
+0000348466 00000 n
+0000348017 00000 n
+0000346565 00000 n
+0000348143 00000 n
+0000348272 00000 n
+0000348401 00000 n
+0000662738 00000 n
+0000352959 00000 n
+0000352015 00000 n
+0000348578 00000 n
+0000352378 00000 n
+0000479339 00000 n
+0000470126 00000 n
+0000479153 00000 n
+0000352162 00000 n
+0000352507 00000 n
+0000352636 00000 n
+0000352765 00000 n
+0000353999 00000 n
+0000353808 00000 n
+0000353194 00000 n
+0000353934 00000 n
+0000354426 00000 n
+0000354235 00000 n
+0000354085 00000 n
+0000354361 00000 n
+0000357739 00000 n
+0000356513 00000 n
+0000354468 00000 n
+0000357030 00000 n
+0000357159 00000 n
+0000357288 00000 n
+0000357417 00000 n
+0000357546 00000 n
+0000357675 00000 n
+0000356669 00000 n
+0000356841 00000 n
+0000358193 00000 n
+0000358002 00000 n
+0000357852 00000 n
+0000358128 00000 n
+0000361437 00000 n
+0000360859 00000 n
+0000358235 00000 n
+0000360985 00000 n
+0000361114 00000 n
+0000361243 00000 n
+0000361372 00000 n
+0000662863 00000 n
+0000365632 00000 n
+0000364414 00000 n
+0000361523 00000 n
+0000364924 00000 n
+0000365053 00000 n
+0000365311 00000 n
+0000364570 00000 n
+0000364749 00000 n
+0000365504 00000 n
+0000365568 00000 n
+0000372517 00000 n
+0000368689 00000 n
+0000365784 00000 n
+0000368815 00000 n
+0000368880 00000 n
+0000368945 00000 n
+0000369010 00000 n
+0000369075 00000 n
+0000369140 00000 n
+0000369205 00000 n
+0000369270 00000 n
+0000369335 00000 n
+0000369400 00000 n
+0000369530 00000 n
+0000369595 00000 n
+0000369660 00000 n
+0000369725 00000 n
+0000369790 00000 n
+0000369855 00000 n
+0000369920 00000 n
+0000369985 00000 n
+0000370050 00000 n
+0000370115 00000 n
+0000370180 00000 n
+0000370245 00000 n
+0000370310 00000 n
+0000370375 00000 n
+0000370440 00000 n
+0000370505 00000 n
+0000370570 00000 n
+0000370635 00000 n
+0000370700 00000 n
+0000370765 00000 n
+0000370830 00000 n
+0000370895 00000 n
+0000370960 00000 n
+0000371025 00000 n
+0000371089 00000 n
+0000371154 00000 n
+0000371219 00000 n
+0000371284 00000 n
+0000371349 00000 n
+0000371414 00000 n
+0000371479 00000 n
+0000371544 00000 n
+0000371609 00000 n
+0000371674 00000 n
+0000371739 00000 n
+0000371804 00000 n
+0000371869 00000 n
+0000371934 00000 n
+0000371999 00000 n
+0000372064 00000 n
+0000372129 00000 n
+0000372194 00000 n
+0000372259 00000 n
+0000372324 00000 n
+0000372389 00000 n
+0000372453 00000 n
+0000379163 00000 n
+0000375599 00000 n
+0000372629 00000 n
+0000375725 00000 n
+0000375790 00000 n
+0000375855 00000 n
+0000375920 00000 n
+0000375985 00000 n
+0000376050 00000 n
+0000376115 00000 n
+0000376180 00000 n
+0000376245 00000 n
+0000376310 00000 n
+0000376375 00000 n
+0000376440 00000 n
+0000376504 00000 n
+0000376569 00000 n
+0000376634 00000 n
+0000376699 00000 n
+0000376764 00000 n
+0000376829 00000 n
+0000376894 00000 n
+0000376959 00000 n
+0000377024 00000 n
+0000377089 00000 n
+0000377154 00000 n
+0000377219 00000 n
+0000377283 00000 n
+0000377348 00000 n
+0000377413 00000 n
+0000377478 00000 n
+0000377543 00000 n
+0000377608 00000 n
+0000377673 00000 n
+0000377738 00000 n
+0000377803 00000 n
+0000377868 00000 n
+0000377933 00000 n
+0000377998 00000 n
+0000378063 00000 n
+0000378128 00000 n
+0000378193 00000 n
+0000378258 00000 n
+0000378322 00000 n
+0000378386 00000 n
+0000378450 00000 n
+0000378515 00000 n
+0000378580 00000 n
+0000378645 00000 n
+0000378710 00000 n
+0000378775 00000 n
+0000378840 00000 n
+0000378905 00000 n
+0000378970 00000 n
+0000379035 00000 n
+0000379099 00000 n
+0000385338 00000 n
+0000381900 00000 n
+0000379275 00000 n
+0000382026 00000 n
+0000382091 00000 n
+0000382156 00000 n
+0000382221 00000 n
+0000382286 00000 n
+0000382351 00000 n
+0000382416 00000 n
+0000382481 00000 n
+0000382546 00000 n
+0000382611 00000 n
+0000382676 00000 n
+0000382741 00000 n
+0000382806 00000 n
+0000382871 00000 n
+0000382936 00000 n
+0000383001 00000 n
+0000383066 00000 n
+0000383131 00000 n
+0000383196 00000 n
+0000383261 00000 n
+0000383326 00000 n
+0000383391 00000 n
+0000383456 00000 n
+0000383521 00000 n
+0000383586 00000 n
+0000383651 00000 n
+0000383716 00000 n
+0000383781 00000 n
+0000383846 00000 n
+0000383911 00000 n
+0000383976 00000 n
+0000384041 00000 n
+0000384106 00000 n
+0000384171 00000 n
+0000384235 00000 n
+0000384300 00000 n
+0000384365 00000 n
+0000384430 00000 n
+0000384495 00000 n
+0000384560 00000 n
+0000384625 00000 n
+0000384690 00000 n
+0000384755 00000 n
+0000384820 00000 n
+0000384885 00000 n
+0000384950 00000 n
+0000385015 00000 n
+0000385080 00000 n
+0000385145 00000 n
+0000385210 00000 n
+0000385274 00000 n
+0000389917 00000 n
+0000387653 00000 n
+0000385450 00000 n
+0000387779 00000 n
+0000387844 00000 n
+0000387909 00000 n
+0000387974 00000 n
+0000388039 00000 n
+0000388104 00000 n
+0000388169 00000 n
+0000388234 00000 n
+0000388299 00000 n
+0000388364 00000 n
+0000388429 00000 n
+0000388494 00000 n
+0000388559 00000 n
+0000388624 00000 n
+0000388686 00000 n
+0000388750 00000 n
+0000388815 00000 n
+0000388879 00000 n
+0000388944 00000 n
+0000389009 00000 n
+0000389074 00000 n
+0000389139 00000 n
+0000389204 00000 n
+0000389269 00000 n
+0000389334 00000 n
+0000389463 00000 n
+0000389592 00000 n
+0000389657 00000 n
+0000389722 00000 n
+0000389787 00000 n
+0000389852 00000 n
+0000392711 00000 n
+0000392067 00000 n
+0000390042 00000 n
+0000392193 00000 n
+0000392322 00000 n
+0000392451 00000 n
+0000392516 00000 n
+0000392581 00000 n
+0000392646 00000 n
+0000662988 00000 n
+0000397049 00000 n
+0000396729 00000 n
+0000392823 00000 n
+0000396855 00000 n
+0000396920 00000 n
+0000396985 00000 n
+0000400646 00000 n
+0000400391 00000 n
+0000397201 00000 n
+0000400517 00000 n
+0000400582 00000 n
+0000403893 00000 n
+0000403702 00000 n
+0000400784 00000 n
+0000403828 00000 n
+0000407676 00000 n
+0000407420 00000 n
+0000404018 00000 n
+0000407546 00000 n
+0000407611 00000 n
+0000410850 00000 n
+0000410075 00000 n
+0000407814 00000 n
+0000410201 00000 n
+0000410266 00000 n
+0000410331 00000 n
+0000410396 00000 n
+0000410461 00000 n
+0000410590 00000 n
+0000410655 00000 n
+0000410720 00000 n
+0000410785 00000 n
+0000415318 00000 n
+0000415127 00000 n
+0000410988 00000 n
+0000415253 00000 n
+0000663113 00000 n
+0000418447 00000 n
+0000417674 00000 n
+0000415456 00000 n
+0000417800 00000 n
+0000417865 00000 n
+0000417930 00000 n
+0000417994 00000 n
+0000418123 00000 n
+0000418188 00000 n
+0000418252 00000 n
+0000418317 00000 n
+0000418382 00000 n
+0000421838 00000 n
+0000421582 00000 n
+0000418585 00000 n
+0000421708 00000 n
+0000421773 00000 n
+0000424701 00000 n
+0000423991 00000 n
+0000421976 00000 n
+0000424117 00000 n
+0000424182 00000 n
+0000424247 00000 n
+0000424312 00000 n
+0000424441 00000 n
+0000424506 00000 n
+0000424571 00000 n
+0000424636 00000 n
+0000428380 00000 n
+0000428124 00000 n
+0000424852 00000 n
+0000428250 00000 n
+0000428315 00000 n
+0000431817 00000 n
+0000431561 00000 n
+0000428505 00000 n
+0000431687 00000 n
+0000431752 00000 n
+0000434286 00000 n
+0000433578 00000 n
+0000431955 00000 n
+0000433704 00000 n
+0000433769 00000 n
+0000433834 00000 n
+0000433961 00000 n
+0000434026 00000 n
+0000434091 00000 n
+0000434156 00000 n
+0000434221 00000 n
+0000663238 00000 n
+0000437172 00000 n
+0000436398 00000 n
+0000434437 00000 n
+0000436524 00000 n
+0000436589 00000 n
+0000436654 00000 n
+0000436719 00000 n
+0000436847 00000 n
+0000436912 00000 n
+0000436977 00000 n
+0000437042 00000 n
+0000437107 00000 n
+0000440529 00000 n
+0000440338 00000 n
+0000437310 00000 n
+0000440464 00000 n
+0000443500 00000 n
+0000442791 00000 n
+0000440654 00000 n
+0000442917 00000 n
+0000442982 00000 n
+0000443047 00000 n
+0000443112 00000 n
+0000443240 00000 n
+0000443305 00000 n
+0000443370 00000 n
+0000443435 00000 n
+0000447012 00000 n
+0000446756 00000 n
+0000443651 00000 n
+0000446882 00000 n
+0000446947 00000 n
+0000449889 00000 n
+0000449633 00000 n
+0000447220 00000 n
+0000449759 00000 n
+0000449824 00000 n
+0000452890 00000 n
+0000452115 00000 n
+0000450097 00000 n
+0000452241 00000 n
+0000452306 00000 n
+0000452371 00000 n
+0000452436 00000 n
+0000452501 00000 n
+0000452630 00000 n
+0000452695 00000 n
+0000452760 00000 n
+0000452825 00000 n
+0000663363 00000 n
+0000456399 00000 n
+0000455756 00000 n
+0000453041 00000 n
+0000455882 00000 n
+0000455947 00000 n
+0000456012 00000 n
+0000456077 00000 n
+0000456142 00000 n
+0000456270 00000 n
+0000456335 00000 n
+0000459960 00000 n
+0000459574 00000 n
+0000456563 00000 n
+0000459700 00000 n
+0000459765 00000 n
+0000459830 00000 n
+0000459895 00000 n
+0000462313 00000 n
+0000461928 00000 n
+0000460085 00000 n
+0000462054 00000 n
+0000462119 00000 n
+0000462184 00000 n
+0000462249 00000 n
+0000465993 00000 n
+0000465413 00000 n
+0000462464 00000 n
+0000465539 00000 n
+0000465668 00000 n
+0000465733 00000 n
+0000465798 00000 n
+0000465863 00000 n
+0000465928 00000 n
+0000468020 00000 n
+0000467634 00000 n
+0000466131 00000 n
+0000467760 00000 n
+0000467825 00000 n
+0000467890 00000 n
+0000467955 00000 n
+0000468237 00000 n
+0000479581 00000 n
+0000481905 00000 n
+0000481874 00000 n
+0000491398 00000 n
+0000501455 00000 n
+0000511923 00000 n
+0000524127 00000 n
+0000542404 00000 n
+0000564494 00000 n
+0000585504 00000 n
+0000603322 00000 n
+0000606153 00000 n
+0000605923 00000 n
+0000633411 00000 n
+0000660520 00000 n
+0000663488 00000 n
+0000663611 00000 n
+0000663737 00000 n
+0000663863 00000 n
+0000663953 00000 n
+0000664045 00000 n
+0000679429 00000 n
+0000696882 00000 n
+0000696923 00000 n
+0000696963 00000 n
+0000697097 00000 n
trailer
<<
/Size 1969
/Root 1967 0 R
/Info 1968 0 R
-/ID [<E6A90AEED63996B4645EFD22D9442323> <E6A90AEED63996B4645EFD22D9442323>]
+/ID [<5A978E7AECC3CFD4A1B098C19FF78DD9> <5A978E7AECC3CFD4A1B098C19FF78DD9>]
>>
startxref
-697206
+697355
%%EOF
diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html
index fed552ef07b8..750457309d61 100644
--- a/doc/arm/man.dig.html
+++ b/doc/arm/man.dig.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.dig.html,v 1.2.2.73 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.dig.html,v 1.2.2.75 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -52,7 +52,7 @@
<div class="cmdsynopsis"><p><code class="command">dig</code> [global-queryopt...] [query...]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2563811"></a><h2>DESCRIPTION</h2>
+<a name="id2563885"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">dig</strong></span>
(domain information groper) is a flexible tool
for interrogating DNS name servers. It performs DNS lookups and
@@ -98,7 +98,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2571483"></a><h2>SIMPLE USAGE</h2>
+<a name="id2570739"></a><h2>SIMPLE USAGE</h2>
<p>
A typical invocation of <span><strong class="command">dig</strong></span> looks like:
</p>
@@ -144,7 +144,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2571594"></a><h2>OPTIONS</h2>
+<a name="id2570850"></a><h2>OPTIONS</h2>
<p>
The <code class="option">-b</code> option sets the source IP address of the query
to <em class="parameter"><code>address</code></em>. This must be a valid
@@ -248,7 +248,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2625116"></a><h2>QUERY OPTIONS</h2>
+<a name="id2625123"></a><h2>QUERY OPTIONS</h2>
<p><span><strong class="command">dig</strong></span>
provides a number of query options which affect
the way in which lookups are made and the results displayed. Some of
@@ -569,7 +569,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2626171"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2626178"></a><h2>MULTIPLE QUERIES</h2>
<p>
The BIND 9 implementation of <span><strong class="command">dig </strong></span>
supports
@@ -615,7 +615,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2626325"></a><h2>IDN SUPPORT</h2>
+<a name="id2626331"></a><h2>IDN SUPPORT</h2>
<p>
If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
domain name) support, it can accept and display non-ASCII domain names.
@@ -629,14 +629,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2626354"></a><h2>FILES</h2>
+<a name="id2626428"></a><h2>FILES</h2>
<p><code class="filename">/etc/resolv.conf</code>
</p>
<p><code class="filename">${HOME}/.digrc</code>
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2626443"></a><h2>SEE ALSO</h2>
+<a name="id2626450"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
@@ -644,7 +644,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2626481"></a><h2>BUGS</h2>
+<a name="id2626487"></a><h2>BUGS</h2>
<p>
There are probably too many query options.
</p>
diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html
index 67fb5a6af50f..e439161c37e9 100644
--- a/doc/arm/man.dnssec-keygen.html
+++ b/doc/arm/man.dnssec-keygen.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.dnssec-keygen.html,v 1.2.2.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-keygen.html,v 1.2.2.76 2010/02/27 01:33:42 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code> {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2598979"></a><h2>DESCRIPTION</h2>
+<a name="id2598985"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">dnssec-keygen</strong></span>
generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
and RFC 4034. It can also generate keys for use with
@@ -58,7 +58,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2598993"></a><h2>OPTIONS</h2>
+<a name="id2598999"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
<dd>
@@ -166,7 +166,7 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2599473"></a><h2>GENERATED KEYS</h2>
+<a name="id2599479"></a><h2>GENERATED KEYS</h2>
<p>
When <span><strong class="command">dnssec-keygen</strong></span> completes
successfully,
@@ -212,7 +212,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2599580"></a><h2>EXAMPLE</h2>
+<a name="id2599587"></a><h2>EXAMPLE</h2>
<p>
To generate a 768-bit DSA key for the domain
<strong class="userinput"><code>example.com</code></strong>, the following command would be
@@ -233,7 +233,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2601548"></a><h2>SEE ALSO</h2>
+<a name="id2601486"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>,
<em class="citetitle">RFC 2539</em>,
@@ -242,7 +242,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2601579"></a><h2>AUTHOR</h2>
+<a name="id2601517"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html
index a48072d31690..5a8c6fe23726 100644
--- a/doc/arm/man.dnssec-signzone.html
+++ b/doc/arm/man.dnssec-signzone.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.dnssec-signzone.html,v 1.2.2.72 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-signzone.html,v 1.2.2.74 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code> [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2600453"></a><h2>DESCRIPTION</h2>
+<a name="id2600869"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">dnssec-signzone</strong></span>
signs a zone. It generates
NSEC and RRSIG records and produces a signed version of the
@@ -61,7 +61,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2600472"></a><h2>OPTIONS</h2>
+<a name="id2600888"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a</span></dt>
<dd><p>
@@ -259,7 +259,7 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2655020"></a><h2>EXAMPLE</h2>
+<a name="id2654958"></a><h2>EXAMPLE</h2>
<p>
The following command signs the <strong class="userinput"><code>example.com</code></strong>
zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
@@ -288,14 +288,14 @@ db.example.com.signed
%</pre>
</div>
<div class="refsect1" lang="en">
-<a name="id2655093"></a><h2>SEE ALSO</h2>
+<a name="id2655031"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>,
<em class="citetitle">RFC 4033</em>.
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2655117"></a><h2>AUTHOR</h2>
+<a name="id2655056"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html
index cf281efa2c71..f54c08c15d2b 100644
--- a/doc/arm/man.host.html
+++ b/doc/arm/man.host.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.host.html,v 1.2.2.71 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.host.html,v 1.2.2.73 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">host</code> [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2598285"></a><h2>DESCRIPTION</h2>
+<a name="id2598292"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">host</strong></span>
is a simple utility for performing DNS lookups.
It is normally used to convert names to IP addresses and vice versa.
@@ -202,7 +202,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2598800"></a><h2>IDN SUPPORT</h2>
+<a name="id2598806"></a><h2>IDN SUPPORT</h2>
<p>
If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
domain name) support, it can accept and display non-ASCII domain names.
@@ -216,12 +216,12 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2598828"></a><h2>FILES</h2>
+<a name="id2598835"></a><h2>FILES</h2>
<p><code class="filename">/etc/resolv.conf</code>
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2598842"></a><h2>SEE ALSO</h2>
+<a name="id2600419"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
</p>
diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html
index d3e8893d7e0c..a2beb7ffbad0 100644
--- a/doc/arm/man.named-checkconf.html
+++ b/doc/arm/man.named-checkconf.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.named-checkconf.html,v 1.2.2.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.named-checkconf.html,v 1.2.2.76 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,14 +50,14 @@
<div class="cmdsynopsis"><p><code class="command">named-checkconf</code> [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2600138"></a><h2>DESCRIPTION</h2>
+<a name="id2601851"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">named-checkconf</strong></span>
checks the syntax, but not the semantics, of a named
configuration file.
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2601040"></a><h2>OPTIONS</h2>
+<a name="id2601865"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
<dd><p>
@@ -88,21 +88,21 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2601142"></a><h2>RETURN VALUES</h2>
+<a name="id2601968"></a><h2>RETURN VALUES</h2>
<p><span><strong class="command">named-checkconf</strong></span>
returns an exit status of 1 if
errors were detected and 0 otherwise.
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2601156"></a><h2>SEE ALSO</h2>
+<a name="id2601981"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2601186"></a><h2>AUTHOR</h2>
+<a name="id2602011"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html
index 1c8748157e75..128e3043ab20 100644
--- a/doc/arm/man.named-checkzone.html
+++ b/doc/arm/man.named-checkzone.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.named-checkzone.html,v 1.2.2.78 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named-checkzone.html,v 1.2.2.80 2010/02/27 01:33:43 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -51,7 +51,7 @@
<div class="cmdsynopsis"><p><code class="command">named-compilezone</code> [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2602458"></a><h2>DESCRIPTION</h2>
+<a name="id2603216"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">named-checkzone</strong></span>
checks the syntax and integrity of a zone file. It performs the
same checks as <span><strong class="command">named</strong></span> does when loading a
@@ -71,7 +71,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2602508"></a><h2>OPTIONS</h2>
+<a name="id2603266"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-d</span></dt>
<dd><p>
@@ -251,14 +251,14 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2655786"></a><h2>RETURN VALUES</h2>
+<a name="id2656817"></a><h2>RETURN VALUES</h2>
<p><span><strong class="command">named-checkzone</strong></span>
returns an exit status of 1 if
errors were detected and 0 otherwise.
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2655800"></a><h2>SEE ALSO</h2>
+<a name="id2656830"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
<em class="citetitle">RFC 1035</em>,
@@ -266,7 +266,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2655833"></a><h2>AUTHOR</h2>
+<a name="id2656864"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html
index 8f7c217bf2c0..e8abccd7eea4 100644
--- a/doc/arm/man.named.html
+++ b/doc/arm/man.named.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.named.html,v 1.2.2.80 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named.html,v 1.2.2.82 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">named</code> [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2603363"></a><h2>DESCRIPTION</h2>
+<a name="id2603984"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">named</strong></span>
is a Domain Name System (DNS) server,
part of the BIND 9 distribution from ISC. For more
@@ -65,7 +65,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2603394"></a><h2>OPTIONS</h2>
+<a name="id2604014"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-4</span></dt>
<dd><p>
@@ -234,7 +234,7 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2605824"></a><h2>SIGNALS</h2>
+<a name="id2605898"></a><h2>SIGNALS</h2>
<p>
In routine operation, signals should not be used to control
the nameserver; <span><strong class="command">rndc</strong></span> should be used
@@ -255,7 +255,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2605874"></a><h2>CONFIGURATION</h2>
+<a name="id2605948"></a><h2>CONFIGURATION</h2>
<p>
The <span><strong class="command">named</strong></span> configuration file is too complex
to describe in detail here. A complete description is provided
@@ -264,7 +264,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2606098"></a><h2>FILES</h2>
+<a name="id2605968"></a><h2>FILES</h2>
<div class="variablelist"><dl>
<dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
<dd><p>
@@ -277,7 +277,7 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2606141"></a><h2>SEE ALSO</h2>
+<a name="id2606011"></a><h2>SEE ALSO</h2>
<p><em class="citetitle">RFC 1033</em>,
<em class="citetitle">RFC 1034</em>,
<em class="citetitle">RFC 1035</em>,
@@ -290,7 +290,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2606212"></a><h2>AUTHOR</h2>
+<a name="id2606082"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html
index ef2ef7953570..62e6746d8157 100644
--- a/doc/arm/man.rndc-confgen.html
+++ b/doc/arm/man.rndc-confgen.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.rndc-confgen.html,v 1.2.2.84 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: man.rndc-confgen.html,v 1.2.2.86 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,7 +48,7 @@
<div class="cmdsynopsis"><p><code class="command">rndc-confgen</code> [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2606467"></a><h2>DESCRIPTION</h2>
+<a name="id2606678"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">rndc-confgen</strong></span>
generates configuration files
for <span><strong class="command">rndc</strong></span>. It can be used as a
@@ -64,7 +64,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2606601"></a><h2>OPTIONS</h2>
+<a name="id2606812"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-a</span></dt>
<dd>
@@ -171,7 +171,7 @@
</dl></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2607056"></a><h2>EXAMPLES</h2>
+<a name="id2607267"></a><h2>EXAMPLES</h2>
<p>
To allow <span><strong class="command">rndc</strong></span> to be used with
no manual configuration, run
@@ -188,7 +188,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2618990"></a><h2>SEE ALSO</h2>
+<a name="id2627803"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -196,7 +196,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2619029"></a><h2>AUTHOR</h2>
+<a name="id2627842"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html
index a43638ad03f8..a37b6c6d0af7 100644
--- a/doc/arm/man.rndc.conf.html
+++ b/doc/arm/man.rndc.conf.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.rndc.conf.html,v 1.2.2.83 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.conf.html,v 1.2.2.85 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2603049"></a><h2>DESCRIPTION</h2>
+<a name="id2600666"></a><h2>DESCRIPTION</h2>
<p><code class="filename">rndc.conf</code> is the configuration file
for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
utility. This file has a similar structure and syntax to
@@ -135,7 +135,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2605201"></a><h2>EXAMPLE</h2>
+<a name="id2605480"></a><h2>EXAMPLE</h2>
<pre class="programlisting">
options {
default-server localhost;
@@ -209,7 +209,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2605390"></a><h2>NAME SERVER CONFIGURATION</h2>
+<a name="id2606284"></a><h2>NAME SERVER CONFIGURATION</h2>
<p>
The name server must be configured to accept rndc connections and
to recognize the key specified in the <code class="filename">rndc.conf</code>
@@ -219,7 +219,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2605416"></a><h2>SEE ALSO</h2>
+<a name="id2606310"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
@@ -227,7 +227,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2605454"></a><h2>AUTHOR</h2>
+<a name="id2606348"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html
index ea9afacd40b5..146018188c5e 100644
--- a/doc/arm/man.rndc.html
+++ b/doc/arm/man.rndc.html
@@ -1,5 +1,5 @@
<!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
- Copyright (C) 2000-2003 Internet Software Consortium.
-
- Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
-<!-- $Id: man.rndc.html,v 1.2.2.82 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.html,v 1.2.2.84 2010/02/27 01:33:45 tbox Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
<div class="cmdsynopsis"><p><code class="command">rndc</code> [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
</div>
<div class="refsect1" lang="en">
-<a name="id2604521"></a><h2>DESCRIPTION</h2>
+<a name="id2604801"></a><h2>DESCRIPTION</h2>
<p><span><strong class="command">rndc</strong></span>
controls the operation of a name
server. It supersedes the <span><strong class="command">ndc</strong></span> utility
@@ -79,7 +79,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2604571"></a><h2>OPTIONS</h2>
+<a name="id2604919"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl>
<dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
<dd><p>
@@ -151,7 +151,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2604865"></a><h2>LIMITATIONS</h2>
+<a name="id2605144"></a><h2>LIMITATIONS</h2>
<p><span><strong class="command">rndc</strong></span>
does not yet support all the commands of
the BIND 8 <span><strong class="command">ndc</strong></span> utility.
@@ -165,7 +165,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2604896"></a><h2>SEE ALSO</h2>
+<a name="id2605175"></a><h2>SEE ALSO</h2>
<p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
<span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -175,7 +175,7 @@
</p>
</div>
<div class="refsect1" lang="en">
-<a name="id2604951"></a><h2>AUTHOR</h2>
+<a name="id2605230"></a><h2>AUTHOR</h2>
<p><span class="corpauthor">Internet Systems Consortium</span>
</p>
</div>
diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
index f15b069b5ba7..3a9f1112f9fa 100644
--- a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt
+++ b/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
@@ -3,13 +3,27 @@
IPv6 Maintenance Working Group S. Kawamura
Internet-Draft NEC BIGLOBE, Ltd.
-Intended status: Informational M. Kawashima
-Expires: April 21, 2010 NEC AccessTechnica, Ltd.
- October 18, 2009
+Updates: 4291 (if approved) M. Kawashima
+Intended status: Standards Track NEC AccessTechnica, Ltd.
+Expires: August 29, 2010 February 25, 2010
A Recommendation for IPv6 Address Text Representation
- draft-ietf-6man-text-addr-representation-01
+ draft-ietf-6man-text-addr-representation-07
+
+Abstract
+
+ As IPv6 deployment increases there will be a dramatic increase in the
+ need to use IPv6 addresses in text. While the IPv6 address
+ architecture in RFC 4291 section 2.2 describes a flexible model for
+ text representation of an IPv6 address this flexibility has been
+ causing problems for operators, system engineers, and users. This
+ document defines a canonical textual representation format. It does
+ not define a format for internal storage, such as within an
+ application or database. It is expected that the canonical format is
+ followed by humans and systems when representing IPv6 addresses as
+ text, but all implementations must accept and be able to handle any
+ legitimate RFC 4291 format.
Status of this Memo
@@ -32,41 +46,71 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 21, 2010.
+ This Internet-Draft will expire on August 29, 2010.
Copyright Notice
- Copyright (c) 2009 IETF Trust and the persons identified as the
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 1]
+
+Internet-Draft IPv6 Text Representation February 2010
+
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Abstract
- As IPv6 network grows, there will be more engineers and also non-
- engineers who will have the need to use an IPv6 address in text.
-Kawamura & Kawashima Expires April 21, 2010 [Page 1]
-
-Internet-Draft IPv6 Text Representation October 2009
- While the IPv6 address architecture RFC 4291 section 2.2 depicts a
- flexible model for text representation of an IPv6 address, this
- flexibility has been causing problems for operators, system
- engineers, and users. This document will describe the problems that
- a flexible text representation has been causing. This document also
- recommends a canonical representation format that best avoids
- confusion. It is expected that the canonical format is followed by
- humans and systems when representing IPv6 addresses as text, but all
- implementations must accept and be able to handle any legitimate
- RFC4291 format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 2]
+
+Internet-Draft IPv6 Text Representation February 2010
Table of Contents
@@ -86,87 +130,43 @@ Table of Contents
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
+ 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 7
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
- 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
- 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10
- 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
+ 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9
4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10
4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
- 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Kawamura & Kawashima Expires April 21, 2010 [Page 2]
-
-Internet-Draft IPv6 Text Representation October 2009
-
-
- 5. Text Representation of Special Addresses . . . . . . . . . . . 11
+ 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5. Text Representation of Special Addresses . . . . . . . . . . . 10
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
- 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13
- Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima Expires April 21, 2010 [Page 3]
+Kawamura & Kawashima Expires August 29, 2010 [Page 3]
-Internet-Draft IPv6 Text Representation October 2009
+Internet-Draft IPv6 Text Representation February 2010
1. Introduction
@@ -190,11 +190,11 @@ Internet-Draft IPv6 Text Representation October 2009
2001:DB8:0:0:1::1
- All the above point to the same IPv6 address. This flexibility has
- caused many problems for operators, systems engineers, and customers.
- The problems will be noted in Section 3. Also, a canonical
- representation format to avoid problems will be introduced in
- Section 4.
+ All of the above examples represent the same IPv6 address. This
+ flexibility has caused many problems for operators, systems
+ engineers, and customers. The problems are noted in Section 3.
+ Also, a canonical representation format to avoid problems is
+ introduced in Section 4.
1.1. Requirements Language
@@ -213,16 +213,16 @@ Internet-Draft IPv6 Text Representation October 2009
'It is not necessary to write the leading zeros in an individual
field.'
- In other words, it is also not necessary to omit leading zeros. This
+ Conversely it is also not necessary to omit leading zeros. This
means that, it is possible to select from such as the following
example. The final 16 bit field is different, but all these
- addresses mean the same.
+ addresses represent the same address.
-Kawamura & Kawashima Expires April 21, 2010 [Page 4]
+Kawamura & Kawashima Expires August 29, 2010 [Page 4]
-Internet-Draft IPv6 Text Representation October 2009
+Internet-Draft IPv6 Text Representation February 2010
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
@@ -245,8 +245,8 @@ Internet-Draft IPv6 Text Representation October 2009
2001:db8:aaaa:bbbb:cccc:dddd:0:1
- In case where there are more than one zero fields, there is a choice
- of how many fields can be shortened. Examples follow.
+ In case where there is more than one zero fields, there is a choice
+ of how many fields can be shortened.
2001:db8:0:0:0::1
@@ -260,8 +260,8 @@ Internet-Draft IPv6 Text Representation October 2009
'The "::" can only appear once in an address.'
- This gives a choice on where, in a single address to compress the
- zero. Examples are shown below.
+ This gives a choice on where in a single address to compress the
+ zero.
2001:db8::aaaa:0:0:1
@@ -269,16 +269,16 @@ Internet-Draft IPv6 Text Representation October 2009
2.3. Uppercase or Lowercase
- [RFC4291] does not mention about preference of uppercase or
- lowercase. Various flavors are shown below.
+ [RFC4291] does not mention any preference of uppercase or lowercase.
-Kawamura & Kawashima Expires April 21, 2010 [Page 5]
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 5]
-Internet-Draft IPv6 Text Representation October 2009
+Internet-Draft IPv6 Text Representation February 2010
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
@@ -327,49 +327,45 @@ Internet-Draft IPv6 Text Representation October 2009
record is set to a database, one will likely check the output to see
if the entry is correct. If an entity was recorded as 2001:db8::/48,
but the whois output showed 2001:0db8:0000::/48, most non-engineers
- would think that their input was wrong, and will likely retry several
+ would think that their input was wrong and will likely retry several
times or make a frustrated call to the database hostmaster. If there
-Kawamura & Kawashima Expires April 21, 2010 [Page 6]
+Kawamura & Kawashima Expires August 29, 2010 [Page 6]
-Internet-Draft IPv6 Text Representation October 2009
+Internet-Draft IPv6 Text Representation February 2010
was a need to register the same address on different systems, and
each system showed a different text representation, this would
confuse people even more. Although this document focuses on
- addresses rather than prefixes, this is worth mentioning since
+ addresses rather than prefixes, this is worth mentioning since the
problems encountered are mostly equal.
3.1.4. Searching for an Address in a Network Diagram
- Network diagrams and blue-prints contain IP addresses as allocated to
- system devices. In times of trouble shooting, there may be a need to
- search through a diagram to find the point of failure (for example,
- if a traceroute stopped at 2001:db8::1, one would search the diagram
- for that address). This is a technique quite often in use in
- enterprise networks and managed services. Again, the different
- flavors of text representation will result in a time-consuming
- search, leading to longer MTTR in times of trouble.
+ Network diagrams and blueprints often show what IP addresses are
+ assigned to a system devices. In times of trouble shooting there may
+ be a need to search through a diagram to find the point of failure
+ (for example, if a traceroute stopped at 2001:db8::1, one would
+ search the diagram for that address). This is a technique quite
+ often in use in enterprise networks and managed services. Again, the
+ different flavors of text representation will result in a time-
+ consuming search leading to longer MTTR in times of trouble.
3.2. Parsing and Modifying
3.2.1. General Summary
- With all the possible text representation ways, each application must
- include a module, object, link, etc. to a function that will parse
- IPv6 addresses in a manner that no matter how it is represented, they
- will mean the same address. This is not too much a problem if the
- output is to be just 'read' or 'managed' by a network engineer.
- However, many system engineers who integrate complex computer systems
- to corporate customers will have difficulties finding that their
- favorite tool will not have this function, or will encounter
- difficulties such as having to rewrite their macro's or scripts for
- their customers. It must be noted that each additional line of a
- program will result in increased development fees that will be
- charged to the customers.
+ With all the possible methods of text representation each application
+ must include a module, object, link, etc. to a function that will
+ parse IPv6 addresses in a manner that no matter how it is
+ represented, they will mean the same address. Many system engineers
+ who integrate complex computer systems for corporate customers will
+ have difficulties finding that their favorite tool will not have this
+ function, or will encounter difficulties such as having to rewrite
+ their macros or scripts for their customers.
3.2.2. Logging
@@ -377,60 +373,57 @@ Internet-Draft IPv6 Text Representation October 2009
address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
the output would be highly unreadable compared to the IPv4 output.
The address would have to be parsed and reformed to make it useful
- for human reading. This will result in additional code on the
- applications which will result in extra fees charged to the
- customers. Sometimes, logging for critical systems is done by
+ for human reading. Sometimes logging for critical systems is done by
mirroring the same traffic to two different systems. Care must be
- taken that no matter what the log output is, the logs should be
+ taken so that no matter what the log output is the logs should be
parsed so they will mean the same.
+3.2.3. Auditing: Case 1
+ When a router or any other network appliance machine configuration is
+ audited, there are many methods to compare the configuration
+ information of a node. Sometimes auditing will be done by just
+ comparing the changes made each day. In this case if configuration
+ was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
-Kawamura & Kawashima Expires April 21, 2010 [Page 7]
+Kawamura & Kawashima Expires August 29, 2010 [Page 7]
-Internet-Draft IPv6 Text Representation October 2009
-
+Internet-Draft IPv6 Text Representation February 2010
-3.2.3. Auditing: Case 1
- When a router or any other network appliance machine configuration is
- audited, there are many methods to compare the configuration
- information of a node. Sometimes, auditing will be done by just
- comparing the changes made each day. In this case, if configuration
- was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
0000:0000:0000:0001 just because the new engineer on the block felt
- it was better, a simple diff will tell you that a different address
- was configured. If this was done on a wide scale network, people
- will be focusing on 'why the extra zeros were put in' instead of
- doing any real auditing. Lots of tools are just plain 'diff's that
- do not take into account address representation rules.
+ it was better, a simple diff will show that a different address was
+ configured. If this was done on a wide scale network people will be
+ focusing on 'why the extra zeros were put in' instead of doing any
+ real auditing. Lots of tools are just plain diffs that do not take
+ into account address representation rules.
3.2.4. Auditing: Case 2
Node configurations will be matched against an information system
- that manages IP addresses. If output notation is different, there
- will need to be a script that is implemented to cover for this. An
- SNMP GET of an interface address and text representation in a humanly
- written text file is highly unlikely to match on first try.
+ that manages IP addresses. If output notation is different there
+ will need to be a script that is implemented to cover for this. The
+ result of an SNMP GET operation, converted to text and compared to a
+ textual address written by a human is highly unlikely to match on the
+ first try.
3.2.5. Verification
Some protocols require certain data fields to be verified. One
- example of this is X.509 certificates. If an IPv6 address was
- embedded in one of the fields in a certificate, and the verification
- was done by just a simple textual comparison, the certificate may be
- maistakenly shown as being invalid due to a difference in text
- representation methods.
+ example of this is X.509 certificates. If an IPv6 address field in a
+ certificate was incorrectly verified by converting it to text and
+ making a simple textual comparison to some other address, the
+ certificate may be mistakenly shown as being invalid due to a
+ difference in text representation methods.
3.2.6. Unexpected Modifying
Sometimes, a system will take an address and modify it as a
convenience. For example, a system may take an input of
- 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
- RIR databases). If the zeros were input for a reason, the outcome
- may be somewhat unexpected.
+ 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were
+ input for a reason, the outcome may be somewhat unexpected.
3.3. Operating
@@ -438,34 +431,32 @@ Internet-Draft IPv6 Text Representation October 2009
When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
0:0:1, the system may take the address and show the configuration
- result as 2001:DB8::1:0:0:1. A distinguished engineer will know that
- the right address is set, but an operator, or a customer that is
- communicating with the operator to solve a problem, is usually not as
+ result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address
+ representation will know that the right address is set, but not
+ everyone may understand this.
+3.3.2. Customer Calls
+ When a customer calls to inquire about a suspected outage, IPv6
+ address representation should be handled with care. Not all
+ customers are engineers nor have the same skill in IPv6 technology.
+ The network operations center will have to take extra steps to
-Kawamura & Kawashima Expires April 21, 2010 [Page 8]
-
-Internet-Draft IPv6 Text Representation October 2009
- distinguished as we would like. Again, the extra load in checking
- that the IP address is the same as was intended, will result in fees
- that will be charged to the customers.
+Kawamura & Kawashima Expires August 29, 2010 [Page 8]
+
+Internet-Draft IPv6 Text Representation February 2010
-3.3.2. Customer Calls
- When a customer calls to inquire about a suspected outage, IPv6
- address representation should be handled with care. Not all
- customers are engineers nor have the same skill in IPv6 technology.
- The NOC will have to take extra steps to humanly parse the address to
- avoid having to explain to the customers that 2001:db8:0:1::1 is the
- same as 2001:db8::1:0:0:0:1. This is one thing that will never
- happen in IPv4 because IPv4 address cannot be abbreviated.
+ humanly parse the address to avoid having to explain to the customers
+ that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one
+ thing that will never happen in IPv4 because IPv4 address cannot be
+ abbreviated.
3.3.3. Abuse
- Network abuse is reported along with the abusing IP address. This
+ Network abuse reports generally include the abusing IP address. This
'reporting' could take any shape or form of the flexible model. A
team that handles network abuse must be able to tell the difference
between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
@@ -485,26 +476,14 @@ Internet-Draft IPv6 Text Representation October 2009
the same code may not work as expected due to the difference in IPv6
address text representation. Usually, a change in a platform (e.g.
Unix to Windows, Cisco to Juniper) will result in a major change of
- code, but flexibility in address representation will increase the
- work load which will again, result in fees that will be charged to
- the customers, and also longer down time of systems.
+ code anyway, but flexibility in address representation will increase
+ the work load.
3.4.2. Preference in Documentation
- A document that is edited by more than one author, may become harder
+ A document that is edited by more than one author may become harder
to read.
-
-
-
-
-
-
-Kawamura & Kawashima Expires April 21, 2010 [Page 9]
-
-Internet-Draft IPv6 Text Representation October 2009
-
-
3.4.3. Legibility
Capital case D and 0 can be quite often misread. Capital B and 8 can
@@ -517,70 +496,89 @@ Internet-Draft IPv6 Text Representation October 2009
addresses is presented in this section. The recommendation in this
document is one that, complies fully with [RFC4291], is implemented
by various operating systems, and is human friendly. The
- recommendation in this document SHOULD be followed by humans and
- systems when generating an address to represent as text, but all
- implementations MUST accept any legitimate [RFC4291] format.
+ recommendation in this section SHOULD be followed by systems when
+
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 9]
+
+Internet-Draft IPv6 Text Representation February 2010
+
+
+ generating an address to represent as text, but all implementations
+ MUST accept and be able to handle any legitimate [RFC4291] format.
+ It is advised that humans also follow these recommendations when
+ spelling an address.
4.1. Handling Leading Zeros in a 16 Bit Field
- Leading zeros should be chopped for human legibility and easier
- searching. Also, a single 16 bit 0000 field should be represented as
- just 0. Place holder zeros are often cause of misreading.
+ Leading zeros MUST be suppressed. For example 2001:0db8::0001 is not
+ acceptable and must be represented as 2001:db8::1. A single 16 bit
+ 0000 field MUST be represented as 0.
4.2. "::" Usage
4.2.1. Shorten As Much As Possible
- The use of "::" should be used to its maximum capability (i.e. 2001:
- db8::0:1 is not considered as clean representation).
+ The use of symbol "::" MUST be used to its maximum capability. For
+ example, 2001:db8::0:1 is not acceptable, because the symbol "::"
+ could have been used to produce a shorter representation 2001:db8::1.
4.2.2. Handling One 16 Bit 0 Field
- "::" should not be used to shorten just one 16 bit 0 field for it
- would tend to mislead that there are more than one 16 bit field that
- is shortened.
+ The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
+ For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+ 2001:db8::1:1:1:1:1 is not correct.
4.2.3. Choice in Placement of "::"
When there is an alternative choice in the placement of a "::", the
- longest run of consecutive 16 bit 0 fields should be shortened (i.e.
- latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the
- consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
- the former is shortened. This is consistent with many current
- implementations. One idea to avoid any confusion, is for the
- operator to not use 16 bit field 0 in the first 64 bits. By nature
- IPv6 addresses are usually assigned or allocated to end-users as
- longer than 32 bits (typically 48 bits or longer).
-
-
+ longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
+ the sequence with three consecutive zero fields is shortened in 2001:
+ 0:0:1:0:0:0:1). When the length of the consecutive 16 bit 0 fields
+ are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
+ bits MUST be shortened. For example 2001:db8::1:0:0:1 is correct
+ representation.
+4.3. Lower Case
+ The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
+ be represented in lower case.
-Kawamura & Kawashima Expires April 21, 2010 [Page 10]
-
-Internet-Draft IPv6 Text Representation October 2009
+5. Text Representation of Special Addresses
-4.3. Lower Case
+ Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+ IPv4-translatable addresses [I-D.ietf-behave-address-format] have
+ IPv4 addresses embedded in the low-order 32 bits of the address.
+ These addresses have special representation that may mix hexadecimal
+ and dot decimal notations. The decimal notation may be used only for
- Recent implementations tend to represent IPv6 address as lower case.
- It is better to use lower case to avoid problems such as described in
- section 3.3.3 and 3.4.3.
-5. Text Representation of Special Addresses
+Kawamura & Kawashima Expires August 29, 2010 [Page 10]
+
+Internet-Draft IPv6 Text Representation February 2010
+
+
+ the last 32 bits of the address. For these addresses, mixed notation
+ is RECOMMENDED if the following condition is met: The address can be
+ distinguished as having IPv4 addresses embedded in the lower 32 bits
+ solely from the address field through the use of a well known prefix.
+ Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+ writing. If it is known by some external method that a given prefix
+ is used to embed IPv4, it MAY be represented as mixed notation.
+ Tools that provide options to specify prefixes that are (or are not)
+ to be represented as mixed notation may be useful.
+
+ There is a trade-off here where a recommendation to achieve exact
+ match in a search (no dot decimals whatsoever) and recommendation to
+ help the readability of an addresses (dot decimal whenever possible)
+ does not result in the same solution. The above recommendation is
+ aimed at fixing the representation as much as possible while leaving
+ the opportunity for future well known prefixes to be represented in a
+ human friendly manner as tools adjust to newly assigned prefixes.
- Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
- IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
- the low-order 32 bits of the address. These addresses have special
- representation that may mix hexadecimal and decimal notations. In
- cases where there is a choice of whether to express the address as
- fully hexadecimal or hexadecimal and decimal mixed, and if the
- address type can be distinguished as having IPv4 addresses embedded
- in the lower 32 bits solely from the 128bits of the address field
- itself, mixed notation is the better choice. However, there may be
- situations where hexadecimal representation is chosen to meet certain
- needs. Addressing those needs is out of the scope of this document.
The text representation method noted in Section 4 should be applied
for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
0:0:0:0:0:ffff:192.0.2.1).
@@ -589,8 +587,8 @@ Internet-Draft IPv6 Text Representation October 2009
6. Notes on Combining IPv6 Addresses with Port Numbers
When IPv6 addresses and port numbers are represented in text combined
- together, there seems to be many different ways to do so. Examples
- are shown below.
+ together, there are many different ways to do so. Examples are shown
+ below.
o [2001:db8::1]:80
@@ -606,45 +604,36 @@ Internet-Draft IPv6 Text Representation October 2009
The situation is not much different in IPv4, but the most ambiguous
case with IPv6 is the second bullet. This is due to the "::"usage in
- IPv6 addresses. This style is not recommended for its ambiguity.
- The [] style as expressed in [RFC3986] is recommended. Other styles
- are acceptable when cross-platform portability does not become an
+ IPv6 addresses. This style is NOT RECOMMENDED for its ambiguity.
+ The [] style as expressed in [RFC3986] SHOULD be employed, and is the
+ default unless otherwise specified. Other styles are acceptable when
+ there is exactly one style for the given context and cross-platform
+ portability does not become an issue. For URIs containing IPv6
-Kawamura & Kawashima Expires April 21, 2010 [Page 11]
+Kawamura & Kawashima Expires August 29, 2010 [Page 11]
-Internet-Draft IPv6 Text Representation October 2009
-
-
- issue.
-
-
-7. Conclusion
-
- The recommended format of text representing an IPv6 address is
- summarized as follows.
+Internet-Draft IPv6 Text Representation February 2010
- (1) omit leading zeros in a 16 bit field
- (2) when using "::", shorten consecutive zero fields to their
- maximum extent (leave no zero fields behind).
+ address literals, [RFC3986] MUST be followed, as well as the rules in
+ this document.
- (3) "::" used where shortens address the most
- (4) "::" used in the former part in case of a tie breaker
+7. Prefix Representation
- (5) do not shorten one 16 bit 0 field, but always shorten when
- there are two or more consecutive 16 bit 0 fields
-
- (6) use lower case
-
- Hints for developers are written in the Appendix section.
+ Problems with prefixes are just the same as problems encountered with
+ addresses. The text representation method of IPv6 prefixes should be
+ no different from that of IPv6 addresses.
8. Security Considerations
- None.
+ This document notes some examples where IPv6 addresses are compared
+ in text format. The example on Section 3.2.5 is one that may cause a
+ security risk if used for access control. The common practice of
+ comparing X.509 data is done in binary format.
9. IANA Considerations
@@ -659,18 +648,10 @@ Internet-Draft IPv6 Text Representation October 2009
starting this document. We also would like to thank Brian Carpenter,
Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
- Vatiainen for their input. Also a very special thanks to Ron Bonica,
- Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
- Lindqvist for their support in bringing this document to the light of
- IETF working groups.
-
-
-
-
-
-Kawamura & Kawashima Expires April 21, 2010 [Page 12]
-
-Internet-Draft IPv6 Text Representation October 2009
+ Vatiainen ,Dan Wing, and Doug Barton for their input. Also a very
+ special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+ Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+ this document to the light of IETF working groups.
11. References
@@ -680,18 +661,32 @@ Internet-Draft IPv6 Text Representation October 2009
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-11.2. Informative References
-
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 12]
+
+Internet-Draft IPv6 Text Representation February 2010
+
+
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+11.2. Informative References
+
+ [I-D.ietf-behave-address-format]
+ Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+ draft-ietf-behave-address-format-04 (work in progress),
+ January 2010.
+
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
@@ -711,24 +706,6 @@ Appendix A. For Developers
be called directly. See [RFC4038] for details.
-Appendix B. Prefix Issues
-
- Problems with prefixes are just the same as problems encountered with
- addresses. Text representation method of IPv6 prefixes should be no
- different from that of IPv6 addresses.
-
-
-
-
-
-
-
-
-Kawamura & Kawashima Expires April 21, 2010 [Page 13]
-
-Internet-Draft IPv6 Text Representation October 2009
-
-
Authors' Addresses
Seiichi Kawamura
@@ -741,6 +718,17 @@ Authors' Addresses
Email: kawamucho@mesh.ad.jp
+
+
+
+
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 13]
+
+Internet-Draft IPv6 Text Representation February 2010
+
+
Masanobu Kawashima
NEC AccessTechnica, Ltd.
800, Shimomata
@@ -780,6 +768,18 @@ Authors' Addresses
-Kawamura & Kawashima Expires April 21, 2010 [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima Expires August 29, 2010 [Page 14]
diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt
deleted file mode 100644
index 25a6dd4d0726..000000000000
--- a/doc/draft/draft-ietf-behave-dns64-01.txt
+++ /dev/null
@@ -1,1624 +0,0 @@
-
-
-
-BEHAVE WG M. Bagnulo
-Internet-Draft UC3M
-Intended status: Standards Track A. Sullivan
-Expires: April 22, 2010 Shinkuro
- P. Matthews
- Alcatel-Lucent
- I. van Beijnum
- IMDEA Networks
- October 19, 2009
-
-
-DNS64: DNS extensions for Network Address Translation from IPv6 Clients
- to IPv4 Servers
- draft-ietf-behave-dns64-01
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on April 22, 2010.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 1]
-
-Internet-Draft DNS64 October 2009
-
-
-Abstract
-
- DNS64 is a mechanism for synthesizing AAAA records from A records.
- DNS64 is used with an IPv6/IPv4 translator to enable client-server
- communication between an IPv6-only client and an IPv4-only server,
- without requiring any changes to either the IPv6 or the IPv4 node,
- for the class of applications that work through NATs. This document
- specifies DNS64, and provides suggestions on how it should be
- deployed in conjunction with IPv6/IPv4 translators.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6
- 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9
- 5.1. Resolving AAAA queries and the answer section . . . . . . 9
- 5.1.1. The answer when there is AAAA data available . . . . . 9
- 5.1.2. The answer when there is an error . . . . . . . . . . 9
- 5.1.3. Data for the answer when performing synthesis . . . . 9
- 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10
- 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11
- 5.2. Generation of the IPv6 representations of IPv4
- addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12
- 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12
- 5.3.2. Handling the additional section . . . . . . . . . . . 13
- 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13
- 5.4. Assembling a synthesized response to a AAAA query . . . . 14
- 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14
- 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15
- 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16
- 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
- 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
- Appendix A. Deployment scenarios and examples . . . . . . . . . . 20
- A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21
- A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
- DNS server mode . . . . . . . . . . . . . . . . . . . . . 22
- A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in
- stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 2]
-
-Internet-Draft DNS64 October 2009
-
-
- A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
- server mode . . . . . . . . . . . . . . . . . . . . . . . 25
- Appendix B. Motivations and Implications of synthesizing AAAA
- RR when real AAAA RR exists . . . . . . . . . . . . . 27
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 3]
-
-Internet-Draft DNS64 October 2009
-
-
-1. Introduction
-
- This document specifies DNS64, a mechanism that is part of the
- toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
- together with an IPv6/IPv4 translator such as NAT64
- [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate
- communications by name to an IPv4-only server.
-
- DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
- from A RRs. A synthetic AAAA RR created by the DNS64 from an
- original A RR contains the same FQDN of the original A RR but it
- contains an IPv6 address instead of an IPv4 address. The IPv6
- address is an IPv6 representation of the IPv4 address contained in
- the original A RR. The IPv6 representation of the IPv4 address is
- algorithmically generated from the IPv4 address returned in the A RR
- and a set of parameters configured in the DNS64 (typically, an IPv6
- prefix used by IPv6 representations of IPv4 addresses and optionally
- other parameters).
-
- Together with a IPv6/IPv4 translator, these two mechanisms allow an
- IPv6-only client to initiate communications to an IPv4-only server
- using the FQDN of the server.
-
- These mechanisms are expected to play a critical role in the IPv4-
- IPv6 transition and co-existence. Due to IPv4 address depletion, it
- is likely that in the future, many IPv6-only clients will want to
- connect to IPv4-only servers. In the typical case, the approach only
- requires the deployment of IPv6/IPv4 translators that connect an
- IPv6-only network to an IPv4-only network, along with the deployment
- of one or more DNS64-enabled name servers. However, some advanced
- features require performing the DNS64 function directly by the end-
- hosts themselves.
-
-
-2. Overview
-
- This section provides a non-normative introduction to the DNS64
- mechanism.
-
- We assume that we have an IPv6/IPv4 translator box connecting an IPv4
- network and an IPv6 network. The IPv6/IPv4 translator device
- provides translation services between the two networks enabling
- communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By
- IPv6-only hosts we mean hosts running IPv6-only applications, hosts
- that can only use IPv6, as well as the cases where only IPv6
- connectivity is available to the client. By IPv4-only servers we
- mean servers running IPv4-only applications, servers that can only
- use IPv4, as well as the cases where only IPv4 connectivity is
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 4]
-
-Internet-Draft DNS64 October 2009
-
-
- available to the server). The IPv6/IPv4 translator used in
- conjunction with DNS64 must allow communications initiated from the
- IPv6-only host to the IPv4-only host.
-
- To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
- learn the address of the responder, DNS64 is used to synthesize a
- AAAA record from an A record containing a real IPv4 address of the
- responder, whenever the DNS64 service cannot retrieve a AAAA record
- for the requested host name. The DNS64 device appears as a regular
- recursive resolver for the IPv6 initiator. The DNS64 box receives an
- AAAA DNS query generated by the IPv6 initiator. It first attempts a
- recursive resolution for the requested AAAA records. If there is no
- AAAA record available for the target node (which is the normal case
- when the target node is an IPv4-only node), DNS64 performs a query
- for A records. If any A records are discovered, DNS64 creates a
- synthetic AAAA RR from the information retrieved in each A RR.
-
- The FQDN of a synthetic AAAA RR is the same as that of the original A
- RR, but an IPv6 representation of the IPv4 address contained in the
- original A RR is included in the AAAA RR. The IPv6 representation of
- the IPv4 address is algorithmically generated from the IPv4 address
- and additional parameters configured in the DNS64. Among those
- parameters configured in the DNS64, there is at least one IPv6
- prefix, called Pref64::/n. The IPv6 address representing IPv4
- addresses included in the AAAA RR synthesized by the DNS64 function
- contain Pref64::/n and they also embed the original IPv4 address.
-
- The same algorithm and the same Pref64::/n prefix or prefixes must be
- configured both in the DNS64 device and the IPv6/IPv4 translator, so
- that both can algorithmically generate the same IPv6 representation
- for a given IPv4 address. In addition, it is required that IPv6
- packets addressed to an IPv6 destination that contains the Pref64::/n
- be delivered to the IPv6/IPv4 translator, so they can be translated
- into IPv4 packets.
-
- Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
- passed back to the IPv6 initiator, which will initiate an IPv6
- communication with the IPv6 address associated with the IPv4
- receiver. The packet will be routed to the IPv6/IPv4 translator
- which will forward it to the IPv4 network .
-
- In general, the only shared state between the DNS64 and the IPv6/IPv4
- translator is the Pref64::/n and an optional set of static
- parameters. The Pref64::/n and the set of static parameters must be
- configured to be the same on both; there is no communication between
- the DNS64 device and IPv6/IPv4 translator functions. The mechanism
- to be used for configuring the parameters of the DNS64 is beyond the
- scope of this memo.
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 5]
-
-Internet-Draft DNS64 October 2009
-
-
- The DNS64 function can be performed in two places.
-
- One option is to locate the DNS64 function in recursive name
- servers serving end hosts. In this case, when an IPv6-only host
- queries the name server for AAAA RRs for an IPv4-only host, the
- name server can perform the synthesis of AAAA RRs and pass them
- back to the IPv6 only initiator. The main advantage of this mode
- is that current IPv6 nodes can use this mechanism without
- requiring any modification. This mode is called "DNS64 in DNS
- server mode".
-
- The other option is to place the DNS64 function in the end hosts
- themselves, 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 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"".
-
-
-3. Background to DNS64 - DNSSEC interaction
-
- DNSSEC presents a special challenge for DNS64, because DNSSEC is
- designed to detect changes to DNS answers, and DNS64 may alter
- answers coming from an authoritative server.
-
- A recursive resolver can be security-aware or security-oblivious.
- Moreover, a security-aware recursive name server can be validating or
- non-validating, according to operator policy. In the cases below,
- the recursive server is also performing DNS64, and has a local policy
- to validate. We call this general case vDNS64, but in all the cases
- below the DNS64 functionality should be assumed needed.
-
- DNSSEC includes some signaling bits that offer some indicators of
- what the query originator understands.
-
- If a query arrives at a vDNS64 device with the DO bit set, the query
- originator is signaling that it understands DNSSEC. The DO bit does
- not indicate that the query originator will validate the response.
- It only means that the query originator can understand responses
- containing DNSSEC data. Conversely, if the DO bit is clear, that is
- evidence that the querying agent is not aware of DNSSEC.
-
- If a query arrives at a vDNS64 device with the CD bit set, it is an
- indication that the querying agent wants all the validation data so
- it can do checking itself. By local policy, vDNS64 could still
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 6]
-
-Internet-Draft DNS64 October 2009
-
-
- validate, but it must return all data to the querying agent anyway.
-
- Here are the possible cases:
-
- 1. A security-oblivious DNS64 node receives a query with the DO bit
- clear. In this case, DNSSEC is not a concern, because the
- querying agent does not understand DNSSEC responses.
-
- 2. A security-oblivious DNS64 node receives a query with the DO bit
- set, and the CD bit clear. This is just like the case of a non-
- DNS64 case: the server doesn't support it, so the querying agent
- is out of luck.
-
- 3. A security-aware and non-validating DNS64 node receives a query
- with the DO bit set and the CD bit clear. Such a resolver is not
- validating responses, likely due to local policy (see [RFC4035],
- section 4.2). For that reason, this case amounts to the same as
- the previous case, and no validation happens.
-
- 4. A security-aware and non-validating DNS64 node receives a query
- with the DO bit set and the CD bit set. In this case, the
- resolver is supposed to pass on all the data it gets to the query
- initiator (see section 3.2.2 of [RFC4035]). This case will be
- problematic with DNS64. If the DNS64 server modifies the record,
- the client will get the data back and try to validate it, and the
- data will be invalid as far as the client is concerned.
-
- 5. A security-aware and validating DNS64 node receives a query with
- the DO bit clear and CD clear. In this case, the resolver
- validates the data. If it fails, it returns RCODE 2 (SERVFAIL);
- otherwise, it returns the answer. This is the ideal case for
- vDNS64. The resolver validates the data, and then synthesizes
- the new record and passes that to the client. The client, which
- is presumably not validating (else it would 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. In principle, this ought to work
- like the previous case, except that the resolver should also set
- the AD bit on the response.
-
- 7. A security-aware and validating DNS64 node receives a query with
- the DO bit set and CD set. This is effectively the same as the
- case where a security-aware and non-validating recursive resolver
- receives a similar query, and the same thing will happen: the
- downstream validator will mark the data as invalid if DNS64 has
- performed synthesis.
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 7]
-
-Internet-Draft DNS64 October 2009
-
-
-4. Terminology
-
- This section provides definitions for the special terms used in the
- document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
- Authoritative server: A DNS server that can answer authoritatively a
- given DNS question.
-
- DNS64: A logical function that synthesizes DNS resource records (e.g
- AAAA records containing IPv6 addresses) from DNS resource records
- actually contained in the global DNS (e.g. A records containing
- IPv4 addresses).
-
- DNS64 recursor: A recursive resolver that provides the DNS64
- functionality as part of its operation.
-
- Recursive resolver: A DNS server that accepts requests from one
- resolver, and asks another resolver for the answer on behalf of
- the first resolver. In the context of this document, "the
- recursive resolver" means a recursive resolver immediately next in
- the DNS resolution chain from an end point. The end point usually
- has only a stub resolver available.[[anchor5: I can't actually
- remember why we needed the sentences following "In the context of
- this document. . ." Unless someone has a reason, I'll take it
- out. --ajs@shinkuro.com]]
-
- 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.
-
- Stub resolver: A resolver with minimum functionality, typically for
- use in end points that depend on a recursive resolver. Most end
- points on the Internet as of this writing use stub
- resolvers.[[anchor6: Do we need this in the document? I don't
- think so. 1034 defines this term. --ajs@shinkuro.com]]
-
- IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
- packets and vice-versa. It is only required that the
- communication initiated from the IPv6 side be supported.
-
- For a detailed understanding of this document, the reader should also
- be familiar with DNS terminology from [RFC1034],[RFC1035] and current
- NAT terminology from [RFC4787]. Some parts of this document assume
- familiarity with the terminology of the DNS security extensions
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 8]
-
-Internet-Draft DNS64 October 2009
-
-
- outlined in [RFC4035].
-
-
-5. DNS64 Normative Specification
-
- A DNS64 is a logical function that synthesizes AAAA records from A
- records. The DNS64 function may be implemented in a stub resolver,
- in a recursive resolver, or in an authoritative name server.
-
- The implementation SHOULD support mapping of IPv4 address ranges to
- separate IPv6 prefixes for AAAA record synthesis. This allows
- handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
- Multicast address handling is further specified in
- [I-D.venaas-behave-mcast46].
-
-5.1. Resolving AAAA queries and the answer section
-
- When the DNS64 receives a query for RRs of type AAAA and class IN, it
- first attempts to retrieve non-synthetic RRs of this type and class,
- either by performing a query or, in the case of an authoritative
- server, by examining its own results.
-
-5.1.1. The answer when there is AAAA data available
-
- If the query results in one or more AAAA records in the answer
- section, the result is returned to the requesting client as per
- normal DNS semantics (except in the case where the AAAA falls in the
- ::ffff/96 network; see below for treatment of that network). In this
- case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response
- (see Appendix B for an analysis of the motivations for and the
- implications of not complying with this recommendation). By default
- DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
- exist.
-
-5.1.2. The answer when there is an error
-
- If the query results in a response with an error code other than 0,
- the result is handled according to normal DNS operation -- that is,
- either the resolver tries again using a different server from the
- authoritative NS RRSet, or it returns the error to the client. This
- stage is still prior to any synthesis having happened, so a response
- to be returned to the client does not need any special assembly than
- would usually happen in DNS operation.
-
-5.1.3. Data for the answer when performing synthesis
-
- If the query results in no error but an empty answer section in the
- response, the DNS64 resolver attempts to retrieve A records for the
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 9]
-
-Internet-Draft DNS64 October 2009
-
-
- name in question. If this new A RR query results in an empty answer
- or in an error, then the empty result or error is used as the basis
- for the answer returned to the querying client. (Transient errors
- may result in retrying the query, depening on the operation of the
- resolver; this is just as in Section 5.1.2.) If instead the query
- results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
- the A RRs according to the procedure outlined in Section 5.1.4. The
- DNS64 resolver then returns the synthesized AAAA records in the
- answer section to the client, removing the A records that form the
- basis of the synthesis.
-
- As an exception to the general rule about always returning the AAAA
- records if they are returned in the answer, AAAA records with
- addresses in the ::ffff/96 network are treated just like the case
- where there is neither an error nor an empty answer section. This is
- because a real IPv6-only node will not be any more able to reach the
- addresses in ::ffff/96 than it is able to reach an IPv4 address
- without assistance. An implementation MAY use the address in
- ::ffff/96 as the basis of synthesis without querying for an A record,
- by using the last 32 bits of the address provided in the AAAA record.
- [[anchor10: I changed this to say "neither. . .nor" because the
- previous version suggested that it would return the error-or-empty-
- answer to the querying client, and that can't be right. Correct?
- --ajs@shinkuro.com]]
-
-5.1.4. Performing the synthesis
-
- A synthetic AAAA record is created from an A record as follows:
-
- o The NAME field is set to the NAME field from the A record
-
- o The TYPE field is set to 28 (AAAA)
-
- o The CLASS field is set to 1 (IN)
-
- o The TTL field is set to the minimum of the TTL of the original A
- RR and the SOA RR for the queried domain. (Note that in order to
- obtain the TTL of the SOA RR the DNS64 does not need to perform a
- new query, but it can remember the TTL from the SOA RR in the
- negative response to the AAAA query).
-
- 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
- check each A RR against 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
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 10]
-
-Internet-Draft DNS64 October 2009
-
-
- effecting the transformation.
-
-5.1.5. Querying in parallel
-
- 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 no AAAA RR
- synthesis is required. A possible trade-off would be to perform them
- sequentially but with a very short interval between them, so if we
- obtain a fast reply, we avoid doing the additional query. (Note that
- this discussion is relevant only if the DNS64 function needs to
- perform external queries to fetch the RR. If the needed RR
- information is available locally, as in the case of an authoritative
- server, the issue is no longer relevant.)
-
-5.2. Generation of the IPv6 representations of IPv4 addresses
-
- DNS64 supports multiple algorithms for the generation of the IPv6
- representation of an IPv4 address. The constraints imposed on the
- generation algorithms are the following:
-
- The same algorithm to create an IPv6 address from an IPv4 address
- MUST be used by both the DNS64 to create the IPv6 address to be
- returned in the synthetic AAAA RR from the IPv4 address contained
- in original A RR, and by the IPv6/IPv4 translator to create the
- IPv6 address to be included in the destination address field of
- the outgoing IPv6 packets from the IPv4 address included in the
- destination address field of the incoming IPv4 packet.
-
- The algorithm MUST be reversible, i.e. it MUST be possible to
- extract the original IPv4 address from the IPv6 representation.
-
- The input for the algorithm MUST be limited to the IPv4 address,
- the IPv6 prefix (denoted Pref64::/n) used in the IPv6
- representations and optionally a set of stable parameters that are
- configured in the DNS64 (such as fixed string to be used as a
- suffix).
-
- If we note n the length of the prefix Pref64::/n, then n MUST
- the less or equal than 96. If a Pref64::/n is configured
- through any means in the DNS64 (such as manually configured, or
- other automatic mean not specified in this document), the
- default algorithm MUST use this prefix. If no prefix is
- available, the algorithm MUST use the Well-Known prefix TBD1
- defined in [I-D.thaler-behave-translator-addressing]
-
- [[anchor12: Note in document: TBD1 in the passage above is to be
- substituted by whatever prefix is assigned by IANA to be the well-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 11]
-
-Internet-Draft DNS64 October 2009
-
-
- known prefix.]]
-
- DNS64 MUST support the following algorithms for generating IPv6
- representations of IPv4 addresses defined in
- [I-D.thaler-behave-translator-addressing]:
-
- Zero-Pad And Embed, defined in section 3.2.3 of
- [I-D.thaler-behave-translator-addressing]
-
- Compensation-Pad And Embed, defined in section of 3.2.4 of
- [I-D.thaler-behave-translator-addressing]
-
- Embed And Zero-Pad, defined in section of 3.2.5 of
- [I-D.thaler-behave-translator-addressing]
-
- Preconfigured Mapping Table, defined in section of 3.2.6 of
- [I-D.thaler-behave-translator-addressing]
-
- The default algorithm used by DNS64 must be Embed and Zero-Pad.
- While the normative description of the algorithms is provided in
- [I-D.thaler-behave-translator-addressing], an sample description of
- the algorithm and its application to different scenarios is provided
- in Appendix A for illustration purposes.
-
-5.3. Handling other RRs
-
-5.3.1. PTR queries
-
- If a DNS64 nameserver receives a PTR query for a record in the
- IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
- reverse the address portion of the QNAME according to the encoding
- scheme outlined in section 2.5 of [RFC3596] , and examine the
- resulting address to see whether its prefix matches the locally-
- configured Pref64::/n. There are two alternatives for a DNS64
- nameserver to respond to such PTR queries. A DNS64 node MUST provide
- one of these, and SHOULD NOT provide both at the same time unless
- different IP6.ARPA zones require answers of different sorts.
-
- The first option is for the DNS64 nameserver to respond
- authoritatively for its prefixes. If the address prefix matches any
- Pref64::/n used in the site, either a LIR prefix or a well-known
- prefix used for NAT64 as defined in
- [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY
- answer the query using locally-appropriate RDATA. The DNS64 server
- MAY use the same RDATA for all answers. Note that the requirement is
- to match any Pref64::/n used at the site, and not merely the locally-
- configured Pref64::/n. This is because end clients could ask for a
- PTR record matching an address received through a different (site-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 12]
-
-Internet-Draft DNS64 October 2009
-
-
- provided) DNS64, and if this strategy is in effect, those queries
- should never be sent to the global DNS. The advantage of this
- strategy is that it makes plain to the querying client that the
- prefix is one operated by the DNS64 site, and that the answers the
- client is getting are generated by the DNS64. The disadvantage is
- that any useful reverse-tree information that might be in the global
- DNS is unavailable to the clients querying the DNS64.
-
- 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. [[anchor15: what are we supposed to do
- here when the in-addr.arpa zone is unmaintained, as it may be. If
- there is no data at the target name, then we'll get a CNAME with a
- map to an empty namespace, I think? Isn't that bad?
- --ajs@shinkuro.com]]
-
- If the address prefix does not match any of the Pref64::/n, then the
- DNS64 server MUST process the query as though it were any other query
- -- i.e. a recursive nameserver MUST attempt to resolve the query as
- though it were any other (non-A/AAAA) query, and an authoritative
- server MUST respond authoritatively or with a referral, as
- appropriate.
-
-5.3.2. Handling the additional section
-
- DNS64 synthesis MUST NOT be performed on any records in the
- additional section of synthesized answers. The DNS64 MUST pass the
- additional section unchanged.
-
- [[anchor16: We had some discussion, as an alternative to the above,
- of allowing the DNS64 to truncate the additional section completely,
- on the grounds that the additional section could break mixed-mode
- iterative/forwarding resolvers that happen to end up behind DNS64.
- Nobody else seemed to like that plan, so I haven't included it.
- --ajs@shinkuro.com]]
-
-5.3.3. Other records
-
- If the DNS64 is in recursive resolver mode, then it SHOULD also serve
- the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
- than forwarding those queries elsewhere to be handled.
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 13]
-
-Internet-Draft DNS64 October 2009
-
-
- All other RRs MUST be returned unchanged.
-
-5.4. Assembling a synthesized response to a AAAA query
-
- The DNS64 uses different pieces of data to build the response
- returned to the querying client.
-
- The query that is used as the basis for synthesis results either in
- an error, an answer that can be used as a basis for synthesis, or an
- empty (authoritative) answer. If there is an empty answer, then the
- DNS64 responds to the original querying client with the answer the
- DNS64 received to the original AAAA query. Otherwise, the response
- is assembled as follows.
-
- The header fields are set according to the usual rules for recursive
- or authoritative servers, depending on the role that the DNS64 is
- serving. The question section is copied from the original AAAA
- query. The answer section is populated according to the rules in
- Section 5.1.4. The authority section is copied from the response to
- the A query that the DNS64 performed. The additional section is
- populated according to the rules in Section 5.3.2.
-
- [[anchor18: The cross-reference to how to do the additional section
- can be removed, and replaced by "copied from the response to the A
- query that the DNS64 performed" if we don't want to allow the DNS64
- to truncate the additional section. See the note above. If I hear
- no more feedback on this topic, then I'll make this change in the
- next version. --ajs@shinkuro.com]]
-
-5.5. DNSSEC processing: DNS64 in recursive server mode
-
- We consider the case where the recursive server that is performing
- DNS64 also has a local policy to validate the answers according to
- the procedures outlined in [RFC4035] Section 5. We call this general
- case vDNS64.
-
- The vDNS64 uses the presence of the DO and CD bits to make some
- decisions about what the query originator needs, and can react
- accordingly:
-
- 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
- validation and do synthesis as needed.
-
- 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
- validation. Whenever vDNS64 performs validation, it MUST
- validate the negative answer for AAAA queries before proceeding
- to query for A records for the same name, in order to be sure
- that there is not a legitimate AAAA record on the Internet.
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 14]
-
-Internet-Draft DNS64 October 2009
-
-
- Failing to observe this step would allow an attacker to use DNS64
- as a mechanism to circumvent DNSSEC. If the negative response
- validates, and the response to the A query validates, then the
- vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
- answer to the client. This is acceptable, because [RFC4035],
- section 3.2.3 says that the AD bit is set by the name server side
- of a security-aware recursive name server if and only if it
- considers all the RRSets in the Answer and Authority sections to
- be authentic. In this case, the name server has reason to
- believe the RRSets are all authentic, so it SHOULD set the AD
- bit. If the data does not validate, the vDNS64 MUST respond with
- RCODE=2 (server failure).
- A security-aware end point might take the presence of the AD bit
- as an indication that the data is valid, and may pass the DNS
- (and DNSSEC) data to an application. If the application attempts
- to validate the synthesized data, of course, the validation will
- fail. One could argue therefore that this approach is not
- desirable. But security aware stub resolvers MUST NOT place any
- reliance on data received from resolvers and validated on their
- behalf without certain criteria established by [RFC4035], section
- 4.9.3. An application that wants to perform validation on its
- own should use the CD bit.
-
- 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
- validation, but MUST NOT perform synthesis. It MUST hand the
- data back to the query initiator, just like a regular recursive
- resolver, and depend on the client to do the validation and the
- synthesis itself.
- The disadvantage to this approach is that an end point that is
- translation-oblivious but security-aware and validating will not
- be able to use the DNS64 functionality. In this case, the end
- point will not have the desired benefit of NAT64. In effect,
- this strategy means that any end point that wishes to do
- validation in a NAT64 context must be upgraded to be translation-
- aware as well.
-
-5.6. DNS64 and multihoming
-
- Synthetic AAAA records may be constructed on the basis of the network
- context in which they were constructed. Therefore, a synthetic AAAA
- received from one interface MUST NOT be used to resolve hosts via
- another network interface. [[anchor21: This seems to be the result of
- the discussion on-list starting with message id 18034D4D7FE9AE48BF19A
- B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty
- strange when stated baldly. In particular, how is the multi-homed
- host supposed to know that a given AAAA is synthetic?
- --ajs@shinkuro.com]]
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 15]
-
-Internet-Draft DNS64 October 2009
-
-
-6. Deployment notes
-
- While DNS64 is intended to be part of a strategy for aiding IPv6
- deployment in an internetworking environment with some IPv4-only and
- IPv6-only networks, it is important to realise that it is
- incompatible with some things that may be deployed in an IPv4-only or
- dual-stack context.
-
-6.1. DNS resolvers and DNS64
-
- Full-service resolvers that are unaware of the DNS64 function can be
- (mis)configured to act as mixed-mode iterative and forwarding
- resolvers. In a native-IPv4 context, this sort of configuration may
- appear to work. It is impossible to make it work properly without it
- being aware of the DNS64 function, because it will likely at some
- point obtain IPv4-only glue records and attempt to use them for
- resolution. The result that is returned will contain only A records,
- and without the ability to perform the DNS64 function the resolver
- will simply be unable to answer the necessary AAAA queries.
-
-6.2. DNSSEC validators and DNS64
-
- Existing DNSSEC validators (i.e. that are unaware of DNS64) will
- reject all the data that comes from the DNS64 as having been tampered
- with. If it is necessary to have validation behind the DNS64, then
- the validator must know how to perform the DNS64 function itself.
- Alternatively, the validating host may establish a trusted connection
- with the DNS64, and allow the DNS64 to do all validation on its
- behalf.
-
-
-7. Security Considerations
-
- See the discussion on the usage of DNSSEC and DNS64 described in the
- document.
-
-
-8. Contributors
-
- Dave Thaler
-
- Microsoft
-
- dthaler@windows.microsoft.com
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 16]
-
-Internet-Draft DNS64 October 2009
-
-
-9. Acknowledgements
-
- This draft contains the result of discussions involving many people,
- including the participants of the IETF BEHAVE Working Group. The
- following IETF participants made specific contributions to parts of
- the text, and their help is gratefully acknowledged: Mark Andrews,
- Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
- Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
- Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
- Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
- Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
- Florian Weimer, Dan Wing, Xu Xiaohu.
-
- Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
- Trilogy, a research project supported by the European Commission
- under its Seventh Framework Program.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
- RFC 2671, August 1999.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
- [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
- (SIIT)", RFC 2765, February 2000.
-
- [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
- (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
- RFC 4787, January 2007.
-
- [I-D.ietf-behave-tcp]
- Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
- Srisuresh, "NAT Behavioral Requirements for TCP",
- draft-ietf-behave-tcp-08 (work in progress),
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 17]
-
-Internet-Draft DNS64 October 2009
-
-
- September 2008.
-
- [I-D.ietf-behave-nat-icmp]
- Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
- Behavioral Requirements for ICMP protocol",
- draft-ietf-behave-nat-icmp-12 (work in progress),
- January 2009.
-
- [I-D.thaler-behave-translator-addressing]
- Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators",
- draft-thaler-behave-translator-addressing-00 (work in
- progress), July 2009.
-
-10.2. Informative References
-
- [I-D.bagnulo-behave-nat64]
- Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
- Address and Protocol Translation from IPv6 Clients to IPv4
- Servers", draft-bagnulo-behave-nat64-03 (work in
- progress), March 2009.
-
- [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
- Translation - Protocol Translation (NAT-PT)", RFC 2766,
- February 2000.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
- Considerations for IP Fragment Filtering", RFC 1858,
- October 1995.
-
- [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
- Fragment Attack (RFC 1858)", RFC 3128, June 2001.
-
- [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
- Address Translator (Traditional NAT)", RFC 3022,
- January 2001.
-
- [RFC3484] Draves, R., "Default Address Selection for Internet
- Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IP Version 6", RFC 3596,
- October 2003.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 18]
-
-Internet-Draft DNS64 October 2009
-
-
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
- Address Translator - Protocol Translator (NAT-PT) to
- Historic Status", RFC 4966, July 2007.
-
- [I-D.iana-rfc3330bis]
- Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
- draft-iana-rfc3330bis-06 (work in progress),
- February 2009.
-
- [I-D.ietf-mmusic-ice]
- Rosenberg, J., "Interactive Connectivity Establishment
- (ICE): A Protocol for Network Address Translator (NAT)
- Traversal for Offer/Answer Protocols",
- draft-ietf-mmusic-ice-19 (work in progress), October 2007.
-
- [I-D.ietf-6man-addr-select-sol]
- Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
- "Solution approaches for address-selection problems",
- draft-ietf-6man-addr-select-sol-01 (work in progress),
- June 2008.
-
- [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
- Managed Objects for Synchronous Optical Network (SONET)
- Linear Automatic Protection Switching (APS)
- Architectures", RFC 3498, March 2003.
-
- [I-D.wing-behave-learn-prefix]
- Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
- of an IPv6/IPv4 Translator",
- draft-wing-behave-learn-prefix-02 (work in progress),
- May 2009.
-
- [I-D.miyata-behave-prefix64]
- Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
- draft-miyata-behave-prefix64-02 (work in progress),
- March 2009.
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 19]
-
-Internet-Draft DNS64 October 2009
-
-
- [I-D.venaas-behave-mcast46]
- Venaas, S., "An IPv4 - IPv6 multicast translator",
- draft-venaas-behave-mcast46-00 (work in progress),
- December 2008.
-
- [I-D.ietf-dnsop-default-local-zones]
- Andrews, M., "Locally-served DNS Zones",
- draft-ietf-dnsop-default-local-zones-08 (work in
- progress), February 2009.
-
-
-Appendix A. Deployment scenarios and examples
-
- In this section, we first provide a description of the default
- address transformation algorithm and then we walk through some sample
- scenarios that are expected to be common deployment cases. It should
- be noted that 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.thaler-behave-translator-addressing].
-
- There are two main different setups where DNS64 is expected to be
- used (other setups are possible as well, but these two are the main
- ones identified at the time of this writing).
-
- One possible setup that is expected to be common is the case of an
- end site or an ISP that is providing IPv6-only connectivity or
- connectivity to IPv6-only hosts that wants to allow the
- communication from these IPv6-only connected hosts to the IPv4
- Internet. This case is called An-IPv6-network-to-IPv4-Internet.
- In this case, the IPv6/IPv4 Translator is used to connect the end
- site or the ISP to the IPv4 Internet and the DNS64 function is
- provided by the end site or the ISP.
-
- The other possible setup that is expected is an IPv4 site that
- wants that its IPv4 servers to be reachable from the IPv6
- Internet. This case is called IPv6-Internet-to-an-IPv4-network.
- It should be noted that the IPv4 addresses used in the IPv4 site
- can be either public or private. In this case, the IPv6/IPv4
- Translator is used to connect the IPv4 end site to the IPv6
- Internet and the DNS64 function is provided by the end site
- itself.
-
- In this section we illustrate how the DNS64 behaves in the different
- scenarios that are expected to be common. We consider then 3
- possible scenarios, namely:
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 20]
-
-Internet-Draft DNS64 October 2009
-
-
- 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
- mode
-
- 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
- resolver mode
-
- 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
- mode
-
- The notation used is the following: upper case letters are IPv4
- addresses; upper case letters with a prime(') are IPv6 addresses;
- lower case letters are ports; prefixes are indicated by "P::X", which
- is an IPv6 address built from an IPv4 address X by adding the prefix
- P, mappings are indicated as "(X,x) <--> (Y',y)".
-
-A.1. Embed and Zero-Pad algorithm description
-
- In this section we describe the default algorithm for the generation
- of IPv6 address from IPv4 address to be implemented in the DNS64.
-
- The only parameter required by the default algorithm is an IPv6
- prefix. This prefix is used to map IPv4 addresses into IPv6
- addresses, and is denoted Pref64. If we note n the length of the
- prefix Pref64, then n must the less or equal than 96. If an Pref64
- is configured through any means in the DNS64 (such as manually
- configured, or other automatic mean not specified in this document),
- the default algorithm must use this prefix. If no prefix is
- available the algorithm must use the Well-Know prefix (include here
- the prefix to be assigned by IANA) defined in
- [I-D.thaler-behave-translator-addressing]
-
- The input for the algorithm are:
-
- The IPv4 address: X
-
- The IPv6 prefix: Pref64::/n
-
- The IPv6 address is generated by concatenating the prefix Pref64::/n,
- the IPv4 address X and optionally (in case n is strictly smaller than
- 96) an all-zero suffix. So, the resulting IPv6 address would be
- Pref64:X::
-
- Reverse algorithm
-
- We next describe the reverse algorithm of the algorithm described in
- the previous section. This algorithm allows to generate and IPv4
- address from an IPv6 address. This reverse algorithm is NOT
- implemented by the DNS64 but it is implemented in the IPv6/IPv4
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 21]
-
-Internet-Draft DNS64 October 2009
-
-
- translator that is serving the same domain the DNS64.
-
- The only parameter required by the default algorithm is an IPv6
- prefix. This prefix is the one originally used to map IPv4 addresses
- into IPv6 addresses, and is denoted Pref64.
-
- The input for the algorithm are:
-
- The IPv6 address: X'
-
- The IPv6 prefix: Pref64::/n
-
- First, the algorithm checks that the fist n bits of the IPv6 address
- X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
- X'/n.
-
- If this is not the case, the algorithm ends and no IPv4 address is
- generated.
-
- If the verification is successful, then the bits between the n+1
- and the n+32 of the IPv6 address X' are extracted to form the IPv4
- address.
-
-A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
- mode
-
- In this example, we consider an IPv6 node located in an IPv6-only
- site that initiates a communication to an IPv4 node located in the
- IPv4 Internet.
-
- The scenario for this case is depicted in the following figure:
-
-
- +---------------------------------------+ +-----------+
- |IPv6 site +-------------+ |IP Addr: | |
- | +----+ | Name server | +-------+ T | IPv4 |
- | | H1 | | with DNS64 | |64Trans|------| Internet |
- | +----+ +-------------+ +-------+ +-----------+
- | |IP addr: Y' | | | |IP addr: X
- | --------------------------------- | +----+
- +---------------------------------------+ | H2 |
- +----+
-
- The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
- IPv4 node H2 with IPv4 address X.
-
- A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
- Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 22]
-
-Internet-Draft DNS64 October 2009
-
-
- an IPv4 address T assigned to its IPv4 interface.
-
- The other element involved is the local name server. The name server
- is a dual-stack node, so that H1 can contact it via IPv6, while it
- can contact IPv4-only name servers via IPv4.
-
- The local name server needs to know the prefix assigned to the local
- IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
- we assume it learns this through manual configuration.
-
- For this example, assume the typical DNS situation where IPv6 hosts
- have only stub resolvers, and always query a name server that
- performs recursive lookups (henceforth called "the recursive
- nameserver").
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
- query for an AAAA record for H2 to the recursive name server.
- The recursive name server implements DNS64 functionality.
-
- 2. The recursive name server resolves the query, and discovers that
- there are no AAAA records for H2.
-
- 3. The recursive name server queries for an A record for H2 and gets
- back an A record containing the IPv4 address X. The name server
- then synthesizes an AAAA record. The IPv6 address in the AAAA
- record contains the prefix assigned to the IPv6/IPv4 Translator
- in the upper n bits then the IPv4 address X and then an all-zero
- padding i.e. the resulting IPv6 address is Pref64:X::
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- H2. The packet is sent from a source transport address of (Y',y)
- to a destination transport address of (Pref64:X::,x), where y and
- x are ports chosen by H2.
-
- 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
- Translator and the subsequent communication flows by means of the
- IPv6/IPv4 Translator mechanisms.
-
-A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
- mode
-
- The scenario for this case is depicted in the following figure:
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 23]
-
-Internet-Draft DNS64 October 2009
-
-
- +---------------------------------------+ +-----------+
- |IPv6 site +-------+ |IP addr: | |
- | +---------------+ | Name | +-------+ T | IPv4 |
- | | H1 with DNS64 | | Server| |64Trans|------| Internet |
- | +---------------+ +-------+ +-------+ +-----------+
- | |IP addr: Y' | | | |IP addr: X
- | --------------------------------- | +----+
- +---------------------------------------+ | H2 |
- +----+
-
- The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
- IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
- function.
-
- A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
- Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
- and an IPv4 address T assigned to its IPv4 interface.
-
- H1 needs to know the prefix assigned to the local IPv6/IPv4
- Translator (Pref64::/n). For the purpose of this example, we assume
- it learns this through manual configuration.
-
- Also shown is a name server. For the purpose of this example, we
- assume that the name server is a dual-stack node, so that H1 can
- contact it via IPv6, while it can contact IPv4-only name servers via
- IPv4.
-
- For this example, assume the typical situation where IPv6 hosts have
- only stub resolvers and always query a name server that provides
- recursive lookups (henceforth called "the recursive name server").
- The recursive name server does not perform the DNS64 function.
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
- query for a AAAA record for H2 to the recursive name server.
-
- 2. The recursive DNS server resolves the query, and returns the
- answer to H1. Because there are no AAAA records in the global
- DNS for H2, the answer is empty.
-
- 3. The stub resolver at H1 then queries for an A record for H2 and
- gets back an A record containing the IPv4 address X. The DNS64
- function within H1 then synthesizes a AAAA record. The IPv6
- address in the AAAA record contains the prefix assigned to the
- IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
- and then an all-zero padding i.e. the resulting IPv6 address is
- Pref64:X::.
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 24]
-
-Internet-Draft DNS64 October 2009
-
-
- 4. H1 sends a packet towards H2. The packet is sent from a source
- transport address of (Y',y) to a destination transport address of
- (Pref64:X::,x), where y and x are ports chosen by H2.
-
- 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
- Translator and the subsequent communication flows using the IPv6/
- IPv4 Translator mechanisms.
-
-A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
-
- In this example, we consider an IPv6 node located in the IPv6
- Internet site that initiates a communication to a IPv4 node located
- in the IPv4 site.
-
- This scenario can be addressed without using any form of DNS64
- function. This is so because it is possible to assign a fixed IPv6
- address to each of the IPv4 servers. Such an IPv6 address would be
- constructed as the Pref64::/n concatenated with the IPv4 address of
- the IPv4 server and an all-zero padding. Note that the IPv4 address
- can be a public or a private address; the latter does not present any
- additional difficulty, since the LIR prefix must be used a Pref64 (in
- this scenario the usage of the WK prefix is not supported). Once
- these IPv6 addresses have been assigned to represent the IPv4 servers
- in the IPv6 Internet, real AAAA RRs containing these addresses can be
- published in the DNS under the site's domain. This is the
- recommended approach to handle this scenario, because it does not
- involve synthesizing AAAA records at the time of query. Such a
- configuration is easier to troubleshoot in the event of problems,
- because it always provides the same answer to every query.
-
- However, there are some more dynamic scenarios, where synthesizing
- AAAA RRs in this setup may be needed. In particular, when DNS Update
- [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
- servers, there are two options: One option is to modify the server
- that receives the dynamic DNS updates. That would normally be the
- authoritative server for the zone. So the authoritative zone would
- have normal AAAA RRs that are synthesized as dynamic updates occur.
- The other option is modify the authoritative server to generate
- synthetic AAAA records for a zone, possibly based on additional
- constraints, upon the receipt of a DNS query for the AAAA RR. The
- first option -- in which the AAAA is synthesized when the DNS update
- message is received, and the data published in the relevant zone --
- is recommended over the second option (i.e. the synthesis upon
- receipt of the AAAA DNS query). This is because it is usually easier
- to solve problems of misconfiguration and so on when the DNS
- responses are not being generated dynamically. For completeness, the
- DNS64 behavior that we describe in this section covers the case of
- synthesizing the AAAA RR when the DNS query arrives. Nevertheless,
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 25]
-
-Internet-Draft DNS64 October 2009
-
-
- such a configuration is NOT RECOMMENDED. Troubleshooting
- configurations that change the data depending on the query they
- receive is notoriously hard, and the IPv4/IPv6 translation scenario
- is complicated enough without adding additional opportunities for
- possible malfunction.
-
- The scenario for this case is depicted in the following figure:
-
-
- +-----------+ +----------------------------------------+
- | | | IPv4 site +-------------+ |
- | IPv6 | +-------+ +----+ | Name server | |
- | Internet |------|64Trans| | H2 | | with DNS64 | |
- +-----------+ +-------+ +----+ +-------------+ |
- |IP addr: Y' | | |IP addr: X | |
- +----+ | ----------------------------------- |
- | H1 | +----------------------------------------+
- +----+
-
- The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
- IPv4 node H2 with IPv4 address X.
-
- A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
- Internet. This IPv6/IPv4 Translator has a prefix (called
- Pref64::/n).
-
- Also shown is the authoritative name server for the local domain with
- DNS64 functionality. For the purpose of this example, we assume that
- the name server is a dual-stack node, so that H1 or a recursive
- resolver acting on the request of H1 can contact it via IPv6, while
- it can be contacted by IPv4-only nodes to receive dynamic DNS updates
- via IPv4.
-
- The local name server needs to know the prefix assigned to the local
- IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example,
- we assume it learns this through manual configuration.
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS
- query for an AAAA record for H2. The query is eventually
- forwarded to the server in the IPv4 site.
-
- 2. The local DNS server resolves the query (locally), and discovers
- that there are no AAAA records for H2.
-
- 3. The name server verifies that FQDN(H2) and its A RR are among
- those that the local policy defines as allowed to generate a AAAA
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 26]
-
-Internet-Draft DNS64 October 2009
-
-
- RR from. If that is the case, the name server synthesizes an
- AAAA record from the A RR and the relevant Pref64::/n. The IPv6
- address in the AAAA record contains the prefix assigned to the
- IPv6/IPv4 Translator in the first n bits and the IPv4 address X
- and then an all-zero padding.
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- H2. The packet is sent from a source transport address of (Y',y)
- to a destination transport address of (Pref64:X::,x), where y and
- x are ports chosen by H2.
-
- 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.
-
-
-Appendix B. Motivations and Implications of synthesizing AAAA RR when
- real AAAA RR exists
-
- The motivation for synthesizing AAAA RR when a real AAAA RR exists is
- to support the following scenario:
-
- An IPv4-only server application (e.g. web server software) is
- running on a dual-stack host. There may also be dual-stack server
- applications also running on the same host. That host has fully
- routable IPv4 and IPv6 addresses and hence the authoritative DNS
- server has an A and a AAAA record as a result.
-
- An IPv6-only client (regardless of whether the client application
- is IPv6-only, the client stack is IPv6-only, or it only has an
- IPv6 address) wants to access the above server.
-
- The client issues a DNS query to a DNS64 recursor.
-
- If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
- then the communication will fail. Even though there's a real AAAA,
- the only way for communication to succeed is with the translated
- address. So, in order to support this scenario, the administrator of
- a DNS64 service may want to enable the synthesis of AAAA RR even when
- real AAAA RR exist.
-
- The implication of including synthetic AAAA RR when real AAAA RR
- exist is that translated connectivity may be preferred over native
- connectivity in some cases where the DNS64 is operated in DNS server
- mode.
-
- RFC3484 [RFC3484] rules use longest prefix match to select which is
- the preferred destination address to use. So, if the DNS64 recursor
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 27]
-
-Internet-Draft DNS64 October 2009
-
-
- returns both the synthetic AAAA RR and the real AAAA RR, then if the
- DNS64 is operated by the same domain as the initiating host, and a
- global unicast prefix (called the LIR prefix as defined in
- [I-D.thaler-behave-translator-addressing]) is used, then the
- synthetic AAAA RR is likely to be preferred.
-
- This means that without further configuration:
-
- In the case of An IPv6 network to the IPv4 internet, the host will
- prefer translated connectivity if LIR prefix is used. If the
- Well-Known (WK) prefix defined in
- [I-D.thaler-behave-translator-addressing] is used, it will
- probably prefer native connectivity.
-
- In the case of the IPv6 Internet to an IPv4 network, it is
- possible to bias the selection towards the real AAAA RR if the
- DNS64 recursor returns the real AAAA first in the DNS reply, when
- the LIR prefix is used (the WK prefix usage is not recommended in
- this case)
-
- In the case of the IPv6 to IPv4 in the same network, for local
- destinations (i.e., target hosts inside the local site), it is
- likely that the LIR prefix and the destination prefix are the
- same, so we can use the order of RR in the DNS reply to bias the
- selection through native connectivity. If a WK prefix is used,
- the longest prefix match rule will select native connectivity.
-
- So this option introduces problems in the following cases:
-
- An IPv6 network to the IPv4 internet with the LIR prefix
-
- IPv6 to IPv4 in the same network when reaching external
- destinations and the LIR prefix is used.
-
- In any case, the problem can be solved by properly configuring the
- RFC3484 [RFC3484] policy table, but this requires effort on the part
- of the site operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 28]
-
-Internet-Draft DNS64 October 2009
-
-
-Authors' Addresses
-
- Marcelo Bagnulo
- UC3M
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6249500
- Fax:
- Email: marcelo@it.uc3m.es
- URI: http://www.it.uc3m.es/marcelo
-
-
- Andrew Sullivan
- Shinkuro
- 4922 Fairmont Avenue, Suite 250
- Bethesda, MD 20814
- USA
-
- Phone: +1 301 961 3131
- Email: ajs@shinkuro.com
-
-
- Philip Matthews
- Unaffiliated
- 600 March Road
- Ottawa, Ontario
- Canada
-
- Phone: +1 613-592-4343 x224
- Fax:
- Email: philip_matthews@magma.ca
- URI:
-
-
- Iljitsch van Beijnum
- IMDEA Networks
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6246245
- Email: iljitsch@muada.com
-
-
-
-
-
-
-
-Bagnulo, et al. Expires April 22, 2010 [Page 29]
-
diff --git a/doc/draft/draft-ietf-behave-dns64-06.txt b/doc/draft/draft-ietf-behave-dns64-06.txt
new file mode 100644
index 000000000000..f648a21029a1
--- /dev/null
+++ b/doc/draft/draft-ietf-behave-dns64-06.txt
@@ -0,0 +1,1680 @@
+
+
+
+BEHAVE WG M. Bagnulo
+Internet-Draft UC3M
+Intended status: Standards Track A. Sullivan
+Expires: August 19, 2010 Shinkuro
+ P. Matthews
+ Alcatel-Lucent
+ I. van Beijnum
+ IMDEA Networks
+ February 15, 2010
+
+
+DNS64: DNS extensions for Network Address Translation from IPv6 Clients
+ to IPv4 Servers
+ draft-ietf-behave-dns64-06
+
+Abstract
+
+ DNS64 is a mechanism for synthesizing AAAA records from A records.
+ DNS64 is used with an IPv6/IPv4 translator to enable client-server
+ communication between an IPv6-only client and an IPv4-only server,
+ without requiring any changes to either the IPv6 or the IPv4 node,
+ for the class of applications that work through NATs. This document
+ specifies DNS64, and provides suggestions on how it should be
+ deployed in conjunction with IPv6/IPv4 translators.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 19, 2010.
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 1]
+
+Internet-Draft DNS64 February 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 2]
+
+Internet-Draft DNS64 February 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 7
+ 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9
+ 5.1. Resolving AAAA queries and the answer section . . . . . . 10
+ 5.1.1. The answer when there is AAAA data available . . . . . 10
+ 5.1.2. The answer when there is an error . . . . . . . . . . 10
+ 5.1.3. Special exclusion set for AAAA records . . . . . . . . 10
+ 5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 11
+ 5.1.5. Data for the answer when performing synthesis . . . . 11
+ 5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 12
+ 5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 12
+ 5.2. Generation of the IPv6 representations of IPv4
+ addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3. Handling other RRs and the Additional Section . . . . . . 13
+ 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 13
+ 5.3.2. Handling the additional section . . . . . . . . . . . 14
+ 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 15
+ 5.4. Assembling a synthesized response to a AAAA query . . . . 15
+ 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 16
+ 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 17
+ 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 17
+ 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 17
+ 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 17
+ 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 18
+ 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 18
+ 7. Deployment scenarios and examples . . . . . . . . . . . . . . 19
+ 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with
+ DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20
+ 7.2. An example of an-IPv6-network-to-IPv4-Internet setup
+ with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21
+ 7.3. Example of IPv6-Internet-to-an-IPv4-network setup
+ DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
+ 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
+ Appendix A. Motivations and Implications of synthesizing AAAA
+ RR when real AAAA RR exists . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 3]
+
+Internet-Draft DNS64 February 2010
+
+
+1. Introduction
+
+ This document specifies DNS64, a mechanism that is part of the
+ toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
+ together with an IPv6/IPv4 translator such as stateful NAT64
+ [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
+ initiate communications by name to an IPv4-only server.
+
+ DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+ from A RRs. A synthetic AAAA RR created by the DNS64 from an
+ original A RR contains the same owner name of the original A RR but
+ it contains an IPv6 address instead of an IPv4 address. The IPv6
+ address is an IPv6 representation of the IPv4 address contained in
+ the original A RR. The IPv6 representation of the IPv4 address is
+ algorithmically generated from the IPv4 address returned in the A RR
+ and a set of parameters configured in the DNS64 (typically, an IPv6
+ prefix used by IPv6 representations of IPv4 addresses and optionally
+ other parameters).
+
+ Together with an IPv6/IPv4 translator, these two mechanisms allow an
+ IPv6-only client to initiate communications to an IPv4-only server
+ using the FQDN of the server.
+
+ These mechanisms are expected to play a critical role in the IPv4-
+ IPv6 transition and co-existence. Due to IPv4 address depletion, it
+ is likely that in the future, many IPv6-only clients will want to
+ connect to IPv4-only servers. In the typical case, the approach only
+ requires the deployment of IPv6/IPv4 translators that connect an
+ IPv6-only network to an IPv4-only network, along with the deployment
+ of one or more DNS64-enabled name servers. However, some advanced
+ features require performing the DNS64 function directly in the end-
+ hosts themselves.
+
+
+2. Overview
+
+ This section provides a non-normative introduction to the DNS64
+ mechanism.
+
+ We assume that we have one or more IPv6/IPv4 translator boxes
+ connecting an IPv4 network and an IPv6 network. The IPv6/IPv4
+ translator device provides translation services between the two
+ networks enabling communication between IPv4-only hosts and IPv6-only
+ hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
+ applications, hosts that can only use IPv6, as well as cases where
+ only IPv6 connectivity is available to the client. By IPv4-only
+ servers we mean servers running IPv4-only applications, servers that
+ can only use IPv4, as well as cases where only IPv4 connectivity is
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 4]
+
+Internet-Draft DNS64 February 2010
+
+
+ available to the server). Each IPv6/IPv4 translator used in
+ conjunction with DNS64 must allow communications initiated from the
+ IPv6-only host to the IPv4-only host.
+
+ To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+ learn the address of the responder, DNS64 is used to synthesize a
+ AAAA record from an A record containing a real IPv4 address of the
+ responder, whenever the DNS64 cannot retrieve a AAAA record for the
+ queried name. The DNS64 service appears as a regular DNS server or
+ resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query
+ generated by the IPv6 initiator. It first attempts a resolution for
+ the requested AAAA records. If there are no AAAA records available
+ for the target node (which is the normal case when the target node is
+ an IPv4-only node), DNS64 performs a query for A records. For each A
+ record discovered, DNS64 creates a synthetic AAAA RR from the
+ information retrieved in the A RR.
+
+ The owner name of a synthetic AAAA RR is the same as that of the
+ original A RR, but an IPv6 representation of the IPv4 address
+ contained in the original A RR is included in the AAAA RR. The IPv6
+ representation of the IPv4 address is algorithmically generated from
+ the IPv4 address and additional parameters configured in the DNS64.
+ Among those parameters configured in the DNS64, there is at least one
+ IPv6 prefix. If not explicitly mentioned, all prefixes are treated
+ equally and the operations described in this document are performed
+ using the prefixes available. So as to be general, we will call any
+ of these prefixes Pref64::/n, and describe the operations made with
+ the generic prefix Pref64::/n. The IPv6 address representing IPv4
+ addresses included in the AAAA RR synthesized by the DNS64 contain
+ Pref64::/n and they also embed the original IPv4 address.
+
+ The same algorithm and the same Pref64::/n prefix(es) must be
+ configured both in the DNS64 device and the IPv6/IPv4 translator(s),
+ so that both can algorithmically generate the same IPv6
+ representation for a given IPv4 address. In addition, it is required
+ that IPv6 packets addressed to an IPv6 destination address that
+ contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so
+ they can be translated into IPv4 packets.
+
+ Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
+ are passed back to the IPv6 initiator, which will initiate an IPv6
+ communication with the IPv6 address associated with the IPv4
+ receiver. The packet will be routed to an IPv6/IPv4 translator which
+ will forward it to the IPv4 network.
+
+ In general, the only shared state between the DNS64 and the IPv6/IPv4
+ translator is the Pref64::/n and an optional set of static
+ parameters. The Pref64::/n and the set of static parameters must be
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 5]
+
+Internet-Draft DNS64 February 2010
+
+
+ configured to be the same on both; there is no communication between
+ the DNS64 device and IPv6/IPv4 translator functions. The mechanism
+ to be used for configuring the parameters of the DNS64 is beyond the
+ scope of this memo.
+
+ The prefixes to be used as Pref64::/n and their applicability are
+ discussed in [I-D.ietf-behave-address-format]. There are two types
+ of prefixes that can be used as Pref64::/n.
+
+ The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved
+ by [I-D.ietf-behave-address-format] for the purpose of
+ representing IPv4 addresses in IPv6 address space.
+
+ The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is
+ an IPv6 prefix assigned by an organization to create IPv6
+ representations of IPv4 addresses.
+
+ The main difference in the nature of the two types of prefixes is
+ that the NSP is a locally assigned prefix that is under control of
+ the organization that is providing the translation services, while
+ the Well-Known Prefix is a prefix that has a global meaning since it
+ has been assigned for the specific purpose of representing IPv4
+ addresses in IPv6 address space.
+
+ The DNS64 function can be performed in any of three places.
+
+ The first option is to locate the DNS64 function in authoritative
+ servers for a zone. In this case, the authoritative server provides
+ a synthetic AAAA RRs for an IPv4-only host in its zone. This is one
+ type of DNS64 server.
+
+ Another option is to locate the DNS64 function in recursive name
+ servers serving end hosts. In this case, when an IPv6-only host
+ queries the name server for AAAA RRs for an IPv4-only host, the name
+ server can perform the synthesis of AAAA RRs and pass them back to
+ the IPv6-only initiator. The main advantage of this mode is that
+ current IPv6 nodes can use this mechanism without requiring any
+ modification. This mode is called "DNS64 in DNS recursive 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
+ DNSSEC validation in the end host. The main drawback of this mode is
+ its deployability, since it requires changes in the end hosts. This
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 6]
+
+Internet-Draft DNS64 February 2010
+
+
+ mode is called "DNS64 in stub-resolver mode". This is the second
+ type of DNS64 resolver.
+
+
+3. Background to DNS64-DNSSEC interaction
+
+ DNSSEC presents a special challenge for DNS64, because DNSSEC is
+ designed to detect changes to DNS answers, and DNS64 may alter
+ answers coming from an authoritative server.
+
+ A recursive resolver can be security-aware or security-oblivious.
+ Moreover, a security-aware recursive name server can be validating or
+ non-validating, according to operator policy. In the cases below,
+ the recursive server is also performing DNS64, and has a local policy
+ to validate. We call this general case vDNS64, but in all the cases
+ below the DNS64 functionality should be assumed needed.
+
+ DNSSEC includes some signaling bits that offer some indicators of
+ what the query originator understands.
+
+ If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
+ set, the query originator is signaling that it understands DNSSEC.
+ The DO bit does not indicate that the query originator will validate
+ the response. It only means that the query originator can understand
+ responses containing DNSSEC data. Conversely, if the DO bit is
+ clear, that is evidence that the querying agent is not aware of
+ DNSSEC.
+
+ If a query arrives at a vDNS64 device with the "Checking Disabled"
+ (CD) bit set, it is an indication that the querying agent wants all
+ the validation data so it can do checking itself. By local policy,
+ vDNS64 could still validate, but it must return all data to the
+ querying agent anyway.
+
+ Here are the possible cases:
+
+ 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
+ the DO bit clear. In this case, DNSSEC is not a concern, because
+ the querying agent does not understand DNSSEC responses.
+
+ 2. A security-oblivious DNS64 receives a query with the DO bit set,
+ and the CD bit clear or set. This is just like the case of a
+ non-DNS64 case: the server doesn't support it, so the querying
+ agent is out of luck.
+
+ 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],
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 7]
+
+Internet-Draft DNS64 February 2010
+
+
+ section 4.2). For that reason, this case amounts to the same as
+ the previous case, and no validation happens.
+
+ 4. A security-aware and non-validating DNS64 receives a query with
+ the DO bit set and the CD bit set. In this case, the resolver is
+ supposed to pass on all the data it gets to the query initiator
+ (see section 3.2.2 of [RFC4035]). This case will be problematic
+ with DNS64. If the DNS64 server modifies the record, the client
+ will get the data back and try to validate it, and the data will
+ be invalid as far as the client is concerned.
+
+ 5. A security-aware and validating DNS64 node receives a query with
+ the DO bit clear and CD clear. In this case, the resolver
+ validates the data. If it fails, it returns RCODE 2 (Server
+ failure); otherwise, it returns the answer. This is the ideal
+ case for vDNS64. The resolver validates the data, and then
+ synthesizes the new record and passes that to the client. The
+ client, which is presumably not validating (else it should have
+ set DO and CD), cannot tell that DNS64 is involved.
+
+ 6. A security-aware and validating DNS64 node receives a query with
+ the DO bit set and CD clear. This ought to work like the
+ previous case, except that the resolver should also set the
+ "Authentic Data" (AD) bit on the response.
+
+ 7. A security-aware and validating DNS64 node receives a query with
+ the DO bit set and CD set. This is effectively the same as the
+ case where a security-aware and non-validating recursive resolver
+ receives a similar query, and the same thing will happen: the
+ downstream validator will mark the data as invalid if DNS64 has
+ performed synthesis.
+
+
+4. Terminology
+
+ This section provides definitions for the special terms used in the
+ document.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ Authoritative server: A DNS server that can answer authoritatively a
+ given DNS question.
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 8]
+
+Internet-Draft DNS64 February 2010
+
+
+ DNS64: A logical function that synthesizes DNS resource records (e.g
+ AAAA records containing IPv6 addresses) from DNS resource records
+ actually contained in the DNS (e.g., A records containing IPv4
+ addresses).
+
+ DNS64 recursor: A recursive resolver that provides the DNS64
+ functionality as part of its operation. This is the same thing as
+ "DNS64 in recursive resolver mode".
+
+ DNS64 resolver: Any resolver (stub resolver or recursive resolver)
+ that provides the DNS64 function.
+
+ DNS64 server: Any server providing the DNS64 function.
+
+ Recursive resolver: A DNS server that accepts requests from one
+ resolver, and asks another server (of some description) for the
+ answer on behalf of the first resolver.
+
+ Synthetic RR: A DNS resource record (RR) that is not contained in
+ any zone data file, but has been synthesized from other RRs. An
+ example is a synthetic AAAA record created from an A record.
+
+ IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
+ packets and vice-versa. It is only required that the
+ communication initiated from the IPv6 side be supported.
+
+ For a detailed understanding of this document, the reader should also
+ be familiar with DNS terminology from [RFC1034], [RFC1035] and
+ current NAT terminology from [RFC4787]. Some parts of this document
+ assume familiarity with the terminology of the DNS security
+ extensions outlined in [RFC4035].
+
+
+5. DNS64 Normative Specification
+
+ DNS64 is a logical function that synthesizes AAAA records from A
+ records. The DNS64 function may be implemented in a stub resolver,
+ in a recursive resolver, or in an authoritative name server.
+
+ 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]. Support of
+ multicast address handling is out of the scope of this document. A
+ possible approach is specified in [I-D.venaas-behave-mcast46].
+
+ DNS64 also responds to PTR queries involving addresses containing any
+ of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 9]
+
+Internet-Draft DNS64 February 2010
+
+
+5.1. Resolving AAAA queries and the answer section
+
+ When the DNS64 receives a query for RRs of type AAAA and class IN, it
+ first attempts to retrieve non-synthetic RRs of this type and class,
+ either by performing a query or, in the case of an authoritative
+ server, by examining its own results. DNS64 operation for classes
+ other than IN is undefined, and a DNS64 MUST behave as though no
+ DNS64 function is configured.
+
+5.1.1. The answer when there is AAAA data available
+
+ If the query results in one or more AAAA records in the answer
+ section, the result is returned to the requesting client as per
+ normal DNS semantics, except in the case where any of the AAAA
+ records match a special exclusion set of prefixes, considered in
+ Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64
+ SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
+ for an analysis of the motivations for and the implications of not
+ complying with this recommendation). By default DNS64
+ implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+ exist.
+
+5.1.2. The answer when there is an error
+
+ If the query results in a response with RCODE other than 0 (No error
+ condition), then there are two possibilities. A result with RCODE=3
+ (Name Error) is handled according to normal DNS operation (which is
+ normally to return the error to the client). This stage is still
+ prior to any synthesis having happened, so a response to be returned
+ to the client does not need any special assembly than would usually
+ happen in DNS operation.
+
+ Any other RCODE is treated as though the RCODE were 0 and the answer
+ section were empty. This is because of the large number of different
+ responses from deployed name servers when they receive AAAA queries
+ without a AAAA record being available.
+
+ It is important to note that, as of this writing, some servers
+ respond with RCODE=3 to a AAAA query even if there is an A record
+ available for that owner name. Those servers are in clear violation
+ of the meaning of RCODE 3, and it is expected that they will decline
+ in use as IPv6 deployment increases.
+
+5.1.3. Special exclusion set for AAAA records
+
+ Some IPv6 addresses are not actually usable by IPv6-only hosts. If
+ they are returned to IPv6-only querying agents as AAAA records,
+ therefore, the goal of decreasing the number of failure modes will
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 10]
+
+Internet-Draft DNS64 February 2010
+
+
+ not be attained. Examples include AAAA records with addresses in the
+ ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
+ records with the site's Pref::64/n or the Well-Known Prefix (see
+ below for more about the Well-Known Prefix). A DNS64 implementation
+ SHOULD provide a mechanism to specify IPv6 prefix ranges to be
+ treated as though the AAAA containing them were an empty answer. An
+ implementation SHOULD include the ::ffff/96 network in that range by
+ default. Failure to provide this facility will mean that clients
+ querying the DNS64 function may not be able to communicate with hosts
+ that would be reachable from a dual-stack host.
+
+ When the DNS64 performs its initial AAAA query, if it receives an
+ answer with only AAAA records containing addresses in the excluded
+ range(s), then it MUST treat the answer as though it were an empty
+ answer, and proceed accordingly. If it receives an answer with at
+ least one AAAA record containing an address outside any of the
+ excluded range(s), then it MAY build an answer section for a response
+ including only the AAAA record(s) that do not contain any of the
+ addresses inside the excluded ranges. That answer section is used in
+ the assembly of a response as detailed in Section 5.4.
+ Alternatively, it MAY treat the answer as though it were an empty
+ answer, and proceed accordingly. It MUST NOT return the offending
+ AAAA records as part of a response.
+
+5.1.4. Dealing with CNAME and DNAME
+
+ If the response contains a CNAME or a DNAME, then the CNAME or DNAME
+ chain is followed until the first terminating A or AAAA record is
+ reached. This may require the DNS64 to ask for an A record, in case
+ the response to the original AAAA query is a CNAME or DNAME without a
+ AAAA record to follow. The resulting AAAA or A record is treated
+ like any other AAAA or A case, as appropriate.
+
+ When assembling the answer section, the original CNAME or DNAME RR is
+ included as part of the answer, and the synthetic AAAA, if
+ appropriate, is included.
+
+5.1.5. Data for the answer when performing synthesis
+
+ If the query results in no error but an empty answer section in the
+ response, the DNS64 attempts to retrieve A records for the name in
+ question, either by performing another query or, in the case of an
+ authortiative server, by examining its own results. If this new A RR
+ query results in an empty answer or in an error, then the empty
+ result or error is used as the basis for the answer returned to the
+ querying client. (Transient errors may result in retrying the query,
+ depending on the mode and operation of the underlying resolver; this
+ is just as in Section 5.1.2.) If instead the query results in one or
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 11]
+
+Internet-Draft DNS64 February 2010
+
+
+ more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs
+ according to the procedure outlined in Section 5.1.6. The DNS64
+ returns the synthesized AAAA records in the answer section, removing
+ the A records that form the basis of the synthesis.
+
+5.1.6. Performing the synthesis
+
+ A synthetic AAAA record is created from an A record as follows:
+
+ o The NAME field is set to the NAME field from the A record
+
+ o The TYPE field is set to 28 (AAAA)
+
+ o The CLASS field is set to the original CLASS field, 1. Under this
+ specification, DNS64 for any CLASS other than 1 is undefined.
+
+ o The TTL field is set to the minimum of the TTL of the original A
+ RR and the SOA RR for the queried domain. (Note that in order to
+ obtain the TTL of the SOA RR, the DNS64 does not need to perform a
+ new query, but it can remember the TTL from the SOA RR in the
+ negative response to the AAAA query.)
+
+ 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
+ check each A RR against configured IPv4 address ranges and select
+ the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
+ See Section 5.2 for discussion of the algorithms to be used in
+ effecting the transformation.
+
+5.1.7. Querying in parallel
+
+ The DNS64 MAY perform the query for the AAAA RR and for the A RR in
+ parallel, in order to minimize the delay. However, this would result
+ in performing unnecessary A RR queries in the case where no AAAA RR
+ synthesis is required. A possible trade-off would be to perform them
+ sequentially but with a very short interval between them, so if we
+ obtain a fast reply, we avoid doing the additional query. (Note that
+ this discussion is relevant only if the DNS64 function needs to
+ perform external queries to fetch the RR. If the needed RR
+ information is available locally, as in the case of an authoritative
+ server, the issue is no longer relevant.)
+
+5.2. Generation of the IPv6 representations of IPv4 addresses
+
+ DNS64 supports multiple algorithms for the generation of the IPv6
+ representation of an IPv4 address. The constraints imposed on the
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 12]
+
+Internet-Draft DNS64 February 2010
+
+
+ generation algorithms are the following:
+
+ The same algorithm to create an IPv6 address from an IPv4 address
+ MUST be used by both a DNS64 to create the IPv6 address to be
+ returned in the synthetic AAAA RR from the IPv4 address contained
+ in an original A RR, and by a IPv6/IPv4 translator to create the
+ IPv6 address to be included in the source address field of the
+ outgoing IPv6 packets from the IPv4 address included in the source
+ address field of the incoming IPv4 packet.
+
+ The algorithm MUST be reversible; i.e., it MUST be possible to
+ derive the original IPv4 address from the IPv6 representation.
+
+ The input for the algorithm MUST be limited to the IPv4 address,
+ the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+ representations and optionally a set of stable parameters that are
+ configured in the DNS64 and in the NAT64 (such as fixed string to
+ be used as a suffix).
+
+ For each prefix Pref64::/n, n MUST the less than or equal to
+ 96. If one or more Pref64::/n are configured in the DNS64
+ through any means in the DNS64 (such as manually configured, or
+ other automatic means not specified in this document), the
+ default algorithm MUST use these prefixes (and not use the
+ Well-Know Prefix). If no prefix is available, the algorithm
+ MUST use the Well-Known prefix 64:FF9B::/96 defined in
+ [I-D.ietf-behave-address-format] to represent the IPv4 unicast
+ address range
+
+ [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as
+ the value for the Well-Known prefix and needs to be confirmed
+ whenis published as RFC.]][I-D.ietf-behave-address-format]
+
+ A DNS64 MUST support the algorithm for generating IPv6
+ representations of IPv4 addresses defined in Section 2 of
+ [I-D.ietf-behave-address-format]. Moreover, the aforementioned
+ algorithm MUST be the default algorithm used by the DNS64. While the
+ normative description of the algorithm is provided in
+ [I-D.ietf-behave-address-format], a sample description of the
+ algorithm and its application to different scenarios is provided in
+ Section 7 for illustration purposes.
+
+5.3. Handling other RRs and the Additional Section
+
+5.3.1. PTR queries
+
+ If a DNS64 server receives a PTR query for a record in the IP6.ARPA
+ domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 13]
+
+Internet-Draft DNS64 February 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.
+
+ The first option is for the DNS64 server to respond authoritatively
+ for its prefixes. If the address prefix matches any Pref64::/n used
+ in the site, either a NSP or the Well-Known Prefix (i.e. 64:
+ FF9B::/96), then the DNS64 server MAY answer the query using locally-
+ appropriate RDATA. The DNS64 server MAY use the same RDATA for all
+ answers. Note that the requirement is to match any Pref64::/n used
+ at the site, and not merely the locally-configured Pref64::/n. This
+ is because end clients could ask for a PTR record matching an address
+ received through a different (site-provided) DNS64, and if this
+ strategy is in effect, those queries should never be sent to the
+ global DNS. The advantage of this strategy is that it makes plain to
+ the querying client that the prefix is one operated by the (DNS64)
+ site, and that the answers the client is getting are generated by
+ DNS64. The disadvantage is that any useful reverse-tree information
+ that might be in the global DNS is unavailable to the clients
+ querying the DNS64.
+
+ The second option is for the DNS64 nameserver to synthesize a CNAME
+ mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
+ name. The rest of the response would be the normal DNS processing.
+ The CNAME can be signed on the fly if need be. The advantage of this
+ approach is that any useful information in the reverse tree is
+ available to the querying client. The disadvantage is that it adds
+ additional load to the DNS64 (because CNAMEs have to be synthesized
+ for each PTR query that matches the Pref64::/n), and that it may
+ require signing on the fly. In addition, the generated CNAME could
+ correspond to an unpopulated in-addr.arpa zone, so the CNAME would
+ provide a reference to a non-existent record.
+
+ If the address prefix does not match any Pref64::/n, then the DNS64
+ server MUST process the query as though it were any other query; i.e.
+ a recursive nameserver MUST attempt to resolve the query as though it
+ were any other (non-A/AAAA) query, and an authoritative server MUST
+ respond authoritatively or with a referral, as appropriate.
+
+5.3.2. Handling the additional section
+
+ DNS64 synthesis MUST NOT be performed on any records in the
+ additional section of synthesized answers. The DNS64 MUST pass the
+ additional section unchanged.
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 14]
+
+Internet-Draft DNS64 February 2010
+
+
+ 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.
+
+5.3.3. Other 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.
+
+5.4. Assembling a synthesized response to a AAAA query
+
+ A DNS64 uses different pieces of data to build the response returned
+ to the querying client.
+
+ The query that is used as the basis for synthesis results either in
+ an error, an answer that can be used as a basis for synthesis, or an
+ empty (authoritative) answer. If there is an empty answer, then the
+ DNS64 responds to the original querying client with the answer the
+ DNS64 received to the original AAAA query. Otherwise, the response
+ is assembled as follows.
+
+ The header fields are set according to the usual rules for recursive
+ or authoritative servers, depending on the role that the DNS64 is
+ serving. The question section is copied from the original AAAA
+ query. The answer section is populated according to the rules in
+ Section 5.1.6. The authority and additional sections are copied from
+ the response to the A query that the DNS64 performed.
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 15]
+
+Internet-Draft DNS64 February 2010
+
+
+5.5. DNSSEC processing: DNS64 in recursive server mode
+
+ We consider the case where a recursive server that is performing
+ DNS64 also has a local policy to validate the answers according to
+ the procedures outlined in [RFC4035] Section 5. We call this general
+ case vDNS64.
+
+ The vDNS64 uses the presence of the DO and CD bits to make some
+ decisions about what the query originator needs, and can react
+ accordingly:
+
+ 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
+ validation and do synthesis as needed.
+
+ 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
+ validation. Whenever vDNS64 performs validation, it MUST
+ validate the negative answer for AAAA queries before proceeding
+ to query for A records for the same name, in order to be sure
+ that there is not a legitimate AAAA record on the Internet.
+ Failing to observe this step would allow an attacker to use DNS64
+ as a mechanism to circumvent DNSSEC. If the negative response
+ validates, and the response to the A query validates, then the
+ vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+ answer to the client. This is acceptable, because [RFC4035],
+ section 3.2.3 says that the AD bit is set by the name server side
+ of a security-aware recursive name server if and only if it
+ considers all the RRSets in the Answer and Authority sections to
+ be authentic. In this case, the name server has reason to
+ believe the RRSets are all authentic, so it SHOULD set the AD
+ bit. If the data does not validate, the vDNS64 MUST respond with
+ RCODE=2 (Server failure).
+ A security-aware end point might take the presence of the AD bit
+ as an indication that the data is valid, and may pass the DNS
+ (and DNSSEC) data to an application. If the application attempts
+ to validate the synthesized data, of course, the validation will
+ fail. One could argue therefore that this approach is not
+ desirable, but security aware stub resolvers must not place any
+ reliance on data received from resolvers and validated on their
+ behalf without certain criteria established by [RFC4035], section
+ 4.9.3. An application that wants to perform validation on its
+ own should use the CD bit.
+
+ 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
+ validation, but MUST NOT perform synthesis. It MUST return the
+ data to the query initiator, just like a regular recursive
+ resolver, and depend on the client to do the validation and the
+ synthesis itself.
+ The disadvantage to this approach is that an end point that is
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 16]
+
+Internet-Draft DNS64 February 2010
+
+
+ translation-oblivious but security-aware and validating will not
+ be able to use the DNS64 functionality. In this case, the end
+ point will not have the desired benefit of NAT64. In effect,
+ this strategy means that any end point that wishes to do
+ validation in a NAT64 context must be upgraded to be translation-
+ aware as well.
+
+
+6. Deployment notes
+
+ While DNS64 is intended to be part of a strategy for aiding IPv6
+ deployment in an internetworking environment with some IPv4-only and
+ IPv6-only networks, it is important to realise that it is
+ incompatible with some things that may be deployed in an IPv4-only or
+ dual-stack context.
+
+6.1. DNS resolvers and DNS64
+
+ Full-service resolvers that are unaware of the DNS64 function can be
+ (mis)configured to act as mixed-mode iterative and forwarding
+ resolvers. In a native IPv4 context, this sort of configuration may
+ appear to work. It is impossible to make it work properly without it
+ being aware of the DNS64 function, because it will likely at some
+ point obtain IPv4-only glue records and attempt to use them for
+ resolution. The result that is returned will contain only A records,
+ and without the ability to perform the DNS64 function the resolver
+ will be unable to answer the necessary AAAA queries.
+
+6.2. DNSSEC validators and DNS64
+
+ Existing DNSSEC validators (i.e. that are unaware of DNS64) might
+ reject all the data that comes from DNS64 as having been tampered
+ with (even if it did not set CD when querying). If it is necessary
+ to have validation behind the DNS64, then the validator must know how
+ to perform the DNS64 function itself. Alternatively, the validating
+ host may establish a trusted connection with a DNS64, and allow the
+ DNS64 recursor to do all validation on its behalf.
+
+6.3. DNS64 and multihomed and dual-stack hosts
+
+6.3.1. IPv6 multihomed hosts
+
+ Synthetic AAAA records may be constructed on the basis of the network
+ context in which they were constructed. If a host sends DNS queries
+ to resolvers in multiple networks, it is possible that some of them
+ will receive answers from a DNS64 without all of them being connected
+ via a NAT64. For instance, suppose a system has two interfaces, i1
+ and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 17]
+
+Internet-Draft DNS64 February 2010
+
+
+ has native IPv6 connectivity only. I1 might receive a AAAA answer
+ from a DNS64 that is configured for a particular NAT64; the IPv6
+ address contained in that AAAA answer will not connect with anything
+ via i2.
+
+ This example illustrates why it is generally preferable that hosts
+ treat DNS answers from one interface as local to that interface. The
+ answer received on one interface will not work on the other
+ interface. Hosts that attempt to use DNS answers globally may
+ encounter surprising failures in these cases. For more discussion of
+ this topic, see [I-D.savolainen-mif-dns-server-selection].
+
+ Note that the issue is not that there are two interfaces, but that
+ there are two networks involved. The same results could be achieved
+ with a single interface routed to two different networks.
+
+6.3.2. Accidental dual-stack DNS64 use
+
+ Similarly, suppose that i1 has IPv6 connectivity and can connect to
+ the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
+ In this case, i1 could receive an IPv6 address from a synthetic AAAA
+ that would better be reached via native IPv4. Again, it is worth
+ emphasising that this arises because there are two networks involved.
+
+ Since it is most likely that the host will attempt AAAA resolution
+ first, in this arrangement the host will often use the NAT64 when
+ native IPv4 would be preferable. For this reason, hosts with IPv4
+ connectivity to the Internet should avoid using DNS64. This can be
+ partly resolved by ISPs when providing DNS resolvers to clients, but
+ that is not a guarantee that the NAT64 will never be used when a
+ native IPv4 connection should be used. There is no general-purpose
+ mechanism to ensure that native IPv4 transit will always be
+ preferred, because to a DNS64-oblivious host, the DNS64 looks just
+ like an ordinary DNS server. Operators of a NAT64 should expect
+ traffic to pass through the NAT64 even when it is not necessary.
+
+6.3.3. Intentional dual-stack DNS64 use
+
+ Finally, consider the case where the IPv4 connectivity on i2 is only
+ to a LAN, with an IPv6-only connection on i1 to the Internet,
+ connecting to the IPv4 Internet via NAT64. Traffic to the LAN may
+ not be routable from the global Internet, as is often the case (for
+ instance) with LANs using RFC1918 addresses. In this case, it is
+ critical that the DNS64 not synthesize AAAA responses for hosts in
+ the LAN, or else that the DNS64 be aware of hosts in the LAN and
+ provide context-sensitive answers ("split view" DNS answers) for
+ hosts inside the LAN. As with any split view DNS arrangement,
+ operators must be prepared for data to leak from one context to
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 18]
+
+Internet-Draft DNS64 February 2010
+
+
+ another, and for failures to occur because nodes accessible from one
+ context are not accessible from the other.
+
+ It is important for deployers of DNS64 to realise that, in some
+ circumstances, making the DNS64 available to a dual-stack host will
+ cause the host to prefer to send packets via NAT64 instead of via
+ native IPv4, with the associated loss of performance or functionality
+ (or both) entailed by the NAT. At the same time, some hosts are not
+ able to learn about DNS servers provisioned on IPv6 addresses, or
+ simply cannot send DNS packets over IPv6.
+
+
+7. Deployment scenarios and examples
+
+ In this section, we walk through some sample scenarios that are
+ expected to be common deployment cases. It should be noted that this
+ is provided for illustrative purposes and this section is not
+ normative. The normative definition of DNS64 is provided in
+ Section 5 and the normative definition of the address transformation
+ algorithm is provided in [I-D.ietf-behave-address-format].
+
+ There are two main different setups where DNS64 is expected to be
+ used (other setups are possible as well, but these two are the main
+ ones identified at the time of this writing).
+
+ One possible setup that is expected to be common is the case of an
+ end site or an ISP that is providing IPv6-only connectivity or
+ connectivity to IPv6-only hosts that wants to allow the
+ communication from these IPv6-only connected hosts to the IPv4
+ Internet. This case is called An-IPv6-network-to-IPv4-Internet
+ [I-D.ietf-behave-v6v4-framework]. In this case, the IPv6/IPv4
+ Translator is used to connect the end site or the ISP to the IPv4
+ Internet and the DNS64 function is provided by the end site or the
+ ISP.
+
+ The other possible setup that is expected is an IPv4 site that
+ wants that its IPv4 servers to be reachable from the IPv6
+ Internet. This case is called IPv6-Internet-to-an-IPv4-network
+ [I-D.ietf-behave-v6v4-framework]. It should be noted that the
+ IPv4 addresses used in the IPv4 site can be either public or
+ private. In this case, the IPv6/IPv4 translator is used to
+ connect the IPv4 end site to the IPv6 Internet and the DNS64
+ function is provided by the IPv4 end site itself.
+
+ In this section we illustrate how the DNS64 behaves in the different
+ scenarios that are expected to be common. We consider then 3
+ possible scenarios, namely:
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 19]
+
+Internet-Draft DNS64 February 2010
+
+
+ 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+ mode
+
+ 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
+ resolver mode
+
+ 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
+ mode
+
+7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+ DNS server mode
+
+ In this example, we consider an IPv6 node located in an IPv6-only
+ site that initiates a communication to an IPv4 node located in the
+ IPv4 Internet.
+
+ The scenario for this case is depicted in the following figure:
+
+
+ +---------------------+ +---------------+
+ |IPv6 network | | IPv4 |
+ | | +-------------+ | Network |
+ | |--| Name server |--| |
+ | | | with DNS64 | | +----+ |
+ | +----+ | +-------------+ | | H2 | |
+ | | H1 |---| | | +----+ |
+ | +----+ | +-------+ | 192.0.2.1 |
+ | |------| NAT64 |----| |
+ | | +-------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
+ address 192.0.2.1 and FQDN h2.example.com
+
+ A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+ Internet. This IPv6/IPv4 Translator has an IPv4 address 203.0.113.1
+ assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96
+ to create IPv6 representations of IPv4 addresses, as defined in
+ [I-D.ietf-behave-address-format].
+
+ The other element involved is the local name server. The name server
+ is a dual-stack node, so that H1 can contact it via IPv6, while it
+ can contact IPv4-only name servers via IPv4.
+
+ The local name server is configured to represent the whole IPv4
+ unicast space with using the WKP 64:FF9B::/96. For the purpose of
+ this example, we assume it learns this through manual configuration.
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 20]
+
+Internet-Draft DNS64 February 2010
+
+
+ For this example, assume the typical DNS situation where IPv6 hosts
+ have only stub resolvers, and they are configured with the IP address
+ of a name server that they always have to query and that performs
+ recursive lookups (henceforth called "the recursive nameserver").
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
+ a DNS query for a AAAA record for H2 to the recursive name
+ server. The recursive name server implements DNS64
+ functionality.
+
+ 2. The recursive name server resolves the query, and discovers that
+ there are no AAAA records for H2.
+
+ 3. The recursive name server queries for A records for H2 and gets
+ back a single A records containing the IPv4 address 192.0.2.1.
+ The name server then synthesizes a AAAA records. The IPv6
+ address in the AAAA record contains the prefix assigned to the
+ IPv6/IPv4 Translator in the upper 96 bits then the received IPv4
+ address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent to the destination address 64:FF9B::
+ 192.0.2.1.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ translator and the subsequent communication flows by means of the
+ IPv6/IPv4 translator mechanisms.
+
+7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
+ stub-resolver mode
+
+ This case is depicted in the following figure:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 21]
+
+Internet-Draft DNS64 February 2010
+
+
+ +---------------------+ +---------------+
+ |IPv6 network | | IPv4 |
+ | | +--------+ | Network |
+ | |-----| Name |----| |
+ | +-----+ | | server | | +----+ |
+ | | H1 | | +--------+ | | H2 | |
+ | |with |---| | | +----+ |
+ | |DNS64| | +-------+ | 192.0.2.1 |
+ | +----+ |------| NAT64 |----| |
+ | | +-------+ | |
+ | | | | |
+ +---------------------+ +---------------+
+
+
+ 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
+
+ A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+ Internet. This IPv6/IPv4 Translator is using the WKP 64:FF9B::/96
+ and an IPv4 address T 203.0.113.1 assigned to its IPv4 interface.
+
+ H1 needs to know the prefix assigned to the local IPv6/IPv4
+ Translator (64:FF9B::/96). For the purpose of this example, we
+ assume it learns this through manual configuration.
+
+ Also shown is a name server. For the purpose of this example, we
+ assume that the name server is a dual-stack node, so that H1 can
+ contact it via IPv6, while it can contact IPv4-only name servers via
+ IPv4.
+
+ For this example, assume the typical situation where IPv6 hosts have
+ only stub resolvers and always query a name server that provides
+ recursive lookups (henceforth called "the recursive name server").
+ The recursive name server does not perform the DNS64 function.
+
+ The steps by which H1 establishes communication with H2 are:
+
+ 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
+ a DNS query for a AAAA record for H2 to the recursive name
+ server.
+
+ 2. The recursive DNS server resolves the query, and returns the
+ answer to H1. Because there are no AAAA records in the global
+ DNS for H2, the answer is empty.
+
+ 3. The stub resolver at H1 then queries for an A record for H2 and
+ gets back an A record containing the IPv4 address 192.0.2.1. The
+ DNS64 function within H1 then synthesizes a AAAA record. The
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 22]
+
+Internet-Draft DNS64 February 2010
+
+
+ IPv6 address in the AAAA record contains the prefix assigned to
+ the IPv6/IPv4 translator in the upper 96 bits, then the received
+ IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
+ 192.0.2.1.
+
+ 4. H1 sends a packet towards H2. The packet is sent to the
+ destination address 64:FF9B::192.0.2.1.
+
+ 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
+ translator and the subsequent communication flows using the IPv6/
+ IPv4 translator mechanisms.
+
+7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
+ server mode
+
+ In this example, we consider an IPv6 node located in the IPv6
+ Internet that initiates a communication to an IPv4 node located in
+ the IPv4 site.
+
+ In some cases, this scenario can be addressed without using any form
+ of DNS64 function. This is so because in principle it is possible to
+ assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6
+ address would be constructed using the address transformation
+ algorithm defined in [I-D.ietf-behave-address-format] that takes as
+ input the Pref64::/96 and the IPv4 address of the IPv4 node. Note
+ that the IPv4 address can be a public or a private address; the
+ latter does not present any additional difficulty, since an NSP must
+ be used as Pref64::/96 (in this scenario the usage of the Well-Known
+ prefix is not supported as discussed in
+ [I-D.ietf-behave-address-format]). Once these IPv6 addresses have
+ been assigned to represent the IPv4 nodes in the IPv6 Internet, real
+ AAAA RRs containing these addresses can be published in the DNS under
+ the site's domain. This is the recommended approach to handle this
+ scenario, because it does not involve synthesizing AAAA records at
+ the time of query.
+
+ However, there are some more dynamic scenarios, where synthesizing
+ AAAA RRs in this setup may be needed. In particular, when DNS Update
+ [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+ nodes, there are two options: One option is to modify the DNS server
+ that receives the dynamic DNS updates. That would normally be the
+ authoritative server for the zone. So the authoritative zone would
+ have normal AAAA RRs that are synthesized as dynamic updates occur.
+ The other option is modify all the authoritative servers to generate
+ synthetic AAAA records for a zone, possibly based on additional
+ constraints, upon the receipt of a DNS query for the AAAA RR. The
+ first option -- in which the AAAA is synthesized when the DNS update
+ message is received, and the data published in the relevant zone --
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 23]
+
+Internet-Draft DNS64 February 2010
+
+
+ is recommended over the second option (i.e. the synthesis upon
+ receipt of the AAAA DNS query). This is because it is usually easier
+ to solve problems of misconfiguration and so on when the DNS
+ responses are not being generated dynamically. However, it may be
+ the case where the primary server (that receives all the updates)
+ cannot be upgraded for whatever reason, but where a secondary can be
+ upgraded in order to handle the (comparatively small amount) of AAAA
+ queries. In such case, it is possible to use the DNS64 as described
+ next. The DNS64 behavior that we describe in this section covers the
+ case of synthesizing the AAAA RR when the DNS query arrives.
+
+ The scenario for this case is depicted in the following figure:
+
+
+ +-----------+ +----------------------+
+ | | | IPv4 site |
+ | IPv6 | +-------+ | +----+ |
+ | Internet |------| NAT64 |-----|---| H2 | |
+ | | +-------+ | +----+ |
+ | | | | 192.0.2.1 |
+ | | +------------+ | |
+ | |----| Name server|--| |
+ | | | with DNS64 | | |
+ +-----------+ +------------+ | |
+ | | | |
+ +----+ | |
+ | H1 | +----------------------+
+ +----+
+
+ The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
+ address X 192.0.2.1 and FQDN h2.example.com.
+
+ A IPv6/IPv4 translator connects the IPv4 network to the IPv6
+ Internet. This IPv6/IPv4 translator has a NSP 2001:DB8::/96.
+
+ Also shown is the authoritative name server for the local domain with
+ DNS64 functionality. For the purpose of this example, we assume that
+ the name server is a dual-stack node, so that H1 or a recursive
+ resolver acting on the request of H1 can contact it via IPv6, while
+ it can be contacted by IPv4-only nodes to receive dynamic DNS updates
+ via IPv4.
+
+ The local name server needs to know the prefix assigned to the local
+ IPv6/IPv4 Translator (2001:DB8::/96). For the purpose of this
+ example, we assume it learns this through manual configuration.
+
+ The steps by which H1 establishes communication with H2 are:
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 24]
+
+Internet-Draft DNS64 February 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. The query is eventually
+ forwarded to the server in the IPv4 site.
+
+ 2. The local DNS server resolves the query (locally), and discovers
+ that there are no AAAA records for H2.
+
+ 3. The name server verifies that h2.example.com and its A RR are
+ among those that the local policy defines as allowed to generate
+ a AAAA RR from. If that is the case, the name server synthesizes
+ a AAAA record from the A RR and the prefix 2001:DB8::/96. The
+ IPv6 address in the AAAA record is 2001:DB8::192.0.2.1.
+
+ 4. H1 receives the synthetic AAAA record and sends a packet towards
+ H2. The packet is sent to the destination address 2001:DB8::
+ 192.0.2.1.
+
+ 5. The packet is routed through the IPv6 Internet to the IPv6
+ interface of the IPv6/IPv4 translator and the communication flows
+ using the IPv6/IPv4 translator mechanisms.
+
+
+8. Security Considerations
+
+ See the discussion on the usage of DNSSEC and DNS64 described in
+ section 3, section 5.5, and section 6.2. .
+
+
+9. IANA Considerations
+
+ This memo makes no request of IANA.
+
+
+10. Contributors
+
+ Dave Thaler
+
+ Microsoft
+
+ dthaler@windows.microsoft.com
+
+
+11. Acknowledgements
+
+ This draft contains the result of discussions involving many people,
+ including the participants of the IETF BEHAVE Working Group. The
+ following IETF participants made specific contributions to parts of
+ the text, and their help is gratefully acknowledged: Mark Andrews,
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 25]
+
+Internet-Draft DNS64 February 2010
+
+
+ Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton,
+ Marc Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis
+ Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh Krishnan,
+ Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata,
+ Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark
+ Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Florian
+ Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
+
+ Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+ Trilogy, a research project supported by the European Commission
+ under its Seventh Framework Program.
+
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [I-D.ietf-behave-address-format]
+ Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+ draft-ietf-behave-address-format-04 (work in progress),
+ January 2010.
+
+12.2. Informative References
+
+ [I-D.ietf-behave-v6v4-xlate-stateful]
+ Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers",
+ draft-ietf-behave-v6v4-xlate-stateful-08 (work in
+ progress), January 2010.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 26]
+
+Internet-Draft DNS64 February 2010
+
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
+ Address Translator - Protocol Translator (NAT-PT) to
+ Historic Status", RFC 4966, July 2007.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "iSpecial Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [I-D.ietf-behave-v6v4-framework]
+ Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation",
+ draft-ietf-behave-v6v4-framework-06 (work in progress),
+ February 2010.
+
+ [I-D.venaas-behave-mcast46]
+ Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
+ IPv4 - IPv6 multicast translator",
+ draft-venaas-behave-mcast46-01 (work in progress),
+ July 2009.
+
+ [I-D.ietf-dnsop-default-local-zones]
+ Andrews, M., "Locally-served DNS Zones",
+ draft-ietf-dnsop-default-local-zones-09 (work in
+ progress), November 2009.
+
+ [I-D.savolainen-mif-dns-server-selection]
+ Savolainen, T., "DNS Server Selection on Multi-Homed
+ Hosts", draft-savolainen-mif-dns-server-selection-01 (work
+ in progress), October 2009.
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 27]
+
+Internet-Draft DNS64 February 2010
+
+
+Appendix A. Motivations and Implications of synthesizing AAAA RR when
+ real AAAA RR exists
+
+ The motivation for synthesizing AAAA RRs when a real AAAA RRs exist
+ is to support the following scenario:
+
+ An IPv4-only server application (e.g. web server software) is
+ running on a dual-stack host. There may also be dual-stack server
+ applications also running on the same host. That host has fully
+ routable IPv4 and IPv6 addresses and hence the authoritative DNS
+ server has an A and a AAAA record as a result.
+
+ An IPv6-only client (regardless of whether the client application
+ is IPv6-only, the client stack is IPv6-only, or it only has an
+ IPv6 address) wants to access the above server.
+
+ The client issues a DNS query to a DNS64 resolver.
+
+ If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+ then the communication will fail. Even though there's a real AAAA,
+ the only way for communication to succeed is with the translated
+ address. So, in order to support this scenario, the administrator of
+ a DNS64 service may want to enable the synthesis of AAAA RRs even
+ when real AAAA RRs exist.
+
+ The implication of including synthetic AAAA RR when real AAAA RR
+ exist is that translated connectivity may be preferred over native
+ connectivity in some cases where the DNS64 is operated in DNS server
+ mode.
+
+ RFC3484 [RFC3484] rules use longest prefix match to select the
+ preferred destination address to use. So, if the DNS64 resolver
+ returns both the synthetic AAAA RRs and the real AAAA RRs, then if
+ the DNS64 is operated by the same domain as the initiating host, and
+ a global unicast prefix (called an NSP in
+ [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
+ is likely to be preferred.
+
+ This means that without further configuration:
+
+ In "An IPv6 network to the IPv4 Internet" scenario , the host will
+ prefer translated connectivity if an NSP is used. If the Well-
+ Known Prefix defined in [I-D.ietf-behave-address-format] is used,
+ it will probably prefer native connectivity.
+
+ In the "IPv6 Internet to an IPv4 network" scenario, it is possible
+ to bias the selection towards the real AAAA RR if the DNS64
+ resolver returns the real AAAA first in the DNS reply, when an NSP
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 28]
+
+Internet-Draft DNS64 February 2010
+
+
+ is used (the Well-Known Prefix usage is not supported in this
+ case)
+
+ In "an IPv6 network to IPv4 network" scenario, for local
+ destinations (i.e., target hosts inside the local site), it is
+ likely that the NSP and the destination prefix are the same, so we
+ can use the order of RR in the DNS reply to bias the selection
+ through native connectivity. If the Well-Known Prefix is used,
+ the longest prefix match rule will select native connectivity.
+
+ So this option introduces problems in the following cases:
+
+ An IPv6 network to the IPv4 internet with an NSP
+
+ IPv6 to IPv4 in the same network when reaching external
+ destinations and an NSP is used.
+
+ In any case, the problem can be solved by properly configuring the
+ RFC3484 [RFC3484] policy table, but this requires effort on the part
+ of the site operator.
+
+
+Authors' Addresses
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6249500
+ Fax:
+ Email: marcelo@it.uc3m.es
+ URI: http://www.it.uc3m.es/marcelo
+
+
+ Andrew Sullivan
+ Shinkuro
+ 4922 Fairmont Avenue, Suite 250
+ Bethesda, MD 20814
+ USA
+
+ Phone: +1 301 961 3131
+ Email: ajs@shinkuro.com
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 29]
+
+Internet-Draft DNS64 February 2010
+
+
+ Philip Matthews
+ Unaffiliated
+ 600 March Road
+ Ottawa, Ontario
+ Canada
+
+ Phone: +1 613-592-4343 x224
+ Fax:
+ Email: philip_matthews@magma.ca
+ URI:
+
+
+ Iljitsch van Beijnum
+ IMDEA Networks
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6246245
+ Email: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al. Expires August 19, 2010 [Page 30]
+
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt
index b0a269b1113d..935c709bcc21 100644
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt
@@ -5,13 +5,13 @@
DNS Extensions Working Group Edward Lewis
Internet-Draft NeuStar, Inc.
-Updates: 1034, 1035 (if approved) A. Hoenes
+Updates: 1034, 1035 (if approved) A. Hoenes, Ed.
Intended status: Standards Track TR-Sys
-Expires: June 6, 2010 December 6, 2009
+Expires: July 18, 2010 January 18, 2010
DNS Zone Transfer Protocol (AXFR)
- draft-ietf-dnsext-axfr-clarify-12
+ draft-ietf-dnsext-axfr-clarify-13
Abstract
@@ -22,12 +22,12 @@ Abstract
forcing implementations intended to be compliant to make assumptions,
impeding interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new
- definition of AXFR -- new in the sense that is it recording an
- accurate definition of an interoperable AXFR mechanism.
+ definition of AXFR -- new in the sense that it records an accurate
+ definition of an interoperable AXFR mechanism.
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
@@ -55,26 +55,30 @@ Status of this Memo
-Lewis & Hoenes Expires June 6, 2010 [Page 1]
+Lewis & Hoenes Expires July 18, 2010 [Page 1]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
- This Internet-Draft will expire on June 6, 2010.
+ This Internet-Draft will expire on July 18, 2010.
Copyright Notice
- Copyright (c) 2009 IETF Trust and the persons identified as the
+ Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
@@ -107,13 +111,9 @@ Copyright Notice
-
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 2]
+Lewis & Hoenes Expires July 18, 2010 [Page 2]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
Table of Contents
@@ -131,13 +131,12 @@ Table of Contents
2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10
2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10
2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11
- 2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11
- 2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12
- 2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14
- 2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14
- 2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14
- 2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14
- 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14
+ 2.2.1. Header Values . . . . . . . . . . . . . . . . . . . . . 12
+ 2.2.2. Question Section . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.4. Authority Section . . . . . . . . . . . . . . . . . . . 14
+ 2.2.5. Additional Section . . . . . . . . . . . . . . . . . . . 14
+ 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 15
3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15
3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16
@@ -148,28 +147,29 @@ Table of Contents
4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20
4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21
- 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22
6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24
- 7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24
7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Internationalization Considerations . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . 25
- 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
+ 12.1. Normative References . .. . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27
- 13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
-Lewis & Hoenes Expires June 6, 2010 [Page 3]
+Lewis & Hoenes Expires July 18, 2010 [Page 3]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
1. Introduction
@@ -201,7 +201,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
written after and prior to the publication of this document.
"General purpose DNS implementation" refers to DNS software developed
- for wide-spread use. This includes resolvers and servers freely
+ for widespread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service
offerings.
@@ -223,9 +223,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
data stored in relational databases (as opposed to master files),
-Lewis & Hoenes Expires June 6, 2010 [Page 4]
+Lewis & Hoenes Expires July 18, 2010 [Page 4]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
relying on the database's non-DNS means to synchronize the database
@@ -270,18 +270,18 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
the code point for the AXFR QTYPE (see Section 2.1.2 below for more
- details). Section 4.2 of RFC 1035 discusses the transport layer use
- of DNS and shortly explains why UDP transport is deemed inappropriate
- for AXFR; the last paragraph of Section 4.2.2 gives details for the
- TCP connection management with AXFR. Finally, the second paragraph
- of Section 6.3 in RFC 1035 mandates server behavior when zone data
- changes occur during an ongoing zone transfer using AXFR.
+ details). Section 4.2 of RFC 1035 discusses how the DNS uses the
+ transport layer and briefly explains why UDP transport is deemed
+ inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
+ details regarding TCP connection management for AXFR. Finally, the
+ second paragraph of Section 6.3 in RFC 1035 mandates server behavior
+ when zone data changes occur during an ongoing zone transfer using
+ AXFR.
-
-Lewis & Hoenes Expires June 6, 2010 [Page 5]
+Lewis & Hoenes Expires July 18, 2010 [Page 5]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
This document will update the specification of AXFR. To this end, it
@@ -335,9 +335,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 6]
+Lewis & Hoenes Expires July 18, 2010 [Page 6]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
2. AXFR Messages
@@ -346,13 +346,13 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
AXFR response messages returned for it. In this document, the AXFR
client is the sender of the AXFR query and the AXFR server is the
responder. (Use of terms such as master, slave, primary, secondary
- are not important to defining AXFR.) The use of the word "session"
+ are not important for defining AXFR.) The use of the word "session"
without qualification refers to an AXFR session.
An important aspect to keep in mind is that the definition of AXFR is
- restricted to TCP [RFC0793]. The design of the AXFR process has
- certain inherent features that are not easily ported to UDP
- [RFC0768].
+ restricted to TCP [RFC0793] (see Section 4 for details). The design
+ of the AXFR process has certain inherent features that are not easily
+ ported to UDP [RFC0768].
The basic format of an AXFR message is the DNS message as defined in
Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
@@ -391,9 +391,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 7]
+Lewis & Hoenes Expires July 18, 2010 [Page 7]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
For convenience, the synopsis of the DNS message header from
@@ -447,9 +447,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 8]
+Lewis & Hoenes Expires July 18, 2010 [Page 8]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
2.1.1. Header Values
@@ -490,7 +490,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
A server MUST reply using messages that use the same message ID to
allow a client to have multiple queries outstanding concurrently
- over the same TCP connection -- see Note a) in Section 2.2.2 for
+ over the same TCP connection -- see Note a) in Section 2.2.1 for
more details.
b) 'n/a' -- The value in this field has no meaning in the context of
@@ -503,28 +503,21 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 9]
+Lewis & Hoenes Expires July 18, 2010 [Page 9]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
d) The client MUST set this field to the number of resource records
- appearing in the Additional section. See Section 2.1.5
- "Additional Section" for details.
-
- The value MAY be 0, 1 or 2. If it is 2, the Additional section
- MUST contain both an EDNS0 [RFC2671] OPT resource record and a
- record carrying transaction integrity and authentication data,
- currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
- value is 1, then the Additional section MUST contain either only
- an EDNS0 OPT resource record or a record carrying transaction
- integrity and authentication data. If the value is 0, the
- Additional section MUST be empty.
+ it places into the Additional section. In the absense of explicit
+ specification of new RRs to be carried in the Additional section
+ of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5
+ "Additional Section" for details on the currently applicable RRs.
2.1.2. Question Section
- The Query section of the AXFR query MUST conform to Section 4.1.2 of
- RFC 1035, and contain a single resource record with the following
+ The Question Section of the AXFR query MUST conform to Section 4.1.2
+ of RFC 1035, and contain a single resource record with the following
values:
QNAME the name of the zone requested
@@ -544,26 +537,36 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
2.1.5. Additional Section
- The client MAY include an EDNS0 OPT [RFC2671] resource record. If
+ Currently, two kinds of resource records are defined that can appear
+ in the Additional section of AXFR queries and responses: EDNS and DNS
+ transaction security. Future specifications defining RRs that can be
+ carried in the Additional section of normal DNS transactions need to
+ explicitly describe their use with AXFR, should that be desired.
+
+ The client MAY include one EDNS0 OPT [RFC2671] resource record. If
the server does not support EDNS0, the client MUST send this section
without an EDNS0 OPT resource record if there is a retry. However,
the protocol does not define an explicit indication that the server
does not support EDNS0; that needs to be inferred by the client.
Often, the server will return a FormErr(1) which might be related to
- the OPT resource record.
+ the OPT resource record. Note that, at the time of this writing,
+ only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in
+ the context of AXFR; future specifications of EDNS0 flags and/or
+ EDNS0 options must describe their usage in the context of AXFR, if
+ applicable.
- The client MAY include a transaction integrity and authentication
+ The client MAY include one transaction integrity and authentication
resource record, currently a choice of TSIG [RFC2845] or SIG(0)
- [RFC2931]. If the server has indicated that it does not recognize
- the resource record, and that the error is indeed caused by the
- resource record, the client probably should not try again. Removing
-Lewis & Hoenes Expires June 6, 2010 [Page 10]
+Lewis & Hoenes Expires July 18, 2010 [Page 10]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+ [RFC2931]. If the server has indicated that it does not recognize
+ the resource record, and that the error is indeed caused by the
+ resource record, the client probably should not try again. Removing
the security data in the face of an obstacle ought to only be done
with full awareness of the implication of doing so.
@@ -577,16 +580,17 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
Additional section might change over time. If either a change to an
existing resource record (like the OPT RR for EDNS0) is made or a new
Additional section record is created, the new definitions ought to
- include a discussion on the impact upon AXFR. Future resource
- records residing in the Additional section might have an effect that
- is orthogonal to AXFR, so can ride through the session as opaque
- data. In this case, a "wise" implementation ought to be able to pass
- these records through without disruption.
+ include a discussion on the applicability and impact upon AXFR.
+ Future resource records residing in the Additional section might have
+ an effect that is orthogonal to AXFR, so can ride through the session
+ as opaque data. In this case, a "wise" implementation ought to be
+ able to pass these records through without disruption.
2.2. AXFR Response
- The AXFR response will consist of 0 or more messages. A "0 message"
- response is covered in Section 2.2.1.
+ The AXFR response will consist of one or more messages. The special
+ case of a server closing the TCP connection without sending an AXFR
+ response is covered in section 2.3.
An AXFR response that is transferring the zone's contents will
consist of a series (which could be a series of length 1) of DNS
@@ -594,47 +598,50 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
SOA resource record of the zone, the last message MUST conclude with
the same SOA resource record. Intermediate messages MUST NOT contain
the SOA resource record. The AXFR server MUST copy the Question
- section from the corresponding AXFR query message in to the first
- response message's Question section. Subsequent messages MAY do the
- same or contain an empty Question section.
-
- An AXFR response indicates an error via a single DNS message with the
- return code set to the appropriate value for the condition
- encountered, sent once the error condition is detected. Such a
- message terminates the AXFR session; it MUST copy the Query Section
- from the AXFR query into its Query Section, but the inclusion of the
- terminating SOA resource record is not necessary.
+ section from the corresponding AXFR query message into the first
+ response message's Question section. For subsequent messages, it MAY
+ do the same or leave the Question section empty.
+
+ The AXFR protocol treats the zone contents as an unordered collection
+ (or to use the mathematical term, a "set") of RRs. Except for the
+ requirement that the transfer must begin and end with the SOA RR,
+ there is no requirement to send the RRs in any particular order or
+ grouped into response messages in any particular way. Although
+ servers typically do attempt to send related RRs (such as the RRs
+ forming an RRset, and the RRsets of a name) as a contiguous group or,
+ when message space allows, in the same response message, they are not
+ required to do so, and clients MUST accept any ordering and grouping
+ of the non-SOA RRs. Each RR SHOULD be transmitted only once, and
+ AXFR clients MUST ignore any duplicate RRs received.
+
+
+Lewis & Hoenes Expires July 18, 2010 [Page 11]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
+
+ Each AXFR response message SHOULD contain a sufficient number of RRs
+ to reasonably amortize the per-message overhead, up to the largest
+ number that will fit within a DNS message (taking the required
+ content of the other sections into account, as described below).
+ Some old AXFR clients expect each response message to contain only a
+ single RR. To interoperate with such clients, the server MAY
+ restrict response messages to a single RR. As there is no standard
+ way to automatically detect such clients, this typically requires
+ manual configuration at the server.
+
+ To indicate an error in an AXFR response, the AXFR server sends a
+ single DNS message when the error condition is detected, with the
+ response code set to the appropriate value for the condition
+ encountered, Such a message terminates the AXFR session; it MUST
+ contain a copy of the Question section from the AXFR query in its
+ Question section, but the inclusion of the terminating SOA resource
+ record is not necessary.
An AXFR server may send a number of AXFR response messages free of an
error condition before it sends the message indicating an error.
-2.2.1. "0 Message" Response
-
- A legitimate "0 message" response, i.e., the client sees no response
- whatsoever, is very exceptional and controversial. Unquestionably it
- is unhealthy for there to be 0 responses in a protocol that is
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 11]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
- designed around a query - response paradigm over an unreliable
- transport. The lack of a response could be a sign of underlying
- network problems and cause the protocol state machine to react
- accordingly. However, AXFR uses TCP and not UDP, eliminating
- undetectable network errors.
-
- A "0 message response" is reserved for situations in which the server
- has a reason to suspect that the query is sent for the purpose of
- abuse. Due to the use of this being so controversial, a "0 message
- response" is not being defined as a legitimate part of the protocol
- but the use of it is being acknowledged as a warning to AXFR client
- implementations. Any earnest query has the expectation of some
- response but nevertheless may not get one.
-
-2.2.2. Header Values
+2.2.1. Header Values
These are the DNS message header values for AXFR responses.
@@ -650,32 +657,27 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
RD RECOMMENDED: copy request's value, MAY be set to 0
RA SHOULD be 0 -- see Note c)
Z 'mbz' -- see Note d)
- AD covered by DNSSEC rules -- see Note e)
- CD covered by DNSSEC rules -- see Note e)
+ AD 'mbz' -- see Note d)
+ CD 'mbz' -- see Note d)
- RCODE See Note f)
+ RCODE See Note e)
QDCOUNT MUST be 1 in the first message;
MUST be 0 or 1 in all following messages;
MUST be 1 if RCODE indicates an error
- ANCOUNT See Note g)
+ ANCOUNT See Note f)
NSCOUNT MUST be 0
- ARCOUNT See Note h)
-
-
-
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 12]
+Lewis & Hoenes Expires July 18, 2010 [Page 12]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+ ARCOUNT See Note g)
+
Notes:
a) Because some old implementations behave differently than is now
@@ -713,43 +715,38 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
it.
- e) If the implementation supports the DNS Security Extensions (DNSSEC
- -- see Section 2), then this value MUST be set according to the
- rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
- Authoritative Response". If the implementation does not support
- the DNS Security Extensions, then this value MUST be set to 0 and
- MUST be ignored upon receipt.
-
- f) In the absence of an error, the server MUST set the value of this
+ e) In the absence of an error, the server MUST set the value of this
field to NoError(0). If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth(9).
(Reminder, consult the appropriate IANA registry [DNSVALS].) If a
client receives any other value in response, it MUST act according
+ to the error. For example, a malformed AXFR query or the presence
+ of an EDNS0 OPT resource record sent to an old server will result
+ in a FormErr(1) value. This value is not set as part of the AXFR-
+ specific response processing. The same is true for other values
+ indicating an error.
-Lewis & Hoenes Expires June 6, 2010 [Page 13]
+Lewis & Hoenes Expires July 18, 2010 [Page 13]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
- to the error. For example, a malformed AXFR query or the presence
- of an EDNS0 OPT resource record sent to an old server will garner
- a FormErr(1) value. This value is not set as part of the AXFR-
- specific response processing. The same is true for other values
- indicating an error.
- g) The count of answer records MUST equal the number of resource
+ f) The count of answer records MUST equal the number of resource
records in the AXFR Answer Section. When a server is aware that a
- client will only accept one resource record per response message,
- then the value MUST be 1. A server MAY be made aware of a
+ client will only accept response messages with a single resource
+ record, then the value MUST be 1. A server MAY be made aware of a
client's limitations via configuration data.
- h) The client MUST set this field to the number of resource records
- appearing in the Additional section. The considerations of Note
- d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
- Section" below for more details.
+ g) The server MUST set this field to the number of resource records
+ it places into the Additional section. In the absense of explicit
+ specification of new RRs to be carried in the Additional section
+ of AXFR response messages, the value MAY be 0, 1 or 2. See
+ Section 2.1.5 above for details on the currently applicable RRs
+ and Section 2.2.5 for additional considerations specific to AXFR
+ servers.
-2.2.3. Question Section
+2.2.2. Question Section
In the first response message, this section MUST be copied from the
query. In subsequent messages, this section MAY be copied from the
@@ -758,44 +755,57 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
this section MAY be used to determine the context of the message,
that is, the name of the zone being transferred.
-2.2.4. Answer Section
+2.2.3. Answer Section
- MUST be populated with the zone contents. See Section 3 below on
- encoding zone contents.
+ The Answer section MUST be populated with the zone contents. See
+ Section 3 below on encoding zone contents.
-2.2.5. Authority Section
+2.2.4. Authority Section
The Authority section MUST be empty.
-2.2.6. Additional Section
+2.2.5. Additional Section
The contents of this section MUST follow the guidelines for EDNS0 and
TSIG, SIG(0), or whatever other future record is possible here. The
contents of Section 2.1.5 apply analogously as well.
-2.3. TCP Connection Aborts
-
- If an AXFR client sends a query on a TCP connection and the
- connection is closed at any point, the AXFR client MUST consider the
- AXFR session terminated. The message ID MAY be used again on a new
- connection, even if the question and AXFR server are the same.
+ The following considerations specifically apply to AXFR responses:
+ If the client has supplied an EDNS0 OPT RR in the AXFR query and if
+ the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR
+ in the first response message and MAY do so in subsequent response
+ messages (see Section 2.2); the specifications of EDNS0 options to be
+ carried in the OPT RR may impose stronger requirements.
+ If the client has supplied a transaction security resource record
+ (currently a choice of TSIG and SIG(0)) and the server supports the
+ method chosen by the client, it MUST place the corresponding resource
-Lewis & Hoenes Expires June 6, 2010 [Page 14]
+Lewis & Hoenes Expires July 18, 2010 [Page 14]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
+ record into the AXFR response message(s), according to the rules
+ specified for that method.
+
+2.3. TCP Connection Aborts
+
+ If an AXFR client sends a query on a TCP connection and the
+ connection is closed at any point, the AXFR client MUST consider the
+ AXFR session terminated. The message ID MAY be used again on a new
+ connection, even if the question and AXFR server are the same.
Facing a dropped connection, a client SHOULD try to make some
- determination whether the connection closure was the result of
- network activity or a decision by the AXFR server. This
+ determination as to whether the connection closure was the result of
+ network activity or due to a decision by the AXFR server. This
determination is not an exact science. It is up to the AXFR client
- implementor to react, but the reaction SHOULD NOT be an endless cycle
- of retries nor an increasing (in frequency) retry rate.
+ to react, but the implemented reaction SHOULD NOT be either an
+ endless cycle of retries or an increasing (in frequency) retry rate.
- An AXFR server implementor SHOULD take into consideration the dilemma
+ An AXFR server implementor should take into consideration the dilemma
described above when a connection is closed with an outstanding query
in the pipeline. For this reason, a server ought to reserve this
course of action for situations in which it believes beyond a doubt
@@ -805,27 +815,34 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
3. Zone Contents
The objective of the AXFR session is to request and transfer the
- contents of a zone. The objective is to permit the AXFR client to
- reconstruct the zone as it exists at the server for the given zone
- serial number. Over time the definition of a zone has evolved from
- denoting a static set of records to also cover a dynamically updated
- set of records, and then a potentially continually regenerated set of
- records (e.g., RRs synthesized "on the fly" from rule sets or
- database lookup results in other forms than RR format) as well.
+ contents of a zone, in order to permit the AXFR client to faithfully
+ reconstruct the zone as it exists at the primary server for the given
+ zone serial number. The word "exists" here designates the externally
+ visible behavior, i.e., the zone content that is being served (handed
+ out to clients) -- not its persistent representation in a zone file
+ or database used by the server -- and that for consistency should be
+ served subsequently by the AXFR client in an identical manner.
+
+ Over time the definition of a zone has evolved from denoting a static
+ set of records to also cover a dynamically updated set of records,
+ and then a potentially continually regenerated set of records (e.g.,
+ RRs synthesized "on the fly" from rule sets or database lookup
+ results in other forms than RR format) as well.
3.1. Records to Include
- In the Answer section of AXFR response messages the resource records
+ In the Answer section of AXFR response messages, the resource records
within a zone for the given serial number MUST appear. The
definition of what belongs in a zone is described in RFC 1034,
Section 4.2, "How the database is divided into zones" (in particular
Section 4.2.1, "Technical considerations"), and it has been clarified
in Section 6 of RFC 2181.
- Unless the AXFR server knows that the AXFR client is old and expects
- just one resource record per AXFR response message, an AXFR server
- SHOULD populate an AXFR response message with as many complete
- resource record sets as will fit within a DNS message.
+
+Lewis & Hoenes Expires July 18, 2010 [Page 15]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
Zones for which it is impractical to list the entire zone for a
serial number are not suitable for AXFR retrieval. A typical (but
@@ -833,17 +850,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
responses generated via other database lookups and/or computed based
upon ever changing data.
-
-
-
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 15]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
3.2. Delegation Records
In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
@@ -865,13 +871,12 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
occurrence at a zone cut and the apex of a zone. This was first
described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
specification of DNSSEC), which parts of RFC 2181 now in fact are
- historical. The current DNSSEC core document set (see Note e) in
- Section 2.2.2 above) gives the full details for DNSSEC(bis) resource
+ historical. The current DNSSEC core document set (see second bullet
+ in Section 2 above) gives the full details for DNSSEC(bis) resource
record placement, and Section 3.1.5 of RFC 4035 normatively specifies
their treatment during AXFR; the alternate NSEC3 resource record
defined later in RFC 5155 behaves identically as the NSEC RR, for the
purpose of AXFR.
-
Informally:
o The DS RRSet only occurs at the parental side of a zone cut and is
@@ -889,23 +894,23 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
does not occur for AXFR, since each such RRSIG RRset belongs to a
single zone.
+
+Lewis & Hoenes Expires July 18, 2010 [Page 16]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
+
o Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
equally may occur at the parental side of a zone cut and at the
apex of a zone; each such resource record belongs to exactly one
of these zones and is to be included in the AXFR of that zone.
-
-Lewis & Hoenes Expires June 6, 2010 [Page 16]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
One issue is that in operations there are times when the NS resource
records for a zone might be different at a cut point in the parent
and at the apex of a zone. Sometimes this is the result of an error
and sometimes it is part of an ongoing change in name servers. The
DNS protocol is robust enough to overcome inconsistencies up to (but
- not including) there being no parent indicated NS resource record
+ not including) there being no parent-indicated NS resource record
referencing a server that is able to serve the child zone. This
robustness is one quality that has fueled the success of the DNS.
Still, the inconsistency is an error state and steps need to be taken
@@ -945,27 +950,25 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
authoritative for both halves would otherwise always answer from the
more authoritative set, concealing the error.)
- 3) The inconsistent NS resource record set might indicate a problem
- in a registration database.
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 17]
+Lewis & Hoenes Expires July 18, 2010 [Page 17]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+ 3) The inconsistent NS resource record set might indicate a problem
+ in a registration database.
+
4) This requirement is necessary to ensure that retrieving a given
(zone,serial) pair by AXFR yields the exact same set of resource
records no matter which of the zone's authoritative servers is chosen
as the source of the transfer.
If an AXFR server were allowed to respond with the authoritative NS
- RRset of a child zone instead of a glue NS RRset in the zone being
- transferred, the set of records returned could vary depending on
- whether or not the server happens to be authoritative for the child
- zone as well.
+ RRset of a child zone instead of a parent-side NS RRset in the zone
+ being transferred, the set of records returned could vary depending
+ on whether or not the server happened to be authoritative for the
+ child zone as well.
The property that a given (zone,serial) pair corresponds to a single,
well-defined set of records is necessary for the correct operation of
@@ -1002,19 +1005,24 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
name or label, you should preserve its case." ("Should" in the quote
predates [BCP14].)
- Name compression in an AXFR message MUST preserve the case of the
- original domain name. That is, although when comparing a domain
- name, "a" equals "A", when comparing for the purposes of message
-Lewis & Hoenes Expires June 6, 2010 [Page 18]
+Lewis & Hoenes Expires July 18, 2010 [Page 18]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
- compression, "a" is not equal to "A". Note that this is not the
- usual definition of name comparison in the DNS protocol and
- represents a new requirement on AXFR servers.
+ Since the primary objective of AXFR is to enable the client to serve
+ the same zone content as the server, unlike such normal DNS responses
+ that are expected to preserve the case in the query, the actual zone
+ transfer needs to retain the case of the labels in the zone content.
+ Hence, name compression in an AXFR message SHOULD be performed in a
+ case-preserving manner, unlike how it is done for 'normal' DNS
+ responses. That is, although when comparing a domain name for
+ matching, "a" equals "A", when comparing for the purposes of message
+ compression for AXFR, "a" is not equal to "A". Note that this is not
+ the usual definition of name comparison in the DNS protocol and
+ represents a new understanding of the requirement on AXFR servers.
Rules governing name compression of RDATA in an AXFR message MUST
abide by the specification in "Handling of Unknown DNS Resource
@@ -1047,11 +1055,19 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
The most common scenario is for an AXFR client to open a TCP
connection to the AXFR server, send an AXFR query, receive the AXFR
- response, and then close the connection. But variations of that
- most simple scenario are legitimate and likely, in particular sending
- a query for the zone's SOA resource record first over the same TCP
+ response, and then close the connection. But variations of that most
+ simple scenario are legitimate and likely: in particular, sending a
+ query for the zone's SOA resource record first over the same TCP
connection, and reusing an existing TCP connection for other queries.
+
+
+
+Lewis & Hoenes Expires July 18, 2010 [Page 19]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
+
Therefore, the assumption that a TCP connection is dedicated to a
single AXFR session is incorrect. This wrong assumption has led to
implementation choices that prevent either multiple concurrent zone
@@ -1061,27 +1077,21 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
servers that are authoritative for a common set of zones found it
desirable to be able to have multiple concurrent zone transfers in
progress; this way a name server does not have to wait for one zone
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 19]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
- transfer to complete before the next could begin. RFC 1035 did not
- exclude this possibility, but legacy implementations missed to
- support this functionality. The remaining presence of such legacy
- implementations makes it necessary that new general purpose server
- implementation still provide options for gracefull fallback to the
- old behavior in their support of concurrent DNS transactions and AXFR
- sessions on a single TCP connection.
+ transfer to complete before the next can begin. RFC 1035 did not
+ exclude this possibility, but legacy implementations failed to
+ support this functionality efficiently, over a single TCP connection.
+ The remaining presence of such legacy implementations makes it
+ necessary that new general purpose client implementations still
+ provide options for graceful fallback to the old behavior in their
+ support of concurrent DNS transactions and AXFR sessions on a single
+ TCP connection.
4.1. TCP
In the original definition there arguably is an implicit assumption
(probably unintentional) that a TCP connection is used for one and
only one AXFR session. This is evidenced in the lack of an explicit
- requirement to copy the Query section and/or the message ID into
+ requirement to copy the Question Section and/or the message ID into
responses, no explicit ordering information within the AXFR response
messages, and the lack of an explicit notice indicating that a zone
transfer continues in the next message.
@@ -1100,7 +1110,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
An AXFR client MAY request a connection to an AXFR server for any
reason. An AXFR client SHOULD close the connection when there is no
apparent need to use the connection for some time period. The AXFR
- server ought not have to maintain idle connections, the burden of
+ server ought not have to maintain idle connections; the burden of
connection closure ought to be on the client. "Apparent need" for
the connection is a judgment for the AXFR client and the DNS client.
If the connection is used for multiple sessions, or if it is known
@@ -1108,6 +1118,12 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
anticipated or currently on the open connection, then there is
"apparent need".
+
+Lewis & Hoenes Expires July 18, 2010 [Page 20]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
+
An AXFR client can cancel the delivery of a zone only by closing the
connection. However, this action will also cancel all other
outstanding activity using the connection. There is no other
@@ -1117,22 +1133,17 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions and non-AXFR transactions.
Recovery from this situation is not straightforward. If the
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 20]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
disruption was a spurious event, attempting to restart the connection
would be proper. If the disruption was caused by a failure that
- proved to be persistent, the AXFR client would be wise to not spend
+ proved to be persistent, the AXFR client would be wise not to spend
too many resources trying to rebuild the connection. Finally, if the
connection was dropped because of a policy at the AXFR server (as can
be the case with older AXFR servers), the AXFR client would be wise
- to not retry the connection. Unfortunately, knowing which of the
+ not to retry the connection. Unfortunately, knowing which of the
three cases above (momentary disruption, failure, policy) applies is
not possible with certainty, and can only be assessed by heuristics.
+ This exemplifies the general complications for clients in connection-
+ oriented protocols not receiving meaningful error responses.
An AXFR client MAY use an already opened TCP connection to start an
AXFR session. Using an existing open connection is RECOMMENDED over
@@ -1147,7 +1158,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
4.1.2. AXFR server TCP
An AXFR server MUST be able to handle multiple AXFR sessions on a
- single TCP connection, as well as handle other query/response
+ single TCP connection, as well as to handle other query/response
transactions over it.
If a TCP connection is closed remotely, the AXFR server MUST cancel
@@ -1160,8 +1171,14 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
response to a suspected security event SHOULD be done only in extreme
cases, when the server is certain the action is warranted. An
isolated request for a zone not on the AXFR server SHOULD receive a
- response with the appropriate return code and not see the connection
- broken.
+ response with the appropriate response code and not see the
+ connection broken.
+
+
+Lewis & Hoenes Expires July 18, 2010 [Page 21]
+
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
+
4.2. UDP
@@ -1174,12 +1191,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
AXFR sessions over UDP transport are not defined.
-
-Lewis & Hoenes Expires June 6, 2010 [Page 21]
-
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
5. Authorization
A zone administrator has the option to restrict AXFR access to a
@@ -1220,20 +1231,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 22]
+Lewis & Hoenes Expires July 18, 2010 [Page 22]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
6. Zone Integrity
@@ -1287,9 +1287,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 23]
+Lewis & Hoenes Expires July 18, 2010 [Page 23]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
7. Backwards Compatibility
@@ -1343,9 +1343,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 24]
+Lewis & Hoenes Expires July 18, 2010 [Page 24]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
8. Security Considerations
@@ -1358,7 +1358,6 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
9. IANA Considerations
[[ Note to RFC-Ed: this section may be deleted before publication. ]]
-
No new registries or new registrations are included in this document.
@@ -1384,8 +1383,8 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
Comments since the -05 version have come from these individuals:
Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
- Ian Jackson, Andreas Gustafsson, Brian Wellington, and other
- participants of the DNSEXT working group.
+ Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
+ Bill Manning, and other participants of the DNSEXT working group.
Edward Lewis served as a patiently listening sole document editor for
two years.
@@ -1399,9 +1398,10 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
URL: http://rfc-editor.org/
-Lewis & Hoenes Expires June 6, 2010 [Page 25]
+
+Lewis & Hoenes Expires July 18, 2010 [Page 25]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
12.1. Normative References
@@ -1455,9 +1455,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 26]
+Lewis & Hoenes Expires July 18, 2010 [Page 26]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
@@ -1511,9 +1511,9 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
-Lewis & Hoenes Expires June 6, 2010 [Page 27]
+Lewis & Hoenes Expires July 18, 2010 [Page 27]
-Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+Internet-Draft DNS Zone Transfer Protocol (AXFR) January 2010
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
@@ -1526,7 +1526,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
progress), September 2009.
-13. Editors' Addresses
+Authors' Addresses
Edward Lewis
46000 Center Oak Plaza
@@ -1535,7 +1535,7 @@ Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
Email: ed.lewis@neustar.biz
- Alfred Hoenes
+ Alfred Hoenes, Editor
TR-Sys
Gerlinger Str. 12
Ditzingen D-71254
@@ -1567,13 +1567,5 @@ Editorial Note: Discussion [[ to be removed by RFC-Editor ]]
-
-
-
-
-
-
-
-
-Lewis & Hoenes Expires June 6, 2010 [Page 28]
+Lewis & Hoenes Expires July 18, 2010 [Page 28]
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt
index 152d96efaca6..f651d1351ec1 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt
@@ -1,12 +1,12 @@
DNS Extensions working group V.Dolmatov, Ed.
Internet-Draft Cryptocom Ltd.
-Intended status: Standards Track November 30, 2009
-Expires: May 30, 2010
+Intended status: Standards Track December 12, 2009
+Expires: June 12, 2010
Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC
- draft-ietf-dnsext-dnssec-gost-05
+ draft-ietf-dnsext-dnssec-gost-06
Status of this Memo
@@ -29,7 +29,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on May 10 2010.
+ This Internet-Draft will expire on June 12 2010.
Copyright Notice
@@ -49,7 +49,7 @@ Abstract
resource records for use in the Domain Name System Security
Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-V.Dolmatov Expires May 30, 2010 [Page 1]
+V.Dolmatov Expires June 12, 2010 [Page 1]
Table of Contents
@@ -106,7 +106,7 @@ Table of Contents
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
-V.Dolmatov Expires May 30, 2010 [Page 2]
+V.Dolmatov Expires June 12, 2010 [Page 2]
2. DNSKEY Resource Records
@@ -121,17 +121,13 @@ V.Dolmatov Expires May 30, 2010 [Page 2]
According to [GOST3410], a public key is a point on the elliptic
curve Q = (x,y).
- The wire representation of a public key MUST contain 66 octets,
- where the first octet designates public key parameters, the second
- octet designates digest parameters next 32 octets contain the
- little-endian representation of x and the second 32 octets contain
- the little-endian representation of y.
+ The wire representation of a public key MUST contain 64 octets,
+ where the first 32 octets contain the little-endian representation
+ of x and the second 32 octets contain the little-endian
+ representation of y.
This corresponds to the binary representation of (<y>256||<x>256)
from [GOST3410], ch. 5.3.
- The only valid value for both parameters octets is 0.
- Other parameters octets values are reserved for future use.
-
Corresponding public key parameters are those identified by
id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
and the digest parameters are those identified by
@@ -145,9 +141,8 @@ V.Dolmatov Expires May 30, 2010 [Page 2]
section 2.3.2.
To make this encoding from the wire format of a GOST public key
- with the parameters used in this document, prepend the last 64 octets
- of key data (in other words, substitute first two parameter octets)
- with the following 37-byte sequence:
+ with the parameters used in this document, prepend the 64 octets
+ of key data with the following 37-byte sequence:
0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
@@ -161,18 +156,19 @@ V.Dolmatov Expires May 30, 2010 [Page 2]
Private-key-format: v1.2
Algorithm: {TBA1} (GOST)
- GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
- 2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
+ GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
+ t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
+
-V.Dolmatov Expires May 30, 2010 [Page 3]
+V.Dolmatov Expires June 12, 2010 [Page 3]
The following DNSKEY RR stores a DNS zone key for example.net
example.net. 86400 IN DNSKEY 256 3 {TBA1} (
- AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
- tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
- yB7i836EfzmJo5LP
- ) ; key id = 15820
+ GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
+ 6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
+ 9Jrfial/yyc5Og==
+ ) ; key id = 10805
3. RRSIG Resource Records
@@ -214,12 +210,12 @@ V.Dolmatov Expires May 30, 2010 [Page 3]
assigned by IANA)
www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
- 20000101000000 15820 example.net.
- 2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl
- jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB
- rdp+C7wVoOHBqA== )
+ 20000101000000 10805 example.net.
+ k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
+ Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
+ HRFSm0XS5YST5g== )
-V.Dolmatov Expires May 30, 2010 [Page 4]
+V.Dolmatov Expires June 12, 2010 [Page 4]
Note: Several GOST signatures calculated for the same message text
differ because of using of a random element is used in signature
@@ -241,16 +237,16 @@ V.Dolmatov Expires May 30, 2010 [Page 4]
assigned by IANA)
example.net. 86400 DNSKEY 257 3 {TBA1} (
- AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
- RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
- 9tCz5oSsZl0cL0R2
- ) ; key id = 21649
-
+ 1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
+ EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
+ q/q4CwA4WR+ovg==
+ ) ; key id = 6204
+
The DS RR will be
- example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
- A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
- A44649C6 )
+ example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
+ 0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
+ 553BC61E )
5. Deployment Considerations
@@ -277,7 +273,7 @@ V.Dolmatov Expires May 30, 2010 [Page 4]
DNSKEY resource records created with the GOST algorithms as
defined in this document.
-V.Dolmatov Expires May 30, 2010 [Page 5]
+V.Dolmatov Expires June 12, 2010 [Page 5]
6.2. Support for NSEC3 Denial of Existence
@@ -333,7 +329,7 @@ V.Dolmatov Expires May 30, 2010 [Page 5]
contributors to these documents are gratefully acknowledged for
their hard work.
-V.Dolmatov Expires May 30, 2010 [Page 6]
+V.Dolmatov Expires June 12, 2010 [Page 6]
The following people provided additional feedback and text: Dmitry
Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen
@@ -389,7 +385,7 @@ V.Dolmatov Expires May 30, 2010 [Page 6]
Infrastructure Certificate and CRL Profile", RFC 4491,
May 2006.
-V.Dolmatov Expires May 30, 2010 [Page 7]
+V.Dolmatov Expires June 12, 2010 [Page 7]
10.2. Informative References
@@ -399,21 +395,21 @@ V.Dolmatov Expires May 30, 2010 [Page 7]
[DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
"GOST R 34.10-2001 digital signature algorithm"
- draft-dolmatov-cryptocom-gost34102001-06, 11.10.09
+ draft-dolmatov-cryptocom-gost34102001-07, 12.12.09
work in progress.
[DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
"GOST R 34.11-94 Hash function algorithm"
- draft-dolmatov-cryptocom-gost341194-04, 11.10.09
+ draft-dolmatov-cryptocom-gost341194-06, 12.12.09
work in progress.
[DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
"GOST 28147-89 encryption, decryption and MAC algorithms"
- draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
+ draft-dolmatov-cryptocom-gost2814789-06, 12.12.09
work in progress.
-V.Dolmatov Expires May 30, 2010 [Page 8]
+V.Dolmatov Expires June 12, 2010 [Page 8]
Authors' Addresses
@@ -440,7 +436,7 @@ Moscow, 117218, Russian Federation
EMail: igus@cryptocom.ru
-V.Dolmatov Expires May 30, 2010 [Page 9]
+V.Dolmatov Expires June 12, 2010 [Page 9]
diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
index ee35cb91af8e..b5877705eb98 100644
--- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt
+++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
@@ -6,13 +6,20 @@
INTERNET-DRAFT A. Gustafsson
Araneus Information Systems Oy
- September 23, 2009
+ February 24, 2010
Intended status: Draft Standard
Obsoletes: RFC3597
Handling of Unknown DNS Resource Record (RR) Types
- draft-ietf-dnsext-rfc3597-bis-00.txt
+ draft-ietf-dnsext-rfc3597-bis-02.txt
+
+Abstract
+
+ Extending the Domain Name System (DNS) with new Resource Record (RR)
+ types should not requires changes to name server software. This
+ document specifies how new RR types are transparently handled by DNS
+ software.
Status of this Memo
@@ -36,30 +43,27 @@ Status of this Memo
Copyright Notice
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- Extending the Domain Name System (DNS) with new Resource Record (RR)
- types should not requires changes to name server software. This
- document specifies how new RR types are transparently handled by DNS
- software.
-
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
-Expires March 2010 Standards Track [Page 1]
+Expires August 2010 Standards Track [Page 1]
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
1. Introduction
The DNS [RFC1034] is designed to be extensible to support new
@@ -78,10 +82,13 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
types by allowing them to be treated transparently by existing
implementations. Thanks to the widespread adoption of that
specification, much of the DNS is now capable of handling new record
- types without software changes.
+ types without software changes. Another development that has
+ simplified the introduction of new DNS RR types is the adoption of a
+ simpler IANA allocation procedure for RR types [RFC5395].
This document is a self-contained revised specification supplanting
- and obsoleting [RFC3597].
+ and obsoleting RFC 3597, with the aim of allowing the specification
+ to advance on the Standards Track.
2. Definitions
@@ -96,25 +103,24 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
Meta-TYPEs. Such an RR cannot be converted to a type-specific text
format, compressed, or otherwise handled in a type-specific way.
- In the case of a type whose RDATA format is class specific, an RR is
- considered to be of unknown type when the RDATA format for that
- combination of type and class is not known.
+ In the case of a type whose RDATA format is known to be class
+ specific, an RR is considered to be of unknown type when the RDATA
+ format for that combination of type and class is not known.
3. Transparency
- To enable new RR types to be deployed without server changes, name
- servers and resolvers MUST handle RRs of unknown type transparently.
- That is, they must treat the RDATA section of such RRs as
- unstructured binary data, storing and transmitting it without change
- [RFC1123].
-
-
-Expires March 2010 Standards Track [Page 2]
+Expires August 2010 Standards Track [Page 2]
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+
+ To enable new RR types to be deployed without server changes, name
+ servers and resolvers MUST handle RRs of unknown type transparently.
+ The RDATA section of RRs of unknown type must be treated as
+ unstructured binary data, and must be stored and transmitted without
+ change ([RFC1123], section 6.1.3.5).
To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known
@@ -142,7 +148,7 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
- NXT, NAPTR, and SRV to ensure interoperability with implementations
+ NXT, SRV, and NAPTR to ensure interoperability with implementations
predating [RFC3597].
Specifications for new RR types that contain domain names within
@@ -158,76 +164,39 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field,
- an unknown class is similarly represented as the word "CLASS"
- immediately followed by the decimal class number.
-
- This convention allows types and classes to be distinguished from
- each other and from TTL values, allowing the "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-Expires March 2010 Standards Track [Page 3]
+Expires August 2010 Standards Track [Page 3]
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+
+ an unknown class is similarly represented as the word "CLASS"
+ immediately followed by the decimal class number.
- [RFC1035] to both be unambiguously parsed.
+ This convention allows types and classes to be distinguished from
+ each other and from TTL values, allowing the "[<TTL>] [<class>]
+ <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
+ [RFC1035] section 5.1 to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a
- sequence of white space separated words as follows:
+ sequence of items separated by any combination of tabs and spaces, as
+ follows:
- The special token \# (a backslash immediately followed by a hash
- sign), which identifies the RDATA as having the generic encoding
- defined herein rather than a traditional type-specific encoding.
+ - The special token \# (a backslash immediately followed by a hash
+ sign), which identifies the RDATA as having the generic encoding
+ defined herein rather than a traditional type-specific encoding.
- An unsigned decimal integer specifying the RDATA length in octets.
+ - An unsigned decimal integer specifying the RDATA length in
+ octets.
- Zero or more words of hexadecimal data encoding the actual RDATA
- field, each containing an even number of hexadecimal digits.
+ - Zero or more items of hexadecimal data encoding the actual RDATA
+ field, each item containing an even number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2010 Standards Track [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
-
-
An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file
@@ -251,6 +220,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
a.example. CLASS32 TYPE731 \# 6 abcd (
ef 01 23 45 )
+
+
+
+Expires August 2010 Standards Track [Page 4]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+
+
b.example. HS TYPE62347 \# 0
e.example. IN A \# 4 C0000201
e.example. CLASS1 TYPE1 192.0.2.1
@@ -274,16 +251,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
records differing only in character case, and not expected to cause
any problems in practice.
-
-
-
-
-
-Expires March 2010 Standards Track [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
-
-
7. DNSSEC Considerations
The rules for the DNSSEC canonical form and ordering were updated to
@@ -309,6 +276,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
+
+
+
+Expires August 2010 Standards Track [Page 5]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+
+
11. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
@@ -332,14 +307,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996.
-
-
-
-Expires March 2010 Standards Track [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
-
-
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
@@ -362,23 +329,112 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
Phone: +358 40 547 2099
EMail: gson@araneus.fi
+Appendix A. Summary of Changes Since RFC3597
+
+ This section summarizes the major changes between RFC3597 and this
+
+
+
+Expires August 2010 Standards Track [Page 6]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+
+
+ document. In addition to the changes listed below, there has also
+ been a number of editorial changes, such as updates to the text in
+ the Abstract and Introduction to better reflect the current state of
+ implementation, updates to boilerplate text, and minor
+ clarifications.
+ The reference to the DNS IANA Considerations BCP (BCP42) has been
+ changed from RFC2929 to the current version, RFC5395.
+ Downward references have been eliminated; specifically, the document
+ no longer refers to RFC2163 or RFC2535.
+ IP addresses in examples have been changed to use the 192.0.2.0/24
+ range per RFC3330.
+ The document no longer specifies changes to the DNSSEC canonical form
+ and ordering, as those changes have now been incorporated into the
+ base DNSSEC specification.
+Appendix B. Detailed Change Log
+
+ [NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
+
+B.1. Changes between RFC3597 and -00
+
+ The reference to the DNS IANA Considerations BCP (BCP42) has been
+ changed from RFC2929 to the current version, RFC5395.
+
+ Downward references have been eliminated; specifically, the document
+ no longer refers to RFC2163 or RFC2535.
+
+ IP addresses in examples have been changed to use the 192.0.2.0/24
+ range per RFC3330.
+
+ The document no longer specifies changes to the DNSSEC canonical form
+ and ordering, as those changes have now been incorporated into the
+ base DNSSEC specification.
+
+ There has also been a number of editorial changes, such as updates to
+ the text in the Abstract and Introduction to better reflect the
+ current state of implementation.
+
+B.2. Changes between -00 and -01
+
+ Moved the Abstract to immediately following the document title.
+
+ Updated boilerplate to the current version.
+
+
+
+
+Expires August 2010 Standards Track [Page 7]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
+ In the Introduction, the text "Another development that has
+ simplified the introduction of new DNS RR types is the adoption of a
+ simpler IANA allocation procedure for RR types" and a reference to
+ [RFC5395] were added.
+ In the Introduction, the text "with the aim of allowing the
+ specification to advance on the Standards Track" was added to explain
+ the motivation for the draft.
+ In section 2, the text "is class specific" was replaced by "is known
+ to be class specific".
+ In section 3, the words "That is" were removed so as not to imply
+ that the transparent treatment of RRs of unknown type is only a
+ matter of how the RDATA field is handled. The remainder of the
+ sentence was rephrased.
+ In section 4, the entries for SRV and NAPTR in the list of RR types
+ to decompress were swapped to make the list consistently ordered by
+ ascending numerical RR type.
+ References to RFC 1035 and RFC 1123 now include the specific section
+ numbers being referenced.
+ A Change History was added as Appendix A.
+B.3. Changes between -01 and -02
+ In section 5, the term "white space" was replaced by "any combination
+ of tabs and spaces", and the term "word" was replaced by "item", for
+ consistency with RFC1035 terminology.
+ In section 5, hyphens were added to mark the beginning of each item
+ in the the list of items comprising the RDATA text representation.
+ The Change History was split into a Summary of Changes Since RFC3597
+ (Appendix A) intended to remain in the document when published as an
+ RFC, and a Detailed Change Log (Appendix B) to be deleted on
+ publication.
@@ -391,5 +447,5 @@ draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
-Expires March 2010 Standards Track [Page 7]
+Expires August 2010 Standards Track [Page 8]
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
new file mode 100644
index 000000000000..c06705b0a714
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
@@ -0,0 +1,504 @@
+
+
+
+Domain Name System Operations W. Wijngaards
+Internet-Draft O. Kolkman
+Intended status: Standards Track NLnet Labs
+Expires: August 26, 2010 February 22, 2010
+
+
+ DNSSEC Trust Anchor History Service
+ draft-ietf-dnsop-dnssec-trust-history-01
+
+Abstract
+
+ When DNS validators have trusted keys, but have been offline for a
+ longer period, key rollover will fail and they are stuck with stale
+ trust anchors. History service allows validators to query for older
+ DNSKEY RRsets and pick up the rollover trail where they left off.
+
+Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 26, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 1]
+
+Internet-Draft Trust History Service February 2010
+
+
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+1. Introduction
+
+ This memo defines a trust history service for DNS validators -- the
+ component in a resolver that performs DNSSEC [RFC4034] validation,
+ validator for short.
+
+ A validator that has been offline or missed an (emergency) rollover
+ can use this service to reconfigure themselves with the current
+ trust-anchor. Using a newly defined resource record (RR) that links
+ old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
+ RRsets and checks they form a chain to the latest key (see
+ Section 2). The lists of old DNSKEYS, linked with the TALINK RRs, do
+ not necessarily need to be published in the zone for which the DNSKEY
+ history is being maintained but can be published in any DNS domain.
+ We will call the entity that offers the trust history the History
+ Provider. The choice of the History Provider is made by the
+ maintainer of the validator, possibly based on a hint provided, using
+ the TALINK, by the zone owner.
+
+ The algorithm that the validator uses to construct a history and
+ reconfigure a new key is detailed in Section 3. The algorithms for
+ how providers of trust history can fetch the DNSKEY data as published
+ by the zone they track and publish that are explained in Section 4.
+
+2. The TALINK Resource Record
+
+ The DNS Resource Record type TALINK (decimal 58) ties the elements of
+ a linked list of DNSKEY RRs together.
+
+ The rdata consists of two domain names. The first name is the start,
+ or previous name, and the other name the end or next name in the
+ list. The empty label '.' is used at the endpoints of the list.
+
+ The presentation format is the two domain names. The wire encoding
+ is the two domain names, with no compression so the type can be
+ treated according to [RFC3597]. The list is a double linked list,
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 2]
+
+Internet-Draft Trust History Service February 2010
+
+
+ because this empowers low memory hosts to perform consistency checks.
+
+3. Trust History Lookup
+
+ This is the algorithm that a validator uses to detect and resolve the
+ situation in which a trust-anchor is out of sync with the DNSKEYs
+ published by a zone owner. The algorithm uses the TALINK RR type
+ which is used to link various old DNSKEYs as published by the History
+ Provider, to arrive from the outdated configured Trust Anchor to one
+ that matches the current DNSKEY. The TALINK RR type is defined in
+ Section 2.
+
+ When the algorithm below results in failure the trust history cannot
+ be build and a new trust anchor will need to be re-configured using
+ another mechanism.
+
+ Step 1: The validator performs a DNSKEY lookup to the target zone,
+ which looks like any other initial DNSKEY lookup that the
+ validator needs to match a trust anchor to the currently used
+ DNSKEY RR set. If the keyset verifies with the trust anchor
+ currently held, the trust-anchor is not out of sync. Otherwise,
+ store the DNSKEY RR set as result. The algorithm will
+ successfully build a linked list to this DNSKEY RR, or delete the
+ trust point, or fail.
+
+ All nameservers (the ones authoritative for the zone or the
+ upstream resolver caches when the validator is not full resolver)
+ SHOULD be checked to make sure the DNSKEY RR sets are the same.
+ The results can differ if a key-rollover is in progress and not
+ all nameservers are in sync yet. This case can be detected by
+ checking that the older keyset signs the newer and take the newer
+ as result keyset. The keysets are distinguished by the average
+ over the middle of the inception and expiration dates of the
+ signatures that are validated by the keyset itself. Otherwise,
+ the history lookup fails. If the check fails then the
+ inconsistency may be the result of spoofing, or compromise of
+ (DNS) infrastructure elements.
+
+ Step 2: Fetch the trust history list end points. Perform a query of
+ QTYPE TALINK and QNAME the domain name that is configured to be
+ the History Provider for the particular domain you are trying to
+ update the trust-anchor for.
+
+ Step 3: Go backwards through the trust history list as provided by
+ the TALINK linked list. Verify that the keyset validly signs the
+ next keyset. This is [RFC4034] validation, but the RRSIG
+ expiration date is ignored. [Editor note: Are we shure that there
+ are no server implementations that will not serve expired RRSIG,
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 3]
+
+Internet-Draft Trust History Service February 2010
+
+
+ are such 'smart' servers allowed by the specs? In other words do
+ we need clarification in the DNSSEC-updates document?] Replace
+ the owner domain name with the target zone name for verification.
+ One of the keys that signs the next keyset MUST have the SEP bit
+ set. The middle of inception and expiration date from the valid
+ signature MUST be older than that of the signature that validates
+ the next keys in the list. Query type TALINK to get previous and
+ next locations.
+
+ If all SEP keys have the REVOKE flag set at this step, and the
+ keyset is signed by all SEP keys, then continue but store that the
+ end result is that the trust point is deleted, see Section 5
+ [RFC5011].
+
+ If all SEP keys are of an unknown algorithm at this step, continue
+ and at the next step, when you verify if the keyset signs validly:
+ if false, continue with result a failure, if true, continue with
+ the end result that the trust point is deleted. Thus, the keysets
+ with unknown algorithms are stepped over with an end result of
+ failure because the validator cannot determine if unknown
+ algorithm signatures are valid, until the oldest keyset with
+ unknown algorithms is signed by a known algorithm and the result
+ is set to deletion and step 3 continues to a known key.
+
+ Step 4: When the trust anchor currently held by the validator
+ verifies the keyset, the algorithm is done. The validator SHOULD
+ store the result on stable storage. Use the new trust anchor for
+ validation (if using [RFC5011], put it in state VALID).
+
+4. Trust History Tracker
+
+ External trackers can poll the target zone DNSKEY RRset regularly.
+ Ignore date changes in the RRSIG. Ignore changes to keys with no SEP
+ flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the
+ owner name to a new name at the history location. Publish the new
+ RRset and TALINK records to make it the last element in the list.
+ Update the TALINK that advertises the first and last name.
+
+ Integrated into the rollover, the keys are stored in the history and
+ the TALINK is updated when a new key is used in the rollover process.
+ This gives the TALINK and new historical key time to propagate.
+
+ The signer can support trust history. Trust history key sets need
+ only contain SEP keys. To use older signers, move historical RRSIGs
+ to another file. Sign the zone, including the TALINK and DNSKEY
+ records. Append the historical RRSIGs to the result. Signing the
+ zone like this obviates the need for changes to signer and server
+ software.
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 4]
+
+Internet-Draft Trust History Service February 2010
+
+
+5. Example
+
+ In this example example.com is the History Provider for example.net.
+ The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
+ and paste of the data from example.net.
+
+ $ORIGIN example.com.
+ example.com. TALINK h0.example.com. h2.example.com.
+
+ h0 TALINK . h1.example.com.
+ h0 DNSKEY ...
+ h0 RRSIG ...
+
+ h1 TALINK h0.example.com. h2.example.com.
+ h1 DNSKEY ...
+ h1 RRSIG ...
+
+ h2 TALINK h1.example.com. .
+ h2 DNSKEY ...
+ h2 RRSIG ...
+
+ The example.net zone can advertise the example.com History Provider
+ by providing the TALINK shown here at example.com at the apex of the
+ example.net zone. The TALINK at example.com is then not needed.
+
+6. Deployment
+
+ The trust history is advertised with TALINK RRs at the zone apex.
+ These represent alternative history sources, that can be searched in
+ turn. The TALINK at the zone apex contains the first and last name
+ of the list of historical keys.
+
+ The historical list of keys grows perpetually. Since most validators
+ have recent keys, their processing time remains similar as the list
+ grows. If validators no longer have trust in the keys then they need
+ no longer be published. The oldest key entries can be omitted from
+ the list to shorten it.
+
+ The validator decides how long it trusts a key. A recommendation
+ from the zone owner can be configured for keys of that zone, or
+ recommendations per algorithm and key size can be used (e.g. see
+ [NIST800-57]). If a key is older than that, trust history lookup
+ fails with it and the trust point can be considered deleted. This
+ assumes the validator has decided on a security policy and also can
+ take actions when the update of the trust anchor fails. Without such
+ policy, or if the alternative is no DNSSEC, the approach below can be
+ used.
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 5]
+
+Internet-Draft Trust History Service February 2010
+
+
+ In general, the decision can be that any key - no matter how old or
+ how small - is better than no security. The validator then never
+ considers a key too old, and the lookup algorithm becomes an
+ unsecured update mechanism at the time where the key can be trivially
+ broken. The history provider SHOULD provide these broken keys to
+ facilitate clients performing the unsecured update. If a key can not
+ be trivially broken then it provides a non-trivial amount of security
+ that the history lookup algorithm uses to get the current keys.
+ Conceivably after the update the result is stored on stable storage
+ and the client is thereafter safe - it performs a leap of faith. The
+ validator operator can opt for this set up after considering the
+ trade-off between loss of DNSSEC, loss of connectivity, and the
+ argument that perceived security is worse than no security.
+
+ The history lookup can be used on its own. Then, the trust history
+ is used whenever the key rolls over and no polling is performed.
+ This has associated risks, in that the immediate rollover without
+ timeout that it provides could be abused, and certainly when taken
+ together with leap-of-faith such systems SHOULD inform their user
+ that the key has changed and urge them to do immediate checks.
+ Initially we put a hold down timer on such rollovers to mitigate the
+ abuse risks but these make following normal rollovers impossible.
+
+ If a validator is also using [RFC5011] for the target zone, then the
+ trust history algorithm SHOULD only be invoked if the [RFC5011]
+ algorithm failed due to the inability to perform probes. This is the
+ case when the last [RFC5011] successful probe was more than 30 days
+ ago. If a new key has been announced, invoke the history if no 2
+ probes succeeded during the add hold-down time and there was no
+ successful probe after the add hold-down time passed. Therefore the
+ time of the last successful probe MUST be stored on stable storage.
+
+ For testing the potentially very infrequently used lookup, the
+ following SHOULD be implemented. For the test the lookup is
+ triggered manually by allowing the system to be given a particular
+ keyset with a last successful lookup date in the past and a test
+ History Provider. The test History Provider provides access to a
+ generated back-dated test history.
+
+7. Security Considerations
+
+ The History Provider only provides copies of old data. If that
+ historic data is altered or withheld the lookup algorithm fails
+ because of validation errors in Step 3 of the algorithm. If the
+ History provider or a Man in the Middle Adversary (MIMA) has access
+ to the original private keys (through theft, cryptanalisis, or
+ otherwise), history can be altered without failure of the algorithm.
+ Below we only consider MIMAs and assume the History Provider is a
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 6]
+
+Internet-Draft Trust History Service February 2010
+
+
+ trusted party.
+
+ Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
+ TALINK and DNSKEY data, can present some alternate history. However
+ the DNSKEY RR set trusted that the history should arrive at is
+ already fixed by step 1. If an attempt is made to subvert the
+ algorithm at step 2 or 3, then the result keyset can not be replaced
+ by another keyset unnoticed.
+
+ To change the keyset trusted as the outcome, the step 1 data has to
+ be spoofed and the key held by the validator (or a newer historic
+ key) has to be compromised. Unless such spoof is targeted to a
+ specific victim, a spoof of the step 1 result has a high visibility.
+ Since most of the validators that receive the spoof have an up-to-
+ date trust anchor most validators that would receive this spoof
+ return validation failure for data from the zone that contains the
+ DNSKEYs. An adversary will therefore have to target the attack to
+ validators that are in the process of an update. Since validators do
+ not announce that they use trust history lookup until step 2
+ adversaries will not be able to select the validators.
+
+ A spoof of data in steps 2 and 3, together with a compromised (old)
+ key, can result in a downgrade. At steps 2 and 3 a faked trust point
+ deletion or algorithm rollover can be inserted in a fake history.
+ This avoids the high visibility of spoofing the current key (see
+ previous paragraph) and downgrades to insecure.
+
+ Finally there is the case that one of the keys published by the
+ History Providers has been compromised. Since someone spoofing at
+ step 1 of the lookup algorithm and presenting some fake history to a
+ compromised key, of course does not include key revocations and does
+ extend the history to contain the compromised key, it therefore is
+ not really useful for a History Provider to remove the key from the
+ published history. That only makes lookups fail for those validators
+ who are not under attack. Useful action could be to update
+ validators using some other means.
+
+ Rollover with [RFC5011] revokes keys after use. If a History
+ Provider is used, then such revoked keys SHOULD be used to perform
+ history tracking and history lookup. The old keys that the validator
+ starts with and final current keys MUST NOT be trusted if they are
+ revoked.
+
+ Depending on choices by the validator operator, it may accept a leap-
+ of-faith, and possibly allow non-hold-down rollovers. Although this
+ allows very fast emergency rollover if all clients are known to do
+ trust-history lookups without the RFC5011-algorithm, it also allows
+ an attacker with the private key to attempt to take over a zone
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 7]
+
+Internet-Draft Trust History Service February 2010
+
+
+ quickly and get validators to roll to a trust anchor of the
+ attacker's choosing.
+
+ The SEP bit is checked to make sure that control over the KSK is
+ necessary to change the keyset for the target zone.
+
+ The algorithm can be used to get the inception and expiration times
+ of signatures on the current keyset, a clock. A MIMA can attempt to
+ shorten history and put back that clock, but the algorithm attempts
+ to make this difficult to target and highly visible to others.
+
+ If the clock of the validator can be influenced, then setting it
+ forward is unlikely to give advantage, but setting it backward
+ enables a replay attack of old DNSSEC data and signatures. This
+ vulnerability exists also in plain DNSSEC.
+
+8. IANA Considerations
+
+ Resource record type TALINK has been defined using RFC5395 expert
+ review, it has RR type number 58 (decimal).
+
+9. Acknowledgments
+
+ Thanks to the people who provided review and suggestions, Joe Abley,
+ George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
+ Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
+ Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
+ Matthijs Mekking.
+
+10. References
+
+10.1. Informative References
+
+ [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M.
+ Smid, "Recommendations for Key Management", NIST
+ SP 800-57, March 2007.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security
+ (DNSSEC) Trust Anchors", RFC 5011, September 2007.
+
+10.2. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+ Record (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 8]
+
+Internet-Draft Trust History Service February 2010
+
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security
+ Extensions", RFC 4034, March 2005.
+
+Authors' Addresses
+
+ Wouter Wijngaards
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XG
+ The Netherlands
+
+ EMail: wouter@nlnetlabs.nl
+
+
+ Olaf Kolkman
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XG
+ The Netherlands
+
+ EMail: olaf@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 9]
+
diff --git a/doc/draft/draft-kerr-ixfr-only-01.txt b/doc/draft/draft-kerr-ixfr-only-01.txt
new file mode 100644
index 000000000000..837b255f1f76
--- /dev/null
+++ b/doc/draft/draft-kerr-ixfr-only-01.txt
@@ -0,0 +1,336 @@
+
+
+
+DNSext Working Group O. Sury
+Internet-Draft CZ.NIC
+Updates: 1995 (if approved) S. Kerr, Ed.
+Intended status: Standards Track ISC
+Expires: August 30, 2010 February 26, 2010
+
+
+ IXFR-ONLY to Prevent IXFR Fallback to AXFR
+ draft-kerr-ixfr-only-01
+
+Abstract
+
+ This documents proposes a new QTYPE (Query pseudo RRtype) for the
+ Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995)
+ that allows an authoritative server to incrementally update zone
+ content from another (primary) server without falling back from IXFR
+ to AXFR. This way, alternate peers can be contacted more quickly and
+ convergence of zone content may be achieved much faster in important,
+ resilient operational scenarios.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 30, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 1]
+
+Internet-Draft IXFR-ONLY February 2010
+
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
+ 2. IXFR Server Side . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. IXFR Client Side . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Applicability of IXFR-ONLY . . . . . . . . . . . . . . . . . . 5
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 2]
+
+Internet-Draft IXFR-ONLY February 2010
+
+
+1. Introduction
+
+ For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
+ Transfer (IXFR), which allows only to transfer the changed portion(s)
+ of a zone.
+
+ In the document, an IXFR client and an IXFR server is defined as in
+ RFC 1995 [RFC1995], a secondary name server which requests IXFR is
+ called an IXFR client and a primary or secondary name server which
+ responds to the request is called an IXFR server.
+
+ IXFR is an efficient way to transfer changes in zones from IXFR
+ servers to IXFR clients. However, when an IXFR client has multiple
+ IXFR servers for a single zone, it is possible that not all IXFR
+ servers have the zone with same serial number for that zone. In this
+ case, if an IXFR client attempts an IXFR from an IXFR server which
+ does not have zone with the serial number used by the IXFR client,
+ the IXFR server will fall back to a full zone transfer (AXFR) when it
+ has a version of the zone with serial number greater than the serial
+ requested by the IXFR client.
+
+ For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
+ a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
+ same zone. An IXFR client that has the zone with serial number 2
+ which sends an IXFR request to IXFR server NS2 will get a full zone
+ transfer (AXFR) of the zone at serial number 3. This is because NS2
+ does not know the zone with serial number 2, and therefore does not
+ know what the differences are between zone with serial number 2 and
+ 3.
+
+ If the IXFR client in this example had known to send the query to
+ IXFR server NS1, then it could have gotten an incremental transfer
+ (IXFR). But IXFR clients can only know what the latest version of
+ the zone is at a IXFR server (this information is available via an
+ SOA query).
+
+ The IXFR-ONLY query type provides a way for the IXFR client to ask
+ each IXFR server to return an error instead of sending the current
+ version of the zone via full zone transfer (AXFR). By using this, a
+ IXFR client can check each IXFR server until it finds one able to
+ provide IXFR.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 3]
+
+Internet-Draft IXFR-ONLY February 2010
+
+
+2. IXFR Server Side
+
+ A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
+ as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
+ for the serial number requested.
+
+ If the IXFR server is is not able to reply with an IXFR it MUST NOT
+ reply with an AXFR unless AXFR result is smaller than IXFR result.
+ Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
+
+ If the IXFR result is larger than an AXFR, then an IXFR server MAY
+ reply with an AXFR result instead. This is an optimization, and IXFR
+ servers MAY only reply with AXFR if they are certain that the reply
+ using AXFR is smaller than an equivalent IXFR reply.
+
+
+3. IXFR Client Side
+
+ An IXFR client who wishes to use IXFR-ONLY will send a message to one
+ of the IXFR servers. The format is exactly the same as for IXFR,
+ except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
+ code.
+
+ If the IXFR server replies with IXFR, then the IXFR client is done.
+
+ If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
+ client proceeds on to a different IXFR server. In this case the IXFR
+ server implements IXFR-ONLY, but does not have information about zone
+ with the serial number requested.
+
+ If the IXFR server replies with any RCODE other than CannotIXFR or
+ NoError, then the IXFR client proceeds on to a different IXFR server.
+ In this case the IXFR server does not implement IXFR-ONLY.
+
+ If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
+ them reply with an incremental transfer (IXFR), then it should
+ attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
+ IXFR servers which replied with an RCODE other than CannotIXFR or
+ NoError.
+
+ The method described above allows IXFR clients to operate normally in
+ situatians where some of the IXFR servers do support IXFR-ONLY, and
+ some who do not. IXFR clients MAY remember which IXFR servers
+ support IXFR-ONLY and query those IXFR servers first. However since
+ IXFR servers may change software or even run a mix of software, IXFR
+ clients MUST attempt to query each IXFR server periodically when they
+ attempt to get new versions of a zone.
+
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 4]
+
+Internet-Draft IXFR-ONLY February 2010
+
+
+ Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+ given IXFR server, if this is known in advance. These IXFR servers
+ are treated as if they replied with an RCODE other than CannotIXFR or
+ NoError, although no query with IXFR-ONLY is actually sent.
+
+
+4. Applicability of IXFR-ONLY
+
+ Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
+ completely.
+
+ Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+ specific zone. This may be useful for small zones, where fallback to
+ AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
+
+ Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
+ servers, by shifting load to ones that support IXFR-ONLY. If this a
+ problem, then administrators can disable IXFR-ONLY in implementations
+ that allow it.
+
+ If a IXFR client has a single IXFR server for a zone, it SHOULD use
+ IXFR rather than IXFR-ONLY.
+
+
+5. IANA Considerations
+
+ IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
+ transfer only". IANA allocates the CannotIXFR RCODE, which means
+ "Server cannot provide IXFR for zone".
+
+
+6. Security Considerations
+
+ IXFR-ONLY may be used by someone to get information about the state
+ of IXFR servers by providing a quick and efficient way to check which
+ versions of a zone each IXFR server supports. Zones should be
+ secured via TSIG [RFC2845] to prevent unauthorized information
+ exposure. However, even administrators of IXFR servers may not want
+ this information given to IXFR clients, in which case they will need
+ to disable IXFR-ONLY.
+
+
+7. Normative References
+
+ [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 5]
+
+Internet-Draft IXFR-ONLY February 2010
+
+
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+
+Authors' Addresses
+
+ Ondrej Sury
+ CZ.NIC
+ Americka 23
+ 120 00 Praha 2
+ CZ
+
+ Phone: +420 222 745 110
+ Email: ondrej.sury@nic.cz
+
+
+ Shane Kerr (editor)
+ ISC
+ Bennebrokestraat 17-I
+ 1015 PE Amsterdam
+ NL
+
+ Phone: +31 64 6336297
+ Email: shane@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr Expires August 30, 2010 [Page 6]
+
diff --git a/lib/dns/include/dns/rdataset.h b/lib/dns/include/dns/rdataset.h
index 2749f8a80eb9..4d3578cc496a 100644
--- a/lib/dns/include/dns/rdataset.h
+++ b/lib/dns/include/dns/rdataset.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 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: rdataset.h,v 1.51.18.9 2009/01/19 23:46:16 tbox Exp $ */
+/* $Id: rdataset.h,v 1.51.18.11 2010/02/26 23:46:37 tbox Exp $ */
#ifndef DNS_RDATASET_H
#define DNS_RDATASET_H 1
@@ -104,6 +104,9 @@ typedef struct dns_rdatasetmethods {
dns_rdataset_t *rdataset,
dns_rdatasetadditional_t type,
dns_rdatatype_t qtype);
+ void (*settrust)(dns_rdataset_t *rdataset,
+ dns_trust_t trust);
+ void (*expire)(dns_rdataset_t *rdataset);
} dns_rdatasetmethods_t;
#define DNS_RDATASET_MAGIC ISC_MAGIC('D','N','S','R')
@@ -592,6 +595,19 @@ dns_rdataset_putadditional(dns_acache_t *acache,
* information for 'rdataset.'
*/
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+/*%<
+ * Set the trust of the 'rdataset' to trust in any in the backing database.
+ * The local trust level of 'rdataset' is also set.
+ */
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset);
+/*%<
+ * Mark the rdataset to be expired in the backing database.
+ */
+
ISC_LANG_ENDDECLS
#endif /* DNS_RDATASET_H */
diff --git a/lib/dns/include/dns/resolver.h b/lib/dns/include/dns/resolver.h
index 3fce33665c48..5ea1d6990e3e 100644
--- a/lib/dns/include/dns/resolver.h
+++ b/lib/dns/include/dns/resolver.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 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: resolver.h,v 1.40.18.13 2009/09/24 23:46:07 tbox Exp $ */
+/* $Id: resolver.h,v 1.40.18.15 2010/02/26 23:46:37 tbox Exp $ */
#ifndef DNS_RESOLVER_H
#define DNS_RESOLVER_H 1
@@ -491,6 +491,48 @@ dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
void
dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+ dns_rdatatype_t type, isc_time_t *expire);
+/*%<
+ * Add a entry to the bad cache for <name,type> that will expire at 'expire'.
+ *
+ * Requires:
+ * \li resolver to be valid.
+ * \li name to be valid.
+ */
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+ dns_rdatatype_t type, isc_time_t *now);
+/*%<
+ * Check to see if there is a unexpired entry in the bad cache for
+ * <name,type>.
+ *
+ * Requires:
+ * \li resolver to be valid.
+ * \li name to be valid.
+ */
+
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name);
+/*%<
+ * Flush the bad cache of all entries at 'name' if 'name' is non NULL.
+ * Flush the entire bad cache if 'name' is NULL.
+ *
+ * Requires:
+ * \li resolver to be valid.
+ */
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp);
+/*%
+ * Print out the contents of the bad cache to 'fp'.
+ *
+ * Requires:
+ * \li resolver to be valid.
+ */
+
ISC_LANG_ENDDECLS
#endif /* DNS_RESOLVER_H */
diff --git a/lib/dns/include/dns/result.h b/lib/dns/include/dns/result.h
index db5481b34c36..a43207e50876 100644
--- a/lib/dns/include/dns/result.h
+++ b/lib/dns/include/dns/result.h
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1998-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: result.h,v 1.104.10.6 2005/06/17 02:04:32 marka Exp $ */
+/* $Id: result.h,v 1.104.10.8 2010/02/26 23:46:37 tbox Exp $ */
#ifndef DNS_RESULT_H
#define DNS_RESULT_H 1
@@ -147,8 +147,11 @@
#define DNS_R_COVERINGNSEC (ISC_RESULTCLASS_DNS + 101)
#define DNS_R_MXISADDRESS (ISC_RESULTCLASS_DNS + 102)
#define DNS_R_DUPLICATE (ISC_RESULTCLASS_DNS + 103)
+#define DNS_R_INVALIDNSEC3 (ISC_RESULTCLASS_DNS + 104)
+#define DNS_R_NOTMASTER (ISC_RESULTCLASS_DNS + 105)
+#define DNS_R_BROKENCHAIN (ISC_RESULTCLASS_DNS + 106)
-#define DNS_R_NRESULTS 104 /*%< Number of results */
+#define DNS_R_NRESULTS 107 /*%< Number of results */
/*
* DNS wire format rcodes.
diff --git a/lib/dns/include/dns/validator.h b/lib/dns/include/dns/validator.h
index 9708cc4ce7eb..befee5d66a40 100644
--- a/lib/dns/include/dns/validator.h
+++ b/lib/dns/include/dns/validator.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) 2000-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: validator.h,v 1.27.18.13 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: validator.h,v 1.27.18.15 2010/02/26 23:46:37 tbox Exp $ */
#ifndef DNS_VALIDATOR_H
#define DNS_VALIDATOR_H 1
@@ -151,6 +151,8 @@ struct dns_validator {
isc_boolean_t mustbesecure;
unsigned int dlvlabels;
unsigned int depth;
+ unsigned int authcount;
+ unsigned int authfail;
};
/*%
diff --git a/lib/dns/ncache.c b/lib/dns/ncache.c
index 1fdc5c80e2d0..89106dad7c06 100644
--- a/lib/dns/ncache.c
+++ b/lib/dns/ncache.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: ncache.c,v 1.36.18.3 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: ncache.c,v 1.36.18.5 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -478,6 +478,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
NULL,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index bd168080e76d..fb561db3cf9d 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: rbtdb.c,v 1.196.18.59 2009/11/26 23:46:11 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.61 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -414,6 +414,8 @@ static isc_result_t rdataset_putadditional(dns_acache_t *acache,
dns_rdataset_t *rdataset,
dns_rdatasetadditional_t type,
dns_rdatatype_t qtype);
+static void rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+static void rdataset_expire(dns_rdataset_t *rdataset);
static dns_rdatasetmethods_t rdataset_methods = {
rdataset_disassociate,
@@ -426,7 +428,9 @@ static dns_rdatasetmethods_t rdataset_methods = {
rdataset_getnoqname,
rdataset_getadditional,
rdataset_setadditional,
- rdataset_putadditional
+ rdataset_putadditional,
+ rdataset_settrust,
+ rdataset_expire
};
static void rdatasetiter_destroy(dns_rdatasetiter_t **iteratorp);
@@ -5823,6 +5827,36 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
return (ISC_R_SUCCESS);
}
+static void
+rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+ dns_rbtdb_t *rbtdb = rdataset->private1;
+ dns_rbtnode_t *rbtnode = rdataset->private2;
+ rdatasetheader_t *header = rdataset->private3;
+
+ header--;
+ NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+ isc_rwlocktype_write);
+ header->trust = rdataset->trust = trust;
+ NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+ isc_rwlocktype_write);
+}
+
+static void
+rdataset_expire(dns_rdataset_t *rdataset) {
+ dns_rbtdb_t *rbtdb = rdataset->private1;
+ dns_rbtnode_t *rbtnode = rdataset->private2;
+ rdatasetheader_t *header = rdataset->private3;
+
+ header--;
+ NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+ isc_rwlocktype_write);
+ header->ttl = 0;
+ header->attributes |= RDATASET_ATTR_STALE;
+ rbtnode->dirty = 1;
+ NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+ isc_rwlocktype_write);
+}
+
/*
* Rdataset Iterator Methods
*/
diff --git a/lib/dns/rdatalist.c b/lib/dns/rdatalist.c
index 7229fa3e4511..b2c08123e31e 100644
--- a/lib/dns/rdatalist.c
+++ b/lib/dns/rdatalist.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1999-2001, 2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: rdatalist.c,v 1.28.18.3 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rdatalist.c,v 1.28.18.5 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -43,6 +43,8 @@ static dns_rdatasetmethods_t methods = {
isc__rdatalist_getnoqname,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
diff --git a/lib/dns/rdataset.c b/lib/dns/rdataset.c
index f3c062da2f5c..56a386a9b51e 100644
--- a/lib/dns/rdataset.c
+++ b/lib/dns/rdataset.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2006, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 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: rdataset.c,v 1.72.18.7 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataset.c,v 1.72.18.9 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -179,6 +179,8 @@ static dns_rdatasetmethods_t question_methods = {
NULL,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
@@ -707,3 +709,22 @@ dns_rdataset_putadditional(dns_acache_t *acache,
return (ISC_R_FAILURE);
}
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+ REQUIRE(DNS_RDATASET_VALID(rdataset));
+ REQUIRE(rdataset->methods != NULL);
+
+ if (rdataset->methods->settrust != NULL)
+ (rdataset->methods->settrust)(rdataset, trust);
+ else
+ rdataset->trust = trust;
+}
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset) {
+ REQUIRE(DNS_RDATASET_VALID(rdataset));
+ REQUIRE(rdataset->methods != NULL);
+
+ if (rdataset->methods->expire != NULL)
+ (rdataset->methods->expire)(rdataset);
+}
diff --git a/lib/dns/rdataslab.c b/lib/dns/rdataslab.c
index 4255b1d0002c..fb5a4b786d2e 100644
--- a/lib/dns/rdataslab.c
+++ b/lib/dns/rdataslab.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-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: rdataslab.c,v 1.35.18.10 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataslab.c,v 1.35.18.12 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -405,6 +405,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
NULL,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index 7b41e72da729..95c7bd4a4f84 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: resolver.c,v 1.284.18.99 2010/01/07 23:46:07 tbox Exp $ */
+/* $Id: resolver.c,v 1.284.18.101 2010/02/26 23:46:36 tbox Exp $ */
/*! \file */
@@ -318,6 +318,18 @@ typedef struct alternate {
ISC_LINK(struct alternate) link;
} alternate_t;
+typedef struct dns_badcache dns_badcache_t;
+struct dns_badcache {
+ dns_badcache_t * next;
+ dns_rdatatype_t type;
+ isc_time_t expire;
+ unsigned int hashval;
+ dns_name_t name;
+};
+#define DNS_BADCACHE_SIZE 1021
+#define DNS_BADCACHE_TTL(fctx) \
+ (((fctx)->res->lame_ttl > 30 ) ? (fctx)->res->lame_ttl : 30)
+
struct dns_resolver {
/* Unlocked. */
unsigned int magic;
@@ -361,6 +373,13 @@ struct dns_resolver {
unsigned int activebuckets;
isc_boolean_t priming;
unsigned int spillat; /* clients-per-query */
+
+ /* Bad cache. */
+ dns_badcache_t ** badcache;
+ unsigned int badcount;
+ unsigned int badhash;
+ unsigned int badsweep;
+
/* Locked by primelock. */
dns_fetch_t * primefetch;
/* Locked by nlock. */
@@ -390,7 +409,7 @@ static void empty_bucket(dns_resolver_t *res);
static isc_result_t resquery_send(resquery_t *query);
static void resquery_response(isc_task_t *task, isc_event_t *event);
static void resquery_connected(isc_task_t *task, isc_event_t *event);
-static void fctx_try(fetchctx_t *fctx);
+static void fctx_try(fetchctx_t *fctx, isc_boolean_t badcache);
static isc_boolean_t fctx_destroy(fetchctx_t *fctx);
static isc_result_t ncache_adderesult(dns_message_t *message,
dns_db_t *cache, dns_dbnode_t *node,
@@ -1088,7 +1107,7 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
if (result != ISC_R_SUCCESS)
fctx_done(fctx, result, __LINE__);
else
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
}
}
@@ -1946,7 +1965,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
if (result != ISC_R_SUCCESS)
fctx_done(fctx, result, __LINE__);
else
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
}
}
@@ -2008,7 +2027,7 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
dns_adb_destroyfind(&find);
if (want_try)
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
else if (want_done)
fctx_done(fctx, ISC_R_FAILURE, __LINE__);
else if (bucket_empty)
@@ -2371,7 +2390,7 @@ isstrictsubdomain(dns_name_t *name1, dns_name_t *name2) {
}
static isc_result_t
-fctx_getaddresses(fetchctx_t *fctx) {
+fctx_getaddresses(fetchctx_t *fctx, isc_boolean_t badcache) {
dns_rdata_t rdata = DNS_RDATA_INIT;
isc_result_t result;
dns_resolver_t *res;
@@ -2590,12 +2609,24 @@ fctx_getaddresses(fetchctx_t *fctx) {
*/
result = DNS_R_WAIT;
} else {
+ isc_time_t expire;
+ isc_interval_t i;
/*
* We've lost completely. We don't know any
* addresses, and the ADB has told us it can't get
* them.
*/
FCTXTRACE("no addresses");
+ isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+ result = isc_time_nowplusinterval(&expire, &i);
+ if (badcache &&
+ (fctx->type == dns_rdatatype_dnskey ||
+ fctx->type == dns_rdatatype_dlv ||
+ fctx->type == dns_rdatatype_ds) &&
+ result == ISC_R_SUCCESS)
+ dns_resolver_addbadcache(fctx->res,
+ &fctx->name,
+ fctx->type, &expire);
result = ISC_R_FAILURE;
}
} else {
@@ -2817,7 +2848,7 @@ fctx_nextaddress(fetchctx_t *fctx) {
}
static void
-fctx_try(fetchctx_t *fctx) {
+fctx_try(fetchctx_t *fctx, isc_boolean_t badcache) {
isc_result_t result;
dns_adbaddrinfo_t *addrinfo;
@@ -2835,7 +2866,7 @@ fctx_try(fetchctx_t *fctx) {
fctx_cleanupaltfinds(fctx);
fctx_cleanupforwaddrs(fctx);
fctx_cleanupaltaddrs(fctx);
- result = fctx_getaddresses(fctx);
+ result = fctx_getaddresses(fctx, badcache);
if (result == DNS_R_WAIT) {
/*
* Sleep waiting for addresses.
@@ -2995,7 +3026,7 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
/*
* Keep trying.
*/
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
}
isc_event_free(&event);
@@ -3165,7 +3196,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
if (result != ISC_R_SUCCESS)
fctx_done(fctx, result, __LINE__);
else
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
} else if (bucket_empty)
empty_bucket(res);
}
@@ -3740,6 +3771,8 @@ validated(isc_task_t *task, isc_event_t *event) {
LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
+ isc_stdtime_get(&now);
+
/*
* If chaining, we need to make sure that the right result code is
* returned, and that the rdatasets are bound.
@@ -3785,36 +3818,80 @@ validated(isc_task_t *task, isc_event_t *event) {
FCTXTRACE("validation failed");
fctx->valfail++;
fctx->vresult = vevent->result;
- result = ISC_R_NOTFOUND;
- if (vevent->rdataset != NULL)
- result = dns_db_findnode(fctx->cache, vevent->name,
- ISC_TRUE, &node);
- if (result == ISC_R_SUCCESS)
- (void)dns_db_deleterdataset(fctx->cache, node, NULL,
- vevent->type, 0);
- if (result == ISC_R_SUCCESS && vevent->sigrdataset != NULL)
- (void)dns_db_deleterdataset(fctx->cache, node, NULL,
- dns_rdatatype_rrsig,
- vevent->type);
- if (result == ISC_R_SUCCESS)
- dns_db_detachnode(fctx->cache, &node);
- result = vevent->result;
+ if (fctx->vresult != DNS_R_BROKENCHAIN) {
+ result = ISC_R_NOTFOUND;
+ if (vevent->rdataset != NULL)
+ result = dns_db_findnode(fctx->cache,
+ vevent->name,
+ ISC_TRUE, &node);
+ if (result == ISC_R_SUCCESS)
+ (void)dns_db_deleterdataset(fctx->cache, node,
+ NULL,
+ vevent->type, 0);
+ if (result == ISC_R_SUCCESS &&
+ vevent->sigrdataset != NULL)
+ (void)dns_db_deleterdataset(fctx->cache, node,
+ NULL,
+ dns_rdatatype_rrsig,
+ vevent->type);
+ if (result == ISC_R_SUCCESS)
+ dns_db_detachnode(fctx->cache, &node);
+ }
+ if (fctx->vresult == DNS_R_BROKENCHAIN && !negative) {
+ /*
+ * Cache the data as pending for later validation.
+ */
+ result = ISC_R_NOTFOUND;
+ if (vevent->rdataset != NULL)
+ result = dns_db_findnode(fctx->cache,
+ vevent->name,
+ ISC_TRUE, &node);
+ if (result == ISC_R_SUCCESS) {
+ (void)dns_db_addrdataset(fctx->cache, node,
+ NULL, now,
+ vevent->rdataset, 0,
+ NULL);
+ }
+ if (result == ISC_R_SUCCESS &&
+ vevent->sigrdataset != NULL)
+ (void)dns_db_addrdataset(fctx->cache, node,
+ NULL, now,
+ vevent->sigrdataset,
+ 0, NULL);
+ if (result == ISC_R_SUCCESS)
+ dns_db_detachnode(fctx->cache, &node);
+ }
+ result = fctx->vresult;
add_bad(fctx, addrinfo, result, badns_validation);
isc_event_free(&event);
UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
INSIST(fctx->validator == NULL);
fctx->validator = ISC_LIST_HEAD(fctx->validators);
- if (fctx->validator != NULL) {
+ if (fctx->validator != NULL)
dns_validator_send(fctx->validator);
- } else if (sentresponse)
+ else if (sentresponse)
fctx_done(fctx, result, __LINE__); /* Locks bucket. */
- else
- fctx_try(fctx); /* Locks bucket. */
+ else if (result == DNS_R_BROKENCHAIN) {
+ isc_result_t tresult;
+ isc_time_t expire;
+ isc_interval_t i;
+
+ isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+ tresult = isc_time_nowplusinterval(&expire, &i);
+ if (negative &&
+ (fctx->type == dns_rdatatype_dnskey ||
+ fctx->type == dns_rdatatype_dlv ||
+ fctx->type == dns_rdatatype_ds) &&
+ tresult == ISC_R_SUCCESS)
+ dns_resolver_addbadcache(fctx->res,
+ &fctx->name,
+ fctx->type, &expire);
+ fctx_done(fctx, result, __LINE__); /* Locks bucket. */
+ } else
+ fctx_try(fctx, ISC_TRUE); /* Locks bucket. */
return;
}
- isc_stdtime_get(&now);
-
if (negative) {
dns_rdatatype_t covers;
FCTXTRACE("nonexistence validation OK");
@@ -5589,7 +5666,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
/*
* Try again.
*/
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
} else {
unsigned int n;
dns_rdataset_t *nsrdataset = NULL;
@@ -6329,7 +6406,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
/*
* Try again.
*/
- fctx_try(fctx);
+ fctx_try(fctx, ISC_FALSE);
} else if (resend) {
/*
* Resend (probably with changed options).
@@ -6390,6 +6467,27 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
/***
*** Resolver Methods
***/
+static void
+destroy_badcache(dns_resolver_t *res) {
+ dns_badcache_t *bad, *next;
+ unsigned int i;
+
+ if (res->badcache != NULL) {
+ for (i = 0; i < res->badhash; i++)
+ for (bad = res->badcache[i]; bad != NULL;
+ bad = next) {
+ next = bad->next;
+ isc_mem_put(res->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ res->badcount--;
+ }
+ isc_mem_put(res->mctx, res->badcache,
+ sizeof(*res->badcache) * res->badhash);
+ res->badcache = NULL;
+ res->badhash = 0;
+ INSIST(res->badcount == 0);
+ }
+}
static void
destroy(dns_resolver_t *res) {
@@ -6427,6 +6525,7 @@ destroy(dns_resolver_t *res) {
isc_mem_put(res->mctx, a, sizeof(*a));
}
dns_resolver_reset_algorithms(res);
+ destroy_badcache(res);
dns_resolver_resetmustbesecure(res);
#if USE_ALGLOCK
isc_rwlock_destroy(&res->alglock);
@@ -6550,6 +6649,10 @@ dns_resolver_create(dns_view_t *view,
ISC_LIST_INIT(res->alternates);
res->udpsize = RECV_BUFFER_SIZE;
res->algorithms = NULL;
+ res->badcache = NULL;
+ res->badcount = 0;
+ res->badhash = 0;
+ res->badsweep = 0;
res->mustbesecure = NULL;
res->spillatmin = res->spillat = 10;
res->spillatmax = 100;
@@ -7380,6 +7483,256 @@ dns_resolver_getudpsize(dns_resolver_t *resolver) {
return (resolver->udpsize);
}
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name) {
+ unsigned int i;
+ dns_badcache_t *bad, *prev, *next;
+
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ LOCK(&resolver->lock);
+ if (resolver->badcache == NULL)
+ goto unlock;
+
+ if (name != NULL) {
+ isc_time_t now;
+ isc_result_t result;
+ result = isc_time_now(&now);
+ if (result != ISC_R_SUCCESS)
+ isc_time_settoepoch(&now);
+ i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+ prev = NULL;
+ for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+ int n;
+ next = bad->next;
+ n = isc_time_compare(&bad->expire, &now);
+ if (n < 0 || dns_name_equal(name, &bad->name)) {
+ if (prev == NULL)
+ resolver->badcache[i] = bad->next;
+ else
+ prev->next = bad->next;
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ } else
+ prev = bad;
+ }
+ } else
+ destroy_badcache(resolver);
+
+ unlock:
+ UNLOCK(&resolver->lock);
+
+}
+
+static void
+resizehash(dns_resolver_t *resolver, isc_time_t *now, isc_boolean_t grow) {
+ unsigned int newsize;
+ dns_badcache_t **new, *bad, *next;
+ unsigned int i;
+
+ if (grow)
+ newsize = resolver->badhash * 2 + 1;
+ else
+ newsize = (resolver->badhash - 1) / 2;
+
+ new = isc_mem_get(resolver->mctx,
+ sizeof(*resolver->badcache) * newsize);
+ if (new == NULL)
+ return;
+ memset(new, 0, sizeof(*resolver->badcache) * newsize);
+ for (i = 0; i < resolver->badhash; i++) {
+ for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+ next = bad->next;
+ if (isc_time_compare(&bad->expire, now) < 0) {
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ } else {
+ bad->next = new[bad->hashval % newsize];
+ new[bad->hashval % newsize] = bad;
+ }
+ }
+ }
+ isc_mem_put(resolver->mctx, resolver->badcache,
+ sizeof(*resolver->badcache) * resolver->badhash);
+ resolver->badhash = newsize;
+ resolver->badcache = new;
+}
+
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+ dns_rdatatype_t type, isc_time_t *expire)
+{
+ isc_time_t now;
+ isc_result_t result = ISC_R_SUCCESS;
+ unsigned int i, hashval;
+ dns_badcache_t *bad, *prev, *next;
+
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ LOCK(&resolver->lock);
+ if (resolver->badcache == NULL) {
+ resolver->badcache = isc_mem_get(resolver->mctx,
+ sizeof(*resolver->badcache) *
+ DNS_BADCACHE_SIZE);
+ if (resolver->badcache == NULL) {
+ result = ISC_R_NOMEMORY;
+ goto cleanup;
+ }
+ resolver->badhash = DNS_BADCACHE_SIZE;
+ memset(resolver->badcache, 0, sizeof(*resolver->badcache) *
+ resolver->badhash);
+ }
+
+ result = isc_time_now(&now);
+ if (result != ISC_R_SUCCESS)
+ isc_time_settoepoch(&now);
+ hashval = dns_name_hash(name, ISC_FALSE);
+ i = hashval % resolver->badhash;
+ prev = NULL;
+ for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+ next = bad->next;
+ if (bad->type == type && dns_name_equal(name, &bad->name))
+ break;
+ if (isc_time_compare(&bad->expire, &now) < 0) {
+ if (prev == NULL)
+ resolver->badcache[i] = bad->next;
+ else
+ prev->next = bad->next;
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ } else
+ prev = bad;
+ }
+ if (bad == NULL) {
+ isc_buffer_t buffer;
+ bad = isc_mem_get(resolver->mctx, sizeof(*bad) + name->length);
+ if (bad == NULL) {
+ result = ISC_R_NOMEMORY;
+ goto cleanup;
+ }
+ bad->type = type;
+ bad->hashval = hashval;
+ isc_buffer_init(&buffer, bad + 1, name->length);
+ dns_name_init(&bad->name, NULL);
+ dns_name_copy(name, &bad->name, &buffer);
+ bad->next = resolver->badcache[i];
+ resolver->badcache[i] = bad;
+ resolver->badcount++;
+ if (resolver->badcount > resolver->badhash * 8)
+ resizehash(resolver, &now, ISC_TRUE);
+ if (resolver->badcount < resolver->badhash * 2 &&
+ resolver->badhash > DNS_BADCACHE_SIZE)
+ resizehash(resolver, &now, ISC_FALSE);
+ }
+ bad->expire = *expire;
+ cleanup:
+ UNLOCK(&resolver->lock);
+}
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+ dns_rdatatype_t type, isc_time_t *now)
+{
+ dns_badcache_t *bad, *prev, *next;
+ isc_boolean_t answer = ISC_FALSE;
+ unsigned int i;
+
+ REQUIRE(VALID_RESOLVER(resolver));
+
+ LOCK(&resolver->lock);
+ if (resolver->badcache == NULL)
+ goto unlock;
+
+ i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+ prev = NULL;
+ for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+ next = bad->next;
+ /*
+ * Search the hash list. Clean out expired records as we go.
+ */
+ if (isc_time_compare(&bad->expire, now) < 0) {
+ if (prev != NULL)
+ prev->next = bad->next;
+ else
+ resolver->badcache[i] = bad->next;
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ continue;
+ }
+ if (bad->type == type && dns_name_equal(name, &bad->name)) {
+ answer = ISC_TRUE;
+ break;
+ }
+ prev = bad;
+ }
+
+ /*
+ * Slow sweep to clean out stale records.
+ */
+ i = resolver->badsweep++ % resolver->badhash;
+ bad = resolver->badcache[i];
+ if (bad != NULL && isc_time_compare(&bad->expire, now) < 0) {
+ resolver->badcache[i] = bad->next;
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ }
+
+ unlock:
+ UNLOCK(&resolver->lock);
+ return (answer);
+}
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp) {
+ char namebuf[DNS_NAME_FORMATSIZE];
+ char typebuf[DNS_RDATATYPE_FORMATSIZE];
+ dns_badcache_t *bad, *next, *prev;
+ isc_time_t now;
+ unsigned int i;
+ isc_uint64_t t;
+
+ LOCK(&resolver->lock);
+ fprintf(fp, ";\n; Bad cache\n;\n");
+
+ if (resolver->badcache == NULL)
+ goto unlock;
+
+ TIME_NOW(&now);
+ for (i = 0; i < resolver->badhash; i++) {
+ prev = NULL;
+ for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+ next = bad->next;
+ if (isc_time_compare(&bad->expire, &now) < 0) {
+ if (prev != NULL)
+ prev->next = bad->next;
+ else
+ resolver->badcache[i] = bad->next;
+ isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+ bad->name.length);
+ resolver->badcount--;
+ continue;
+ }
+ prev = bad;
+ dns_name_format(&bad->name, namebuf, sizeof(namebuf));
+ dns_rdatatype_format(bad->type, typebuf,
+ sizeof(typebuf));
+ t = isc_time_microdiff(&bad->expire, &now);
+ t /= 1000;
+ fprintf(fp, "; %s/%s [ttl "
+ "%" ISC_PLATFORM_QUADFORMAT "u]\n",
+ namebuf, typebuf, t);
+ }
+ }
+
+ unlock:
+ UNLOCK(&resolver->lock);
+}
+
static void
free_algorithm(void *node, void *arg) {
unsigned char *algorithms = node;
diff --git a/lib/dns/result.c b/lib/dns/result.c
index fdb58e0df7f4..504de7ebbf76 100644
--- a/lib/dns/result.c
+++ b/lib/dns/result.c
@@ -1,8 +1,8 @@
/*
- * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 1998-2003 Internet Software Consortium.
*
- * Permission to use, copy, modify, and distribute this software for any
+ * 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.
*
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: result.c,v 1.115.10.7 2005/06/17 02:04:31 marka Exp $ */
+/* $Id: result.c,v 1.115.10.9 2010/02/26 23:46:37 tbox Exp $ */
/*! \file */
@@ -155,7 +155,11 @@ static const char *text[DNS_R_NRESULTS] = {
"must-be-secure", /*%< 100 DNS_R_MUSTBESECURE */
"covering NSEC record returned", /*%< 101 DNS_R_COVERINGNSEC */
"MX is an address", /*%< 102 DNS_R_MXISADDRESS */
- "duplicate query" /*%< 103 DNS_R_DUPLICATE */
+ "duplicate query", /*%< 103 DNS_R_DUPLICATE */
+ "invalid NSEC3 owner name (wildcard)", /*%< 104 DNS_R_INVALIDNSEC3 */
+
+ "not master", /*%< 105 DNS_R_NOTMASTER */
+ "broken trust chain", /*%< 106 DNS_R_BROKENCHAIN */
};
static const char *rcode_text[DNS_R_NRCODERESULTS] = {
diff --git a/lib/dns/sdb.c b/lib/dns/sdb.c
index 972b72a985f8..42a1ce364096 100644
--- a/lib/dns/sdb.c
+++ b/lib/dns/sdb.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000, 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: sdb.c,v 1.45.18.19 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdb.c,v 1.45.18.21 2010/02/26 23:46:37 tbox Exp $ */
/*! \file */
@@ -1374,6 +1374,8 @@ static dns_rdatasetmethods_t methods = {
isc__rdatalist_getnoqname,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
diff --git a/lib/dns/sdlz.c b/lib/dns/sdlz.c
index 6c9a521b05f2..9dcaa57e3330 100644
--- a/lib/dns/sdlz.c
+++ b/lib/dns/sdlz.c
@@ -1,5 +1,5 @@
/*
- * Portions Copyright (C) 2005-2007, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009, 2010 Internet Systems Consortium, Inc. ("ISC")
* Portions Copyright (C) 1999-2001 Internet Software Consortium.
*
* Permission to use, copy, modify, and/or distribute this software for any
@@ -50,7 +50,7 @@
* USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: sdlz.c,v 1.2.2.14 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdlz.c,v 1.2.2.16 2010/02/26 23:46:37 tbox Exp $ */
/*! \file */
@@ -1198,6 +1198,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
isc__rdatalist_getnoqname,
NULL,
NULL,
+ NULL,
+ NULL,
NULL
};
diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 387c433f5450..9642791ad1ac 100644
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2000-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: validator.c,v 1.119.18.51 2009/12/30 06:44:05 each Exp $ */
+/* $Id: validator.c,v 1.119.18.53 2010/02/26 23:46:37 tbox Exp $ */
/*! \file */
@@ -170,9 +170,16 @@ static inline void
markanswer(dns_validator_t *val) {
validator_log(val, ISC_LOG_DEBUG(3), "marking as answer");
if (val->event->rdataset != NULL)
- val->event->rdataset->trust = dns_trust_answer;
+ dns_rdataset_settrust(val->event->rdataset, dns_trust_answer);
if (val->event->sigrdataset != NULL)
- val->event->sigrdataset->trust = dns_trust_answer;
+ dns_rdataset_settrust(val->event->sigrdataset,
+ dns_trust_answer);
+}
+
+static inline void
+marksecure(dns_validatorevent_t *event) {
+ dns_rdataset_settrust(event->rdataset, dns_trust_secure);
+ dns_rdataset_settrust(event->sigrdataset, dns_trust_secure);
}
static void
@@ -337,7 +344,7 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
if (eresult == ISC_R_CANCELED)
validator_done(val, eresult);
else
- validator_done(val, DNS_R_NOVALIDKEY);
+ validator_done(val, DNS_R_BROKENCHAIN);
}
want_destroy = exit_check(val);
UNLOCK(&val->lock);
@@ -407,7 +414,7 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
if (eresult == ISC_R_CANCELED)
validator_done(val, eresult);
else
- validator_done(val, DNS_R_NOVALIDDS);
+ validator_done(val, DNS_R_BROKENCHAIN);
}
want_destroy = exit_check(val);
UNLOCK(&val->lock);
@@ -547,10 +554,16 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
if (result != DNS_R_WAIT)
validator_done(val, result);
} else {
+ if (eresult != DNS_R_BROKENCHAIN) {
+ if (dns_rdataset_isassociated(&val->frdataset))
+ dns_rdataset_expire(&val->frdataset);
+ if (dns_rdataset_isassociated(&val->fsigrdataset))
+ dns_rdataset_expire(&val->fsigrdataset);
+ }
validator_log(val, ISC_LOG_DEBUG(3),
"keyvalidated: got %s",
isc_result_totext(eresult));
- validator_done(val, eresult);
+ validator_done(val, DNS_R_BROKENCHAIN);
}
want_destroy = exit_check(val);
UNLOCK(&val->lock);
@@ -597,10 +610,16 @@ dsvalidated(isc_task_t *task, isc_event_t *event) {
if (result != DNS_R_WAIT)
validator_done(val, result);
} else {
+ if (eresult != DNS_R_BROKENCHAIN) {
+ if (dns_rdataset_isassociated(&val->frdataset))
+ dns_rdataset_expire(&val->frdataset);
+ if (dns_rdataset_isassociated(&val->fsigrdataset))
+ dns_rdataset_expire(&val->fsigrdataset);
+ }
validator_log(val, ISC_LOG_DEBUG(3),
"dsvalidated: got %s",
isc_result_totext(eresult));
- validator_done(val, eresult);
+ validator_done(val, DNS_R_BROKENCHAIN);
}
want_destroy = exit_check(val);
UNLOCK(&val->lock);
@@ -802,6 +821,8 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
validator_log(val, ISC_LOG_DEBUG(3),
"authvalidated: got %s",
isc_result_totext(result));
+ if (result == DNS_R_BROKENCHAIN)
+ val->authfail++;
if (result == ISC_R_CANCELED)
validator_done(val, result);
else {
@@ -867,6 +888,7 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
* \li DNS_R_NCACHENXRRSET
* \li DNS_R_NXRRSET
* \li DNS_R_NXDOMAIN
+ * \li DNS_R_BROKENCHAIN
*/
static inline isc_result_t
view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
@@ -876,9 +898,12 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
dns_rdata_t rdata = DNS_RDATA_INIT;
isc_result_t result;
unsigned int options;
+ isc_time_t now;
char buf1[DNS_NAME_FORMATSIZE];
char buf2[DNS_NAME_FORMATSIZE];
char buf3[DNS_NAME_FORMATSIZE];
+ char namebuf[DNS_NAME_FORMATSIZE];
+ char typebuf[DNS_RDATATYPE_FORMATSIZE];
if (dns_rdataset_isassociated(&val->frdataset))
dns_rdataset_disassociate(&val->frdataset);
@@ -888,6 +913,16 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
if (val->view->zonetable == NULL)
return (ISC_R_CANCELED);
+ if (isc_time_now(&now) == ISC_R_SUCCESS &&
+ dns_resolver_getbadcache(val->view->resolver, name, type, &now)) {
+
+ dns_name_format(name, namebuf, sizeof(namebuf));
+ dns_rdatatype_format(type, typebuf, sizeof(typebuf));
+ validator_log(val, ISC_LOG_INFO, "bad cache hit (%s/%s)",
+ namebuf, typebuf);
+ return (DNS_R_BROKENCHAIN);
+ }
+
options = DNS_DBFIND_PENDINGOK;
if (type == dns_rdatatype_dlv)
options |= DNS_DBFIND_COVERINGNSEC;
@@ -896,6 +931,7 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
result = dns_view_find(val->view, name, type, 0, options,
ISC_FALSE, NULL, NULL, foundname,
&val->frdataset, &val->fsigrdataset);
+
if (result == DNS_R_NXDOMAIN) {
if (dns_rdataset_isassociated(&val->frdataset))
dns_rdataset_disassociate(&val->frdataset);
@@ -1240,7 +1276,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
/*
* We don't know anything about this key.
*/
- result = create_fetch(val, &siginfo->signer, dns_rdatatype_dnskey,
+ result = create_fetch(val, &siginfo->signer,
+ dns_rdatatype_dnskey,
fetch_callback_validator, "get_key");
if (result != ISC_R_SUCCESS)
return (result);
@@ -1255,7 +1292,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
* This key doesn't exist.
*/
result = DNS_R_CONTINUE;
- }
+ } else if (result == DNS_R_BROKENCHAIN)
+ return (result);
if (dns_rdataset_isassociated(&val->frdataset) &&
val->keyset != &val->frdataset)
@@ -1503,8 +1541,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
"looking for noqname proof");
return (nsecvalidate(val, ISC_FALSE));
} else if (result == ISC_R_SUCCESS) {
- event->rdataset->trust = dns_trust_secure;
- event->sigrdataset->trust = dns_trust_secure;
+ marksecure(event);
validator_log(val, ISC_LOG_DEBUG(3),
"marking as secure");
return (result);
@@ -1680,8 +1717,7 @@ dlv_validatezonekey(dns_validator_t *val) {
"no RRSIG matching DLV key");
}
if (result == ISC_R_SUCCESS) {
- val->event->rdataset->trust = dns_trust_secure;
- val->event->sigrdataset->trust = dns_trust_secure;
+ marksecure(val->event);
validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
return (result);
} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -1782,8 +1818,7 @@ validatezonekey(dns_validator_t *val) {
keynode = nextnode;
}
if (result == ISC_R_SUCCESS) {
- event->rdataset->trust = dns_trust_secure;
- event->sigrdataset->trust = dns_trust_secure;
+ marksecure(event);
validator_log(val, ISC_LOG_DEBUG(3),
"signed by trusted key; "
"marking as secure");
@@ -1810,11 +1845,14 @@ validatezonekey(dns_validator_t *val) {
*/
dns_name_format(val->event->name, namebuf,
sizeof(namebuf));
- validator_log(val, ISC_LOG_DEBUG(2),
+ validator_log(val, ISC_LOG_NOTICE,
"unable to find a DNSKEY which verifies "
"the DNSKEY RRset and also matches one "
"of specified trusted-keys for '%s'",
namebuf);
+ validator_log(val, ISC_LOG_NOTICE,
+ "please check the 'trusted-keys' for "
+ "'%s' in named.conf.", namebuf);
return (DNS_R_NOVALIDKEY);
}
@@ -1875,7 +1913,8 @@ validatezonekey(dns_validator_t *val) {
dns_rdataset_disassociate(&val->fsigrdataset);
validator_log(val, ISC_LOG_DEBUG(2), "no DS record");
return (DNS_R_NOVALIDSIG);
- }
+ } else if (result == DNS_R_BROKENCHAIN)
+ return (result);
}
/*
@@ -2024,8 +2063,7 @@ validatezonekey(dns_validator_t *val) {
"no RRSIG matching DS key");
}
if (result == ISC_R_SUCCESS) {
- event->rdataset->trust = dns_trust_secure;
- event->sigrdataset->trust = dns_trust_secure;
+ marksecure(event);
validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
return (result);
} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -2231,6 +2269,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
"nsecvalidate");
if (result != ISC_R_SUCCESS)
return (result);
+ val->authcount++;
return (DNS_R_WAIT);
}
@@ -2252,8 +2291,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
"noqname proof found");
validator_log(val, ISC_LOG_DEBUG(3),
"marking as secure");
- val->event->rdataset->trust = dns_trust_secure;
- val->event->sigrdataset->trust = dns_trust_secure;
+ marksecure(val->event);
return (ISC_R_SUCCESS);
}
validator_log(val, ISC_LOG_DEBUG(3),
@@ -2284,6 +2322,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
return (ISC_R_SUCCESS);
}
+ if (val->authcount == val->authfail)
+ return (DNS_R_BROKENCHAIN);
validator_log(val, ISC_LOG_DEBUG(3),
"nonexistence proof(s) not found");
val->attributes |= VALATTR_INSECURITY;
@@ -2315,6 +2355,58 @@ check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) {
return (ISC_FALSE);
}
+static void
+dlvvalidated(isc_task_t *task, isc_event_t *event) {
+ dns_validatorevent_t *devent;
+ dns_validator_t *val;
+ isc_result_t eresult;
+ isc_boolean_t want_destroy;
+
+ UNUSED(task);
+ INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
+
+ devent = (dns_validatorevent_t *)event;
+ val = devent->ev_arg;
+ eresult = devent->result;
+
+ isc_event_free(&event);
+ dns_validator_destroy(&val->subvalidator);
+
+ INSIST(val->event != NULL);
+
+ validator_log(val, ISC_LOG_DEBUG(3), "in dlvvalidated");
+ LOCK(&val->lock);
+ if (CANCELED(val)) {
+ validator_done(val, ISC_R_CANCELED);
+ } else if (eresult == ISC_R_SUCCESS) {
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "dlvset with trust %d", val->frdataset.trust);
+ dns_rdataset_clone(&val->frdataset, &val->dlv);
+ val->havedlvsep = ISC_TRUE;
+ if (dlv_algorithm_supported(val))
+ dlv_validator_start(val);
+ else {
+ markanswer(val);
+ validator_done(val, ISC_R_SUCCESS);
+ }
+ } else {
+ if (eresult != DNS_R_BROKENCHAIN) {
+ if (dns_rdataset_isassociated(&val->frdataset))
+ dns_rdataset_expire(&val->frdataset);
+ if (dns_rdataset_isassociated(&val->fsigrdataset))
+ dns_rdataset_expire(&val->fsigrdataset);
+ }
+ validator_log(val, ISC_LOG_DEBUG(3),
+ "dlvvalidated: got %s",
+ isc_result_totext(eresult));
+ validator_done(val, DNS_R_BROKENCHAIN);
+ }
+ want_destroy = exit_check(val);
+ UNLOCK(&val->lock);
+ if (want_destroy)
+ destroy(val);
+}
+
/*%
* Callback from fetching a DLV record.
*
@@ -2534,6 +2626,24 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
namebuf);
result = view_find(val, dlvname, dns_rdatatype_dlv);
if (result == ISC_R_SUCCESS) {
+ if (DNS_TRUST_PENDING(val->frdataset.trust) &&
+ dns_rdataset_isassociated(&val->fsigrdataset))
+ {
+ dns_fixedname_init(&val->fname);
+ dns_name_copy(dlvname,
+ dns_fixedname_name(&val->fname),
+ NULL);
+ result = create_validator(val,
+ dns_fixedname_name(&val->fname),
+ dns_rdatatype_dlv,
+ &val->frdataset,
+ &val->fsigrdataset,
+ dlvvalidated,
+ "finddlvsep");
+ if (result != ISC_R_SUCCESS)
+ return (result);
+ return (DNS_R_WAIT);
+ }
if (val->frdataset.trust < dns_trust_secure)
return (DNS_R_NOVALIDSIG);
val->havedlvsep = ISC_TRUE;
@@ -2584,6 +2694,7 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
* \li DNS_R_NOVALIDSIG
* \li DNS_R_NOVALIDNSEC
* \li DNS_R_NOTINSECURE
+ * \li DNS_R_BROKENCHAIN
*/
static isc_result_t
proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
@@ -2800,7 +2911,8 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
if (result != ISC_R_SUCCESS)
goto out;
return (DNS_R_WAIT);
- }
+ } else if (result == DNS_R_BROKENCHAIN)
+ return (result);
}
validator_log(val, ISC_LOG_DEBUG(3), "insecurity proof failed");
return (DNS_R_NOTINSECURE); /* Couldn't complete insecurity proof */
@@ -3007,6 +3119,8 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
val->seensig = ISC_FALSE;
val->havedlvsep = ISC_FALSE;
val->depth = 0;
+ val->authcount = 0;
+ val->authfail = 0;
val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name);
dns_rdataset_init(&val->frdataset);
dns_rdataset_init(&val->fsigrdataset);
diff --git a/lib/dns/view.c b/lib/dns/view.c
index 4851cf008455..801654be365d 100644
--- a/lib/dns/view.c
+++ b/lib/dns/view.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008, 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: view.c,v 1.126.18.16 2008/06/17 23:46:03 tbox Exp $ */
+/* $Id: view.c,v 1.126.18.18 2010/02/26 23:46:37 tbox Exp $ */
/*! \file */
@@ -1194,10 +1194,11 @@ dns_view_dumpdbtostream(dns_view_t *view, FILE *fp) {
(void)fprintf(fp, ";\n; Cache dump of view '%s'\n;\n", view->name);
result = dns_master_dumptostream(view->mctx, view->cachedb, NULL,
- &dns_master_style_cache, fp);
+ &dns_master_style_cache, fp);
if (result != ISC_R_SUCCESS)
return (result);
dns_adb_dump(view->adb, fp);
+ dns_resolver_printbadcache(view->resolver, fp);
return (ISC_R_SUCCESS);
}
@@ -1218,6 +1219,8 @@ dns_view_flushcache(dns_view_t *view) {
dns_cache_attachdb(view->cache, &view->cachedb);
if (view->acache != NULL)
dns_acache_setdb(view->acache, view->cachedb);
+ if (view->resolver != NULL)
+ dns_resolver_flushbadcache(view->resolver, NULL);
dns_adb_flush(view->adb);
return (ISC_R_SUCCESS);
@@ -1232,6 +1235,8 @@ dns_view_flushname(dns_view_t *view, dns_name_t *name) {
dns_adb_flushname(view->adb, name);
if (view->cache == NULL)
return (ISC_R_SUCCESS);
+ if (view->resolver != NULL)
+ dns_resolver_flushbadcache(view->resolver, name);
return (dns_cache_flushname(view->cache, name));
}
diff --git a/version b/version
index 7d97c13f850f..61b21455d9b1 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.28 2010/01/21 01:10:54 marka Exp $
+# $Id: version,v 1.29.134.29 2010/03/04 00:25:25 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=
+RELEASEVER=-R1