diff options
| author | cvs2svn <cvs2svn@FreeBSD.org> | 2006-01-13 06:51:44 +0000 |
|---|---|---|
| committer | cvs2svn <cvs2svn@FreeBSD.org> | 2006-01-13 06:51:44 +0000 |
| commit | a7f4d3a87f3e05db91c4e5760af85aae44d1d84b (patch) | |
| tree | 3721e32e68428520f738b07bb0e37ca7133ec47d | |
| parent | 1c9ec3804f7f0ffdf98e2b7fdb929180d16c070e (diff) | |
Notes
47 files changed, 46656 insertions, 0 deletions
diff --git a/LOCKS b/LOCKS new file mode 100644 index 000000000000..977f30b0a4ed --- /dev/null +++ b/LOCKS @@ -0,0 +1,12 @@ +$FreeBSD$ + +This file documents formal review/approval requirements that have been +approved by core. + +subsystem login expires notes +-------------------------------------- + +Special cases: +src/* RELENG_4_* Requires Security Officer approval. +src/* RELENG_5_* Requires Security Officer approval. +src/* RELENG_6_* Requires Security Officer approval. diff --git a/contrib/bind9/FAQ.xml b/contrib/bind9/FAQ.xml new file mode 100644 index 000000000000..963cd0a8c40d --- /dev/null +++ b/contrib/bind9/FAQ.xml @@ -0,0 +1,1007 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> +<!-- + - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + - Copyright (C) 2000-2003 Internet Software Consortium. + - + - Permission to use, copy, modify, and distribute this software for any + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> + +<!-- $Id: FAQ.xml,v 1.4.6.3 2005/11/02 22:53:51 marka Exp $ --> + +<article class="faq"> + <title>Frequently Asked Questions about BIND 9</title> + <qandaset defaultlabel='qanda'> + <qandaentry> + <question> + <para> + Why doesn't -u work on Linux 2.2.x when I build with + --enable-threads? + </para> + </question> + <answer> + <para> + Linux threads do not fully implement the Posix threads + (pthreads) standard. In particular, setuid() operates only + on the current thread, not the full process. Because of + this limitation, BIND 9 cannot use setuid() on Linux as it + can on all other supported platforms. setuid() cannot be + called before creating threads, since the server does not + start listening on reserved ports until after threads have + started. + </para> + <para> + In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability + to preserve capabilities across a setuid() call is present. + This allows BIND 9 to call setuid() early, while retaining + the ability to bind reserved ports. This is a Linux-specific + hack. + </para> + <para> + On a 2.2 kernel, BIND 9 does drop many root privileges, so + it should be less of a security risk than a root process + that has not dropped privileges. + </para> + <para> + If Linux threads ever work correctly, this restriction will + go away. + </para> + <para> + Configuring BIND9 with the --disable-threads option (the + default) causes a non-threaded version to be built, which + will allow -u to be used. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why does named log the warning message <quote>no TTL specified - + using SOA MINTTL instead</quote>? + </para> + </question> + <answer> + <para> + Your zone file is illegal according to RFC1035. It must either + have a line like: + </para> + <informalexample> + <programlisting> +$TTL 86400</programlisting> + </informalexample> + <para> + at the beginning, or the first record in it must have a TTL field, + like the "84600" in this example: + </para> + <informalexample> + <programlisting> +example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why do I see 5 (or more) copies of named on Linux? + </para> + </question> + <answer> + <para> + Linux threads each show up as a process under ps. The + approximate number of threads running is n+4, where n is + the number of CPUs. Note that the amount of memory used + is not cumulative; if each process is using 10M of memory, + only a total of 10M is used. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why does BIND 9 log <quote>permission denied</quote> errors accessing + its configuration files or zones on my Linux system even + though it is running as root? + </para> + </question> + <answer> + <para> + On Linux, BIND 9 drops most of its root privileges on + startup. This including the privilege to open files owned + by other users. Therefore, if the server is running as + root, the configuration files and zone files should also + be owned by root. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why do I get errors like <quote>dns_zone_load: zone foo/IN: loading + master file bar: ran out of space</quote>? + </para> + </question> + <answer> + <para> + This is often caused by TXT records with missing close + quotes. Check that all TXT records containing quoted strings + have both open and close quotes. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How do I produce a usable core file from a multithreaded + named on Linux? + </para> + </question> + <answer> + <para> + If the Linux kernel is 2.4.7 or newer, multithreaded core + dumps are usable (that is, the correct thread is dumped). + Otherwise, if using a 2.2 kernel, apply the kernel patch + found in contrib/linux/coredump-patch and rebuild the kernel. + This patch will cause multithreaded programs to dump the + correct thread. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How do I restrict people from looking up the server version? + </para> + </question> + <answer> + <para> + Put a "version" option containing something other than the + real version in the "options" section of named.conf. Note + doing this will not prevent attacks and may impede people + trying to diagnose problems with your server. Also it is + possible to "fingerprint" nameservers to determine their + version. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How do I restrict only remote users from looking up the + server version? + </para> + </question> + <answer> + <para> + The following view statement will intercept lookups as the + internal view that holds the version information will be + matched last. The caveats of the previous answer still + apply, of course. + </para> + <informalexample> + <programlisting> +view "chaos" chaos { + match-clients { <those to be refused>; }; + allow-query { none; }; + zone "." { + type hint; + file "/dev/null"; // or any empty file + }; +};</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + What do <quote>no source of entropy found</quote> or <quote>could not + open entropy source foo</quote> mean? + </para> + </question> + <answer> + <para> + The server requires a source of entropy to perform certain + operations, mostly DNSSEC related. These messages indicate + that you have no source of entropy. On systems with + /dev/random or an equivalent, it is used by default. A + source of entropy can also be defined using the random-device + option in named.conf. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I installed BIND 9 and restarted named, but it's still BIND 8. Why? + </para> + </question> + <answer> + <para> + BIND 9 is installed under /usr/local by default. BIND 8 + is often installed under /usr. Check that the correct named + is running. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I'm trying to use TSIG to authenticate dynamic updates or + zone transfers. I'm sure I have the keys set up correctly, + but the server is rejecting the TSIG. Why? + </para> + </question> + <answer> + <para> + This may be a clock skew problem. Check that the the clocks + on the client and server are properly synchronised (e.g., + using ntp). + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I'm trying to compile BIND 9, and "make" is failing due to + files not being found. Why? + </para> + </question> + <answer> + <para> + Using a parallel or distributed "make" to build BIND 9 is + not supported, and doesn't work. If you are using one of + these, use normal make or gmake instead. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I have a BIND 9 master and a BIND 8.2.3 slave, and the + master is logging error messages like <quote>notify to 10.0.0.1#53 + failed: unexpected end of input</quote>. What's wrong? + </para> + </question> + <answer> + <para> + This error message is caused by a known bug in BIND 8.2.3 + and is fixed in BIND 8.2.4. It can be safely ignored - the + notify has been acted on by the slave despite the error + message. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I keep getting log messages like the following. Why? + </para> + <para> + Dec 4 23:47:59 client 10.0.0.1#1355: updating zone + 'example.com/IN': update failed: 'RRset exists (value + dependent)' prerequisite not satisfied (NXRRSET) + </para> + </question> + <answer> + <para> + DNS updates allow the update request to test to see if + certain conditions are met prior to proceeding with the + update. The message above is saying that conditions were + not met and the update is not proceeding. See doc/rfc/rfc2136.txt + for more details on prerequisites. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I keep getting log messages like the following. Why? + </para> + <para> + Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied + </para> + </question> + <answer> + <para> + Someone is trying to update your DNS data using the RFC2136 + Dynamic Update protocol. Windows 2000 machines have a habit + of sending dynamic update requests to DNS servers without + being specifically configured to do so. If the update + requests are coming from a Windows 2000 machine, see + <ulink + url="http://support.microsoft.com/support/kb/articles/q246/8/04.asp"> + http://support.microsoft.com/support/kb/articles/q246/8/04.asp + </ulink> + for information about how to turn them off. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I see a log message like the following. Why? + </para> + <para> + couldn't open pid file '/var/run/named.pid': Permission denied + </para> + </question> + <answer> + <para> + You are most likely running named as a non-root user, and + that user does not have permission to write in /var/run. + The common ways of fixing this are to create a /var/run/named + directory owned by the named user and set pid-file to + "/var/run/named/named.pid", or set pid-file to "named.pid", + which will put the file in the directory specified by the + directory option (which, in this case, must be writable by + the named user). + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + When I do a "dig . ns", many of the A records for the root + servers are missing. Why? + </para> + </question> + <answer> + <para> + This is normal and harmless. It is a somewhat confusing + side effect of the way BIND 9 does RFC2181 trust ranking + and of the efforts BIND 9 makes to avoid promoting glue + into answers. + </para> + <para> + When BIND 9 first starts up and primes its cache, it receives + the root server addresses as additional data in an authoritative + response from a root server, and these records are eligible + for inclusion as additional data in responses. Subsequently + it receives a subset of the root server addresses as + additional data in a non-authoritative (referral) response + from a root server. This causes the addresses to now be + considered non-authoritative (glue) data, which is not + eligible for inclusion in responses. + </para> + <para> + The server does have a complete set of root server addresses + cached at all times, it just may not include all of them + as additional data, depending on whether they were last + received as answers or as glue. You can always look up the + addresses with explicit queries like "dig a.root-servers.net A". + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Zone transfers from my BIND 9 master to my Windows 2000 + slave fail. Why? + </para> + </question> + <answer> + <para> + This may be caused by a bug in the Windows 2000 DNS server + where DNS messages larger than 16K are not handled properly. + This can be worked around by setting the option "transfer-format + one-answer;". Also check whether your zone contains domain + names with embedded spaces or other special characters, + like "John\032Doe\213s\032Computer", since such names have + been known to cause Windows 2000 slaves to incorrectly + reject the zone. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why don't my zones reload when I do an "rndc reload" or SIGHUP? + </para> + </question> + <answer> + <para> + A zone can be updated either by editing zone files and + reloading the server or by dynamic update, but not both. + If you have enabled dynamic update for a zone using the + "allow-update" option, you are not supposed to edit the + zone file by hand, and the server will not attempt to reload + it. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I can query the nameserver from the nameserver but not from other + machines. Why? + </para> + </question> + <answer> + <para> + This is usually the result of the firewall configuration stopping + the queries and / or the replies. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How can I make a server a slave for both an internal and + an external view at the same time? When I tried, both views + on the slave were transferred from the same view on the master. + </para> + </question> + <answer> + <para> + You will need to give the master and slave multiple IP + addresses and use those to make sure you reach the correct + view on the other machine. + </para> + <informalexample> + <programlisting> +Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias) + internal: + match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; + notify-source 10.0.1.1; + transfer-source 10.0.1.1; + query-source address 10.0.1.1; + external: + match-clients { any; }; + recursion no; // don't offer recursion to the world + notify-source 10.0.1.2; + transfer-source 10.0.1.2; + query-source address 10.0.1.2; + +Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias) + internal: + match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; + notify-source 10.0.1.3; + transfer-source 10.0.1.3; + query-source address 10.0.1.3; + external: + match-clients { any; }; + recursion no; // don't offer recursion to the world + notify-source 10.0.1.4; + transfer-source 10.0.1.4; + query-source address 10.0.1.4;</programlisting> + </informalexample> + <para> + You put the external address on the alias so that all the other + dns clients on these boxes see the internal view by default. + </para> + </answer> + <answer> + <para> + BIND 9.3 and later: Use TSIG to select the appropriate view. + </para> + <informalexample> + <programlisting> +Master 10.0.1.1: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + view "internal" { + match-clients { !key external; 10.0.1/24; }; + ... + }; + view "external" { + match-clients { key external; any; }; + server 10.0.0.2 { keys external; }; + recursion no; + ... + }; + +Slave 10.0.1.2: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + view "internal" { + match-clients { !key external; 10.0.1/24; }; + ... + }; + view "external" { + match-clients { key external; any; }; + server 10.0.0.1 { keys external; }; + recursion no; + ... + };</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I have FreeBSD 4.x and "rndc-confgen -a" just sits there. + </para> + </question> + <answer> + <para> + /dev/random is not configured. Use rndcontrol(8) to tell + the kernel to use certain interrupts as a source of random + events. You can make this permanent by setting rand_irqs + in /etc/rc.conf. + </para> + <informalexample> + <programlisting> +/etc/rc.conf +rand_irqs="3 14 15"</programlisting> + </informalexample> + <para> + See also + <ulink url="http://people.freebsd.org/~dougb/randomness.html"> + http://people.freebsd.org/~dougb/randomness.html + </ulink> + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why is named listening on UDP port other than 53? + </para> + </question> + <answer> + <para> + Named uses a system selected port to make queries of other + nameservers. This behaviour can be overridden by using + query-source to lock down the port and/or address. See + also notify-source and transfer-source. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get error messages like <quote>multiple RRs of singleton type</quote> + and <quote>CNAME and other data</quote> when transferring a zone. What + does this mean? + </para> + </question> + <answer> + <para> + These indicate a malformed master zone. You can identify + the exact records involved by transferring the zone using + dig then running named-checkzone on it. + </para> + <informalexample> + <programlisting> +dig axfr example.com @master-server > tmp +named-checkzone example.com tmp</programlisting> + </informalexample> + <para> + A CNAME record cannot exist with the same name as another record + except for the DNSSEC records which prove its existance (NSEC). + </para> + <para> + RFC 1034, Section 3.6.2: <quote>If a CNAME RR is present at a node, + no other data should be present; this ensures that the data for a + canonical name and its aliases cannot be different. This rule also + insures that a cached CNAME can be used without checking with an + authoritative server for other RR types.</quote> + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get error messages like <quote>named.conf:99: unexpected end + of input</quote> where 99 is the last line of named.conf. + </para> + </question> + <answer> + <para> + Some text editors (notepad and wordpad) fail to put a line + title indication (e.g. CR/LF) on the last line of a + text file. This can be fixed by "adding" a blank line to + the end of the file. Named expects to see EOF immediately + after EOL and treats text files where this is not met as + truncated. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get warning messages like <quote>zone example.com/IN: refresh: + failure trying master 1.2.3.4#53: timed out</quote>. + </para> + </question> + <answer> + <para> + Check that you can make UDP queries from the slave to the master + </para> + <informalexample> + <programlisting> +dig +norec example.com soa @1.2.3.4</programlisting> + </informalexample> + <para> + You could be generating queries faster than the slave can + cope with. Lower the serial query rate. + </para> + <informalexample> + <programlisting> +serial-query-rate 5; // default 20</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How do I share a dynamic zone between multiple views? + </para> + </question> + <answer> + <para> + You choose one view to be master and the second a slave and + transfer the zone between views. + </para> + <informalexample> + <programlisting> +Master 10.0.1.1: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; + + key "mykey" { + algorithm hmac-md5; + secret "yyyyyyyy"; + }; + + view "internal" { + match-clients { !external; 10.0.1/24; }; + server 10.0.1.1 { + /* Deliver notify messages to external view. */ + keys { external; }; + }; + zone "example.com" { + type master; + file "internal/example.db"; + allow-update { key mykey; }; + notify-also { 10.0.1.1; }; + }; + }; + + view "external" { + match-clients { external; any; }; + zone "example.com" { + type slave; + file "external/example.db"; + masters { 10.0.1.1; }; + transfer-source { 10.0.1.1; }; + // allow-update-forwarding { any; }; + // allow-notify { ... }; + }; + };</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get a error message like <quote>zone wireless.ietf56.ietf.org/IN: + loading master file primaries/wireless.ietf56.ietf.org: no + owner</quote>. + </para> + </question> + <answer> + <para> + This error is produced when a line in the master file + contains leading white space (tab/space) but the is no + current record owner name to inherit the name from. Usually + this is the result of putting white space before a comment. + Forgeting the "@" for the SOA record or indenting the master + file. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Why are my logs in GMT (UTC). + </para> + </question> + <answer> + <para> + You are running chrooted (-t) and have not supplied local timzone + information in the chroot area. + </para> + <simplelist> + <member>FreeBSD: /etc/localtime</member> + <member>Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo</member> + <member>OSF: /etc/zoneinfo/localtime</member> + </simplelist> + <para> + See also tzset(3) and zic(8). + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get the error message <quote>named: capset failed: Operation + not permitted</quote> when starting named. + </para> + </question> + <answer> + <para> + The capability module, part of "Linux Security Modules/LSM", + has not been loaded into the kernel. See insmod(8). + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get <quote>rndc: connect failed: connection refused</quote> when + I try to run rndc. + </para> + </question> + <answer> + <para> + This is usually a configuration error. + </para> + <para> + First ensure that named is running and no errors are being + reported at startup (/var/log/messages or equivalent). + Running "named -g <usual arguments>" from a title + can help at this point. + </para> + <para> + Secondly ensure that named is configured to use rndc either + by "rndc-confgen -a", rndc-confgen or manually. The + Administrators Reference manual has details on how to do + this. + </para> + <para> + Old versions of rndc-confgen used localhost rather than + 127.0.0.1 in /etc/rndc.conf for the default server. Update + /etc/rndc.conf if necessary so that the default server + listed in /etc/rndc.conf matches the addresses used in + named.conf. "localhost" has two address (127.0.0.1 and + ::1). + </para> + <para> + If you use "rndc-confgen -a" and named is running with -t or -u + ensure that /etc/rndc.conf has the correct ownership and that + a copy is in the chroot area. You can do this by re-running + "rndc-confgen -a" with appropriate -t and -u arguments. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I don't get RRSIG's returned when I use "dig +dnssec". + </para> + </question> + <answer> + <para> + You need to ensure DNSSEC is enabled (dnssec-enable yes;). + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get <quote>Error 1067</quote> when starting named under Windows. + </para> + </question> + <answer> + <para> + This is the service manager saying that named exited. You + need to examine the Application log in the EventViewer to + find out why. + </para> + <para> + Common causes are that you failed to create "named.conf" + (usually "C:\windows\dns\etc\named.conf") or failed to + specify the directory in named.conf. + </para> + <informalexample> + <programlisting> +options { + Directory "C:\windows\dns\etc"; +};</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + I get <quote>transfer of 'example.net/IN' from 192.168.4.12#53: + failed while receiving responses: permission denied</quote> error + messages. + </para> + </question> + <answer> + <para> + These indicate a filesystem permission error preventing + named creating / renaming the temporary file. These will + usually also have other associated error messages like + </para> + <informalexample> + <programlisting> +"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"</programlisting> + </informalexample> + <para> + Named needs write permission on the directory containing + the file. Named writes the new cache file to a temporary + file then renames it to the name specified in named.conf + to ensure that the contents are always complete. This is + to prevent named loading a partial zone in the event of + power failure or similar interrupting the write of the + master file. + </para> + <para> + Note file names are relative to the directory specified in + options and any chroot directory ([<chroot + dir>/][<options dir>]). + </para> + <informalexample> + <para> + If named is invoked as "named -t /chroot/DNS" with + the following named.conf then "/chroot/DNS/var/named/sl" + needs to be writable by the user named is running as. + </para> + <programlisting> +options { + directory "/var/named"; +}; + +zone "example.net" { + type slave; + file "sl/example.net"; + masters { 192.168.4.12; }; +};</programlisting> + </informalexample> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + How do I intergrate BIND 9 and Solaris SMF + </para> + </question> + <answer> + <para> + Sun has a blog entry describing how to do this. + </para> + <para> + <ulink + url="http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris"> + http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris + </ulink> + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + Can a NS record refer to a CNAME. + </para> + </question> + <answer> + <para> + No. The rules for glue (copies of the *address* records + in the parent zones) and additional section processing do + not allow it to work. + </para> + <para> + You would have to add both the CNAME and address records + (A/AAAA) as glue to the parent zone and have CNAMEs be + followed when doing additional section processing to make + it work. No namesever implementation supports either of + these requirements. + </para> + </answer> + </qandaentry> + + <qandaentry> + <question> + <para> + What does <quote>RFC 1918 response from Internet for + 0.0.0.10.IN-ADDR.ARPA</quote> mean? + </para> + </question> + <answer> + <para> + If the IN-ADDR.ARPA name covered refers to a internal address + space you are using then you have failed to follow RFC 1918 + usage rules and are leaking queries to the Internet. You + should establish your own zones for these addresses to prevent + you quering the Internet's name servers for these addresses. + Please see <ulink url="http://as112.net/">http://as112.net/</ulink> + for details of the problems you are causing and the counter + measures that have had to be deployed. + </para> + <para> + If you are not using these private addresses then a client + has queried for them. You can just ignore the messages, + get the offending client to stop sending you these messages + as they are most probably leaking them or setup your own zones + empty zones to serve answers to these queries. + </para> + <informalexample> + <programlisting> +zone "10.IN-ADDR.ARPA" { + type master; + file "empty"; +}; + +zone "16.172.IN-ADDR.ARPA" { + type master; + file "empty"; +}; + +... + +zone "31.172.IN-ADDR.ARPA" { + type master; + file "empty"; +}; + +zone "168.192.IN-ADDR.ARPA" { + type master; + file "empty"; +}; + +empty: +@ 10800 IN SOA <name-of-server>. <contact-email>. ( + 1 3600 1200 604800 10800 ) +@ 10800 IN NS <name-of-server>.</programlisting> + </informalexample> + <note> + Future versions of named are likely to do this automatically. + </note> + </answer> + </qandaentry> + + </qandaset> +</article> diff --git a/contrib/bind9/bin/named/include/named/ns_smf_globals.h b/contrib/bind9/bin/named/include/named/ns_smf_globals.h new file mode 100644 index 000000000000..49aa31dc5c06 --- /dev/null +++ b/contrib/bind9/bin/named/include/named/ns_smf_globals.h @@ -0,0 +1,44 @@ +/* + * Copyright (C) 2005 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: ns_smf_globals.h,v 1.2.4.4 2005/05/13 01:22:33 marka Exp $ */ + +#ifndef NS_SMF_GLOBALS_H +#define NS_SMF_GLOBALS_H 1 + +#include <libscf.h> + +#undef EXTERN +#undef INIT +#ifdef NS_MAIN +#define EXTERN +#define INIT(v) = (v) +#else +#define EXTERN extern +#define INIT(v) +#endif + +EXTERN unsigned int ns_smf_got_instance INIT(0); +EXTERN unsigned int ns_smf_chroot INIT(0); +EXTERN unsigned int ns_smf_want_disable INIT(0); + +isc_result_t ns_smf_add_message(isc_buffer_t *text); +isc_result_t ns_smf_get_instance(char **name, int debug, isc_mem_t *mctx); + +#undef EXTERN +#undef INIT + +#endif /* NS_SMF_GLOBALS_H */ diff --git a/contrib/bind9/config.threads.in b/contrib/bind9/config.threads.in new file mode 100644 index 000000000000..f2816c447fb2 --- /dev/null +++ b/contrib/bind9/config.threads.in @@ -0,0 +1,152 @@ +# +# Begin pthreads checking. +# +# First, decide whether to use multithreading or not. +# +# Enable multithreading by default on systems where it is known +# to work well, and where debugging of multithreaded programs +# is supported. +# + +AC_MSG_CHECKING(whether to build with thread support) + +case $host in +*-dec-osf*) + use_threads=true ;; +[*-solaris2.[0-6]]) + # Thread signals are broken on Solaris 2.6; they are sometimes + # delivered to the wrong thread. + use_threads=false ;; +*-solaris*) + use_threads=true ;; +*-ibm-aix*) + use_threads=true ;; +*-hp-hpux10*) + use_threads=false ;; +*-hp-hpux11*) + use_threads=true ;; +*-sgi-irix*) + use_threads=true ;; +*-sco-sysv*uw*|*-*-sysv*UnixWare*) + # UnixWare + use_threads=false ;; +*-*-sysv*OpenUNIX*) + # UnixWare + use_threads=true ;; +*-netbsd*) + if test -r /usr/lib/libpthread.so ; then + use_threads=true + else + # Socket I/O optimizations introduced in 9.2 expose a + # bug in unproven-pthreads; see PR #12650 + use_threads=false + fi + ;; +*-openbsd*) + # OpenBSD users have reported that named dumps core on + # startup when built with threads. + use_threads=false ;; +*-freebsd*) + use_threads=false ;; +*-bsdi[234]*) + # Thread signals do not work reliably on some versions of BSD/OS. + use_threads=false ;; +*-bsdi5*) + use_threads=true ;; +*-linux*) + # Threads are disabled on Linux by default because most + # Linux kernels produce unusable core dumps from multithreaded + # programs, and because of limitations in setuid(). + use_threads=false ;; +*) + use_threads=false ;; +esac + +AC_ARG_ENABLE(threads, + [ --enable-threads enable multithreading]) +case "$enable_threads" in + yes) + use_threads=true + ;; + no) + use_threads=false + ;; + '') + # Use system-dependent default + ;; + *) + AC_MSG_ERROR([--enable-threads takes yes or no]) + ;; +esac + +if $use_threads +then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + +if $use_threads +then + # + # Search for / configure pthreads in a system-dependent fashion. + # + case "$host" in + *-netbsd*) + # NetBSD has multiple pthreads implementations. The + # recommended one to use is "unproven-pthreads". The + # older "mit-pthreads" may also work on some NetBSD + # versions. The PTL2 thread library does not + # currently work with bind9, but can be chosen with + # the --with-ptl2 option for those who wish to + # experiment with it. + CC="gcc" + AC_MSG_CHECKING(which NetBSD thread library to use) + + AC_ARG_WITH(ptl2, +[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], + use_ptl2="$withval", use_ptl2="no") + + : ${LOCALBASE:=/usr/pkg} + + if test "X$use_ptl2" = "Xyes" + then + AC_MSG_RESULT(PTL2) + AC_MSG_WARN( +[linking with PTL2 is highly experimental and not expected to work]) + CC=ptlgcc + else + if test -r /usr/lib/libpthread.so + then + AC_MSG_RESULT(native) + LIBS="-lpthread $LIBS" + else + if test ! -d $LOCALBASE/pthreads + then + AC_MSG_RESULT(none) + AC_MSG_ERROR("could not find thread libraries") + fi + + if $use_threads + then + AC_MSG_RESULT(mit-pthreads/unproven-pthreads) + pkg="$LOCALBASE/pthreads" + lib1="-L$pkg/lib -Wl,-R$pkg/lib" + lib2="-lpthread -lm -lgcc -lpthread" + LIBS="$lib1 $lib2 $LIBS" + CPPFLAGS="$CPPFLAGS -I$pkg/include" + STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" + fi + fi + fi + ;; + *) + AC_CHECK_LIB(pthread, pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create_system,, + AC_CHECK_LIB(c_r, pthread_create,, + AC_CHECK_LIB(c, pthread_create,, + AC_MSG_ERROR("could not find thread libraries")))))) + ;; + esac +fi diff --git a/contrib/bind9/doc/arm/Bv9ARM.pdf b/contrib/bind9/doc/arm/Bv9ARM.pdf new file mode 100755 index 000000000000..6119ca4ce244 --- /dev/null +++ b/contrib/bind9/doc/arm/Bv9ARM.pdf @@ -0,0 +1,8964 @@ +%PDF-1.4 +5 0 obj +<< /S /GoTo /D (chapter.1) >> +endobj +8 0 obj +(1 Introduction) +endobj +9 0 obj +<< /S /GoTo /D (section.1.1) >> +endobj +12 0 obj +(1.1 Scope of Document) +endobj +13 0 obj +<< /S /GoTo /D (section.1.2) >> +endobj +16 0 obj +(1.2 Organization of This Document) +endobj +17 0 obj +<< /S /GoTo /D (section.1.3) >> +endobj +20 0 obj +(1.3 Conventions Used in This Document) +endobj +21 0 obj +<< /S /GoTo /D (section.1.4) >> +endobj +24 0 obj +(1.4 The Domain Name System \(DNS\)) +endobj +25 0 obj +<< /S /GoTo /D (subsection.1.4.1) >> +endobj +28 0 obj +(1.4.1 DNS Fundamentals) +endobj +29 0 obj +<< /S /GoTo /D (subsection.1.4.2) >> +endobj +32 0 obj +(1.4.2 Domains and Domain Names) +endobj +33 0 obj +<< /S /GoTo /D (subsection.1.4.3) >> +endobj +36 0 obj +(1.4.3 Zones) +endobj +37 0 obj +<< /S /GoTo /D (subsection.1.4.4) >> +endobj +40 0 obj +(1.4.4 Authoritative Name Servers) +endobj +41 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.1) >> +endobj +44 0 obj +(1.4.4.1 The Primary Master) +endobj +45 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.2) >> +endobj +48 0 obj +(1.4.4.2 Slave Servers) +endobj +49 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.3) >> +endobj +52 0 obj +(1.4.4.3 Stealth Servers) +endobj +53 0 obj +<< /S /GoTo /D (subsection.1.4.5) >> +endobj +56 0 obj +(1.4.5 Caching Name Servers) +endobj +57 0 obj +<< /S /GoTo /D (subsubsection.1.4.5.1) >> +endobj +60 0 obj +(1.4.5.1 Forwarding) +endobj +61 0 obj +<< /S /GoTo /D (subsection.1.4.6) >> +endobj +64 0 obj +(1.4.6 Name Servers in Multiple Roles) +endobj +65 0 obj +<< /S /GoTo /D (chapter.2) >> +endobj +68 0 obj +(2 BIND Resource Requirements) +endobj +69 0 obj +<< /S /GoTo /D (section.2.1) >> +endobj +72 0 obj +(2.1 Hardware requirements) +endobj +73 0 obj +<< /S /GoTo /D (section.2.2) >> +endobj +76 0 obj +(2.2 CPU Requirements) +endobj +77 0 obj +<< /S /GoTo /D (section.2.3) >> +endobj +80 0 obj +(2.3 Memory Requirements) +endobj +81 0 obj +<< /S /GoTo /D (section.2.4) >> +endobj +84 0 obj +(2.4 Name Server Intensive Environment Issues) +endobj +85 0 obj +<< /S /GoTo /D (section.2.5) >> +endobj +88 0 obj +(2.5 Supported Operating Systems) +endobj +89 0 obj +<< /S /GoTo /D (chapter.3) >> +endobj +92 0 obj +(3 Name Server Configuration) +endobj +93 0 obj +<< /S /GoTo /D (section.3.1) >> +endobj +96 0 obj +(3.1 Sample Configurations) +endobj +97 0 obj +<< /S /GoTo /D (subsection.3.1.1) >> +endobj +100 0 obj +(3.1.1 A Caching-only Name Server) +endobj +101 0 obj +<< /S /GoTo /D (subsection.3.1.2) >> +endobj +104 0 obj +(3.1.2 An Authoritative-only Name Server) +endobj +105 0 obj +<< /S /GoTo /D (section.3.2) >> +endobj +108 0 obj +(3.2 Load Balancing) +endobj +109 0 obj +<< /S /GoTo /D (section.3.3) >> +endobj +112 0 obj +(3.3 Name Server Operations) +endobj +113 0 obj +<< /S /GoTo /D (subsection.3.3.1) >> +endobj +116 0 obj +(3.3.1 Tools for Use With the Name Server Daemon) +endobj +117 0 obj +<< /S /GoTo /D (subsubsection.3.3.1.1) >> +endobj +120 0 obj +(3.3.1.1 Diagnostic Tools) +endobj +121 0 obj +<< /S /GoTo /D (subsubsection.3.3.1.2) >> +endobj +124 0 obj +(3.3.1.2 Administrative Tools) +endobj +125 0 obj +<< /S /GoTo /D (subsection.3.3.2) >> +endobj +128 0 obj +(3.3.2 Signals) +endobj +129 0 obj +<< /S /GoTo /D (chapter.4) >> +endobj +132 0 obj +(4 Advanced DNS Features) +endobj +133 0 obj +<< /S /GoTo /D (section.4.1) >> +endobj +136 0 obj +(4.1 Notify) +endobj +137 0 obj +<< /S /GoTo /D (section.4.2) >> +endobj +140 0 obj +(4.2 Dynamic Update) +endobj +141 0 obj +<< /S /GoTo /D (subsection.4.2.1) >> +endobj +144 0 obj +(4.2.1 The journal file) +endobj +145 0 obj +<< /S /GoTo /D (section.4.3) >> +endobj +148 0 obj +(4.3 Incremental Zone Transfers \(IXFR\)) +endobj +149 0 obj +<< /S /GoTo /D (section.4.4) >> +endobj +152 0 obj +(4.4 Split DNS) +endobj +153 0 obj +<< /S /GoTo /D (section.4.5) >> +endobj +156 0 obj +(4.5 TSIG) +endobj +157 0 obj +<< /S /GoTo /D (subsection.4.5.1) >> +endobj +160 0 obj +(4.5.1 Generate Shared Keys for Each Pair of Hosts) +endobj +161 0 obj +<< /S /GoTo /D (subsubsection.4.5.1.1) >> +endobj +164 0 obj +(4.5.1.1 Automatic Generation) +endobj +165 0 obj +<< /S /GoTo /D (subsubsection.4.5.1.2) >> +endobj +168 0 obj +(4.5.1.2 Manual Generation) +endobj +169 0 obj +<< /S /GoTo /D (subsection.4.5.2) >> +endobj +172 0 obj +(4.5.2 Copying the Shared Secret to Both Machines) +endobj +173 0 obj +<< /S /GoTo /D (subsection.4.5.3) >> +endobj +176 0 obj +(4.5.3 Informing the Servers of the Key's Existence) +endobj +177 0 obj +<< /S /GoTo /D (subsection.4.5.4) >> +endobj +180 0 obj +(4.5.4 Instructing the Server to Use the Key) +endobj +181 0 obj +<< /S /GoTo /D (subsection.4.5.5) >> +endobj +184 0 obj +(4.5.5 TSIG Key Based Access Control) +endobj +185 0 obj +<< /S /GoTo /D (subsection.4.5.6) >> +endobj +188 0 obj +(4.5.6 Errors) +endobj +189 0 obj +<< /S /GoTo /D (section.4.6) >> +endobj +192 0 obj +(4.6 TKEY) +endobj +193 0 obj +<< /S /GoTo /D (section.4.7) >> +endobj +196 0 obj +(4.7 SIG\(0\)) +endobj +197 0 obj +<< /S /GoTo /D (section.4.8) >> +endobj +200 0 obj +(4.8 DNSSEC) +endobj +201 0 obj +<< /S /GoTo /D (subsection.4.8.1) >> +endobj +204 0 obj +(4.8.1 Generating Keys) +endobj +205 0 obj +<< /S /GoTo /D (subsection.4.8.2) >> +endobj +208 0 obj +(4.8.2 Signing the Zone) +endobj +209 0 obj +<< /S /GoTo /D (subsection.4.8.3) >> +endobj +212 0 obj +(4.8.3 Configuring Servers) +endobj +213 0 obj +<< /S /GoTo /D (section.4.9) >> +endobj +216 0 obj +(4.9 IPv6 Support in BIND 9) +endobj +217 0 obj +<< /S /GoTo /D (subsection.4.9.1) >> +endobj +220 0 obj +(4.9.1 Address Lookups Using AAAA Records) +endobj +221 0 obj +<< /S /GoTo /D (subsection.4.9.2) >> +endobj +224 0 obj +(4.9.2 Address to Name Lookups Using Nibble Format) +endobj +225 0 obj +<< /S /GoTo /D (chapter.5) >> +endobj +228 0 obj +(5 The BIND 9 Lightweight Resolver) +endobj +229 0 obj +<< /S /GoTo /D (section.5.1) >> +endobj +232 0 obj +(5.1 The Lightweight Resolver Library) +endobj +233 0 obj +<< /S /GoTo /D (section.5.2) >> +endobj +236 0 obj +(5.2 Running a Resolver Daemon) +endobj +237 0 obj +<< /S /GoTo /D (chapter.6) >> +endobj +240 0 obj +(6 BIND 9 Configuration Reference) +endobj +241 0 obj +<< /S /GoTo /D (section.6.1) >> +endobj +244 0 obj +(6.1 Configuration File Elements) +endobj +245 0 obj +<< /S /GoTo /D (subsection.6.1.1) >> +endobj +248 0 obj +(6.1.1 Address Match Lists) +endobj +249 0 obj +<< /S /GoTo /D (subsubsection.6.1.1.1) >> +endobj +252 0 obj +(6.1.1.1 Syntax) +endobj +253 0 obj +<< /S /GoTo /D (subsubsection.6.1.1.2) >> +endobj +256 0 obj +(6.1.1.2 Definition and Usage) +endobj +257 0 obj +<< /S /GoTo /D (subsection.6.1.2) >> +endobj +260 0 obj +(6.1.2 Comment Syntax) +endobj +261 0 obj +<< /S /GoTo /D (subsubsection.6.1.2.1) >> +endobj +264 0 obj +(6.1.2.1 Syntax) +endobj +265 0 obj +<< /S /GoTo /D (subsubsection.6.1.2.2) >> +endobj +268 0 obj +(6.1.2.2 Definition and Usage) +endobj +269 0 obj +<< /S /GoTo /D (section.6.2) >> +endobj +272 0 obj +(6.2 Configuration File Grammar) +endobj +273 0 obj +<< /S /GoTo /D (subsection.6.2.1) >> +endobj +276 0 obj +(6.2.1 acl Statement Grammar) +endobj +277 0 obj +<< /S /GoTo /D (subsection.6.2.2) >> +endobj +280 0 obj +(6.2.2 acl Statement Definition and Usage) +endobj +281 0 obj +<< /S /GoTo /D (subsection.6.2.3) >> +endobj +284 0 obj +(6.2.3 controls Statement Grammar) +endobj +285 0 obj +<< /S /GoTo /D (subsection.6.2.4) >> +endobj +288 0 obj +(6.2.4 controls Statement Definition and Usage) +endobj +289 0 obj +<< /S /GoTo /D (subsection.6.2.5) >> +endobj +292 0 obj +(6.2.5 include Statement Grammar) +endobj +293 0 obj +<< /S /GoTo /D (subsection.6.2.6) >> +endobj +296 0 obj +(6.2.6 include Statement Definition and Usage) +endobj +297 0 obj +<< /S /GoTo /D (subsection.6.2.7) >> +endobj +300 0 obj +(6.2.7 key Statement Grammar) +endobj +301 0 obj +<< /S /GoTo /D (subsection.6.2.8) >> +endobj +304 0 obj +(6.2.8 key Statement Definition and Usage) +endobj +305 0 obj +<< /S /GoTo /D (subsection.6.2.9) >> +endobj +308 0 obj +(6.2.9 logging Statement Grammar) +endobj +309 0 obj +<< /S /GoTo /D (subsection.6.2.10) >> +endobj +312 0 obj +(6.2.10 logging Statement Definition and Usage) +endobj +313 0 obj +<< /S /GoTo /D (subsubsection.6.2.10.1) >> +endobj +316 0 obj +(6.2.10.1 The channel Phrase) +endobj +317 0 obj +<< /S /GoTo /D (subsubsection.6.2.10.2) >> +endobj +320 0 obj +(6.2.10.2 The category Phrase) +endobj +321 0 obj +<< /S /GoTo /D (subsection.6.2.11) >> +endobj +324 0 obj +(6.2.11 lwres Statement Grammar) +endobj +325 0 obj +<< /S /GoTo /D (subsection.6.2.12) >> +endobj +328 0 obj +(6.2.12 lwres Statement Definition and Usage) +endobj +329 0 obj +<< /S /GoTo /D (subsection.6.2.13) >> +endobj +332 0 obj +(6.2.13 masters Statement Grammar) +endobj +333 0 obj +<< /S /GoTo /D (subsection.6.2.14) >> +endobj +336 0 obj +(6.2.14 masters Statement Definition and Usage) +endobj +337 0 obj +<< /S /GoTo /D (subsection.6.2.15) >> +endobj +340 0 obj +(6.2.15 options Statement Grammar) +endobj +341 0 obj +<< /S /GoTo /D (subsection.6.2.16) >> +endobj +344 0 obj +(6.2.16 options Statement Definition and Usage) +endobj +345 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.1) >> +endobj +348 0 obj +(6.2.16.1 Boolean Options) +endobj +349 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.2) >> +endobj +352 0 obj +(6.2.16.2 Forwarding) +endobj +353 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.3) >> +endobj +356 0 obj +(6.2.16.3 Dual-stack Servers) +endobj +357 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.4) >> +endobj +360 0 obj +(6.2.16.4 Access Control) +endobj +361 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.5) >> +endobj +364 0 obj +(6.2.16.5 Interfaces) +endobj +365 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.6) >> +endobj +368 0 obj +(6.2.16.6 Query Address) +endobj +369 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.7) >> +endobj +372 0 obj +(6.2.16.7 Zone Transfers) +endobj +373 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.8) >> +endobj +376 0 obj +(6.2.16.8 Bad UDP Port Lists) +endobj +377 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.9) >> +endobj +380 0 obj +(6.2.16.9 Operating System Resource Limits) +endobj +381 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.10) >> +endobj +384 0 obj +(6.2.16.10 Server Resource Limits) +endobj +385 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.11) >> +endobj +388 0 obj +(6.2.16.11 Periodic Task Intervals) +endobj +389 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.12) >> +endobj +392 0 obj +(6.2.16.12 Topology) +endobj +393 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.13) >> +endobj +396 0 obj +(6.2.16.13 The sortlist Statement) +endobj +397 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.14) >> +endobj +400 0 obj +(6.2.16.14 RRset Ordering) +endobj +401 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.15) >> +endobj +404 0 obj +(6.2.16.15 Tuning) +endobj +405 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.16) >> +endobj +408 0 obj +(6.2.16.16 Built-in server information zones) +endobj +409 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.17) >> +endobj +412 0 obj +(6.2.16.17 The Statistics File) +endobj +413 0 obj +<< /S /GoTo /D (subsection.6.2.17) >> +endobj +416 0 obj +(6.2.17 server Statement Grammar) +endobj +417 0 obj +<< /S /GoTo /D (subsection.6.2.18) >> +endobj +420 0 obj +(6.2.18 server Statement Definition and Usage) +endobj +421 0 obj +<< /S /GoTo /D (subsection.6.2.19) >> +endobj +424 0 obj +(6.2.19 trusted-keys Statement Grammar) +endobj +425 0 obj +<< /S /GoTo /D (subsection.6.2.20) >> +endobj +428 0 obj +(6.2.20 trusted-keys Statement Definition and Usage) +endobj +429 0 obj +<< /S /GoTo /D (subsection.6.2.21) >> +endobj +432 0 obj +(6.2.21 view Statement Grammar) +endobj +433 0 obj +<< /S /GoTo /D (subsection.6.2.22) >> +endobj +436 0 obj +(6.2.22 view Statement Definition and Usage) +endobj +437 0 obj +<< /S /GoTo /D (subsection.6.2.23) >> +endobj +440 0 obj +(6.2.23 zone Statement Grammar) +endobj +441 0 obj +<< /S /GoTo /D (subsection.6.2.24) >> +endobj +444 0 obj +(6.2.24 zone Statement Definition and Usage) +endobj +445 0 obj +<< /S /GoTo /D (subsubsection.6.2.24.1) >> +endobj +448 0 obj +(6.2.24.1 Zone Types) +endobj +449 0 obj +<< /S /GoTo /D (subsubsection.6.2.24.2) >> +endobj +452 0 obj +(6.2.24.2 Class) +endobj +453 0 obj +<< /S /GoTo /D (subsubsection.6.2.24.3) >> +endobj +456 0 obj +(6.2.24.3 Zone Options) +endobj +457 0 obj +<< /S /GoTo /D (subsubsection.6.2.24.4) >> +endobj +460 0 obj +(6.2.24.4 Dynamic Update Policies) +endobj +461 0 obj +<< /S /GoTo /D (section.6.3) >> +endobj +464 0 obj +(6.3 Zone File) +endobj +465 0 obj +<< /S /GoTo /D (subsection.6.3.1) >> +endobj +468 0 obj +(6.3.1 Types of Resource Records and When to Use Them) +endobj +469 0 obj +<< /S /GoTo /D (subsubsection.6.3.1.1) >> +endobj +472 0 obj +(6.3.1.1 Resource Records) +endobj +473 0 obj +<< /S /GoTo /D (subsubsection.6.3.1.2) >> +endobj +476 0 obj +(6.3.1.2 Textual expression of RRs) +endobj +477 0 obj +<< /S /GoTo /D (subsection.6.3.2) >> +endobj +480 0 obj +(6.3.2 Discussion of MX Records) +endobj +481 0 obj +<< /S /GoTo /D (subsection.6.3.3) >> +endobj +484 0 obj +(6.3.3 Setting TTLs) +endobj +485 0 obj +<< /S /GoTo /D (subsection.6.3.4) >> +endobj +488 0 obj +(6.3.4 Inverse Mapping in IPv4) +endobj +489 0 obj +<< /S /GoTo /D (subsection.6.3.5) >> +endobj +492 0 obj +(6.3.5 Other Zone File Directives) +endobj +493 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.1) >> +endobj +496 0 obj +(6.3.5.1 The \044ORIGIN Directive) +endobj +497 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.2) >> +endobj +500 0 obj +(6.3.5.2 The \044INCLUDE Directive) +endobj +501 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.3) >> +endobj +504 0 obj +(6.3.5.3 The \044TTL Directive) +endobj +505 0 obj +<< /S /GoTo /D (subsection.6.3.6) >> +endobj +508 0 obj +(6.3.6 BIND Master File Extension: the \044GENERATE Directive) +endobj +509 0 obj +<< /S /GoTo /D (chapter.7) >> +endobj +512 0 obj +(7 BIND 9 Security Considerations) +endobj +513 0 obj +<< /S /GoTo /D (section.7.1) >> +endobj +516 0 obj +(7.1 Access Control Lists) +endobj +517 0 obj +<< /S /GoTo /D (section.7.2) >> +endobj +520 0 obj +(7.2 chroot and setuid \(for UNIX servers\)) +endobj +521 0 obj +<< /S /GoTo /D (subsection.7.2.1) >> +endobj +524 0 obj +(7.2.1 The chroot Environment) +endobj +525 0 obj +<< /S /GoTo /D (subsection.7.2.2) >> +endobj +528 0 obj +(7.2.2 Using the setuid Function) +endobj +529 0 obj +<< /S /GoTo /D (section.7.3) >> +endobj +532 0 obj +(7.3 Dynamic Update Security) +endobj +533 0 obj +<< /S /GoTo /D (chapter.8) >> +endobj +536 0 obj +(8 Troubleshooting) +endobj +537 0 obj +<< /S /GoTo /D (section.8.1) >> +endobj +540 0 obj +(8.1 Common Problems) +endobj +541 0 obj +<< /S /GoTo /D (subsection.8.1.1) >> +endobj +544 0 obj +(8.1.1 It's not working; how can I figure out what's wrong?) +endobj +545 0 obj +<< /S /GoTo /D (section.8.2) >> +endobj +548 0 obj +(8.2 Incrementing and Changing the Serial Number) +endobj +549 0 obj +<< /S /GoTo /D (section.8.3) >> +endobj +552 0 obj +(8.3 Where Can I Get Help?) +endobj +553 0 obj +<< /S /GoTo /D (appendix.A) >> +endobj +556 0 obj +(A Appendices) +endobj +557 0 obj +<< /S /GoTo /D (section.A.1) >> +endobj +560 0 obj +(A.1 Acknowledgments) +endobj +561 0 obj +<< /S /GoTo /D (subsection.A.1.1) >> +endobj +564 0 obj +(A.1.1 A Brief History of the DNS and BIND) +endobj +565 0 obj +<< /S /GoTo /D (section.A.2) >> +endobj +568 0 obj +(A.2 General DNS Reference Information) +endobj +569 0 obj +<< /S /GoTo /D (subsection.A.2.1) >> +endobj +572 0 obj +(A.2.1 IPv6 addresses \(AAAA\)) +endobj +573 0 obj +<< /S /GoTo /D (section.A.3) >> +endobj +576 0 obj +(A.3 Bibliography \(and Suggested Reading\)) +endobj +577 0 obj +<< /S /GoTo /D (subsection.A.3.1) >> +endobj +580 0 obj +(A.3.1 Request for Comments \(RFCs\)) +endobj +581 0 obj +<< /S /GoTo /D (subsection.A.3.2) >> +endobj +584 0 obj +(A.3.2 Internet Drafts) +endobj +585 0 obj +<< /S /GoTo /D (subsection.A.3.3) >> +endobj +588 0 obj +(A.3.3 Other Documents About BIND) +endobj +589 0 obj +<< /S /GoTo /D [590 0 R /FitH ] >> +endobj +592 0 obj << +/Length 221 +/Filter /FlateDecode +>> +stream +xÚOKA Åïû)rlÁ‰“Ý™£¥* +ö s“ Öv*…îÖêçw¶[‹ É!$ùñ y¾A0ôê¨hž ÖmåáÜî+:3j‚¦"eøãê$ +• +endobj +590 0 obj << +/Type /Page +/Contents 592 0 R +/Resources 591 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +>> endobj +593 0 obj << +/D [590 0 R /XYZ 85.0394 794.5015 null] +>> endobj +594 0 obj << +/D [590 0 R /XYZ 85.0394 769.5949 null] +>> endobj +591 0 obj << +/Font << /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +604 0 obj << +/Length 302 +/Filter /FlateDecode +>> +stream +xÚµ’ÁNÃ0 @ïýŠ Wiõ ;N–+CãºÞ4º±ÃZÔ¡ý= ekCì‚zˆ-?ÙÉ«µÂði%¬'¯œ7 ¨Ev ªM¨Ý%ú‹1 †9$ª»)’„ÈÀ4tR?hÍÈìTæăeâˆßÉdfXyð–¬*ÖJ³ƒxŸU<?ŒòúõÐl7/múXÜ+Apèõ€;` “™6ƒN³> pËкC¿%!šqš‘` ¥‹æU[6UÙvÙâ°oËݾKòºÚ×M»}Ûì +ÒŒ5†y‚K"3_äñ©Žã“Ûâd&ŠkrF‡âåOŸt6Ä/kã|ßõ7ôŸ ±÷¨ûú/Ú×íûS“êé¨<W çþŽ›ÌqW¯ÞãÊ´Jendstream +endobj +603 0 obj << +/Type /Page +/Contents 604 0 R +/Resources 602 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +>> endobj +605 0 obj << +/D [603 0 R /XYZ 56.6929 794.5015 null] +>> endobj +602 0 obj << +/Font << /F43 600 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +611 0 obj << +/Length 2204 +/Filter /FlateDecode +>> +stream +xÚÝYKã6¾ûWø¨ÆZ>ÄWn;3›Å‹Yìv9$9¨%¶-Œ,)ztÇùõ[d‘¶lË3ƒ6X4ЦJ,²XõÕWE›® üѵ)á&[+“¥‚P±.ö+²Þ»¿¯h˜“ žŠŒsxXx»\§B3µÞÌyû°úË÷[3’JÉÄúá鸗T:5<3ë‡òçäÝ.ïFÛßm˜ ½ûõáTËR¥uj¶©2D{…ÍØ·åTŒUÛ„é|mR#™Œ³è‚¹nöÃÎÂÒZ:5Û7vħ÷í>¯ Ì÷aÎýaí Ç¿AÞ¼‡ê*)Úf¨†qÀ×í~ŽqýáÐŒùïAØYg‹êép1³ý.V±ÍXJURÝѤÁ¡S‚3ºSQš!XôA8 g$qáŒ&9>î*Ûçý ÕI±«Š¼Fé>op³Ê’7 àíqoú;LµÛÜ-2
¶DùSÛã ´µÝæcÕlÃ>Ó¸kûj3(iŸm˜ëvÈ›°RØŠ‚“¼ƒÏNDý‰ª}WÛ=ø!÷qÝ00tÜå.\J$y1Ny] P¾Ï»GÑ•0Åû D³8;Ųôž°Ã`‡ŒÐ<¨âÔ2 sœV
qå +,¨ç÷ì!â–ÁÇ_«:”BôbSHúêqý"b) Nê6̽Uó4Ky&Y@qFR&9bž¦ +.ƒpŽ(£cžÀØeÄÛ ß‡” +Îzè°Ÿ-&¸ +D’m<ìpҡèàíƵáGó¿sVþöpüöÆHh5]S¡S"¡•+ö«ßV?ÿJÖ劬X‘”-Ö/ð +ûUÆaH„Ž’zu¿úש혵7-@=k…aõùR›x¦
Í$l©éñû¨ 8ó”r“J“…{ŽošÂ %Ö¼+·q&R˜§×ó-¾Íêã’_0›CØieÎÍþéñ&\†ñP_ B¸ÎX +ñŠ‡È\:4W› û¿ƒãPé¡Kÿú3E›pbøÏðÓ×›|N®ÁÌmrǯÜÀÇû"ÄÑmÆáFOXm–üøï¼Á™»vg3×êX×.¾8¨H1ºa¾¿ú†Ë}c_l¿?:ÖÛˆžòÛ 7Cô¥ç„ZDôÌsßW¿;Ž•@¿/U9înƒ÷Õìý7ú¹èI¾ +endobj +610 0 obj << +/Type /Page +/Contents 611 0 R +/Resources 609 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +>> endobj +612 0 obj << +/D [610 0 R /XYZ 85.0394 794.5015 null] +>> endobj +6 0 obj << +/D [610 0 R /XYZ 85.0394 769.5949 null] +>> endobj +613 0 obj << +/D [610 0 R /XYZ 85.0394 582.8476 null] +>> endobj +10 0 obj << +/D [610 0 R /XYZ 85.0394 512.9824 null] +>> endobj +614 0 obj << +/D [610 0 R /XYZ 85.0394 474.7837 null] +>> endobj +14 0 obj << +/D [610 0 R /XYZ 85.0394 399.5462 null] +>> endobj +615 0 obj << +/D [610 0 R /XYZ 85.0394 363.8828 null] +>> endobj +18 0 obj << +/D [610 0 R /XYZ 85.0394 223.0066 null] +>> endobj +619 0 obj << +/D [610 0 R /XYZ 85.0394 190.9009 null] +>> endobj +620 0 obj << +/D [610 0 R /XYZ 85.0394 170.4169 null] +>> endobj +621 0 obj << +/D [610 0 R /XYZ 85.0394 158.4617 null] +>> endobj +609 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +630 0 obj << +/Length 3297 +/Filter /FlateDecode +>> +stream +xÚÍZÝsÛÆ×_ÁGhÆDï8àúæÄv£ÌÄN-u2m’ +·ú]ù=ÛüTæýÃóÚ"FìŸ\]FB'_W—T°› xð˜ ÊlS¨®F\üyue,ÄÇ(¿®+±6¦4óÁ…»¬ò‘°=öpqðóݵUAñ¥ç9Ž‰E½šYìì> 'ÑusȶŸŠ¾ûõYŽyý£4zÎ0ÿðª„
Ó’ÒLk=Nu³”§’4ŒR
)Ï€ý4$ë³Õ@Ô(ÔäÃQÎ3°«° 9†`'~;d¿7Í>óæxŸí™zûÔõÅ~ÜÕ˜¸dOØÄŽ²jª‚öxh‰SIˆýƒó äÍö¸‡4Kt¢Â|C³Å—¶"®ÜK¼KYw}VU>sÂTVç48¶ŸŠ¢½<Œßãô ¤®Ùõ§³Ç!›àpÙ}ñ +%g:”…vQpÂÅàÛ›âÞ1¤Í‘h¯Ç²` +ßV%˜ÞÅî8¨šæŽ-='*%=rÅÞL°¹–Á
Á”ÃlpcN³f’f!$§&â4ËÚl*ÐÙ‚ j
)AK^\•<O%¾¢óNà=tZWÔ9KóùX Jg ˜mĦf¾›=÷ìC \®•Ñ¡²6ö:§œX“·»Ãhå–!(§ŠÅ9¼h§<°MKç¡ÎµW$X -XªèÐÓUÌ·-Ž9²áÈòÑ“ +^
±c$<‹0q7|9_²Õ†å}žW³kö'Fó;; +¬´Ä‚T*L’T
_Å’º#H¸Âª‘¾v—‹17ûÍ6e½( ¤V!ý^‹au¢$Œ5:ÆexU>¼ºðØ]hâ2%àšQ¸• + +^OaÝÇ…¥ºðˆ¢©+Æßp©KHª4>•€ñ9”•=º–o~Íðƒ ox¼Ã{©¥… Û·^& + v}¬ÏX0Ú¹w”ð«á(ã'A…ý·}›ÕKaNÅ +®ˆðNóvrüM½
—J”¿šÛæXåtÞ¦Xh"D°’Œ6Ë*d!C`ka{GR7Ÿ<3–¡ˆaÁÄ3O Gx%™ªdàré(È‚V¤^ôniSR”¬àZ-Qªâ=‡ÞnaCëqÍY‰¡²õ±®9 ÐF/ˆ/e Æ‘õ™\±©ï="˜l¯1’ +/!ﺄt˜Ê!âz)3â½;nÎ1Bfš„IES=Ãå\Ü J^P0Öö*C¡{Ò +B†Oƒ³qù°à®ié ŽÁtáK4¼ Ý «&÷cT¤Á à±þÂ…ãŠ
Ûýç›e8 ÀµÓÈxV‡eí¦o¶MµT«AôUƒ€¡ +2”6¾¸/d€$e8Ž£¬ëšmÉ)~c^¤›#9GP ³aäŒÏ‰1Î+{£
Qir_T©ÑPýø"ëHÞƒ¨€¬óE Ÿ +nÏ´ 1Ì )*¡q<u´îض͡÷þµÀÓ@õhŸ-ûÔKŸãü‡ ³Ã^4ŽU1 ‚©‚úÍJ)±[Js‡û
>NÚ«´|=^?ï‰ÏvEán‹íù› ÔL¡¼d!¿”JN¸™µx‡U/01ßmä¨*´!ZDWæÜÞp•V^¸¸QVT‰%-3¬¾è +N +JÐ}y_s5·[®6¹æʹÙÔø: 5 +ê<eX¿ ¿0·Ò|ß™¯¼^òñÒ)'üÌ?øU/p1ßíù.rlMªæ] Í]Œ=“{§= +ü„6ÓC¨m‹ÖHÁ±kXke nׂÐbÒƒ‚âK špxÞ(÷G²šÉ=Ÿe;¤ž|NsºÀA^îƒ gÖzË'oŠþT`y†‹–Ò\$L˜¥G¨c tH@ª‰œ4öžÙЕ–PœG‹µøKå¿¿ÝLäËM +º±±ûZÑô@r µþ;Esì*בå>i¤ `À5”RñÍ’wÊègÛ”NÑ@q÷ HyQ÷>>Xêÿ"n¹ÿë(Ü”pêLGõg¹nd³#:ííOüv´pͱyYÞ A jà¶x$F‹ g"^sîF™‰C[ g%MšÅQ<¦ñ
]¢>d|ȶ±ÐpŸ]bsÙ÷Ýl*oÒ ‚õ„Úx{ê:8”=YÊ!½Ø}âÀUç®[êZ-ˆÿ1¹¡8‘Áà¹i +endobj +629 0 obj << +/Type /Page +/Contents 630 0 R +/Resources 628 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +/Annots [ 640 0 R 641 0 R ] +>> endobj +640 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [272.8897 231.1055 329.1084 243.1651] +/Subtype /Link +/A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >> +>> endobj +641 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [190.6691 203.5826 249.6573 212.9922] +/Subtype /Link +/A << /S /GoTo /D (rfcs) >> +>> endobj +631 0 obj << +/D [629 0 R /XYZ 56.6929 794.5015 null] +>> endobj +635 0 obj << +/D [629 0 R /XYZ 56.6929 756.8229 null] +>> endobj +636 0 obj << +/D [629 0 R /XYZ 56.6929 744.8677 null] +>> endobj +22 0 obj << +/D [629 0 R /XYZ 56.6929 651.295 null] +>> endobj +637 0 obj << +/D [629 0 R /XYZ 56.6929 612.4036 null] +>> endobj +26 0 obj << +/D [629 0 R /XYZ 56.6929 567.3837 null] +>> endobj +638 0 obj << +/D [629 0 R /XYZ 56.6929 542.6255 null] +>> endobj +30 0 obj << +/D [629 0 R /XYZ 56.6929 441.1968 null] +>> endobj +639 0 obj << +/D [629 0 R /XYZ 56.6929 415.1634 null] +>> endobj +34 0 obj << +/D [629 0 R /XYZ 56.6929 188.7253 null] +>> endobj +642 0 obj << +/D [629 0 R /XYZ 56.6929 161.3171 null] +>> endobj +628 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +647 0 obj << +/Length 3284 +/Filter /FlateDecode +>> +stream +xÚ¥ZKsÛF¾ëWð¶TÕ™f +>悺¾ßó=ñä-„¸Éüò~T”¡Òå6¯™tÈ<€· 馻†‰9ÿ´eýPÉ›ì¾*:YnúŽUe@Vk¼
ªÒâ_}µ»]Y—yÕ6<;àƒ3 ù˜Ÿ: 5÷ò +ÿ aR>½xºÕé²h/^‘xÂá„÷FÞKBîD 6=ñÃŽGmqz*N-‡:÷€·0CŠrò‚Q~I!Øi +ì(ÏÀ¸kŽåv?¬I6IiùZª…UjùýûoxÄü zçUE®8ƒ +t6ƒôÎ.žEÛœ ˜®ý"´†)ÐPÖ 'Y >sú®Ø@1çLä 8 +N]6öÌšbó g&r™¦Öž'O |žöäaýjúÂuO~½/Jð¥Ø²êW±…–êÂù†¼g#éèêB[zOqª Ñ÷zöÖ`Xµš.»–ðz7Ñ‘ŽfÔ
¥12Ô-Æp0“Ú1ß‚ œq‚ü?¨xᇠ¾™iS$ÉU*œ¤ œ~ÆÂ+u)d¤PÆÛæøÂÓ„^’$,ó!IÒ^€ç°Jbº¤¤>¡¨K6ºÎæ1š; <í( +`S‡¹3k ^S Ôd
gh&øäIL½Il9©A’oKHá¨âؼ"8žÎŒ»é²2‘ . ":ï;æR5ù® ™MúìXSuÀ—“,ˆòTâ=@< ¸ —»’šU¤o^øwß òZ¶ ÷ÚAJô…úŽìûü(IE
õ…w„àPl÷y]n²à‚i’Žƒx@$‡Ã )Ì’y¸Çb솤Ax“ð0Ç“¤ÐËÂëâP3hyÞ”ÚGÐwøó[ º±¤½glê" 'á…f#ê(õ.´È!z¾ºk¬#§\e&M "I- FòD<ÉFòÄƉ ‡qv@4%ÀPÌ f’BK@H½ªL )FÒÌÄ!ä` + ‰\ù€uó\ ú›»‹ÐÊE&KÆ lvó¡ÛbÜœóäzO ²¡®×˜€äFTŠ˜®–Úb1¢ÓËëP‰T ù +–Úñ S;É´v¬Ç@Ι‰÷XA\u·zI éGÞp[´Â!è·oÃת1ø©KÝ™cãâ b{?› ØÅÇzÌWÎgˆBÕòåâ݆û
ÜKò<Š"…ƒµ£{Ážçñ'Œy%R¨%?Êbr†ø’€¶’dH²ô !%©;é>‘Öl“ú‚¿rׂ4m[n(]$rQ‰5'hƒßêæd¬ˆSäÓ˜‰ + f²}¿¾ewÅk<A{syFÍáòKWäU·ÿ‹æ—6ô·´YU8H?811ÐGÿÖʪ‹ä&HŸæ âǶ|9 tí¿„‡]ˆ«m0ÄtQpd‡È×aD#{k1=¶Å°çŒ½¯8`s€ß‚º²ë;iæB4M +>ðű„€q™°? BBGÏ$3)ɶN.Žq +,õ@ž/$½ ñŸI:,ºHˆ>\)H÷R§oó…, È8šÊ/>R"<ã7$a RÚ…ÛɧaÝ”µé¹ÛÂN‰
_º‘o}K ¦è Hz,Š#£áãH:t6ôžH¤( ? „µRבõ±(äƒMä©|Ë Š>¬4²<|i\ÃΔ âxš½ÕjB5~ ŵ ÃM
|á„RæCEÊË*ß„ò= €%ól¼¸jÆï#e^ÉUÖx»Æ¬ÚyþùTR€ +¤ „H¯DÃÊhuy¿ÄÄÉÅ>2/& MO‹žÀ =A;ZT¢Éà²Á›.ß‘uÍ}Wˆ ,À¾Ô´ 'þ6Œ¨}¹Ûõ\§(b‹J!.éÞÅËO\Ïbôd °¶½“ÏX3¯2‘'\ç +À‚I£Ê€:¨lòΦؗtË$dÀ§~FWùÚ—².Xê¾™Z¿¯Gÿ >½m‡ ûü +endobj +646 0 obj << +/Type /Page +/Contents 647 0 R +/Resources 645 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +/Annots [ 650 0 R 651 0 R ] +>> endobj +650 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [519.8432 488.7856 539.579 500.8452] +/Subtype /Link +/A << /S /GoTo /D (diagnostic_tools) >> +>> endobj +651 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [84.0431 477.498 133.308 488.8901] +/Subtype /Link +/A << /S /GoTo /D (diagnostic_tools) >> +>> endobj +648 0 obj << +/D [646 0 R /XYZ 85.0394 794.5015 null] +>> endobj +38 0 obj << +/D [646 0 R /XYZ 85.0394 599.0929 null] +>> endobj +649 0 obj << +/D [646 0 R /XYZ 85.0394 568.7172 null] +>> endobj +42 0 obj << +/D [646 0 R /XYZ 85.0394 457.9037 null] +>> endobj +652 0 obj << +/D [646 0 R /XYZ 85.0394 429.0681 null] +>> endobj +46 0 obj << +/D [646 0 R /XYZ 85.0394 352.2747 null] +>> endobj +653 0 obj << +/D [646 0 R /XYZ 85.0394 326.5176 null] +>> endobj +50 0 obj << +/D [646 0 R /XYZ 85.0394 247.1936 null] +>> endobj +654 0 obj << +/D [646 0 R /XYZ 85.0394 221.4964 null] +>> endobj +645 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F56 618 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +658 0 obj << +/Length 2395 +/Filter /FlateDecode +>> +stream +xڥ˒ã¶ñ>_¡[4UM|VNcï:;.ïl¼# RŽXK‚²HÎDùút£ )q*©Jé@ Ñh4úÝX…ð«$
Ò"*VYI(’UÙÜ…«XûÛ`œCÚL±~ØÞ}ÿSŠ H£tµ=LhåA˜çbµÝÿ¾A Ü…p½ýôñ~%áú×ÏO4~zøÌÐç<o?~¦ñ?Ã$üðô q¿"ÍÂõŸ þ¾ýø•Ö“||Ú~ýòá· ·_žîÿØþ|÷q빞ÞL„Yþóî÷?ÂÕ .øó]È"OVo0 QѪ¹‹$±”Rß=ßýê NVíÖEI‰0ˆ$HåVTq´"(’$šÉ*)‚TFÒË* ‡!ÜW•Çʼ°”T£YJúüªÏ ^HʉôÃÕ&Šƒ"±¥µ=âŽ<^ŸïE¾Ö][Ã>‚ÔÕî¬Î•îhz²íkµ×{‚ì.ômÚ®§Q{ÒgÕ?0í.]¯»?Y+:XJÒ KQ–""à
YêúawËÓÒ]’$ˆ£Hð¾ï`S!×VÆsÐ UïFšÙuŒØ‰i{$¼ÚH)ƒ4ò/~ Yª“ÚÕˆ›Âíô…K ÚsC‡¤–4
C]Ó¬’þ +C_µ†÷“$KÝu°‚$BM§á¶×pUó§í+¢Yöµ[n¯øPClÏÕÆÞ,t7"GëA?¯ˆ—%ëä^¬Ï 8Ši<P˜Ú£$sáD–¹[Øó`›½|-Öm©j‚2@ +åäÿ÷E´ýÈ4_Wóq€Â1®L©Á$ š]3ˆ»:5vG áˆáý‘©°‚‡ºïhýz‡êîèö]fǃÎÓ4Y?WÀƸqÁ´'~e=Hä²q8åÛÚ,)³§µÒ‡P„úà + é8¡‰<b)¢«„†—¤X&Á(tÀ`Ç€ÖØABzAŒvŠO\X¿¤†Y/(UH2D&§¦›HŒc#âg
Fj:”tŽ†ZaÍlñ;úê ÕÐõŽŒclò¦Ð1Ý›UfL*ýÐf OV° »kÞÈ2ßåTaIt¡5Šó¸ðvD‡FØ¥ ´o @Vc$ꎴDF ‡Î˜‹I9€GöŒFÓ—êÕïª~1‡[sM#L½ÐJ”=Íæ5/B(ÊTº*"r±·P‘ËHÑh^f6±¶ˆ³õã’P£ÔóóÖ—‰µWìHh¢ˆ 34;²ÜkM‘·Çt!c‰Ë„úâ‚ Ù,+C€ Ï0Ãì@—|¹ÛÞVúNÏî u+ˆMŽU·êxõ¤Êoºç³ú#Eáåè +E„©/XR.Wn_=˜Iú~†Æ£:ÕŒòµõÿü,’…ë Ÿ>ÐÈõ¶“ö2sB`ÕÀAÊhª¡‡°‡ñ mÌHððiÄy&@h ýCŽÂÔã{lX¬Õ«¾ÚÀùüfõ +7c®ûrún„u謘+Òi+í{Lßf÷s»x¯÷¼j>µoz,)✌{»B¸Â NL‰ÖÑ”ŠwáÞ6Ü3.¹Ú¸JžP4…-|×ﯛ×÷¶Šé[Õµ ëöÅ'Î ·Ôjt¼ˆˆ¨fË9'g…k¥äí „ 6BgØ ç¹vÔ
Z3?p}w’‡ÎßmƒfåÁáÖ/—’’qo9“W=k£éµ€§Ï:é(%£Ù,—Ì¡D$ÝÃÜŒâÆž½ðš‘Y^d®|¶—`3„£ØÍR/+rC”¥7í=,î«s!Wüˆåy”_…zÿâAÑL‘Ÿº*µ«êª¿L
A0uÀ›ò%Ê=_¼#5Œ¬!À—j'$ue¿ +öºD‘äó‡÷ +ÈYÊ%…ÂÜÂÑÔÈhÛ=LÜ1÷t!8Žßbeì}’
€}ú'¥‡Ð7d©¸Š„ µjòr—x¨î˜æ¨ ¯œjUºÆ¦2 ˆ}¯Ë²wþ`€ô…ÿ +,ü úD÷ÿù0þgÌóhü_AÎzÚ0(2é™B±¤7Œ»?)n9ÿÔ‹ö`endstream +endobj +657 0 obj << +/Type /Page +/Contents 658 0 R +/Resources 656 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 601 0 R +>> endobj +659 0 obj << +/D [657 0 R /XYZ 56.6929 794.5015 null] +>> endobj +54 0 obj << +/D [657 0 R /XYZ 56.6929 769.5949 null] +>> endobj +660 0 obj << +/D [657 0 R /XYZ 56.6929 749.4437 null] +>> endobj +58 0 obj << +/D [657 0 R /XYZ 56.6929 609.0996 null] +>> endobj +661 0 obj << +/D [657 0 R /XYZ 56.6929 584.3177 null] +>> endobj +62 0 obj << +/D [657 0 R /XYZ 56.6929 437.466 null] +>> endobj +662 0 obj << +/D [657 0 R /XYZ 56.6929 410.2571 null] +>> endobj +656 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +665 0 obj << +/Length 1888 +/Filter /FlateDecode +>> +stream +xÚ•XK“Û6 ¾çWø¨‰UIÔÃ:6iÚ¦3Ítší©ékÑgõpEÊŽóë -oÔN:> +Œì„SxóþÃ$ý»2ã<í• ý=ëIõj°&˜IóXäeÆfÊ".ÅŽÖÍâôa›&Iý,§æ"'63}mFlê¸.³’ˆ4Îïþ‡ AÌ¢VNé.BCøEc¥ˆˆFƒŽ@£idh²•gEÊv’¶z d×]‰õ¤Ô@h[6×26~ØŠ¼Š~ 'èåÀJz0LH4e^#¯ˆŒšÎjâ%m+-:…n¤i\EæÜà€û¼.P'5°£Žtá@ƒƒógìi$÷V{ýf¶W¢n6Oj:ŒSï-ɦד|êXNúR(à Ça£u¼KÚèc‹6« J|÷–h94D¼ÿí\uPÒÎtCœñ@_N júôòJĉœ:ó +v¤ïý9 +Íž3_·F^¢vß2Ëm @=¦ÂFÍ4F€!g,©£ïÖ‹Hú Ô…ˆ‹Rφ´‚ñ¥É{ìÅI@Á®!šë8ìnåè$÷ØNý;+ß‚ÇO 7Œî®:êÒª‚0è»áª¼›ù|ÒS +½z÷þËòÿP‰"Æÿ»Öþíò"Û› ýÕµDg(°±È’`Ý«^.þ7ûzµ +endobj +664 0 obj << +/Type /Page +/Contents 665 0 R +/Resources 663 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +>> endobj +666 0 obj << +/D [664 0 R /XYZ 85.0394 794.5015 null] +>> endobj +66 0 obj << +/D [664 0 R /XYZ 85.0394 769.5949 null] +>> endobj +667 0 obj << +/D [664 0 R /XYZ 85.0394 573.1436 null] +>> endobj +70 0 obj << +/D [664 0 R /XYZ 85.0394 573.1436 null] +>> endobj +668 0 obj << +/D [664 0 R /XYZ 85.0394 538.4223 null] +>> endobj +74 0 obj << +/D [664 0 R /XYZ 85.0394 433.7668 null] +>> endobj +669 0 obj << +/D [664 0 R /XYZ 85.0394 392.81 null] +>> endobj +78 0 obj << +/D [664 0 R /XYZ 85.0394 329.225 null] +>> endobj +670 0 obj << +/D [664 0 R /XYZ 85.0394 290.8035 null] +>> endobj +82 0 obj << +/D [664 0 R /XYZ 85.0394 191.4678 null] +>> endobj +671 0 obj << +/D [664 0 R /XYZ 85.0394 156.6041 null] +>> endobj +663 0 obj << +/Font << /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +675 0 obj << +/Length 561 +/Filter /FlateDecode +>> +stream +xÚ¥T]o›0}çWø¤áúƒý˜¦´K¥¤)MSׇ4¸ÆÇÚþûl¢tOŠÌ=çúúÜÃu0@êÁ€ùÐD€@x!ÌÀî`!°WÜ…MŽ;&¹Ó¬ëĺºõ PøÄÉ뤇ˆs ’ôÉ&AGU@v¼Y¯ "‡vÞ8.aÈ~X‡ÑÌ <;Y¬î4“p;. ¶ç_gë$Œ4EL¡ëÅÊìÂøaÍÃ1zÜ,¢p®’ØyNî09ö0í#Ú7ðÛzzF UíÞ[RÁxS‚X–Ç(d ¥#’[±õx,8a‡Ÿú†$TytiœG +.â¹ÚáñÑ@/°…vå¡ÊrÙèh[¤ú¥v¸ÝN- Ãê%ßÖæö^j¶è/²ÖTùª×M‘½»yöˤ”ÙŠmÙg'žùæ0fgEZ¾M«D¯W}›}cCÁ˜qJ™¤fƒ*þ¶ìEøD•ìWjw•Û–nºm¥Æó¬i53ÈTH3qWÁZWó¥˜ÝH©áö§)…³›e¨Á ‘ÜàYq–¨^ÊÊ )ÿÈ\ci6¸&wmYhVËÐûÎzÓ÷ç4ìB/MÙ
5vRÇ©j¨Î^º6+ ø¯±§ ö³úɪŸqò¿¯Äé 圜¦}:•„#(zÕwÉ/„WçRù_` éendstream +endobj +674 0 obj << +/Type /Page +/Contents 675 0 R +/Resources 673 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +>> endobj +676 0 obj << +/D [674 0 R /XYZ 56.6929 794.5015 null] +>> endobj +86 0 obj << +/D [674 0 R /XYZ 56.6929 769.5949 null] +>> endobj +677 0 obj << +/D [674 0 R /XYZ 56.6929 744.7247 null] +>> endobj +673 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +680 0 obj << +/Length 1190 +/Filter /FlateDecode +>> +stream +xÚÍW;ã6î÷W[É@D‹¤ž¸j³y )‚ +.AŠ.D‡óøfæ“EW üèªÌH«tUT)ÉšêÓC²:ÀÙ·Ôë¤'YÊ9lN㌗$+Y±Šo|¹}Ø|“²KHž³lµmf_y8\Øb0r\Ç,K"¾þeû=^KIQÔ^KÀENhÅþâ$Qù'9žÃÅgÕHv˜FaZÕ{3|U‘*g¹·’S’EêÌ|×ÃÅ*̱ÕvÅ#-kwÕ‰/ŸÃ¸¦e¤Îkµ{/ÓêVÓá µ‘{´Pß¡QItª?x«9¢êas]ÛK¯Ô¨ÌQ¶#Ê&-É:NS½_W,’ÁœV6=›¥¤Ê2æû½‹Uj€%¿PC[ãR5øDM¡U/vWSƒO ÖZÓö2—ƒ¦„§9ó@¦”äIE_Nè:¦Iõ§!{~
Ål(„ì qJXî ͦž¼Q !ŒXõÝ JÞT±Ð,³ý…¸l- <Ï +¡Ä¸ØyýºkeoôRÛ Æ¤ (fÕ>Sç9³áƒÂСgr–FO×üu’ckûÌnÌã„;5íÚÚZ +®Ý‰ÀÁ
®vª“Fm +ó:ó= |ïß;O“9ª¦ÎÎö¿¤}GÞ´rDïX F÷-˃*–ž•A üXˆÆ*ÎT:æ( Jƒ?W{»@àß^™ý|`,] Ž4ÉHÁàˆ„(s F ‡w€×Àèo!¡©8+½ ç
¯÷\'<ÏuâìáÅÿ!wT:íöê$Z_¡¿ˆ™Be“„ç!føïâ^Ž¬ào!¿m‰CÁe5€B=—Òÿ1ëˆþåJ8q™ÞÇn´«ðœb/1ufi<!†iÔ®OÃÌÅ”³»_©pdp1Üò•¿oèÁ¶–‹ 'MøÌ…ìŸráÃ×Ûù»$|mðŒØo—¥/— _uð³å¶SyR +endobj +679 0 obj << +/Type /Page +/Contents 680 0 R +/Resources 678 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +>> endobj +681 0 obj << +/D [679 0 R /XYZ 85.0394 794.5015 null] +>> endobj +90 0 obj << +/D [679 0 R /XYZ 85.0394 769.5949 null] +>> endobj +682 0 obj << +/D [679 0 R /XYZ 85.0394 575.896 null] +>> endobj +94 0 obj << +/D [679 0 R /XYZ 85.0394 529.2011 null] +>> endobj +683 0 obj << +/D [679 0 R /XYZ 85.0394 492.9468 null] +>> endobj +98 0 obj << +/D [679 0 R /XYZ 85.0394 492.9468 null] +>> endobj +684 0 obj << +/D [679 0 R /XYZ 85.0394 466.0581 null] +>> endobj +102 0 obj << +/D [679 0 R /XYZ 85.0394 237.1121 null] +>> endobj +685 0 obj << +/D [679 0 R /XYZ 85.0394 206.4074 null] +>> endobj +678 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +688 0 obj << +/Length 1948 +/Filter /FlateDecode +>> +stream +xÚÍXëÛ6ÿî¿BØO23|I¢.Ÿ6¯v‹d“sÜ.Š^?h-îZˆ ®$ïvïÐÿ½C)Ë^9›Þ¸Â€5$‡ÃáÃy~,ˆb§<
’T’ˆ²(XW3ÜÂØw3æxži1æz¹š=ó %iÌã`u3’¥UŠ«ü—PAæ †—çïßÌ<¢á§7Ëy…?ÁǶ?||³<Ÿ'2\]|¸ü4_$4•á«ïÏ?®<ÇÓ2^}¸|{ñÝ{9ó_W?ÌÞ¬†]Œwʨ0[ømö˯4ÈaÃ?Ì(©Š‚{hPÂÒ”ÕLF‚DRßSÎ>Íþ9 Ú©“È1J¸ +:ýÀ²¦ÜeVi2 $$\Ù·f"WÂ_àgÐJyXܘ^>4sîÞX»7¼ý•Ð8puu…ýƒÓ0û¢ßàxûû¦ýŒÝÆ°ìdt?f¼¹Á!1æÇœ®Éݼ:Gn×-žMú@JP¤G ÍpíÖ¤2Û¹S¡Oã°ð Yip\Hö›ÌÉ^—…®{×}_”¥ënêZ¯ q–æ«3¿Teì¡vË4žè7ª†zxµ>§Ù•þÇqZ@ZP ˆ2–~]^À ò+¥ó‚ÿn–×c¤ëI
p YŽô3E-üž"fDÄ’
IÇÁ V‚P‹ +&Ã¥îš=€µF—± ŒÛÿ¢].áŸaûuÖgÇ' x˜FÁXÛÿ
+<¯ŠºèzÀ—hƒ NÑ7xn¦Ýã^-Ç߸ïÆ+òÐ-&Ë3ú¸âã…±Ìæ? Lì1h–eÎÈÚ™ƒu®1šëÝímáûX j(ÿüd¹-°`ÿÊÇ«9”ÏÚ‹AÛóS v¦aMÝŠ.º©(ÓA[àiM9¹™˜¼Ã4x2õüÚ·é½S’ Üŧ½Á)9¥ì!}¤¹Ä~¬úŸ<SÝendstream +endobj +687 0 obj << +/Type /Page +/Contents 688 0 R +/Resources 686 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +/Annots [ 693 0 R ] +>> endobj +693 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 208.0574 126.0739 220.117] +/Subtype /Link +/A << /S /GoTo /D (rrset_ordering) >> +>> endobj +689 0 obj << +/D [687 0 R /XYZ 56.6929 794.5015 null] +>> endobj +106 0 obj << +/D [687 0 R /XYZ 56.6929 492.2203 null] +>> endobj +690 0 obj << +/D [687 0 R /XYZ 56.6929 453.7474 null] +>> endobj +691 0 obj << +/D [687 0 R /XYZ 56.6929 385.673 null] +>> endobj +692 0 obj << +/D [687 0 R /XYZ 56.6929 373.7178 null] +>> endobj +110 0 obj << +/D [687 0 R /XYZ 56.6929 177.8714 null] +>> endobj +694 0 obj << +/D [687 0 R /XYZ 56.6929 136.2124 null] +>> endobj +114 0 obj << +/D [687 0 R /XYZ 56.6929 136.2124 null] +>> endobj +695 0 obj << +/D [687 0 R /XYZ 56.6929 109.3045 null] +>> endobj +686 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +699 0 obj << +/Length 2677 +/Filter /FlateDecode +>> +stream +xÚÕZÝsÛ¸÷_¡—N¥éÅA°O—Ë%×ÜÌ%×Äi ÒÌ”– ‹w©);Îôï À$EJÎø©ãàò·ËÅ~f3 +l¦SBE.gY.IJY:[î®èìžýtÅ<Mˆ’.Õ×W}ø,'¹âjv½î`iBµf³ëÕ§ùË¿¿øõúÕûEÂS:d‘¤ŠÎß¾øå®|€Gi:ÿg xùîíë7?}|ÿb‘Éùõ›woIFs o^~÷ݯ¯ ßû°ø|ýóÕ«ëøÝ/eTØOøãêÓg:[Áÿ|E‰Èu:»‡ %,Ïùlw%SAR)DXÙ^}¸úGì<u¯Ži.š¤šg#ª“£ªKs¢Nuö›a‹„QJç?–ÅmU7m¹Ä¯½^0Ææu½mì—žèàÑYÂÉy–;¤ëñD]¦,'4eVVK³*oG€˜$¹ÚÓ|7‚"‰ÖÀ 6 àJN„ÊxDI¸dó¢ZÀqØ ®¥'šm]ÿ~Ü`Ê´Ï2O¸?,˜ž×·‡b× +;ÏÉÓ”õ?à¦Êµ•jm8/+ümÚ‡Á!JƒúØî-ŽA¨]Ñ’›¦°ƒàhJç`\9÷^O”t©¦M0RuŒ¢Ë3‡W´àçy¢ž=» `^J¦}¦ÖZN³ùªÞNCTƒ¦Pe]áÃ[Üñ½S%ÌÿMS:fäR°6ñ
VH 1Ë™·A¢µo7²›Ò¸] +Ü5XÛoMëéëuhü’7h7vfqçjþÆoŠÆÛR +’S¡ú¶ÔÞ׋DP¢¬Ló·E"Ÿ7¥eŠëeÕšC±lË;óHˆ#gÚbIóì9¼æìÛ…pOÁ$~‘}rS´ËÍê~S†EóÅ,ipVtáìwоüè^`Ò¦° +¿rL6È‚ë ær[4ͨJI– +9 +˜ê UM—jºª‰TÝ*µËÔ†<I•:Ï5R°ƒÀ(lYÜã;]†3ÉÏWÐ Ü™Æxx„£l]ešÎÍn5C¹`ó¯¦Á%gõå2’øŠWBÒu> +\ñN +‰S=ë4¡‹1à#UÏE}6ÂpHüÄøT¯+‘ª›K’¶NÖe8Ýíw¥š0 ý¿È'ñìÐu>&a4Uy/9ô=[çÁ(aäŒ~%qVµÂ…û+Zs +ÑWðXèöh{Ѧ»ä¡n¾Â¡=aDû…‰¯’qâY‡ã`Ï »J¹ò4wÕçÊ.Ž.škQÅ¢Õ2¦ü€fÝéÐsç½0Ý<ì"E‘ÿ“üÙŸhZçl]ðÆ@i¿º„佂ÎQtÕ©êGBL§Æ dfü h4¨0“sÜ®#ÐI<<
“0²Û_ŒGv„ +µ#÷‚+ÏÌ.¹Qø}lHì¬'¬#[÷BÏã–jü½ñO¬ ÖÖ•,¿r4êÓ’À°Á_T3 ·Ü>íl‹kÖ´?ë€gè£î¸fq3où§{³,-²²ó» +#¿UÃ¥ìœô£e0fÆOØGG÷ãÑê‹aº°¿®Ï³”Z;Gà32’ØMZKÿ&žPÃ` 3GÕÚû¤M4Ý×Û•³)îÊÚIdϸ¹žß{¤•—¡ª=-âÕ +ÅðEàð{»
åÈm–&™Œ%â¹J&•…S4¦ý±1ã7dh¿á¸Š†Ö+2–0‘Û®SÙ$F”d²sõÈýÕã‹Õ®¬@•‡"T +ñPà·æ6žøï‹CÛ¿)ˆí<ÔÓF½…Ÿ• ŽÕÚLf„ju¡ÖîRM×Ú‘*8Â*YnÌòw°ÄõIÉR5Y~^€H5"A¿)HÌû"Lž71;’1Øš“Œçüô¢Õ·RöÕf°/ÍCÕ_†{rZ8ë“ñfØ C&äPœp¥ÒxIGùvú>Æ^ÄjÊÄs*¨.ÆtU©.VuŒAŸcK¥çÈÔÁ˜®ê"ÕØûâî·»¯gOF˜bŒZÇ8s0˶ÆK½á)$Š§ì[ïEÖåÖLœ;€kNU÷¼`Ìy50¦ê¼ë>ÒL;®§hëk]™S·…’LŸc iNx÷]²¼ËüœÃêS‡
VÂƉ'9lÂhÓ†; t¬xõqêÏñ´$&Ø%^ O_Ž¦Dpö¬kȈpæbi¦ÝÐo¶H‰ý¯†4 Œ=ûŸƒ ÿg +LYhÍÇ@P†žgA(+<cCÉãŠþ? H·endstream +endobj +698 0 obj << +/Type /Page +/Contents 699 0 R +/Resources 697 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +>> endobj +700 0 obj << +/D [698 0 R /XYZ 85.0394 794.5015 null] +>> endobj +118 0 obj << +/D [698 0 R /XYZ 85.0394 769.5949 null] +>> endobj +655 0 obj << +/D [698 0 R /XYZ 85.0394 749.3395 null] +>> endobj +122 0 obj << +/D [698 0 R /XYZ 85.0394 221.8894 null] +>> endobj +704 0 obj << +/D [698 0 R /XYZ 85.0394 197.4323 null] +>> endobj +697 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F77 703 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +707 0 obj << +/Length 3116 +/Filter /FlateDecode +>> +stream +xÚåZK“Û6¾Ï¯Ð-œªŒA‚{ó&vÖ©Z;±'û(ÇŽHiS¤"R3–+?~h +ÐCm=3cÍ +³`Á‚z‹ÿ)þY@«ÉùQ{@ð—‚Šà•¥<×'l oUpª¦”ÓŽ˜¸¢ 8KÝ,Ú€r;—êl'wÐm°SاOEYb++šC™ž 85éά€û¼q xÜX¥$”(!Åð@mk³ p€ + Ž QÓ¶ù… ·Ça|TœÃuDzJ?š¹ÏÍŽ`™ú=걘<•ßÈOA ÄknÛÁ0·ÅnÊ3GB qéš« Àšä$GÎC~Éñp•ã¡>NÅC?àù¯òû˜Oùu¦„RÑ;ƒM½ß§U6ÞŠp–87wÕ
,02þÒ’B>L ãµP! +MYM™²£2¦œ—uš]Še°ÎL~Y®§ ¨ƒÂ…a%¿EÉFpD~¢”ïN ‘aP”VCZϦ¡ãƒ†Ì©IÆ!x# ççÕÔ§šW“§ª Ì,™·zÑ‹š‹ôÞOp1Æ:•¨Ù6ËÆÙüc‘?MÍex¤Gqà,Y/ëÒS•9ôm Ÿ$´u ÍþÖûC°+ óªÛäù=Ssy{T {ì¨p·Ç¼y˜ÚäA¨¸´É>Ò½º=ÿå]9ì lÕ¢6=ÕX» °Ëh¨Ïw#g'w‚?{øÛ§EÕBT^m<ü «-°0Éå[èQ-Ø‚£B[€³j¶ÎË6 ‚¨ZúLþa…è&fË +õTcÍ”PUú¶Séâf[›ÀP~A»O!°ÁøŒM„à¬á°FË6ѧš· Oebãcžvõž?$JLÀ„6,YVª§kuh'Rð¡ZßšC®Ý»ap:di›7ØÑ™þOñ/;CRVl°ƒ°°–7ù˜ ªêî¶ +ËlŠµÍ{$䢢K¹ÍI)ϵGJml¶R“`AÃD v ógì48÷<ƒ©„2†$»hü«˜ÉB¢ÄSj9åYÑÚa“¸Âÿ}îȲ|ø$í¤c«ª{àlbkÐý ŸEÕi=‚}ÞŸõ?Ó:»…œÕ}$Ò³XðªEâ´ljlmÒSc´¯ÛiµÃ䜚ƒ¨?קc¥¥;.RÓ”euo ›3à¼à~m©lnN‡Û`÷šsòqWà=™ºã£Ch}å½í»Ç£Ù-ùyi_óF¤;¨
|7mÛ|0{OlnÍéÏ-èÇNëé¡('áÁªC3—XTûœWóðE!+ 9»_=ªørT8ôi ¼†€ò»âØÿìr!ê¢F»@v¤Òé@v ÓUzoŒ0” t鎱HøOñ¯ÛwÝzV-” ª°´CUÝ=–± xs +‚]
9½"ÙSEKA"$¡þØ=íëÂÁ4Æ5!ô^ Ú @£{¹[0
ƒjLÄWXNÔ-UmýüSÑ´Eµëxô¥Ú¹ `å! "SþèbÆbë!çŒ#飅 © ÐtÁ"þ«`ë „˜j€BÛÀǸ8É'¡nÓQ¡j yÁ i Ù“qaž]DÛ!\ŠÝ}ÂÎÅŸ§ý½Çz‹úàQ¨k± +qnÅ ›ñ6jmAï±.²æÂð«<wU!‹ù'€VEuY`zO6½ja[ìÀQ}µ7»•³ÐÊeD”`W* +}ªùóå©L;MÛf\geàÁc¹,ÖSåƒÐ$ þ‡Î–Ekuá]µnÃœ´Åoš¡Ö½â. P{óÊã WEWRï>Õ‚ò •^Ã/§üx.ëypZ”ÜÓHô48
dßÝ&<¨w;“à°ç¢›p:`àBç¡Œ?Œ à }õ¨Í³`È$GúÐaeíËù§CYlŠ¶<ãxVàÝ´–¥réÓè;Åš˜×]áÌ NL¾ó—.«õç2ê*ÎÒ©ÏšŠDaâ(5¨Uy99žJé §¨:㚀±˜„Iä¼¾ÓßϘˆ(é>„m:@@ºü¾r÷uÕÜÝ!ÚÑM°– èÄÅ/³FÎTH’«FÞ§š7rOenÄœö‡ìÞ}cƒ€ý×õ&Ý<ä¿®5~}˜ÏÝ @!"ö‹4‘!&„L„FW.>ª¿GÓ+ õTã•÷‹ÆàwØÅR¿¥‚%DZ-(ÄÊã€ÕW
>3«·m}ý Ë·é©lñþ€~ÇD +áòcìQ-££BwU üçã‘0ÒE«eùžj<!îBÐ,â„
gðÎÌ@gŶè¤zW1têÅE°O?·,0°Hu9ΩNS›Ûºaá3¯Zì÷*[ÊVÝP ¦£§ÝtGª|H· p á!Þ¾úçK}}€»ÛH†1ä±iñI!a†ãÆ™=zÀ×ÀXìOóÀ„5}J_ñÓ£öè ÓŒ!Áú€ÏŒùi±Îü@gî=‰_Y{!g“cfv™ÙÐœq}íéX-˜¨Jà,²+Ÿd{DóêˆôT Ò²ýû\Þ™ç¥ôiëì‹Gãä`‚¶:É»À +‹=(µ€Í ÑÞ bç jo„ú][ú5ìzF¨zKÞ+XŠ ¶²Œ½M™#î™7Bˆ1óÑ
k€ºiJ²,´§ œê¶5@}ÜÃLJc)C·îíKöæUé¸t>¡è Ùwµ #Ô ëêÈ4+ä(Žx¢¸Òd‡ aë :}X^ ®€qw Ó? +øÚbüîÎ ˜˜¾Í<a~ÔßuùÝ—¦»»äúâ‰R3×0x¬Ë…ÀÄNJëññ½G +f ñ‰©ÿ_M¯endstream +endobj +706 0 obj << +/Type /Page +/Contents 707 0 R +/Resources 705 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 672 0 R +>> endobj +708 0 obj << +/D [706 0 R /XYZ 56.6929 794.5015 null] +>> endobj +705 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F77 703 0 R /F14 608 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F79 711 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +714 0 obj << +/Length 3636 +/Filter /FlateDecode +>> +stream +xÚZmÛ6þ¾¿Âè—óµÂwQ—OIšä¶‡K{Iš¢o8hm-D–¶–œíÞáþûÍpH½Ø´½@‹…(rć3Ï Íg þøÌê„ÉLÍÒL%šq=[n¯Øl
co¯¸§Y¢Å˜êåÇ«goŒ˜eIf„™}¼Íef-Ÿ}\ý2õ·ß|ýþz!4›Ëäz¡
›¿{ñ×Ôó†´ž +¯¾{÷ææíï_\§jþñæ»w׋”e +¾¼üíwß¿ ¾ûpýÛÇo¯^ìW1^)g—ðûÕ/¿±Ù +üíKdfõì^X³L̶WJËD+)COuõáêŸý„£Q÷iLs0œng †Ë(g +t¨RЯâ‰PLôúÕv¤_Π̬§Býv»|Y ®•Ë,±Rf³ñ„Ç|Õ1_%Ç|•J,×bÊø¦^ۢîhºMA¶Ø})v-½¬ŠÛýz]ÖkzŠ/EEÍÛGz6u‘ -!(%å,±ÙEÍ
Tgç‰&z{ö&ÍF´R'Öh
ó# {(Zª“¡)- ‰6Õe‰±ÌNdûPtmT£pÔü/õÚ5ôÌkzÜWå²ô»ô%¯ögô
Ò€YƒþÎ+|LvZã=.«nâƪy’ÚŒ_à ¨Ž9OªM’¦LMYÿ¿4ÊÎèM£—°æ’ÞFdgô¨Pø»jßnN ñó|û#~Ä7~Ä'Œß ãâ Š[æËÍ9“â …æê’jFdgT¨zÕÔù6v’Á„µ™?Éh"`‹7~AÀ@u,àT‡™N¸0Æu¸.¿þp:Á\ëÎùÓfû§õmaZ‰ ú “ÖwO…«i»¼Û·GŒ8M°à<ã@uÌøà³$Í„rþ¦lï« †T,ˆáÚÍ <eFúrƒ¤/P"†4›¿k:?ÔÓÔûí-ê´Ÿ +Ôtžw :æ=µXc“Tèæßì·÷;Y•×SãUþû¾Ø•Á= +XMuò“þê®z )¼_˜PN»x²À +3¢[ +tÇ, Xp©‚Õ´-šËªÜEæ7ü·æa9yK“¯ +Ôeí¼ã…Ð [ä§ áâ ³/xKŒ†09˜·û²BÛ@_•»`zŒ¯`9 6X1áåñB8hÛ šÚ = +¸SH qojŒÉ´ÄýÎ[ øFÉM6=c˜SºZf‹AÙ¤'¢@ýŒñ‰[m#¢JdÁDZãlCI´ C +´ò¶m–%†J‚’°h+ +hὧ÷ÖÈ¥?+˜aù< ø z aëÖÓ_îò%…}xuu#”®‰8öEXÝÄË.ÚX5cvb¿x ”žzœç¬h„(t +—.Œýð:Wêf ÖŒŸðû8 ÖÚø¯SýŒ‹ñ”‘‹'Q€]ödg<Dšd²7·ÖI}(§×°aŠ6É—âŽ)C?l.ù%†ë±_[Ñ=4Ôs°ÂTFõ!=¯ÖÍÜÆ6VôO!ësÍ“I“Ô}–‡¹I-ëƒbBŒ} ›ÿ¸)CuÍ;r-»«©IEªsf~ŸïZ‡Ø” 8
ZùÒÝxP»~¤Fo¶J¨P!KRæ5*ŸHáHP • ÝD %דù<³Hqù)'c³Í—‹íJÇ÷Ê>wð¦ÛÞï?/& FVç¯ÑG©ã(ÂûKÍÛ¼-ÆOZÔËfâ-)\°a Z WQb! ï-í¥/°)uĸ%’ã–¼NNÝtá}Œ
¡ïo%;pÜOÒþ¶ìÄq³‰Í´ŒKäéA–Ém;dYáF€]=˜üã±8¬ÂœDBàL_*vQHðqT†Ä'F!Á|ú„ „Ó±å +¾H2¤Oø+ 2c³XHŸ +endobj +713 0 obj << +/Type /Page +/Contents 714 0 R +/Resources 712 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +/Annots [ 716 0 R ] +>> endobj +716 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [120.1376 425.576 176.3563 434.7914] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +715 0 obj << +/D [713 0 R /XYZ 85.0394 794.5015 null] +>> endobj +712 0 obj << +/Font << /F62 634 0 R /F58 627 0 R /F43 600 0 R /F79 711 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +721 0 obj << +/Length 1521 +/Filter /FlateDecode +>> +stream +xÚÝXKoÛF¾ëWðЃ„ë}?š“k8‰ÄIc¥(#ÒŠtEÊ®Qä¿wöEQ]©Q…ÚåÎÎÎ~ó̓$ † I„DÒP“(ÑÀD$‹Õ'W°örB‚L…Ò¡ÔOóÉÑ IƒŒ¤2™_ti„µ&É<ÿ8eˆ¡hÀÓóã7§³” +<½8}?bú ü¹ùÛw§ïgŠOçgoÏ/f©Â†OO^ ¿›G‰‡uœ¼=qöòÃVÏìÓüõätÞßbxS‚™½Â “Ÿp’Ã…_O0bF‹ä&ch²špÁàŒÅ'Õäbòs¯p°ê¶Ž"G0¢ P:„N¨t„ĵ‰IF™Ã./.³MÕ¥_Š;¸$Çxº®óÅï0}no—¤Ô 8¶!¨ÛõÕ- ½àlp +[™ù²l=n¿aL«â™Ÿ”—á¿n»¬ªŠÜO³ÖkÜ5cd0 +vv^h +øc¯žÅ+¥œC0¦ûr¶¢¡Hi¥É:]O¾‹³—¯>¼Û‰(HBR°d¨ñßÙ« ±r׋;fžXþ·{íô–ö¸OB¡ åcI˜0È\}C6ˆgۻgY[ ÐCƒCˆyB ™aHa@n_Ôþ? fйIL `0ô ‚K ïÕoî§ð@å“QøÀÌq +í|4…USe_I#‹?Ëî~Ž=ÙM¿;Ž‘§äÅоHñ +endobj +720 0 obj << +/Type /Page +/Contents 721 0 R +/Resources 719 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +>> endobj +722 0 obj << +/D [720 0 R /XYZ 56.6929 794.5015 null] +>> endobj +126 0 obj << +/D [720 0 R /XYZ 56.6929 526.4445 null] +>> endobj +723 0 obj << +/D [720 0 R /XYZ 56.6929 499.14 null] +>> endobj +724 0 obj << +/D [720 0 R /XYZ 56.6929 469.6226 null] +>> endobj +725 0 obj << +/D [720 0 R /XYZ 56.6929 457.6675 null] +>> endobj +719 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F58 627 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +728 0 obj << +/Length 2277 +/Filter /FlateDecode +>> +stream +xÚXK“Ü6¾ûWô-š*·V"%JÚ[Öɤ¼o•=[[©x ‰=X-õêáÉä× @êÑ{K$’x| +ùÇÛ¿Ý'â ¢P)‘ N~-•Á„Lf‡‡ê·àÝY_GÓß EÉÝ þIÓ’0˳§E°„ +ãTXþ «¯º-ME~úð‰÷FSo/ NB™(ÁTÆBÄV4ïŽqEÁ‡n¬O/<E Š°PBñ Q„Ìo×R þõðþþWj×þ³@y1åY·õp!r<ë‘Ç›¦{ ˜Iö¤Ø LÿÕô<0vÄÜÒ~X„© o£¿š›iYШ—~2Y…‰ã°HYyvù…LƒJ:Þ(
Þ·ÔÕßÅy`†k׆zPþµ×묤X¨PÆY‹ lÖÎ2“8T X›ØNv‘îâäÚŸÓ ¶éˆwY¼ÅŽ 5Á#¤l>×MCòlÊ/ëÍÆíÞš[õȧFíÕ ŸˆJ:Æ*ƒÝ‚ß²²Èî´.øjZhuüû¡rêIiíH ³| t[½å‰'úƒ…]O[µ YŽÞ®4öº N¤‡Ð›2ÄÏì”QÜw=5. 턨º=uýEv/Ø¡ »iܳb +GIö=+Ê"”‘Ìö–„ZMcÃ*•Ê¾¾ÎëZ'eŽ= ŠÂ,ŽÝêík)Mz êòëÙßüü0ÃU‡ ÐÈU˜ç©D8¢Áþé@ üòüÇ寕 ßÈŽ|2弊0¬ÚnÉCär…o +éÜäÖ8 +7Ŷíæá¯éw1ã¹CW΢à„ØfǪªnŸ9 æ®.¡Æ _e3ú^b, +^Æ ~±œË<ÐæÌcÛ/´H„qÐV$èz\çU>Ò„Õ¿nˆ@ü¥VwÚ+3 26úF YßðSôès‡c†ÂÂ.¿ñ;˜µ°u†Zºç›ÑE,Õnfq†’R +ÛTòÈuú±A±HX䃿¦ ÂÉññåH°‚=z¨L©´Jµ’Ú²™H§vî êHpÃ8U3ê@ uœ^s5%Crù¡ßM5¡Ê… "’t¼vM]îáØQQ˜¨H®C§lôäï4ºŸÙÒ 5ê¶oõq» +Ä”nOÃ[º@)Af9æo +à @uÝ ëR'@bF¥MMj#-ÉÙ"ÚŸ‰iì°”)Á ˜™†ŸLkz=Z‡N'‰“[>4ŠçS£¼–þ]ÛÔ-³º<˜_ÌË] ǧ‡*Úȹëë?µË”Û³¸è§wqçjA[Ði—Ž0Bë§ï,Tso‚^3“ùã +Z3&øó@›=—vê¡ÛíÅ‚¯Äú</ vûkǛ߻©o ^!X4¯Áxê“ÀXxC¢[Ü:€¸èÊPËÞ?à¯éÇ@{·Ãfå!&—3Äà$_Â1Œ\ÑVDc¼ÙÎf–ýoÀ : +*8m=,»YØ°g¿ O+i[/+ö½ìùlÚâªý0Ò$òÙã™]q¾™Í¬RtÂ4nQ ç(üÑwò’;±Ï ÀŽIÆ9§;‹¾^KrËëùc4íàËÂ4[â)”¡2÷ +呧Z°½+º¥˜É7+"Xç*'BOí&ºÄ¶$oœîÙ‚¢ ÿ¤2hT$‡.à–x#¶§+bH T™Á˜Ñå™ù} +endobj +727 0 obj << +/Type /Page +/Contents 728 0 R +/Resources 726 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +/Annots [ 732 0 R 733 0 R ] +>> endobj +732 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [470.3398 483.0796 539.579 495.1392] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +733 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [316.7164 471.1244 385.3363 483.1841] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +729 0 obj << +/D [727 0 R /XYZ 85.0394 794.5015 null] +>> endobj +130 0 obj << +/D [727 0 R /XYZ 85.0394 769.5949 null] +>> endobj +730 0 obj << +/D [727 0 R /XYZ 85.0394 582.1251 null] +>> endobj +134 0 obj << +/D [727 0 R /XYZ 85.0394 582.1251 null] +>> endobj +731 0 obj << +/D [727 0 R /XYZ 85.0394 543.5676 null] +>> endobj +138 0 obj << +/D [727 0 R /XYZ 85.0394 445.615 null] +>> endobj +734 0 obj << +/D [727 0 R /XYZ 85.0394 406.7709 null] +>> endobj +142 0 obj << +/D [727 0 R /XYZ 85.0394 289.0425 null] +>> endobj +735 0 obj << +/D [727 0 R /XYZ 85.0394 261.2074 null] +>> endobj +726 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +740 0 obj << +/Length 3604 +/Filter /FlateDecode +>> +stream +xÚ¥ZYsÛF~ׯÐ[¨*‹¹päM±åR‰ã•´»© ™Xƒ +Rç4-©—Ä„éb¿]e ŠlTH"c# €–»ö-ŠÜ@icóS(7I˜yïê•0~ØÅ—‚GÄéXÍ`œÊ(@30Ûñ^h¤h LVgA wë²eæ¼d”+«ZšU²i ‹ñ"€§øªåI\<– EIUìgù_]͉`wVˆ~
C]É Y½"ý.Jƒ$ÌTϬZ uZ„q +ö»íŠ 72/X\¤ìâjUvG´¢ý)¥[Üìë™ÐÊ.Õfº0v_?»Q ض"¬Ò~ƒÉD€+k»j²Ë*BkñÕñ +z]ÁŽÆëuÅ€Åì–EMFK828 TÄLƒ~á +¶Î‚Oƒ€`Þ6ÄšóØw±TaØWç»bSÔ]V î±Û!î‘¿í²º}(ví øê¦ÑI+Ñ4wì¤á¢„YØôüLIØ;8(F&áö)Àb‹8u×äŒ-[ ™qõ=qá¡&m%Åb÷È À©nœNÙÔ•0è·‰AŸÙ«9x(k°PÜVíÜ¢Aøs¢ ôÑ4Ð6š[I Ð Z({x‚TX®Ñ±è ÚP\:Z>Œ§åCO»-ò
Ÿ$ÆŽš;n޾戎8G‹Û¢8Ž5`1`·"«ƒØ¦„úܹûpÎ…›Q˜èé—ã§aâ”/jí—÷¼mÓ Â¢Ž§ê½íÀ2"^µ¿ BØÐÄç‘ Wf6¢õTË1Ù©¨§ÜMY¼Œ9L€[ ÒÅ–úþ».@ËÆÚE–w´ãTnåË Á0ò°L”,¾¹~÷†»Rþ´ûí¶Ùu2ŒwKdÂXèÖ '.¢}áa]xËa")ÔE^´m¶{ª;æ. ] ³† Óm²®lpI +pB1“TÖ‡IêwfW|Úm·$K9Ý"˜KýåUFŠzy: }Æ!}†=`¸RÎ[kÛ¾`Ê1›Að‹ˆlês#+¹‘•Üèö¤Nn/¦;·E'¶(±ßòwðÚ¸ºãæDz8 VÓæR[[Þ—0gÒ1¢ìe¤‡"±Ðn³\ÚÈì4Æ€¬3,ã‘ +“Šâsw¡}O,¹dÛTœÑPùî[ÆÄ ãQ°. ZÎu´Y0þbdïÆY4 œÖ²/^±@<¯Xkƒ$îói +9íz³œrÙk¿d¢´³FøíYœÜ0 HÂX<M„xNþ´3ë¦ õõÜ<ßÝW”öUf”ïÅœqÆhú[°RƨÃa‰ÏGáTØ„8$@^±lh Æà•N0S#8;\ѹpæ¶ÏFÅ>““9£û1;ÄθŸb‘×™_›ÆXÉ› œD¦¨-ù>5õ.Å#ÉüRÌ[8¨bjéRMn´£qï \9”ÝšKS¿Áo«X‹ï§w*1#ïõ{¹tŠwD,ò‰ +üõQk«bƒY[¶+¿øÉäØ!Û7?üÌç´„h Ŷ(n‹| +g¯)’²Ôãž)Bɰؽ†`‡¾"ü$ïõѺ¿V‚20/õôvŒÈD1œÎry,s@%MÁÞ,ÌR"Í×vØŒ.,q=ö7ïPòbÙF9ÄiJ ñó~Å3ažó2JúÞ¼ØáEà >û–rôwÃÅÄf²1òQz4cA=qUÍ@±·Î¿ +ZÐ~ü(º0¦•”³ó ³áeå^ºYÁI˜ì¯‹YOI8Æ«”À"Wâ…cèJ)äÓM6BÒp-.°”C}E·Þ wú§/‰»tÛÍ=÷Y+èèBtÃ…odë2_Ë Ã+c”\F~"”š±9btl`}ÐeÕÇ) Ý7„Ùˆv ¤vjM¥g5E»²>26@ØYÓb·t_ƒZÿ$`\â·šï…8ojLÜ>ìûs.¶ò³NŒ9èA.§™AæÇÚ»’î Mbt +ºzzs±_š¢ÈC(†HôbŸ"nb‚(‰ü‘úÕ Ç¥u*Ýñí:rÖs ¨X™‰¤¿Ÿ-¨V%iÏsiãÐ?x 1×I +endobj +739 0 obj << +/Type /Page +/Contents 740 0 R +/Resources 738 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +/Annots [ 743 0 R 744 0 R ] +>> endobj +743 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [464.1993 638.9439 511.2325 651.0035] +/Subtype /Link +/A << /S /GoTo /D (proposed_standards) >> +>> endobj +744 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 628.0049 105.4 639.0483] +/Subtype /Link +/A << /S /GoTo /D (proposed_standards) >> +>> endobj +741 0 obj << +/D [739 0 R /XYZ 56.6929 794.5015 null] +>> endobj +146 0 obj << +/D [739 0 R /XYZ 56.6929 704.5459 null] +>> endobj +742 0 obj << +/D [739 0 R /XYZ 56.6929 671.1703 null] +>> endobj +150 0 obj << +/D [739 0 R /XYZ 56.6929 515.8828 null] +>> endobj +745 0 obj << +/D [739 0 R /XYZ 56.6929 480.2977 null] +>> endobj +738 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F79 711 0 R /F57 624 0 R /F58 627 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +749 0 obj << +/Length 2227 +/Filter /FlateDecode +>> +stream +xÚå]oã6ò=¿ÂØ—ÊEÅ¢>¨æ)ífoS´A»›kè8EfbÝ*’kÉñ¦Eÿû
9¤LÉ´öpOE€h4Î÷ ‡4›Qøc3‘Êóx–å1I(Kfåã=À·œ1CZ¢Ð¥úêöìüMÍr’§Q:»½wx B…`³ÛÅÏÁ×o/¿¿½z7£„1™‡IJƒË×?ÎcÁåÍ×W¯ñÓë›÷¼¹ºœgqpûÏwW€a"N¬³+ßÿíõínÅ/·ßœ]ÝšºÖ0Ê•š¿žýü -À¨oÎ(á¹Hf[x¡„åy4{<‹N’˜s‹©ÏÞŸý00t¾ê¥>ï$\DD™Ç=1÷¹'ÉIÊ#®ÝsÝÌC ± X,ª¾j›/à•‹ _J…§ÁjsWW¥²óüM’9ÜÀ<ÊrÐAñéª^2$ å BE†ªh V%4e£ˆÈOÅ㪖¤l =L‰`Ürýmd‡ftËvS/Põeñ$
v%˪¨ýÝ¿¹ž3ȲÕÏ…Yß/‹^ œ…QÊx–ÏBÆHž$‘U¶M_TೈÇÁ¶ªeë† hBÿýùgð`H²'D!WmÕôUó€kú±Úå +¸+: üºl»¾ƒÜã4 n—U‡ØÊpj¤\È…Y&ËbÓI$Ÿz¹n”ÉêÓcQ¨“ë'¹î´‰tlÚBé‘DAÓö ÿT4Ï´ äÁmaq÷êɃºm?¢Q€Ü¬ v‹@o¸/d]=Y F/çsö¡à#k‚fdüÀÒà§y’U¿D¹è7¥‘Ž‘Ø &±ø«Ø,§ƒ2T12ÐùfµV f];Y¿ ¼(u€í²*—–E3,2Ð}»ÞîRUOËÉÊqÝA;¬•ÉE.´•ošŸuHiEšŠ2ÌïÍÇÁ`7‘,õ ûìKOñ*ñ9É8Ç,ú\ëq’«þÇHóÍÍ<L)rVOFñi3•¹5O<E Z¦ÆÜL³½Q Æy‚•k ùŒPQ–re°^)Ïr]0Ë¢¾78ó„Lï—:‹Õ[Õ -ÂA½5²ß¶ëªe&éŽhHõ¢… ¦.” _ ªXsš m@K à'±« …46
ŸsWA½‹&)6zÀ™PZ†ƒn../eB+½¦]Éu=gÁ³Þ:•Õ‘éZŠ3¥kkÝ_PTcYK_=îL7-?í§QØ‚„>üÒèaãIÝ`”鸎šâÑàmg´U9™ +ó6Jgoåý°‘ëJmD‘à†ƒµ1í\Éìð£1>hÄjµÝÖi4êË3>Ñ‚=ŽFoÕlrª7Xþu§Ld•m F™Ð«¡·: Ëúý®(?šÆ²9ä÷Á“#G·Í©.êïr*›#Ø +œlV¯h(ƒ:ÖZ³Ô¤µ†Z|bZ+h5×S@´ ++®–e_=Jå›Ô5ƒ'Lwõ‡ßì_,°
['LÑY…ìÛI“‘N³qÞ÷?K2ÂãÌNµW¸%™üº)}S’?ì0j÷ÝqŸÙ¥Ï¸Ááx´s`qg·è¾ýòÐé"I``fâøQÉ!ÒG;*ç +¾ã¤ÿ@Y6•¨í<³£"¢=™“¡ à8 ÉüfF4FjGM:ê”Ú»ôð FxBàtÆO F"Â3‘ =Œ@mñ$‹ÿäiŒKÝÓ9;ÐBó=<‡êHô,Õéð “êÄo*Ö @Wìÿ3‚ÄmhÓÃlJX–Š„’By’¥-ýE ÓUs$,@¤'éP ¤¥: ÈcR@NÅúéŠ}y ÷:õµö©ìú*ÎSBcq¢c¹T‡}5PôÕQ©;_í‰õúj$öêS¹,šÏÁ±_úºÿåÍk{sÑ+Ùª®bî@ š¦ãÓÍÛÝT|Ðë‡æ´m%qªî^ +ÂjÕ…m¸”ky€ níJ‘<Ü‹ÊÑ™âKâh¼Y WU¾+C¥ÜÆp +wÝaÙkYnÖ®Ò#ò•¼L ”·câqñ‰ 'Y9–["Øé”ÄWxfr6¥W»TãÑH=BÊØi^J†;¾œ~^ÖøÓ¼²Œ_=žï+tq¤€ÜÒ2L¸]´6
a“°4)ôµ’®ŠLM BŒ82÷·»ŒÜñìGu8¤ghxæ¾*ùKiz0ñ¼5çÉ»“ Œ¬ê—bÏŽA‡ˆþÏ?H;#eF¸‘ïá4%"‚ÁÆ(¥ŒÜ '‡_®÷Uÿ/“Õendstream +endobj +748 0 obj << +/Type /Page +/Contents 749 0 R +/Resources 747 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +/Annots [ 751 0 R ] +>> endobj +751 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [417.8476 408.3291 466.5943 420.3887] +/Subtype /Link +/A << /S /GoTo /D (sample_configuration) >> +>> endobj +750 0 obj << +/D [748 0 R /XYZ 85.0394 794.5015 null] +>> endobj +747 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F56 618 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +754 0 obj << +/Length 767 +/Filter /FlateDecode +>> +stream +xÚ½W[OÛ0~ϯˆxJ âø–Ûxê lCb4Û ‚ •r)q¸”‰ÿ>;ICÚ:¥P˜*µÎÉñwŽ¿Ï>ÇE: ¤;.p è^@‘£Ç©õkñ kîdu½¾†š}àb= +Š&yVnr^ +#Zªôœ÷219Žóì B|ý¥¶PX—‚Eq¢daEhcÚ,ÒèÔ5ª7[ ß–”øfaÖdÊëܺaë«‹B>•îüÕ + +endobj +753 0 obj << +/Type /Page +/Contents 754 0 R +/Resources 752 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 717 0 R +>> endobj +755 0 obj << +/D [753 0 R /XYZ 56.6929 794.5015 null] +>> endobj +752 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +758 0 obj << +/Length 2227 +/Filter /FlateDecode +>> +stream +xÚ¥X[wÛ6~÷¯Ð#u1Á ˜ž>¨¶“¸mÒl¬Ý—¦IILxQx±«ýõ;ƒR¤L7Û]ë s0 +ß5"¥.Ò& ÒšÄDèÚ"°á¿û÷ÄåT\|GÜc‹¹ áÙÒ´Â)`¶ c#ifƒó–+á8gl]˜ä¥°•_£üæ5`¯ °ú§¦Gs¨êIßÚwY’·ømÚ¶Y¹§Aw¤çf à®uÙè˜Ý +G3©ŠÓ¦á`ÙÑ3¦Õt{ž3±60¾¦'ž¤Ë„ˆ®y^¼ÉöSï1kD‘“Xs×± H0Fs|"¡ºf…®³üDæ; {¸RŒ
ßØÊpt m +–5~TNo> =ºß7ÏŠ¬¥…±&†‚ÆhÅ ¡™gÝÄö—Ò*²ý¡%r›2 r,Q]“hrÉ ’Y³Ä1ÑmŠ¾p<kM<òü‰ƒ[ÇK處Øa8åPuy2hÀSbƒú™CBˆ·¨©bô(ïé R¶ADžµíZ’»û¸|å÷úÉ +k0%+›Î„6¦’8ƒÈF h L¨âÔútl«}s¿Xy€ è¢1§8¾µ=Ñ“<‡ê‚Vßéš +(ƒ1- Ãâý]ÀÐBÌÆy^=RºCl˜wvCHíÏx)qƒ¬pÁìD`ó'fžÚ”;@}÷~}½zãÓ;2 ®Ôгïæ’ÖÛêÁ”“0²~ ëªçÒ#÷2¡:wc8 +j¶PSMTRc×Ìœrâ¨9 9wJCçyq!¥0\çM…j„‚>U…Öײz,‰  +hÚ³ <륲:æµÊ+Ýþ0wíQ®-ƒ¨ï4‹‚ 1ƒUR/ ‚ÔtëAØ+@ÌrͼɕȨPÑsÔ7á0è‘H™\z¶‚"qñK·Ú~î²ômüð;óÅ×î(ÿ÷÷åóu/´¥Rîü§cé¶r£°W +•Ñ¥æÇ觪ÿ¿ü+#endstream +endobj +757 0 obj << +/Type /Page +/Contents 758 0 R +/Resources 756 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +>> endobj +759 0 obj << +/D [757 0 R /XYZ 85.0394 794.5015 null] +>> endobj +154 0 obj << +/D [757 0 R /XYZ 85.0394 638.3105 null] +>> endobj +760 0 obj << +/D [757 0 R /XYZ 85.0394 600.2421 null] +>> endobj +158 0 obj << +/D [757 0 R /XYZ 85.0394 433.5475 null] +>> endobj +761 0 obj << +/D [757 0 R /XYZ 85.0394 403.0897 null] +>> endobj +162 0 obj << +/D [757 0 R /XYZ 85.0394 351.2066 null] +>> endobj +762 0 obj << +/D [757 0 R /XYZ 85.0394 325.7421 null] +>> endobj +166 0 obj << +/D [757 0 R /XYZ 85.0394 166.6305 null] +>> endobj +763 0 obj << +/D [757 0 R /XYZ 85.0394 141.1659 null] +>> endobj +756 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F42 597 0 R /F56 618 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +767 0 obj << +/Length 2286 +/Filter /FlateDecode +>> +stream +xÚ¥YY“Û¸~Ÿ_¡ÚK‹ƒà×>ŒÇcg6»ŽãѦ*µÙJ„$:)“”e%µÿ=
4@‘æp¶¦j„£Ñht7úëÙ„Â ›ÈˆD)O'qI™œ,·Wt²†¹wWÌÒŽ(R½ž_}ÿ6â“”¤&óÕ€WBh’°É<ÿu + È 8ÐéüþîÝ,àŒ§tzó—ëóÛЕHàúÍ?fŒ±éõû›Û78õæý=6ÞÞ^Ïâp:ÿåãíýì·ùW·ó^¾áZ¸ÏW¿þF'9 åÇ+JDšÈÉ:”°4å“íU(‘¡n¤¼º¿ú{Ïp0k–zuÂ(áΩ”O#©”|¤™’HpÑk…ÏF)è¢Þ ‹jçì6 +÷›¬Q¹m«e£:KPãïëºÛ`ëçl¹)*ÕjµÀæb`: xD$èÜì:ß-¬I¢)þÊéB ë*Ç1ÜÛe½S8V¯ðì@pòZµÜ73–L-a7cÓ&«Ú]Ýt8²UËMVíÖ.ØÔû2w»âؾU9°
YÜ‹&§KGõtƒÍàŒúT¨_ô°·ó3pªéKTGÛnl«S¥ÚmêJÙ¾ê–Ä*id!à'Ó8ém#¬mîªUÝl=ÖQÍÕ´Ø1JÎþU _Ì$(»·_‹¶SÕR=m¡»m¶["¡Œ„ a$ÂhºMÝvÌÃŽ‡„F©´T˜ö’K‰±pB1¹ ÈQîøõòEï€-*,)\s§…U]–õ¡×]aµ‘å¹ókçË +<xÈjÀUa ZÆCy$#”J§†*Û‚-ëjå‘=â„G‘ÓÅ¿(å¥ú³‡grF’4„K-(Œ +¼¢ÿVÇY]ú?'8ò_ã†Îƒ‚Þ•´ŠÊuÝÝfk×n³e°Íå+Ÿã¶öZkÂï~ʾ¿•7ŸÞ¥ûSݲOŸiÆ?å×?üð .
¼»ýþÊïRÃs{ÊO¢½Ô† +{ÙlWÛG“uŽ¾®Ê£n1hÙ¡v¿Ó\ÛO/Ž8üúîý‚CýnúpÆ[:œð°W8³V•j2ËÄ\Ô_ë O{_è;ˆ(.†_dņßLÿÈÁ¶úX)ŸÝNNqvYo·ª2Žˆì2K¦@Aà€ Ï’0–ˆgyž !©%]X™«º +uSÚ=Q,Ï¥2²ŠiÝ8qìíƒÆú UrÎÇ”ö4]ñÅÝJõà-Ëðg †îÅÀ¼).¤eÝøú‚
Ê}Ï{qô©* +P )ÝaaíÊX®..é¶e¨@çvaæXµm¶v+Šu…ZŠÍ=‹®¥Ô©ÎKŸŸ—¥át™UØ€‹ÕÛöþ„fƒ¬³¸¨Q4fÓ»ÕcD8„¦öË%¼Ú—åñ´6¾ÊMHˆOlp=€{Õžs±ÇÔíÅ…ˆ`z_às§.‡=·]³o + ®ËŠ +G³ÊnwJÚ—¶‚¨ +´Úrx¨zŽ'È4p<„”§\Å ^¯;Ÿw¥$‰x:…!w)7è57‡F”ÑèQ&î! ZNovQØÏ{ÕZM™Û<Z1¸FKáÉL£=EYbka§{l3³¦ ˆ ÃP»SK $Љ*/Üx#Eq(¼¡¸þ¦bÇŠ©Ë‰¯ €5-úDŸç „µã +û mÚ’šÓ{6f°±ü¶Èíö ø#ìÀpБÔÁ”= ¦CÖocliô½®¬U¸ Rã‘_ŽoŽÏ%<›X|Ó±½ÉH8eÐe$mdŸÑl:ƒoAYë¼òÚ$uؾàØÔåc)z¢®ß´rÔˆ{pDN=v²‹Q‚ Â7#ó䃚zT0³®ÊFaÀ˜¨ +×7?a#Wzº*´›Y&ý“E8|YÔèIAwî BK ‡‡•‡S ‘(´ó`ãæèã’BúÑ'Ÿ<\À®¼éô«×Ê•Œ#>`AÎÒð>A(©.€Ò± îw9„ ǰ؅ŵǰ1‰X/ÚBÍóŒa¡Þd¦y»I^uK}ílU¬ ŒAuiÕCÖù°4mÝt[æ¡}ûÑcºˆÇ%XÁØÁ>ì™ q.W€ä*÷j†‘8eñ%f× ¥<^ÿ EÚÊC¶Ý9ðv¯v™ÃzãTVõfÄS^»3Lð%zgiÔ˜é g{äuéÕó^uúŒÝ]Y-ñòðb‰ Üõ ëtÕç‚…MÐ|ióE<dí%.Ž£<©7©lŽÄyè»Ñ©¾ÑýåxžR¿°K—i–=°ÂUŒÂhüTðÏYʧõþ,¹;dÕÙºËèì!õ¾;Sö >yîêƒj `öœ‡k7í«!T}°«Ëbé+9# @ú’!ècòyöC +endobj +766 0 obj << +/Type /Page +/Contents 767 0 R +/Resources 765 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +/Annots [ 773 0 R ] +>> endobj +773 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [389.9997 61.5153 458.6717 73.5749] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_policies) >> +>> endobj +768 0 obj << +/D [766 0 R /XYZ 56.6929 794.5015 null] +>> endobj +170 0 obj << +/D [766 0 R /XYZ 56.6929 769.5949 null] +>> endobj +769 0 obj << +/D [766 0 R /XYZ 56.6929 748.9393 null] +>> endobj +174 0 obj << +/D [766 0 R /XYZ 56.6929 700.6394 null] +>> endobj +770 0 obj << +/D [766 0 R /XYZ 56.6929 671.7552 null] +>> endobj +178 0 obj << +/D [766 0 R /XYZ 56.6929 470.7895 null] +>> endobj +771 0 obj << +/D [766 0 R /XYZ 56.6929 441.9053 null] +>> endobj +182 0 obj << +/D [766 0 R /XYZ 56.6929 233.8866 null] +>> endobj +772 0 obj << +/D [766 0 R /XYZ 56.6929 205.0024 null] +>> endobj +765 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +777 0 obj << +/Length 3193 +/Filter /FlateDecode +>> +stream +xÚ¥ZÝ“Û¶¿¿BoÕÍX üw:s¶Ï‰Ó‰“ÚJ;$”„;±¡H… î|ýë»_à×Ñvf:z +‹8z'wÙcŒ½»Tä>JîÌ‚³ßÄ`8ïjî(ê'žKnœ×ø:ë(ú„Ãòrðq#iDYÀ¥tKÇÆ* yÙ÷?nÑ—Þü¼ý.ü +Ôò„Âñ5Ek4éúÕ»÷ox@.ÓOçÊž +5 ¸!T%Û¥ƒd)Þ$5x…’e±Ç–Hjš ûƒdRÅIüÕí%aæÏŸ¥DÔ]9‰ ;Áã"ï(f le;é(‚à¹W„ˆ+š€Z)å±±bÈesqäT€Ö{)F÷›PGA’À½”?ä± çªm Óýš;M•‰—L:2ì-©¬Ë®do‰Mü ÃZhî«’3R#ŽÊ ¬ùáD«œ_s‡2?…ë¢ÔŸ’ßÇŒ?.¶•µðN@rW]dE !¤à›h²À$É,LgÙþ¹Å¢cNÑå9¼YÜ"ø +eÁÉ”ëõf TÃt’”mLÊCÃÐCõ /[ÈôBrü;îEó T¶qœ0`%ƒÉ ÒЮ ×o‰L²èÏ^ƒê¢Îg^Ze+¨1@CÊ\oØ Ñ +ÁƒÎ“õÍ]G^LaòGŽCe}C·ôä ÏE ˜¦<bq((ì³µ„ –5 ¡åò=ô Ñ'¡É¹ÜÐöTúÝÂÉ}Åv__b
#í§b/Pcêø‰û,Ûy €eæ3…¹UgyeæO` ã!N8ò¯£4pᇪÑf²iàKk®f1ÇõçâÅ:ñb|M¼ÌdÑH¼ˆÝ“Ï!¸hX32A²·‚ƒ0 ãÂÆC0||@Ô E X +ÛäVf“¿"Yé!¥žªalj_Fû± ýTÐþ8æ.?32êg÷, 24"ÁÚiaí@u—ó¹iÉÜ¡óÍû o_sÏd êí u`‰%™Yh¦Ï¢pÒç ‹È¼¡£”I Þ¾f‚6‘aßk AŸÎ£pñím*Oé„CǵóeW•ûoÀ <°÷š {.,PBÖ6Ü‘KcŠç`â) +Míc¿íâJ
rÎÞíØdä¢Gü, ž~f “ç„Ñ+1v0ŽŽÇO$ôT‹»›æü±Ï_€Æx: eäÂînòŒ‹ô£…䱤E"8·líß
ûÓÀe1Ǹør¦§þ%–p ‰ŒJk9]gOçY_5lZ4 >|ãÏÆ?- ¿ö-œÂLé(( /žë —'À×%¤…›ÉÃíöõO2‡mØ'1¦ÒÍ6"À ßp·^V9+ÚlSyÀYžÏÞÐ,,.jù wzH)B,ïÑsœbíÒ-¥NQè,ô8†ÍžŸ»E.ÊôyƢǷ°œ¿³dâyÅ;~Õç¾nŸÎ]·ô|,÷ŒCF®‡½'Ðès#ßÊòd+˜à¸<7Ε»Êr«Ìvd×Ĉ$÷/yy20ûh÷—¶ìž¸…jfÁ”ô—'°ã>õà
nvåÒ÷+xH½}ô]ÀúÚdSoGïˆvâ(¼„³x±ù7MÙm¦äñy0 j$ZûÔ௠â¤A÷‚o_Ý,qjì‘Ìß¾Æb@’åò‰E„pÏGr ¬Û·åÎJŸ`„d-ˆ ð#S#NÄ‘B/¼é]‰ù(9“0PIœMݾ ¸E×ð®æçÁÆ„é?Å"™?, +_‰ñÞ<ñQ9,‹ˆ| X½¡ñ +ý$D<V8¡k¨,?“o AÎâÈ<O¦†¯sr”zôIï±içl¨Yrß5”“CÓÎ&<“M1+Žñ —Dg&0qn¾x"&Ða¦''B_#½£Ð©·Û±pÞªQ(‰²œS)¤Iš.}ŽœÅÞ@Ÿz(Â[´UÙcÐþTÆp`ßœÎàÌ8ØLÂz[ÀsðÔºóØ@ ÕÒß8"à/þt¡úÿUüßñþÓ§A”ezø÷Æ4yL‚Lç© +u§Ã¹äýAž‹þ?ïp;2endstream +endobj +776 0 obj << +/Type /Page +/Contents 777 0 R +/Resources 775 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +>> endobj +778 0 obj << +/D [776 0 R /XYZ 85.0394 794.5015 null] +>> endobj +186 0 obj << +/D [776 0 R /XYZ 85.0394 769.5949 null] +>> endobj +779 0 obj << +/D [776 0 R /XYZ 85.0394 751.9762 null] +>> endobj +190 0 obj << +/D [776 0 R /XYZ 85.0394 588.2109 null] +>> endobj +780 0 obj << +/D [776 0 R /XYZ 85.0394 552.101 null] +>> endobj +194 0 obj << +/D [776 0 R /XYZ 85.0394 373.7735 null] +>> endobj +781 0 obj << +/D [776 0 R /XYZ 85.0394 339.0798 null] +>> endobj +198 0 obj << +/D [776 0 R /XYZ 85.0394 207.963 null] +>> endobj +782 0 obj << +/D [776 0 R /XYZ 85.0394 174.5031 null] +>> endobj +775 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F11 785 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +788 0 obj << +/Length 2920 +/Filter /FlateDecode +>> +stream +xÚZYsãÆ~ׯÐCª*‹ã9p:OòJk¯È‰$§*> @”PK4J¡}º§{† +SäÉù üB…>_ŸÅ‰IlŒã¬ÎîÏþé' µÚ¡A()´
œª%6!µ$…H6V-OõöBåQ›K£õ® J¢rÕwÄ›sÛ¢[¯wm³(‡¦k©ÓK3<QãðTó¸jÝ´M?lË¡ÛöÔØ-:mJZ´ ¨¡l«/»-/óÔ¬*êö{×òÚËÓ¶ýºPñ°û™RNQÛ|ª÷=œ_ ÃùAï"¶ãß¡ …‰úz±Û6ÞZú¡ vÜÂ{®Ý)pš¶ÂmÖ³÷Ä&ñ˜ˆÏëPËÒîX%ýv¶†¬E¹)ç+îHôÝê¹æ°ÅÀ¦†íE ñ¡È¨z"ªr(a¯FI8Á†™î[±Ú$Hl×évOŽÁ- n{æþeTιpÌ%3Q¶/?$ÙÈžtV)ˆŒ’^ßSŸ‰Í©XÄq’sZsÑÙoÅ3G’Uõª~ô6’vM;«ÔœÈTƒŽ +!u\Øi? è&ÖQ7 5©à¸· Ùžøh=ö땉]P‡ÄoZâ V•ÈÁ½2MP°=5¯y¨ŽêƤ£ù…BïA + gµÚÓïE×þ"¥~ÜÑÆ+š†œÆÊ3Y,5` +^¹ž®[×:n2`¼Îçïî¯î¿½RÂ÷9ôƒ }Ënµê^|àBÒ%ÞÙN‚EIŸ,͉˜7ÃdÅ£X½ ôÓ<k$ÂXeØj,>õJTZÀÆr $]o<è¯xÒ|Ô "5 o.Ó鶧Ñt–B¸™•ôõ²[朾v‹–Á½á[j"§û‰Æ/ +Ð(fjS +}¿ Ò«Ý¢®¾ +¨O¥R¸)äû©\_H™|¡´‰ç@0Y*2#5dz@!@àqúÚäN&É Bè©) Vßl›g4 €2ÆÐâRØ/2‘/ÔnŒŒì DZ@a0ïã Û‰ebøµô±ˆÄP>¬ +‹ŸD‘éOÚéˆÆ€ÈkøLfç²örOâ*Tçv#!sWBó†¬=dE¹ižêƒrâ¶l–LœÙÕ -L +ÄzuI E jÈÑÔÿ~ð<ÉIº7ÖÃBŒ×l+êMÚ€î¤C䔬ÀĹŠã©! x|Œ‡Lì"re_ó!@€ŠœÝØîR€‹ÓÑ ê•¨¢òLd±ŒYqŸ±¿D‚“&
£- $,iOK3€Âõ:úŽb"ü¢¤ÀɾÇÔ§3N}ÚoÜÎn¾‚ÄBh߀ˆi’ž”y-ý _œ1 Å$q; û7àÍXªÐæ‚èÐÇêÉ~ˆGƒ3¸Äl7‘%"IÒ“PÉ eùXKY1‚ëÛr¹Ìé X n€ÅñoSo‡=[Q5ó ¤Îáx‚’U³ÄQËzTÈŽWäˆ`JÂ`bS—< K‘û2xg¡d‹Ùòõ kréŽÜÒ„F À†þ©Ûá= +?$ø5Ãâ +ÜD –”ÁÒ§ª»@UH¬?¤Ó£5~ÀyŒ®PDÚ (Òxæø}³:„óM2ï৲‚«`”)Dlüý·½¦r×ñÇ⸀ôœy¤QÁµkå0g"Î<,Á*ŠaÕ,ÖJÄyjŽ.jºvùÜ-û#‡oZ«LB×$}82øD| f<ÿg
"ˆ’¤p—g|’gî +¨Ñ9r}8›‹.Ò0ßxžO㣠eDètQ?š¬Z=
ÄÀmfîݺÞwòœ|‡`>ï`úxƒÂo„Ï°›ª& ©ÇIºp.e:?¥ÙLOiF:,o^+z4¨>3‰³èëÛûïoþ ºl!µ .#±d°Ç̃¨üëü8p;5O¨õ4欬c•…×\vñ’5áTM×'¹±:„MÊu¯¦*Pçv?z@šF¸Wì8§ §
Ãé÷þUǃê{~mzNÿØ®šO¶b2Ñ× oñm9‹£ü’j(Ç1QA
UGá¤,,2—{bNC3ñì³ô[ueÅÓZ Êü¥/4r2ÉÜrF·Êx_µë3÷r9 Z«ŽX(Fà²üup‚ANÞ–d£G?ç}¯ÞÌbá‹.•Ž£Ú5w[Êø•8£·_`“3v\òò¥;ðç“‚Úsj°" Šï, r–³Èïú@T41š’ÐÖ¬«Ù§ðXR-µ+C|ÕwÉÁ °E‘ÆEà9ƾö‹m3wº^ÁØí±Ú¯Ä‹Ýºæ§ÕÐ?1˜Dà þå@zOùŸÿÁáð? àLžëðÿ.€‚!ÇÁ$,nZëÉÝBœŠþ_2ç;endstream +endobj +787 0 obj << +/Type /Page +/Contents 788 0 R +/Resources 786 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +>> endobj +789 0 obj << +/D [787 0 R /XYZ 56.6929 794.5015 null] +>> endobj +202 0 obj << +/D [787 0 R /XYZ 56.6929 684.186 null] +>> endobj +790 0 obj << +/D [787 0 R /XYZ 56.6929 655.2772 null] +>> endobj +206 0 obj << +/D [787 0 R /XYZ 56.6929 387.8252 null] +>> endobj +791 0 obj << +/D [787 0 R /XYZ 56.6929 356.2664 null] +>> endobj +210 0 obj << +/D [787 0 R /XYZ 56.6929 153.01 null] +>> endobj +792 0 obj << +/D [787 0 R /XYZ 56.6929 124.1011 null] +>> endobj +786 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F42 597 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +795 0 obj << +/Length 2016 +/Filter /FlateDecode +>> +stream +xÚ¥X_w£¶÷§ðÃ}ÀçĪ„@@ÞÜÝl›ž{²iÖÛûÐöØrLƒ 8îöÓwF3`Àlúp“¤Ñh4YÍ%ü«y +©“` %¥ +ç›ÃLÎ_`퇙bžeË´ìs}¿ž}÷ÁøóD$Æ7óõ®'+2ŽÕ|½ýÕ{÷ãêq}÷´Xú¡ô±X†Fz«÷¿,”RÞêáÝÝ{Zzÿð‰ îV‹(ðÖŸŸî€¢”‘ö%¼óþñC|Ÿ>?>~|ZèÈ[áþ¾ßß?°Ìdñûú§Ùݺ³¤o’Íøsöëïr¾£šI¡“8œŸa"…J~˜¡a uKÉgŸf?w{«në”÷B ‹0ö£ ÷þ\Bàƾÿ„†¡ó ˜^MmM? eÕÐ$+&Íáº9_ú±0Q¢Tf–0»Ïî”ç_qh¼š¤×´æ9
6§ªZ¨Ø³ECœ‘·µ¿IévË2ÊêP“ŒrG$ÖFEz°4jJ–¼Ý’Àš7¥Åvrå²å"$/Ë/§c-ÐT4N)‘„¡ïŒ»gÏœ3§;ŒÒ¼.itª-gKçÍÞi¶&RÃ܇ô ³ÿy²UÖ.Ÿ÷–^-bïTYñBó’éi1>e“ Ó眥Õ_ëÆ .ÊG"Ñ~ì”ÿPVÀê€7Ï©S ½¢:“o`æma9¡O/lÀ\.H@_Á ÑÈÊMIBÁwK
iµÞ[Z&×À’ V†æ£}DÌø =òzÚ¸D€ñ3 ýôáÝ0> Z}ƒ‡G ò$ô§ ê.·ƒ> êÐ@`g›+ ²O`”Ð'cÒðP¾ZÞžnZs tà)#ðGïÇòl_m…Ô*yjöe•5i“½Ú©„ãs}Š|8OaTÛ +„Õ<i(#a˜—é–F—ób1å–y7eѤgÌ]0ü. åõâáø¹<7
Ûƒ‰¢5¸¸>ÛŠ˜.YìÇìÜkÑÜ›)S)`˜á›=r¡± X8 ·sÇÁŒN@æ1ßÀ:˜¯L[O£ THÔ«£Úâ2í6t´¥¥^ÝÆÇH XîÕ +)÷€ Úo³&+‹4§•ß ÒŠìêGÄ„(—6´%³%ªKA±·„¾¡é¡¯Ž•ý8 +Éð%©MÝTp89Š–(šØ\È€ © áá¿^0vzazi¼ý1€’ñÁ +
6åá˜ÛÆæ¼ +Ê€œøÌÕH³QƳ%6+èÀ8öîw´”Ò +YèF)ïvÃÇ2ïå„h$ðÁ0Ù"r&OµtŒ$¤Ü¥3D'Þ´¯¶f?A¥a,Ûêöv·*0± F WÊi‚˜7¥õ {&M×´ † ,Ž¯kÚŸªéöÙø@wÈUþàšJþÁƒ`ú_ËüîÕ häº[ê`r:Ò7åÅAu!!ã…‚ÏÄ1]
ب¶ûšÚŠm Ü`EÃó´-cœÔ”ÍW÷ð“j¼?N˜TÚªô¢ÈÔk 2ŒÁKê:ò´Ä*Ñ£ÞYL8,„LˆUËØê UB…º¸þIê‹Ílð)oØ£kð1Iºr‘Ö¡Çvež—ç.çò”óAÔc—¯ÙÖr·*£‡}Âðå‚•Ñå½a¦_R\±m¹Œ³yª~’Xø*ˆØ;oC• Eê¶ØÄ„8|Wai¨7€UŠá,žÅ¾ÊÍ|1å8-”oýCùÅp„‚wŠ¤Ó:@~\?¹_6ÈKb ïS¿Buãx‚ìðàÿþðò3j @aÿ„WŸDR.Zz¬y÷£âµêÿ +endobj +794 0 obj << +/Type /Page +/Contents 795 0 R +/Resources 793 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +/Annots [ 798 0 R ] +>> endobj +798 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [377.8384 566.941 436.8266 577.7254] +/Subtype /Link +/A << /S /GoTo /D (ipv6addresses) >> +>> endobj +796 0 obj << +/D [794 0 R /XYZ 85.0394 794.5015 null] +>> endobj +214 0 obj << +/D [794 0 R /XYZ 85.0394 769.5949 null] +>> endobj +797 0 obj << +/D [794 0 R /XYZ 85.0394 745.0977 null] +>> endobj +218 0 obj << +/D [794 0 R /XYZ 85.0394 552.7519 null] +>> endobj +799 0 obj << +/D [794 0 R /XYZ 85.0394 524.1722 null] +>> endobj +222 0 obj << +/D [794 0 R /XYZ 85.0394 397.0585 null] +>> endobj +800 0 obj << +/D [794 0 R /XYZ 85.0394 368.4788 null] +>> endobj +793 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +804 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0 +endobj +803 0 obj << +/Type /Page +/Contents 804 0 R +/Resources 802 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 764 0 R +>> endobj +805 0 obj << +/D [803 0 R /XYZ 56.6929 794.5015 null] +>> endobj +802 0 obj << +/ProcSet [ /PDF ] +>> endobj +808 0 obj << +/Length 1920 +/Filter /FlateDecode +>> +stream +xÚXO“Û¶¿çSø¨‰‘ÔßcÒm;yÓf:íöÔô@Kôš™ô3¥õÛoÿ +A®¤Ç ÓIÈ !íÙ9ˆêu2¼ )Špšæ;É* +®¨kÄI§ˆ =ŽÁ,0¦X O‹0ÚŠÏ>n–üùøÛv' sÞ4ѽÁ¶¶Çô±àʾrž÷sTÆõ7»ÎÜ.¡Å„(׎žvƒ6í@ò=:’Œb +¹,ƒ
³Š‰±gìÇ>¬‡R$æÞ¤w:Qž¥¼uèD<t¢ßcVfcÙƒ )¯ßÓ‚x‚õ+rÈ"‚ò+°˜æ!ÉMH«Î{Ù*LIQ\׺W8hGR:Žn2€%µøÌ[«SYƘ\ÝU#E^À>ÐýþrV®[Ù¦€(f
j68+éAe‹ÙÚ欺Õ2koZu1k¾f Éß +ÕVµ2,Û
è_ç³î:ù¯ke—U)¯Å5¡.Þf2g)¯ò2*j£Â‡u(碚Û)/ò<hPCûáìÓR/j(OÆÅ2VPˆûµ"iòh,XˆÌEíÐ$[Öü#
ó …Ê 8‰"ËšHá$âˆÔAˆF +jSlïíùn°+¼²±œ Ç9hÉÞY¢Zy’þ–hJ“60;Kƒ(±šßŽúÔ|žVü¶¨å8XcpQó +endobj +807 0 obj << +/Type /Page +/Contents 808 0 R +/Resources 806 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +>> endobj +809 0 obj << +/D [807 0 R /XYZ 85.0394 794.5015 null] +>> endobj +226 0 obj << +/D [807 0 R /XYZ 85.0394 769.5949 null] +>> endobj +810 0 obj << +/D [807 0 R /XYZ 85.0394 576.7004 null] +>> endobj +230 0 obj << +/D [807 0 R /XYZ 85.0394 576.7004 null] +>> endobj +811 0 obj << +/D [807 0 R /XYZ 85.0394 544.8207 null] +>> endobj +234 0 obj << +/D [807 0 R /XYZ 85.0394 403.9445 null] +>> endobj +812 0 obj << +/D [807 0 R /XYZ 85.0394 368.2811 null] +>> endobj +806 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +816 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0 +endobj +815 0 obj << +/Type /Page +/Contents 816 0 R +/Resources 814 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +>> endobj +817 0 obj << +/D [815 0 R /XYZ 56.6929 794.5015 null] +>> endobj +814 0 obj << +/ProcSet [ /PDF ] +>> endobj +820 0 obj << +/Length 3052 +/Filter /FlateDecode +>> +stream +xÚÍË’ã¶ñ>_¡‹+ÚÔÆ›àæä×&냓Ø{³]ŠâŒXK‘²HíxòõéF)Q£MF©ré + +Îtl<jt° +,¨=ôq<U–bŽnRš¯Ûâ€ø×o‘þ»ï> þ?³ ôT/´ÌòL¢óÿíîç_ùb
±âû;ÎTæÌâ 8 +æ¬ÊŽ€Ÿ!$É2çÜ<³É€1£œ!©3à + +â/³a%Ôq:ôj4u„`øö‡Ÿh ɸ§µ 8)Ï·É\‡d«¹_¤Ô3žê ¡xtµÛgÖ—]ÏŽ'q«S×l4\Äù‚šŽàœ +˜A
~MM•d†giPÔ ö¢¢FتêåKÊ:¡²,ªm^_×Ø¿c2¥Dê{: l2íi¥júò±Üw´þ)¯¾Â€7<|rl6Œ4†Þtå.ßç=ÁÛP‘¤(»nNQá†ÿ‹ý ã +ɶh·àãÖÄž¿Cš‘dÀ*ÈlÈ™¡Š â*¦¿ -Bz7©~«¡Õæ°-÷UAËÕØ°7 +Y h Ò™¿8C@jͦÍk5íµ.Œ>=‡‘øZù£Äçüez +ï³!†ññÅ1>V MKc×çÍšî‰×´²!rNÕ‚‡ó&è¿ ÂäØÛ_ÏIb,@ôY —¥Ëâ°'ŠÂ…g–Á©ãÌÓÙãþ!Ô7붮šö™=ŠáôÂåðpåšh»]‹w’H
GÒ ¶Tg(¨LÒ·‰× „ „/WeÿT–Íœü²ý–$?Ajýáò¼ó¥Wæ:ÞðÞÆŽIÝy PŒR‚sŸ'!·ÆEŸ÷P:þn¶) !'"BõR©!SW©b…¥¼ïóbã“phO +ø» ~‚YŸOLbÊVÃó;,E9:~>ca‚Î[y/D+Û¶ëCiâí´£‡ñQáóè¨JªT’¸ÕDKòú)—¯ &Ç@!€®PÒäñî¾)‡ÛÚ–ÆU¼u GË©Ð8ÅxeÚ2Ê…‚ðÿ œá‹‹™„È™kM $ÈT¸ k! %ÓG¸W§Bc2F9C¡pÌaGnBáÅdæ©Çdhæ2Â⟡ҡG¯Ï³w¨…3·ãuÀx…WPLã=ûçð:iàÎö¬§ñL~«´b’ky;NŒW8UÚÂ÷ŸÉh( ®ÕêcMñ íQ§ÌÉ—î¡ÏPÆ/.Ùc +ï6×ÌQ¤PïY{Õ #Ü
Íq„ò%s Sˆ)Àg™#D ¬Mh<~5ÙÂH–ò¡¹äªÜ_½¢b3ˆ2¼t4WñdlØ̧s@å×kz |¿
'ý6X +endobj +819 0 obj << +/Type /Page +/Contents 820 0 R +/Resources 818 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +/Annots [ 826 0 R ] +>> endobj +826 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [356.2946 363.7923 412.5133 376.6291] +/Subtype /Link +/A << /S /GoTo /D (address_match_lists) >> +>> endobj +821 0 obj << +/D [819 0 R /XYZ 85.0394 794.5015 null] +>> endobj +238 0 obj << +/D [819 0 R /XYZ 85.0394 769.5949 null] +>> endobj +822 0 obj << +/D [819 0 R /XYZ 85.0394 576.7004 null] +>> endobj +242 0 obj << +/D [819 0 R /XYZ 85.0394 479.565 null] +>> endobj +823 0 obj << +/D [819 0 R /XYZ 85.0394 441.8891 null] +>> endobj +824 0 obj << +/D [819 0 R /XYZ 85.0394 424.9629 null] +>> endobj +825 0 obj << +/D [819 0 R /XYZ 85.0394 413.0077 null] +>> endobj +818 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +830 0 obj << +/Length 3528 +/Filter /FlateDecode +>> +stream +xÚÍÛr·õ]_Á>…ʘî—dúà$rê4qRG™>$gE®ä “KywiYiûï=¸rw ®”J™éxl€XàààÜÏLfþ™HjfÊp$0³åæÏ®áÛ×'$ÌYÄI‹þ¬/.NÎ^H:3ÈH*gW=XaÉìbõó\"‚Nžùý«/¿þéõóSÅç/¿uº Ï_¼üöÜ÷ο=ÿîüÕÅð 33ÿòoϸ8í¿É +ÎýÍ FÌh1»… cèlsÂC‚3GÖ'?žü#ì}uKsäœ I›-´DTIq|[¿†mCW¤”У]R#I°å ÖˆÒ=K„ê±Dqd´š) +%ˆ÷ˆµÕ¥ŠÕªÉPˆ2d¬Lûc<ƒƒ&\m×ëí)™ß:R +1
;‚¶Â›!A ÿ QDCøŒæHÄ)(¤2=<‘F xFÕPtˆ‚Ƈûæøbú›FòàiòÃe<é/Ïí |PQ>ÐX_¸…²¬ì¹›Ç90PÄ L +ÉÝß•wã#ðëD‰ý¼ÇZˆpч˜ñŠ ƒVçøU«¬G:€ˆE˜smqE£`¯¶›¢ªl!ðž3¥žî¤ â=G¥ +УR ÏZ›2o›ÀF]qž ¼ñM[Öõ +æÐ9Ûqp Ç'²#…oÚ·…_·ò¿-ó !ÖcRÎlë‡/ƒÕSÀ¡ÈÐèíZ·Ú9ØÆwº¦¨ÛbÙUÛÚ´år×T~\¥úÒú8ëJ’À+ÌÙ´N)Àê{u*Î{:êAœÐ©>~ëªí ¢U-q?Ùõ¬01&æÛº o7[/U5´¬Æ,Zã a“ऄy:Ê$ˆ÷†Y÷¦H›¼½ ÍŸ¢u¦ + j³woEÔ£ +•È²R;ûè „ ރழa¾ý}Y‰‡&(ÇTÔ ŽKØj¹Þµ€ŠÍ lYýK› 0 +@–Ëò¦+.×Q*ç Šõ®ôŸ6ÕõÛÎ^í°ç y”¬+ˆ†£1¶Òçl±sÐYná¼ ;ÿ£ +†ùömµ "VÅOo]Ÿ³ 'jøƒ1’TO×$‘ˆ(ìixStol5ÄÄX›&>ÚV€‹>ÄCü¦ˆkØ +ÑÝÓ©çïw[oŽ ßv3,LªÈv;|[×¾wYúÖ;tÛsµÛúÆÒÆîn…Ú¨y»‹0`Þ¡¥ éÄïà%Ú3ˆÑ»²9ÛÜ¡®l;´ÃƧ‘`
W÷Fá}?•¹³vœä ‘í´ä˜$r i'%Ó¸0ãá¶ú½<&‰iâ“Ib â„$1¼)—‘D—ŸyK +!賑]ºõÁBp³ õ‚‚¤InvWGw¸§`HÝ+øXÈ) }ÀV›Q¦bL½*¯ŠÝ:q‚4O¥7´¯X<°Æϳ6 He…ý‰\Ð,ÇE€üu&40sýøp(B\ôAfÂ!°ðŒkºßy‚çT#NÈ0%y¿oýÑF'sê² ™c“ LŬ©Qá`S|¬6»
ÌÅ}(ªµw™îçf»«;p¬J˜|öÇ
›ƒÈ’ÝÖ©5#b&@ƒ8óG“=A\ôA ’sŽ4ó”¦M‘]!mxR¶lƒ@BäD Õ/“ 8^DÝ(Bï¶h‡±Á•×–eT Wã èS[6 Êf´¼íŠ¦ ¡ÃØ dYâHS’q4Ìc¶0•$lY¸@ÌÌ·76Ë,Öë;ÿÛ91h]±×WzíhøêÂ:p…Ëbí}¡ ‰ê¶ù,c(áÖþDKö÷ Và Äå¸Èµm2àC‹x‚whúãdÄ\6Í4Ÿ¿«ÖÛË;ð—Ï2@% +c\ðÂÊLò!¾]"M°Ü×™=G¥©Q>™¦Ë²Mv-fBÛ` Š+Kù`ÁºA‚í é͉³”¾>v]Ž£˜ãi?Ò{dôøgV±8¤Í”é*—)Á<mï¼wÉU±Ò¼'«bõ! ¯b
ðó–£ Â-ØåÉðKïAŠlÈ4@°Þæ¢e ¡dÒA¼Ï+—å š@†Ÿ‰.ðb @¼,ÒåÍ1KŠŠÊ”ÇhPܲWkšs‚ cè6çŒÀÔ“t{Ü5»òÈM cl| 5ô¼ m"–WźÍAbÌÊr¤\¨d{,a…µW¶Ò½Œ. + C a¨A´ã•?wnB¬ûI—¬$ƒ+0Yj:yh + +„é~<B\ôA攜#Iñ +f«è‡²À3)̤¶{³Ÿàå‚Cè™tWú +D%8ÄïŠ.^|[Ù¢Îá3 l«Sº•€ýx™ÉÇ|‘¸¿ªð›¾ÙØýÞø›F[¢ù«o?¿)×åÒ ÿýsçé£] Hþñ¥Ÿûµ¡øök°œÜ³<!H(´ »NºySD"Ú9gë²¾¶zöÇ¿£j/EÝ è¼©Vq¾§ÀrýÆßæ÷ÿuŒ:~ü?¾qÏÖù¶?/W Á‹yöÑÀ¾¯Jû‚°®öú^3¡óS[\ç”ÄX+M^ç[ÿ¤`$ +ºk'QÐ¥=#ã7Mµ)šÊ¥bð3¼3°ï³„UٕͦªË°x¹Làíe—"·öþmt> +Xða{S6…=!˜«=6ä½Ëåð=$i4mowJæEêkh*Õ4G4×(̽=Y/²A·ázŠè>Ù*¹vÛtGîóG”é¬íŠÎI°?¯ð!¾E:Hv Q¼"TÄRµíªn×ÅÇSCîÒÀ]¯NZ bS¡ÑUeLÏ]%ÏgìQ´BîíÞªôp_Ó«êëÏŽ½e& h¡%Ÿ~¼ÝŸåL#áýÈ’(&{°|!„¨ñ¦ +àM§7“7 zt>|å`ÓHû°×Qf@fáÌË >ðáuŒÈ¨ìY"Ašˆ)&÷©7k‚HqÖ½DšÚtO¤ñ¦y"õ7 )Ô¬Áú¸§R¬iÿvöIHæ¶SöIBÙ[/ÁÔ=„êÍš Tœu/¡¦6Ýj¼ižPýMC…ËyG°¯FYïÊ[ùÜ‚ŒÑqE >äg¬WªÊ&ƒsŒÞÖjØ4¹{“ŽS;NºØS;&ZwÌ’º¿ã¾bàßÝõlY”ÖUÞì#¬½m qdÿ (ÏJ9xÜTX!Ç[ æ¡<‘1z©ØÏ9Α0ç>†Ll—ø1Ú.ËŽÞvE| ܦ·1£~Y/×Ûô¸1Z˦X BS8-ý 0üqŠ¾ ý mö”‡iMó´H¹@@Ê=Ö˜ Q¤Ôÿ ½¬Vâendstream +endobj +829 0 obj << +/Type /Page +/Contents 830 0 R +/Resources 828 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +>> endobj +831 0 obj << +/D [829 0 R /XYZ 56.6929 794.5015 null] +>> endobj +246 0 obj << +/D [829 0 R /XYZ 56.6929 363.2968 null] +>> endobj +827 0 obj << +/D [829 0 R /XYZ 56.6929 335.217 null] +>> endobj +250 0 obj << +/D [829 0 R /XYZ 56.6929 335.217 null] +>> endobj +832 0 obj << +/D [829 0 R /XYZ 56.6929 306.9099 null] +>> endobj +254 0 obj << +/D [829 0 R /XYZ 56.6929 226.5017 null] +>> endobj +833 0 obj << +/D [829 0 R /XYZ 56.6929 197.9796 null] +>> endobj +828 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F42 597 0 R /F58 627 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +836 0 obj << +/Length 2750 +/Filter /FlateDecode +>> +stream +xÚ]sÛ6òÝ¿Â{( G4Hð³}j\»u§u{‰2w3Mg&!‰cŠTI*Žþýíb %ÓIgÚÑ]`±‹ý†‚s¿à<‹}!óè<Í#?A|^lÏÄùp?œ¼fa-¦«Þ,Ï®n“ð<÷ó$LΗ« ÌYœ/Ëß½ë ¿ûmyóöbÆÂKü‹EœïÍÝý÷ÉésýëýíÝïß~w‘FÞòî×{¿½¹½y{s}S
û¦ð†ۻŸohtóóÍ/7÷Ëw,:»Y:a¦B¢$žýþ‡8/AîŸÎ„/ó,>‚‰ðƒ<Ï·gQ,ý8’ÒBê³wgÿv'X³uîc™ùq¦37ɹŒs?‘¡47xSën† ä’Ò+TCƒßÐkôZ
º$àS5lh¤èSkUVÍš&úSQ«ª¶¡½[Õ=ꃈÅÿ¾ú>Ák„$žj˜æ°Ñ4€S¯«~ Q£¶º'j Â0RÍ?†Fj MÛh&à:Aàçq ÙQ·…ª7m?ðÆ(äÃe Œ =ô8!°ê.‚ÌÓ4ÙÑ¤Ô „]‚‰¤ÀÙ/í¸HxU³j;+;î²ßŽfB, Í5ãàq«voyªÜN='S©û¢«v|Ë`ŠíŠ¾t‘0PEMƒ~ +Ý÷„A›o÷MHåk²Š>hj„ +#!Zÿ!úY3ΪޚCU³eð«1TÚýš¥œZRÙ{T”±ëY#úÏF£¹JâË0÷ÖÕG ¹û@Gœ"/ìYèWŸƒ¬"¦h·;vÂ’0xˆ˜=îˆ( X|Ä¡ø`+2ÊI £…s1tê£îÌEpã˜CÝ‚ÅÍXؾ;„»ÉÃH˜Om9Oˆ š¢„= ÀUºci a¯±õœlÝî&L©wº){‚ÛåO4”Ž€¤$€r°ÄcxýÃEàir(˜±®a!jÎÀœµƒÆ‹¶È ê×l÷Ø?é"u³°Ñg×vCÏKÁ£Á1N±ÝÁV‰6lz£8S››ÄX¢˜/NCŸ³AÐ6‰Š#Üg¾Œ±2Êc iíÝ“ U.ó!ÀZ’ªëö©?!kŽ²g3
·tN„—º© ÌXQÃ$N½»Ú£É.Ñ@$ë…¼ÜÚFæc9rãÖI:dšË
S¡Pn˜€aZe…‰ôEœk†#”uÑ´Cµ:ðâiA'~¥)/~=C.ñ…p ˆÚŸ{ÝÍ‹} {¿@+9¢>Üô+òÕr `Y–|†Þ"Š&ÇZ0”÷;“fèB!Èø3tc? +epÄ'Q[€>©ÎTLÏ A %c9Ê೑±ª-ÁR)– jU<nÚzŽÝ(õ“$ÎFn€l{”ȳä8Ž"Æ!À¡_0S9Fµ õÞUÛªV]}¸‚À²i‹pVé'‘LCÌ4h$P ÙòJí'JJ EÄUp4€A¯»&D$”æH´÷ Ѫ*S*ÂJ{”‹|àêˆ.úc%‡þºç…ã-h=m*s0,Û9o%6Ž¯‹b(ðl°z£˜ANl…v +{øTc`§•WÍæ*‰aØ>&˜èj ›¤ß“"'°ãлmíêOj»«õlñEÒžx .Õ?ôåU}‹A8÷¾‚Pf'ývÆ'¡“inC •(¡t[pŽ—Ž(ª‹Ì=§ƒç3‹À’j®€°ºeÓBŒ£êL„¦än¸Â¦$\Ó È{óÔóàXµuÛ>îwh ÒT0ˆ&¼"Øxf`•Hw'Ö5Þ=5" ÌÌ{ß!ð(¬PÂȆÀ¯hõx•ÆÆ í盦~$6曺ÒØ:²ÈNqÕÙ>Àýêá@ˆúHUN0Ñ5h«ÃHäÇó + n÷£#™ôYTâÊã·"A~´Šõ¾³ºI2c'µÆn býò"½–怚vRòIõ¬;’u=)½d¬\ +0/u
u;õ£0e.„yGèí 'âk." o;òôf)(zá—»mAÁ‘åš&mcÏVôÁ§z 2 7Ñj(ÍŸ(u̬ìí¾ ª]íêíŸ]>§ùðHóС¡DTÄf|ïî©D”Br‰PW"ÂÌ>yxÕbÒãp깑®#j^-}[÷Ë`$ +×âüí¿QÇ?™£Ô—YÎÿC + ÑÏÂ<µL¡ a~ʹû¿õ9ëÿ×kendstream +endobj +835 0 obj << +/Type /Page +/Contents 836 0 R +/Resources 834 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +>> endobj +837 0 obj << +/D [835 0 R /XYZ 85.0394 794.5015 null] +>> endobj +258 0 obj << +/D [835 0 R /XYZ 85.0394 497.0473 null] +>> endobj +838 0 obj << +/D [835 0 R /XYZ 85.0394 468.4726 null] +>> endobj +262 0 obj << +/D [835 0 R /XYZ 85.0394 408.9221 null] +>> endobj +839 0 obj << +/D [835 0 R /XYZ 85.0394 382.8699 null] +>> endobj +266 0 obj << +/D [835 0 R /XYZ 85.0394 310.3501 null] +>> endobj +840 0 obj << +/D [835 0 R /XYZ 85.0394 283.0525 null] +>> endobj +834 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +844 0 obj << +/Length 2301 +/Filter /FlateDecode +>> +stream +xÚÍZmoã6þž_! j£k._DRì}J³I.E7í%.‡¶À)2 •%W’“fý
ßd9Vì¤ñÁ+¾ ‡ä gž‡tH„á ‰¸@BQI#Ž ²ÅŽî ïüˆx™Išô¥¾› }<4RH *¢émOW‚p’h:ûe$EcЀG'?^ž]œÿ|u<–ñhzñãåxB9 ]üpêJçWÇŸ? _'$ádtòÏ㟦§W®Kx ß]\~r-Ê}žQzuzvzuzyr:þmúýÑé´ÛK¿3³‘?Ž~ù
G3Øö÷G1•ðè*¥h´8Š9C<f,´G×GÿêözíÐAûŒ([mË!r…£ÌðãÇñD`<šÎóƕ·kWhÚ´n]±ºußÔ}²j±Ðe Ö#Ôêð#Jý§ Pä¥6F‚•NAŠsº1m˜,
64p5}¯Ë°¨ju7÷cÛM Eu—giQ<îšp¹µ—nŸËZßçÕªy²7Pöñ,f=C‚jªP’HeU_ÏuQLšö± +ì ²"†TrÒÍÌr³¼ðp^§‹EZ?ƒµ L¬Xˆ> +a扔”ûd[ú3MÞX ;ðµn +è +u‡jVG + M Øk»†9°]øî@îotg^oó›Ç5¹wÓö—I€1Â}$p©ºœe‹ƒK‹,,nÕæEÞ>Ž !£ .\[çmæ~êAz@2Ž8gÉ 2®ÁŽæ´W3½×ƒ^®ÙH—Ží°Yo=‡2Zˆ‹Ãå*˜RÄŒï1•ˆ$>ü® ÷¬Yê,7²6Ø«Á½„¤³èhv9ÈôXrlZrß“®à˜ÃU8ëH +tÂuVƒt°Î¿ôXЪéjz}q¾Ã]=K *K Ü] +’1ºÇ]˜!*c-pg½3&x˘FaÙ” Qb 0„úÞæ|h½–{ÄáåÂÑ ú¯ÇYY§`(“ÞÁ½aÔ¸†À€¦¤õÁ]}K Ö]d@“QBéž”DaOLÄUŠ‡Zþ-ÉÂÊ6@ÆV< Xàh¶ZfÀ€/e€‡¨Ä“F[ÊZ_hü×|À£ùÝÜ÷<èuÙ/§*ì11-³T/ íSVb^²˜Üt³¹ò, lCdx8³F\>hL:À3×æ '¦çŒ÷à +6îBn«®¿iW7^eé55Ez?ø&÷Å> ˜dÜMféO‘î¦}³¼ßh' +t琉˜ß \r®–©^ï0“A\ÝÕ}Óߥehß¾ªƒ@˜ÆJ¸lL6·w6èŸéÛtU<½”ºãuÞ{{|}çÛᲞ5Þ-ë§8F¸ÿ†9è1ó6Øð¨dm½Mu¸gº^_곡‡šµwLeóú¿t€:é\l.i“ï2üzOï–«PÙŒDq$dâ¸z[¯ cÌ&À$_•ëìu© '#;ÜÕ?]^_Ÿž¸²Ñ÷¼1û }¿Ö`%Lˆ=ÖL’”¹¨¾ÏõÃkè¤ ªèŽÛb=‡5ÚCŸØjBö -‘I‘ôÐë¯Í Ýa°ÞZe°—¿Qÿ?ÞÕˆ"(–‚E ýÂ…ðÛúÖoìT&(NH+HµDÄý •¶b 1JºWÉ¡‡˜SªÀ Ÿ½1 Ä[–i€qPã’y™ç› ”`Òåÿ'¯¢‹ô1ä÷"”²l µÌô:ß!ų¿2`‚Œ
ýåŽö&š—þÄúw +¸U°$¡ÃþéÜèe ÁðÖÊà Tl/ýòÿ-Îendstream +endobj +843 0 obj << +/Type /Page +/Contents 844 0 R +/Resources 842 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 813 0 R +>> endobj +841 0 obj << +/Type /XObject +/Subtype /Form +/FormType 1 +/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/warning.pdf) +/PTEX.PageNumber 1 +/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] +/BBox [0.00000000 0.00000000 31.00000000 31.00000000] +/Resources << +/ProcSet [ /PDF ] +>> +/Length 557 +/Filter [/FlateDecode] +>> +stream +xÚm”In 1 EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5 oʯÅésÀóή¯ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5? ùÆ [ÄIÚL’~ ”F Ø PÈùYÌÀ¹dˆÐzZ8å±Ýƒ²ÙËò‘–Œ€f¾Å(ÌÀE#@x˜oL Û¹[ƒ±ñðù +ä +6\>RgÈbÏWÖ¹j[†› +WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk; Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½t•‹ùD„™Â²]°Ä(‡;„ ·åŽ°Šr²ÂÙÄLûˆ
T¥Í¡èª‹ŠŽt’¹w_ =Î]ˆ‹=¦uSä÷—ä"ï ±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèÐ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ' ^
m" ^˜h±ÎW9AVªy ©/fýÆ"•œãûFy-Sng \Çdª¼˜©Æ¥†Í}B©• µŒÎ$âw1.¶&Øíþ²C¶O–ÃVç X×9g¹E{îÇ< •ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ_[Èü.øšŠû*]3QôçÇñ !Ö-žendstream +endobj +845 0 obj << +/D [843 0 R /XYZ 56.6929 794.5015 null] +>> endobj +270 0 obj << +/D [843 0 R /XYZ 56.6929 486.3415 null] +>> endobj +849 0 obj << +/D [843 0 R /XYZ 56.6929 454.4975 null] +>> endobj +850 0 obj << +/D [843 0 R /XYZ 56.6929 395.7282 null] +>> endobj +851 0 obj << +/D [843 0 R /XYZ 56.6929 383.773 null] +>> endobj +842 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F84 848 0 R /F42 597 0 R >> +/XObject << /Im1 841 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +854 0 obj << +/Length 3138 +/Filter /FlateDecode +>> +stream +xÚÅZKsãƾëWð*µÏƒÝ“,k ¹ÖëÍ®|²].ˆ„$dI@! ••Äÿ=ÝÓ3x %[J¥xÀ¼ÐÓÓϯ3?1s†q•éYšif¸0³ÅúˆÏ®aîÛ#Ö$qQ2\õõÅÑWoœe,³ÒÎ.®´ ãΉÙÅò§ùéßN>\œ}<N¤ásËŽcùüëó÷ßÐHFÓ Þ¿=ÿöÇ'Ç©ž_œÿðž†?ž½=ûxöþôì8Îx_ +{^x{þîŒZß~<ùþû“Ç¿\|wtvÑex^Á äŸG?ýÂgK8öwGœ©Ì™Ù=t8Y&gë#m3Z©8²:útô÷Žà`Ö¿:%?£ 3N¦Ôr&ËŒ‘# šŒY%•— Z€ +%éXÂ7–ËMÑ4¿®óvqóëªlZ¿6ÙZLÚþý
±0>ð SÆqÝä#ú¦ø™sY•mYW4’WKjüØä×EØFí?éÅMÑñÒ/Âe°8Jc—0LX×4Æ´™çMS^WMèУyX_Ö«rA=’*¶Ú:,«ÂDy,Ü Ä‰vîeJs(X°mÅÝü<lu]´aŸ26zÚWžR½ 1r»)Á + ¨sפ)¥™tÒÕZ_±Žx‚È4‘§æ50%øüd±è–œÖUKÛå½Ã…Ôü™~rú®§`~ЋHY¦Àþqã÷u GP +Äs“·Ø²^@82b'38‡Ìü% “pt}×—adI–S,iø¾lo&ì@¦Že<‡
Á‚Ñê4¬¹,®jâŽ6*ÃÆ‹È=q`QðK)VMqSÐ[o`,ÍæU üBA–Š-µÀ÷¹_ ¬Þ½ +4*PBÐ[dÅwV«ú¾XNÊýÀ/ºªqUY]S•4Aêò®\µIY½ÞŽœBh–¦©œ«˜SZ?%vB0¦é8vþ¹·"#¼—Ø^è=´B3¾1&•t‡J ‚1—fr™– ¢¼1†éÈòêaÂj2Å”0&XÍ÷hÁÒVÁanjp¶-bà ÓÚêY`F=ÿ€ +¸±æÿ'2Spj©Åc2Ó"'s¬êªøcB«ê§ÉlÀÌKÉ,渧“Œoì—¡Üc2S‚/ŽU½ÈWxü? ¸TA|EŸNåüüÃMC”DiȆ¡>æÆ}n€Ed®0Pí}½ùL²j‹ÍU¾(ŽÅ<¾Pu‘gËÚyš‡RèÕ
dò<9÷ªÀá$ØÜÓIÆ7öªN[+Õ£æÎSfuW]…‰üɪ™ö‘Ê=
!¢)š!¥ú™
=I§8×é ‡¯âüýM‰ÉxÕà©fJ{79*W(B/Böz˜"37ÿT{,+ˆHCË–5
VuK[‚ +_À\Êex#§Ç}þ@&Ã{˶Y—%z¦ÄÀ¤¤D}ªÿFVED®Û›†úÞˆq 5@Í`ôн‡]b~^Ñ\sçñ$.a`‘7Å«) cM RuÒ ƒ°jõ0@]1âuŽy‡fà}ŒØŠæýÃà ÂlŸ§p/6X·SC^÷DÍDÛˆŒö{íÐ žçb½×öEÔÿYˆL2n¤ApƲ,Ãjn§ªSÜÂi2¨ê´JY +J}¤ªSYÆ´tº+‚T(‚ˆ§ëUó'J;ËT +žžJ_ÑE 8²:ð–!X§Vyû«·+ßù½Ë˜,ÔJ‰`©V”ŠþJSÚ`ñ> GÂë·õ¦í¨RÇ{”¹ C»Å%Mü JÃœÁŽøÿ\<4c202zù
½JŒ#HxÆØ›ÉRV .e
–”²Ó¢~Šÿd=ëÕkÔ³˜1©
ÎÚ±0éÕ’«ÝšVÙ BîbŠ +Àgªi¨ˆ[)0¯÷
ó ädèoo¤¤Û)é. +û¡h‚ÄÏaĆ5=óàQîó¼íÍÒ½R•:ƒ*OXpEwÏkG1’Ü•«4 ~
ñª[vH°ŠI¬€x¼9ÜÅ" RΕÜÅ +[¤ `í†À¼ÛPy`}ëc. +:L+¶VÌü¾\-ýUÙX+oHûWªbù¢ ™^pàÓȱ
+Œ ë¶àÙë×SôbÂ…‚‹²‚„;€}Še¼ÞÄÊø·r}·Žxdq·AÌ$„$ékœ29¿_ R2Üu_m¯ÉŒ/FÈèCÈÏRê)«ƒ„nœ!ê½Ð°,À>Xå)úm ѵ ^ÄýÖ½H&lO0áºÐ¼*u. å°¨}>t‰“Å è’J¼73ݾ hΉL¯ ¨¾6&UcÅúÏ*»¿ èY:õå –Msæ{øŒ½a,-½éŒJÓƒNO‰n7±Ü @õ¢¥:ÇP“š}Å +:>ÿ¼êr.¬Øý“Àè+rgxÉÄå +°]÷å³é›x ò0…›5`}+²Þèw3`nS̼ÂIý¸9L§`3‡XfL·¯¹Ëiˆá2QH±ò×-A8ñÛû´W@x…"_<âì#}At @¥`ovK +endobj +853 0 obj << +/Type /Page +/Contents 854 0 R +/Resources 852 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +>> endobj +855 0 obj << +/D [853 0 R /XYZ 85.0394 794.5015 null] +>> endobj +274 0 obj << +/D [853 0 R /XYZ 85.0394 769.5949 null] +>> endobj +856 0 obj << +/D [853 0 R /XYZ 85.0394 752.4085 null] +>> endobj +278 0 obj << +/D [853 0 R /XYZ 85.0394 683.64 null] +>> endobj +857 0 obj << +/D [853 0 R /XYZ 85.0394 653.5261 null] +>> endobj +858 0 obj << +/D [853 0 R /XYZ 85.0394 576.1881 null] +>> endobj +859 0 obj << +/D [853 0 R /XYZ 85.0394 564.2329 null] +>> endobj +282 0 obj << +/D [853 0 R /XYZ 85.0394 420.3273 null] +>> endobj +860 0 obj << +/D [853 0 R /XYZ 85.0394 391.7481 null] +>> endobj +286 0 obj << +/D [853 0 R /XYZ 85.0394 295.8129 null] +>> endobj +718 0 obj << +/D [853 0 R /XYZ 85.0394 264.2689 null] +>> endobj +852 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F57 624 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +864 0 obj << +/Length 3271 +/Filter /FlateDecode +>> +stream +xÚµZÝ“Û¶¿¿Bº‹Á7ÀøÉqÎ“ž/3í8™O¤$Ž%R)Ÿ¯þïÝÅ)ò>ÚLGåb±Øßâ3?>Ó&1©Hg6U‰f\Ï–» 6[ÃØû h‘hѧúîöâ›wFÌÒ$5ÂÌnW=^.aÎñÙmþin‘\6ûó‡w×ï½ysiÕüöúç— ¡ÙüÝõWÔzó槟ÞÜ\.¸Ó|þöOo~¹½º¡!x|wýá{êIéñÓ›«wW7W Þ^]þ~ûÃÅÕm·–þz9“¸\|úÍrXö,‘©Ó³{xa OS1Û](-¤Œ=Û‹éöFý§SúëhR%æG*=¬gÔ¸™Ô·N#…ìô䔾#êûÓM±«ÛÔ`ÅüC¶ó-9ÿ>ƒîŠzßÖU{¸än^oi0Ûï·å2k˺úý\aBëD:-g}YF+쨞Yhjg|(sYf5i¢¹àƒYŸÐXGÿÜü#¾8ÿÇb‰k'íÈD&<çIÉ%Õ3z訞‘cÌ
åøiNB¬êmMYAs—ÄËîêcKc˺ú1±> ÊjM£Ÿ‹‡%X•XÅÕlÁy’j-zšaú~ ÜÙV€$‡*_¢æX¢¬ 4 Í‹0†r—8Ë »^(\Ï«zb*!À‡¬ l–hˆõ¶™˜N:`y lÚ¬-vEÕ벡çÞ[qÑÀÀ«‰ÉRžXm¢ÌøB>5l·„8FT÷åvKÌ›"ÌvÜÓ3£G^¬²ã6Œ-®„ ›¬ªŠð²-›¶¨hsàÕo!<ÛMÆëz—-?“6!ê¼úlDz<«„EK§æ\Ø„Áã+øn•SÙ‚ë_¾[ÖǪ-ûìÐÒзßr¤–óùuE$í¦ Ÿ-³¦xu¹PÜžxfÛ¦&ºûMQQ J?Öµ;æF¿`gJ¥Ìxgý"‚õÊý”uº \ÒÛoP Pó»chäu6!ÐìB×&ûRP+›²yÁ—ÊhôÑoÎ^&Â(µÍŽ¨£‰Õ Hx/04!: +††âµ }ºiÛ:ËCÏ&,cYïv~güKggðÒÓW+²ÅÝéKŠ œ×¸thY;¶a/µíëÆ@,w¼œa¼"Íp“t Œ±eÈ‹¯¨ÀoŠv2´@ ÃœÀbdýX XÇ—â0ÁX£töÖ<4`r«¼<Lð7V¯£ÅÝg
1oöŲD%9uIJul¸}qðîXn[ ÔàHÞo/S1¯ilIö™QúeÑðrÃÎÀ +À1 +ÖÐÑ95övN/;ˆøÙ:~ØÑ´›cèòÒa——ò<ùTR61JñgBžJXzŠã>ä©+È×-1ßeŸI,\Gˆ×r-í³x]7My·Å
’†öNÚù± YEÏâ+äIÊ’0 6ú =N0' +ÁË”OüÒúâ +L&©•bh +ž€÷iÊcAAñ„F5 ¾g
ùØ^fUè\.©¼Ã0ÒâÆéëhÉ¢=ÂH^4å)ñùºG‡¸*&!—— A)Ì€a¨¢†µ ‚®À€ž? | Uðn°mq¬ c ™šg%ÙFª®:ô¹%ÎÐÁm¿TlTEÄäícÐz²Ø +W ËË&Xtß +OšÅÚäUg aòŠžx‚1e .vµ÷S~d¹çÇBßNÁc<4é$O® å¹ +¾8y¾Û…§×S,Q)3ýÒسè6 +{©EbSÊšñþC_.8cˆ]—Ûc 4÷±gExùqÈ@ÛS' ·±IƒÑ&µWå¶À„ôzJ"6–ļ@’ï 4Ë*–Ò~“ƒüêÁéX;g"ÞN bÅrª¨¢–`°LUG¿R#ü/ EÈx +áQ`§òPϳöŒz_—‘Ý=&ÂÍ#g›àŒ +Ãí®¬ "ï• ÙÀÙ‰(梲¢ðu%<=ÂkCaÙg Sh7R(‚×Y.=C"÷‡²
¸Å„‚¶»öˆŸ™ +Q–,|››šˆÚg +çáx—¸_ÐR'Î4l"Á1žÓxªØHã
q'•C×ið„¸3@ã©uàâ©SqMž,ž˜"1ýåø ×1¥]añ€Êªý“À鉄óyV¬õ01=âÐÜÊ +9–huÉcÿ½’:Á?CMÈͺÔþ‡ÿ—uú•²x- ùCu‰rÀ$…*£?ÿh0‹þ o'àßendstream +endobj +863 0 obj << +/Type /Page +/Contents 864 0 R +/Resources 862 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +/Annots [ 866 0 R 867 0 R 872 0 R 873 0 R 874 0 R ] +>> endobj +866 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 755.8266 256.3816 767.8862] +/Subtype /Link +/A << /S /GoTo /D (rndc) >> +>> endobj +867 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [268.5158 755.8266 332.4306 767.8862] +/Subtype /Link +/A << /S /GoTo /D (admin_tools) >> +>> endobj +872 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [378.2799 116.2526 428.5017 128.3123] +/Subtype /Link +/A << /S /GoTo /D (tsig) >> +>> endobj +873 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [112.234 104.965 168.4527 116.3571] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +874 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [75.273 61.5153 131.4917 73.5749] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +865 0 obj << +/D [863 0 R /XYZ 56.6929 794.5015 null] +>> endobj +290 0 obj << +/D [863 0 R /XYZ 56.6929 441.8384 null] +>> endobj +868 0 obj << +/D [863 0 R /XYZ 56.6929 416.1193 null] +>> endobj +294 0 obj << +/D [863 0 R /XYZ 56.6929 378.9792 null] +>> endobj +869 0 obj << +/D [863 0 R /XYZ 56.6929 348.5817 null] +>> endobj +298 0 obj << +/D [863 0 R /XYZ 56.6929 276.8275 null] +>> endobj +870 0 obj << +/D [863 0 R /XYZ 56.6929 248.1435 null] +>> endobj +302 0 obj << +/D [863 0 R /XYZ 56.6929 167.2435 null] +>> endobj +871 0 obj << +/D [863 0 R /XYZ 56.6929 135.7502 null] +>> endobj +862 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F58 627 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +878 0 obj << +/Length 2414 +/Filter /FlateDecode +>> +stream +xÚ¥Ù’Û6ò}¾Bš*‹&^ñ“㌽“ÚØÙñ¤ò`»\ Ò°Ìc"RV´›üûv£!qâ©réA@hô}€bÃOÌò$ŠU¡gY¡£$ÉlY_ij
¬½¹¼gá7-Æ»~¼½xþ:•³"*R™În×#\y繘ݮ>Ì_ýë寷W7— ™Äó4º\$i<ÿñúíO)èïÕ»·¯¯ßüvóò2ÓóÛëwo |sõúêæêí««Ë…Èç%cxäÀëë_ÑèÍÍË_~yysùéöç‹«Û—1¿"VÈÈ >ų°ýóE ©"Of{˜Ä‘( +9«/t¢¢D+å!ÕÅû‹ÿ G«îè”ü•GI.³ j5%À¤ˆR%•àí½E&ž¿Î²ÑV‘G…J3À{¾ØÃ)£BJ¸)MÈžÀªŒŠ<ϧ] c”Ž‹4™DºHNØ(WÄEÀ°Q‘$’¹xšSbnª®…‘Ìæ_švßÐÐtô߃4h
X†A:oLmÝI9/y“¡•U[›’Ïã.íšò4+W¶éËõ¡l6t(¸@1ƒS±œ_÷^ÆxçñuÖ±j–‘B‚¤˜-Ç7nWh"öe¨D•Ä³ßÙíW»’Š£Xx!u½ém
DÚ E¥ è ÐöRäs <v}G‹ÝÙöþÞ0„o%hK0Çž+7
0ç`û²¿÷gœæEäÄŸÏÛ-‰ådnV+¢¥ãýµé—÷$+
¬§²eU•Drž)y>Ú@; #¢aT6˶&•Áž†aýÞ|µ´vgmC°33°n@ÖG’YͳÁÊ +°®jÓnAíç
é?öÌVç’ë£a˜ÖÙ?yuåR&¬êá¢3ßÇ’IV̲\Mù÷û¶Ç¸£œðíTFRCܶ=îÛ ØX3/(G%R”·`YýÖ A¤V uvY~Œci;Úfn—;Äá¹Ù{‚¿.M_¶
côRÂÌgN²n¡mÐÉ š± g‹BF*¶ÛƒH]MïŽi5ïví¶G£Á)Òr~ûþú
ÁΰꤑŒ'AµY¦RÇ}m–‹z•LÈMg`±ìÈT^<b.2´ÎÒ!~,·¶?µ-2ÈO:™¥…ŠtªÓﶕãbŒòÜV´Œ£DAf ¶QüršŸˆr`¹Pc{aºpì”1¸/´¤‹;KJU™'2tBœ]=pw Šï0Üç
ït.;é>Ó{† c4]¤š&"ÒÊo$ £!âv¶Æ( RH)Y 4P£ÄóªÝl(ò +ÿçDê*”<1÷´cyošÆVÁä3åÊ> ø'1mZ—o0è!8r(ð¬TQuV ¾ b{^ÓÑ숰ÙÕw˜’püòQ(
ûïhºkª².A1g>…¡8`¶+ÿkÏFrÆ'“Ì2Ý¡ùŽÇŸ×fYVš¦2€?Õ¯ìv;E×_žßª:òñbL‡˜fÄbZ„KÁ-a +A¨ +„·¶¡÷fÛ Öáooá¤õ ¼;Q¦DÈKÙ¬ÛàØÊÞíSUU•—e°õ +&’V IUˆóÚ\)hÚ©Ûì¸ +F¨«8qq¾šmiÑ&qÒ®i×À´>ô'q²F;Ã¥FØK:DóÐcÝa×ÒMp§ ÚS±ð5†OçìQ®Ïrjøá~k¨ÛÀ¤ØµËøî¨{kwýÚö÷íª{FÕ?^^8r
ŸS™Ç5œ¹xÂ[ö奘S"\þU±oéT<t3‚»3²<¢fF û´så^€Kƒ aQœø²dpɉº-ŽÒÜ‹t¢m¹*°•]²ÝÞ·{ òÛ Ë +¤iy‚–€ÿ5´O`ɾö [¢ ‰]±·eP`jî1ÒÂQñÎUÀRk¨…§XÓP|èæ°ò,RBç ( vå’N|©¥¹ÉÈŠœÓÔð¾Ú4LÛ ÃÉ +L2._èÁÀ: +«ƒRa¼iùDœÔƒsM9 G9î‘lœz|L5·’žLnG×'Q壔z"TàÓLZä^_‹Í7ß[ ""êa’|›{|YEfåŽÒãªÂGm•J·Hpñvë© :MœüJéñ›ÅÙK ]Ûå(õåŒ7ÏŠ^˜mcC)×-;-É+
Þ§ð @,Â"¨›òƒ* +endobj +877 0 obj << +/Type /Page +/Contents 878 0 R +/Resources 876 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +>> endobj +879 0 obj << +/D [877 0 R /XYZ 85.0394 794.5015 null] +>> endobj +306 0 obj << +/D [877 0 R /XYZ 85.0394 662.5434 null] +>> endobj +880 0 obj << +/D [877 0 R /XYZ 85.0394 634.6304 null] +>> endobj +310 0 obj << +/D [877 0 R /XYZ 85.0394 376.1585 null] +>> endobj +881 0 obj << +/D [877 0 R /XYZ 85.0394 345.4362 null] +>> endobj +314 0 obj << +/D [877 0 R /XYZ 85.0394 136.7105 null] +>> endobj +882 0 obj << +/D [877 0 R /XYZ 85.0394 113.7908 null] +>> endobj +876 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F77 703 0 R /F42 597 0 R /F57 624 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +885 0 obj << +/Length 4116 +/Filter /FlateDecode +>> +stream +xÚ]sã¶ñݿ“—È3C|‘`ïéšÞ¥×6—öê>tÒN†–(™=‰TEÊŠÛéï.v’dûÚŒ .@`±»ØOH\§ð×&K²B×y¡“ +s½Ø^¥×kèûîJ𘹠4 úõÝÕ7ï3y]$E&³ë»Õh.›¤ÖŠë»å³,‘É
ÌξýáãûßýåÓÛ›\Ïî>üðñf.M:{ÿáï¨õݧ·ßÿöÓÍ\X#fßþöí ïÞ}¢®Œçøõ‡¿!HA “~z÷þݧw ¿}wó÷»ß]½» {ïW¤ +7òÏ« ÿž^/aÛ¿»JUXs}„—4E!¯·WÚ¨Äh¥<dsõç«?… G½îÓ(ýDšH´:' V1š"É”TŽ€í®¯Û¦Ülž`k*Ÿ•›®Å–mêmÝ°¨¶º®\WíªÇj_÷O< Þ6~xÙðXovÏ •‹Eµë«%õß?,°x(›ÆÏó·Ô¤¡gYÊƪ;¤<ìo, ZÚ¤7V7«–‰ lb™Á +âG]ϵΓ\ ¢Ia Ê0U"Ÿ *@eO/}KϺYlËŠ^ÊJB˜Äjë5å6~Ž“J“¢P ñùºjª}éhä«·¼B×—ÛÝ-´•&Š!p#×íþ‰Þp F§Y~Ó2¾§ð9…MOaG¡³Ä*›M)0Ð èîžMË +•ÚYëĆDLÀ!VÅ”¾t +~ãÄK€ZY””¢.h[Ç£”žŸ«jG½Š§Þ,é}´¥”%0õŠ%“£oò1I i–{Êo€òû.A>ž“ OˆàX:wföC×Së¾BåFê ßk†ãqÃ'Ij z? TÖ€O""å(Ê[?yà + +ômd¥,Mr)# ÉØB`”à±·‘ÙÀË<Ÿ,ýŸ°&’9•MÏxt/0@ëWmº8–¤ÜΧ•:)´Ê_#™LŒ2z´'™çSN Î •¤Ff¯$Þ{8Rª³¿ÞrFŠ-'c‚®|Š)6øÞæêT±¹/³9QÝ3WYž€°'Â'Skö‘´ Ž´ö +`Ía{Þ$Ýј_9!ÇÁégèŽú•9ðA^`ºú_1#¶~*Ò¹4¥c¬Xv]»¨ÉÕDø±FsŠ=Œ¨fý
Ò·¡»¡Ö‰¾ “öš
kJQ˜$Íì‰ã³lçªf¬±Å^m.:©÷•›Á¬$\»úyQUËîäúYÖ ï<gŽ2Ü¥ÅìcK ¯ö±=0ß‚{…/Ÿ!LáØofOøMÌÎ’Q¯¬ú¹F_iMoD=h2r¢»”=Vî`gË –ú¢ÏlÕË`³p½àfVXƬ〆Ÿà +,©Û‡:,Įٮ©oíèÕ û$±Nd]ÈBÜ°6b Âsvdp Cps œÔ,ϳ—|ˆ½MØ´ó H{ª 4R~âv}‹T™ÙB$â ¼¸Sìã,B´xÝÔ¦ Ï’Ñó +ÊÐj)_å<
Š/œYurV[:«€bÝ;aHc@Wpl”«3œ$ð‚~;ÄßäÔ¤àåeö$ + Ɉ ŸAÇ¿ÝlH\ “AÄ°Ø×÷|ß>ò QKÀ£©ŽÔ€ +šV‘_ Ø•. •óz‡•%‹*|ßÆ$ã—ÜšWÐ[$²bBp”B™ãÌn…m;^wYö%G\Ô<=±Æ䃪”¼y|¢\õNñߦRŽ°A§ ‡¦¯ùË®Ýro{èçíj~OTÀ¶Â¨ªî¶ôJ˜mº °çù÷7¦DUØ]ZÑãBÂLcÊfªÞ‚CÇAgùs½=l½sÊU¯zçLÒ÷ÕCùXû˜öbòÀÈqÜëšk9ó8îòcDS¾#šÆ 8Uu2ǹ´ø}™|Ù˜Ú +ÞÑ©JVæÜ“ˆžrPdS©ë~q„æ"Ï€
ÚN÷"ë,ÅtËO 8ü4ÿÛQH*ˆÆR5åçªF"á ¯øSô®¾"Ð 22 ++ðAüÀ–L·ob2²Û×M?§(Ç=U]ÔTÒ¸!m5;¢ûŸ7´ßÀ>k$
np÷ÔÅ}U†¥rKr”[’Ót8o$Çy#Éy£Q/¬Ý»@ÚèÉÞ =š}ð³pbâ°å¼)8×¾'oÆU¹¨75¨K—|@IÁ?áüQqšÁt±.\¶ +Ÿñ³›$Ó…~‘`2‘&óqÀ¶ä9wpâ0““f³ß7í‘¡„n_;MïÞ‚DØ¥MR¨p‚>Wû&žLOC¯©GŸH!<rÀ¹},Ãg5ËåkgÙ–õ&®t@÷â$^þ–%¨êØŽœg"Ï‘)`û/!óê-]d®´…a/γÙEé«’g74× ¬.È›hpb +ÔB^¤Ï¡d!´—ÛÃa±‹Í"“lHa]œÅ»
‹}”Y 9…4¯Ey*ï1Æõ}ýÚ™VýîSñÚI6í¢ÜÄ¢h "˜¥ò‹æÿû<f<ü…ðQ¿Ð<úÚ—ù…ðÉbóåäú%DgÊŽ§Ê_Ò\f +sÚ.bãÄS‘ä¹>1ËäÈÂ×XÄDÓ»ŽoÀKwØíÚ=0ðJÆ5|œbp¿/9ÃáÎ`vÎPªÙo)¯ZÍ +þ9 É<hCNØ£ïÞø$‰G üøc;®ˆ‘ÛÔM£Š $ΰX ì>&” +†Žî 8vG¥"©•/EK:Åàóy×b!S¤CD¸Æš4\s¸?ô„ ™ Ä86g£_hp¦R3µfë¸TA ‘ÛPž¡$Çrß ÃÇhXØÔ!oTÇSȉ‘J¿N˜ô8>óIE÷b°)Gg;ðl"ôÄšLõ›€LçÏ_¯‚Ðܪ ò½R¼¾—zS/ªø¥(pÙ<M(U©8§*gKØÝ.˜Peó¤Pö¤ç’Ç©¿“®†£Áex=9å4ãl*z6Õò–Ê.Í Ùƒ¶xùz‚NR ðP`À•Ç 0Ì +Ûé—Õ~!’Ò2&ÿL1òœŠ“ä_°+Æ÷´Ø©0ÅÐÛU{Wý|Í_v=œ¾IFƒ;Üøž¿éir‹N‚²°Ir'‹Yx6½«rN[*OT;Ùh+ùv¨v¾…b}nÒÊ€ ¶ÝÜ+ X? UpWÞ²”Ž„‡¿ÌÁ5Àƒ» +Ÿíè}¼¾¥°.`P…äü §›×Ã:ô +£Cž Gɦ¯7í}‰âd3¶^Ð w7JŒÊ¸ +[•=q0÷¾*tý‹´[ë8ªö6ŸÒ<s˜RdzÊîÀZ¾óÝ%„<n+ :ˆ¾ÐÅ00ÌÏ®¤±ÿ]õ¤Z«z¸QK5v‹§bÏ:’kÃ1e(!„S¯*‡ú8Ó;¨ôP§>¯¹ä)Ø°psg ›ãt™šá¥*åUë¯
Ž·UÒcׂù© ¹8Ž§¨½ 4³23_–÷_ŽŽa$–àÀ(=D8t6öÍr×W€€û2j\µN¬åQwgF1gá«ÀÙ<œÍ‡ÞÐä5€&Õl±éøêmé9–>ëoKæv"|ðʇWû¦âA`‘šî[C÷ÄÝí¡g¨¡ + \ U5$B¨ûÚdg±Íâ(• +endobj +884 0 obj << +/Type /Page +/Contents 885 0 R +/Resources 883 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +>> endobj +886 0 obj << +/D [884 0 R /XYZ 56.6929 794.5015 null] +>> endobj +883 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +889 0 obj << +/Length 2466 +/Filter /FlateDecode +>> +stream +xÚÍMsÛ6öî_¡é%ôL„àƒ Áô”¦vâÎ6ÙuÝSÛÙ¡%Hæ,Eº$v§ÿ½ïá)#q:{ÙñAàðð¾¿, þÄÂhÆU‘.ò"eš ½Xí.øb {ï.„?³ ‡–ÓSßÝ]¼ºÎä¢`E&³ÅÝf‚Ë0nŒXÜIÞ¾ó÷»«ÛË¥Ô<ÉØåRg<ùîæÃ÷)èçíÇ×7ï~¾}s™§ÉÝÍǾ½º¾º½úðöêr)Œp_z Ÿ¹p}ó·+Z½»}óãon/»ûáâênäeʯà +ùýâ—ßøb
lÿpÁ™*Œ^ àƒ3Qr±»Hµb:U*@ê‹Ÿ.þ1"œìº«1ùie˜62Pç1ê‚eJ*'À?¾E ^]§jr’/–J³"/´;s¨êú "ÙÚk{¿ßn«f‹Ÿ<i÷ÃãÞoµúí'ë¯)¿ÓÑéÚö=AÊæH‹¡ÚY¿zð‹ÞvŸ¬¿QùóUy^$»vm_Â2Ï’îR˜ÄnK÷»>½TŸÈ™¬ÐZ:Îè1£’mÝÞ—HIgÈaËñv‘ ‘¼}(›ÆÖ=í ªáÁKoj¨’sÆy®á1|c}lÊ]µŠˆ9ULåõðLW
GB½ï-3RÄù¢§½ÑŠˆ&p<@‡Öq½”ø”ä:pO㶃ívUcɦå@« ˆÜÚž¾ +Æs%<wîîÒi9"ÃL®Rô¡ÄwS‘Ü[Ûà +(Øw]´m^âB¡dÂ6Ê÷ÖåàWe³ö{ΰDVLˆé·n·[»f1jˆ1©Öú]yœ>“þÑ®ª_9—
¸SŠÊRf2ÎM²Œ“C È1ý±Â#„(ÁTšþØŠL…¥‹ä~ïTkœ'Iƒí˺>ð±þÈWp¯¯š•!2ÃR9²ú•„”uß^'Æžž$Ðë @¤3 +¾B¸¥ ýBœNŽrÀŸF`uï!Á—i‘%w1›“ª`JféŒÇo²€„[ i ‡ªmzODyœ? ÁuM+—ODÈC +
ÿÕ+÷®°ºsw -çtž:5 Ϧ\UµÏ6ÀÀü¨<+lñBÕlÚ'Ô´M}<§ âI;¿£FΨ)Ãå‡j‹ŽKD)L
êŒê{œ»;¦Ÿ—º/?+tB¸©0²â¡oœ“2ˆ1ß §Pœ8= +¨\ǒ¨¶Í†¿ôtµ9£>´4Sú¡ì»þ ×vÍ1½Xn^xš\~aQ{{ôÝÙE„Q;Bõ‹þy5ö]g›!XÓhET1ESFóK!a¢Ä/…w ¹ÌŸ˜ccDïÿožüÕÂjöu=‘È!&ãÀdŠ!?Å”Ÿ¡íû@Ñqx} õê[l)9Ïâž7=š@×”¡4ÆÐçF2i¨K¢“èhB’ÿyêUº +í3A¶àÓ¢£º· n¦:6Cψ<—EðR¯ÄÙk+/ê ‘$´VšåÐy>3Ú 6Ú<à|ÀÈçzÅ´6b6~Ó¹s9šRà¸Æp¼e˜¤±‚ü|óýKZùù¡nÚÍv‚ ˜Ñ©Lq§ÑǪ:Í@Ú,5Eþ—Èó-WGx;5ÉþÑ‹¯ +è3ÿ
ƒÂÿ…é§ùhKÿóÊNÿFLs¦Œ‘ñÆ Ò 3‚Š' +E«ô9åã¿Ôž’þ'
µ[Bendstream +endobj +888 0 obj << +/Type /Page +/Contents 889 0 R +/Resources 887 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +/Annots [ 891 0 R ] +>> endobj +891 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [173.6261 554.783 242.2981 564.1926] +/Subtype /Link +/A << /S /GoTo /D (the_category_phrase) >> +>> endobj +890 0 obj << +/D [888 0 R /XYZ 85.0394 794.5015 null] +>> endobj +887 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +895 0 obj << +/Length 2361 +/Filter /FlateDecode +>> +stream +xÚÍZÝoÛ8Ï_aìK æñ[Òõ)ÛMzY\Ò^Ö÷°·»(d›Ž…Ê’×”“õ-ö¿’²%G¶Ók +i8 ’¿ù¦Ìþ±ÒD§< Ä©$Š25˜,Îèà ÆÞ±À3l˜†m®ïGg»Ò|’Ts=ÍZ²B“„
FÓ_"M89 4zûþöêúÝ¿ï.Îc®ßßž¹¢ÑÕõ?/ýÓ»»‹››‹»ó!K‹ÞþãâÃèòÎé ãûëÛ <%õ½»¼º¼»¼}{yþÛèdzËÑö,íó2*ð ¿Ÿýò LáØ?žQ"ÒD
á…–¦|°8“J%…h(ÅÙOgÿÚ +lº©½ø1J¸ +ëßfժÿÕc,‚3ê +è"p:”‚:ñ6Ѷ3&IR6똚Y¶.ê ㊀Á{®öâ lÕÖ&›¢[JíÐDª× ¬ÐDÚM¤gžÖ¬èhO ’I³o +S¿²~ÀfÏ€ÖcÉ«\yÛrÌf²^åu˜îUÖALÚù×_)åÛÕÆëzo‰¬°¿YLGŸŒY†eשeEû +[ºß*klæÙCîÌG0ý|žò¨Z¿šzŽÿÁKÝÄ»Îê/öúó¾é5°Ø|l øØøÓí• ’2*÷ ,/Œgú®= Éß½ésR‹áË“òrVy¶a¯ø¿ÞôÁÔµºúîÕ/Ýs¾^ñû&{„%pßXë +²Âc3£+j¸=ÔP$’ĉ`ýU(ï‘`ï’q\ùp… +ãMñqp[»þ–ÁU‚ðXóà*
}èŸBoÿ¬¢¡º}?º¾ú¹ôëjRG°ó›úÖ“*—ŒÎN$U.%Ii ’ª –'±ûÐÉ}ñösj”ö>_ +N•B@SŸ›áÄÛq%Õ‰Ú [ã>ƒ®Ëvd¦ž_ä³T…¯ØtaRšzâcú·u™ 8Cs65P×/ò²!ÏÃkèúÒ'ªK$iT¹ï@ÔSAÂã<Ç|´ºõý +G2ëéØâ#Á
ç«€¥c N÷›Ç¾KAN˜Ði`‚ž½è¯QÏ_‰R?ˆ¶o +wT. Ò‹Ì}™!ü ®Ñ!¾¹›W&ˆÐ·ˆC™ º3&Ó¤¹¦<ä +<&±ˆÕþ—¼5Å+v¨aFó܆/*±»2‡î"…nÏBH(^ð«R§% ¹Æ(™mªV$9} ìæ§f劕׾ÅoüÀî».æ¶ÿ«^ã±Mk׸e©øÜ«Þîßö©/óÓ¯I™N¡¡£'")‹a±ö‘´4õcµútÒñoŸ¡Pðº&åH´lïåN> ö«…LO@¦áœ…h¹œ‚cœî66óIs“„sŽÁÕÚÇ· —T/a¿Çá’)áZ‹\ïu¿´ñy¼}†/ÃERèG bF¨)áRÇ}?õ ƒ“ŠxîKv¿º‘1IÒª7»¡?=€ú^
B?ùÙKó ”ÀÕÚúÿ +endobj +894 0 obj << +/Type /Page +/Contents 895 0 R +/Resources 893 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 861 0 R +>> endobj +896 0 obj << +/D [894 0 R /XYZ 56.6929 794.5015 null] +>> endobj +318 0 obj << +/D [894 0 R /XYZ 56.6929 769.5949 null] +>> endobj +892 0 obj << +/D [894 0 R /XYZ 56.6929 749.9737 null] +>> endobj +897 0 obj << +/D [894 0 R /XYZ 56.6929 433.0023 null] +>> endobj +898 0 obj << +/D [894 0 R /XYZ 56.6929 421.0471 null] +>> endobj +893 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +901 0 obj << +/Length 2759 +/Filter /FlateDecode +>> +stream +xÚ¥koã6ò{~…ûp +zæŠ/‰Ú~J7Ù½»Ù^’´E¡ØŒ#T–\KNš;Ü¿)K¶ 7M()r83œçáðI ÿøÄhËLMÒL1 s=™-OâÉö>p3
@Ó>Ôw·'ï>&b’±,Éäö¾‡Ë°Ø>¹ÿ}øçٷקS¡ã(a§SÄÑw—Wç´’ÑðáëÕÇËO?^Ÿ¦*º½üzEË× /®/®>\œN¹Ñ Î áÀ—Ÿ/höéúìË—³ëÓ_n¿?¹¸íîÒ¿/%^ä÷“Ÿ~‰'s¸ö÷'1“™Ñ“'øˆÏ21Yž(-™VR†•òäæä_ ÂÞ®;:&?sÆ…–¸gOÍaºD#º~ʵfŠ§»t§\¦Lé´’pÁ´‘i§Õ× +W’)õ$ÕK¤N-¿o캰
Šàe “j•„»YÙYqÿL2}z°ëSn"KŸ‡ûh êM9§ù(ëÅÂúµ¶fH ÐN9È@ká🵰mDÔ´ùºÝ¬þ_YÔ ÕŸãXT Ún ¥áÑ,oí¢^?{ÆÕ1Ó™0žóÃ7” ÓÚ¸§¢,‰H^65Q±ÕÔ1 úJ×<2ß•ÀŽ’$‚gšâe ä?6Ui›fŒI!XÊEÚcòNŽp©4š{¸zÕuE¸ ò†&wÖVžÍ$…s`žMr½NŠv>*û['ÔÔ„[àyq[µat¾ª×mC m88+ €û»_¾üÆ ¼5šÏ½©ð¨qûY”Wó16ñéTŠ8ª6Ë;°0ðhôrXp âŽçÐåK f"%’Ï7®"n7iŸWÖæÑ¥Gëô: LòÜK ì»E‡”.‰«×v¶Y7Nüøyn›‚NÎ $,ó…Ç{Tmiòs¬ãoÆ®]܃T²!ñ:qMi6LTÕmX¸‡º8¿º¡uG̨èĦ±´€D/ð }Öë>f5<@b aŽP£[‹*¸0b½A¬ŒÌU§=sÝ‘-YÆé4‰ãÌÅðÿ-G0yæ!b¯Ó÷£ÔŸž˜ý#_®JËfõ’°\^ÑxÿÑì››‹±Ó}ÒïßÑô%¢|heÛCD§D´ S•4P؈ßøºKe˜„ :™ + #V¯ÀI'äဠKR)Œ$VLp/žyѬòvöp4bœ{@÷ +)¢úžÆ¢]úU òÙoÖ=(°ÕÖ~t† “Æ® Ñq¾¬ç›’ ò=C$8î#U>X®‡aiå6ë¼Ðþe Õf_Jo“üV™Áà^a þº‡•™&QŒ8¢Lm€H¬ )³‚«ÏŽ«òêææ⃗hå_Û›ËO9¶õ¬.÷$ Š~A´=žß&‡h¥f&Ñú(ÉâU13Z K¬t<¨,q2+!<MÉ|gWŸ^uyƒo rAǸ×øÎ’ñcY4³ºÂ¾Ø¬sL 0Ü@:Œ +à˜ÓлòQw#Èñ’è?uei†Y ˆ0ì§Õà*–!¥?.Ï’ëLxç=@!§BWK¤ˆdÕÉæ®ÇåÜ Ê$3ÉÐàç’RrÍÖÜ3‘·YÝÖ·Õç±rϤqºSÎþµSždL¦PZNÔV‚|4”Á{å°Œ¸MÕŠJÆylúÎÒ™Á¶¡ $ÔÏ2ÖNÂØàØò²±òi +ЛJÃ¥Ëü\ý¿Î—Kx<÷u¦&ËW¾ +*<†0R“…Çá>\ãwGê:¨•öE|íÓ†LXšàÆÍc—Å÷ òëL&
豚Cj\ÝÐHI@1X”öýF¬t7Ø•€êQ +ÓãÜ¥ºÿu†.2fLš
ͼ,šÖ¢wH7«_s¬ûÜ•u~yûñOÄÿ$,Œ1èߎ=…}"HœýŠÂùv<üåkH`û Ïëe^TîȽ±—y!ÁTóºõâ£j– ¦;R$†Å®ÕÇè ݳwqÔÞÏë—ÛM¾°ÆÆ [Ä ;WGÌŒ?bß®1'Ùf,h•Êk˜T;9Î
e˜þ¸žŒ›Í<¾ÜcÈi(‹ÅCûdñÿý ò ¬C Akhï¹µ»³†‹|l„NXSG›ëÅ„&×½G¬ƒŸöÐ#ÖÍ>^×V³3ßaR˜£ Í«ø„(µË'gMe µ†R,Q:Ž Ô´¶ÏÝ>6d +»†–°]Cm1€s].êá ¥‚¸Ñºð‡kEÔ«™ÝA (ö½L{Q&õ·óÚ„¼tžCMRÑ<4ŠqžÏfvåe¡ €„µ¡v 0…Ât:º¼§…ª¦Ñw aVxÐ^«]\$=˜Lp¢€7®ì `öR@L=
±ôtY´#µ-`ç®QN=å^Ïn:iá‰î:c 1í~ü¶Æ3†õg¼
‡#>¦ÿd$÷02º+ªyCSζ_.ÿ1§ â”G}'”{N(;Å;Äõ +¬ÝNü*Ÿa3XH¹Þ½3h4máŒÜÒÄóµ‚rÙ(¸/éã΃Á;Ó´ëSmf¤)ç«j\¸ÂÙ2¯*êQQù#È[p¨êõ2÷Øé2°ºìîè¶Aæ]p$—pÊ„k†ÇÜÛªêlU
mUFaykRÆ¡
º°÷¹+dž¤³p +½ÂùNæ›é¸×‘ì"AŸù£êc– מ|^Œ]ÓCºî¨ŽøU».‹Ð‘رó²ýs•uy5åy#?üpqnäÊPö¯œ#yÙ;³UÙ¡¼ p&‰o#]¤ç.taámgïÖγeý™†øÍCeô[ÁeK¼û öXÌ¿eNœÕ÷äf2D©ØÉ÷) ¯ÛCiô^Ÿ5_l5ßþà× K(‰ =œóêaÍãû¯S¹àAì”uæ™ÉøX½¥|¹§‡ +‡ub\¿ ð,UÉ›( Ð·Ñ Þ¿¤q!Iãßy¿•6þNTÒÂËSÀ»~Ý”ø‹p›¡®‹åf ÈT~ƒ9õopê\q]E9‰JwôL h4´ë³|Þgœu™€¶‹p/œË=ûåÿ°ä OZ-ëú·ÍŠ–ï¬ïTÙCµŸkcyÃ]åŸÙ²Ë54;ôW»+ú`7»ŠîÍa°ýó …݃~§ð„®Šg +o-Ó½2G¦HGXÿ? º€_endstream +endobj +900 0 obj << +/Type /Page +/Contents 901 0 R +/Resources 899 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +/Annots [ 905 0 R 906 0 R ] +>> endobj +905 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [519.8432 252.798 539.579 264.8576] +/Subtype /Link +/A << /S /GoTo /D (lwresd) >> +>> endobj +906 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [84.0431 240.8428 118.7265 252.9024] +/Subtype /Link +/A << /S /GoTo /D (lwresd) >> +>> endobj +902 0 obj << +/D [900 0 R /XYZ 85.0394 794.5015 null] +>> endobj +322 0 obj << +/D [900 0 R /XYZ 85.0394 451.0558 null] +>> endobj +903 0 obj << +/D [900 0 R /XYZ 85.0394 423.9067 null] +>> endobj +326 0 obj << +/D [900 0 R /XYZ 85.0394 301.4703 null] +>> endobj +904 0 obj << +/D [900 0 R /XYZ 85.0394 271.3564 null] +>> endobj +899 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +910 0 obj << +/Length 1238 +/Filter /FlateDecode +>> +stream +xÚ¥Xßs›8~÷_Ácò Uü†»§4uré\Ó;×}j; „ ŠDbß]ÿ÷“,aƒC <™LFBì~ÚýV»¬l[HþÙ– À vb+Œ=è#Û·’b‚¬•|w;± h…@Wêý|òî&p¬ÆXó¬ƒAE¶5O¿]З]\¾¿¹»ý:»º ½‹ùÝçûKàøèâæîÏ©žÝή>}ºš];òí‹ë?®þšOgúU`0ÞßÝÐ+± ^ +]ˆB/6ª*yR˜°2Ø%p 5êØåä·HàÄúq(Y–¸¡íõÌ7I(õ,'†QÊB¼‘”{”'dw˜•œyXpQÓrµË ŵ–×y͸8$}û4¬¡wख¸€¦ZE?.hzJ'¥5I«M’WX¬jŸA“d- +R¨£'ËMø-m\EÓÑ;œ¯UT- +(ðÆ|í›bIêAË +ZÒç &¼’u‡ŒÚ¨ýÌ€D¨Q*%4;J¯ ›*§ ƒfÊ*Ñt +Þé½ê,q\±ˆ=FA~Hecù˜hª/ä? ›¬KÌG Ÿ´äœ$€”x™Ÿ£3ö ?ú)éV1=u##ŽËdÍêîÛA«
\¡T–2Û£˜¯ä +endobj +909 0 obj << +/Type /Page +/Contents 910 0 R +/Resources 908 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +>> endobj +911 0 obj << +/D [909 0 R /XYZ 56.6929 794.5015 null] +>> endobj +330 0 obj << +/D [909 0 R /XYZ 56.6929 769.5949 null] +>> endobj +912 0 obj << +/D [909 0 R /XYZ 56.6929 752.2028 null] +>> endobj +334 0 obj << +/D [909 0 R /XYZ 56.6929 693.9224 null] +>> endobj +913 0 obj << +/D [909 0 R /XYZ 56.6929 663.1642 null] +>> endobj +338 0 obj << +/D [909 0 R /XYZ 56.6929 628.9495 null] +>> endobj +914 0 obj << +/D [909 0 R /XYZ 56.6929 601.0964 null] +>> endobj +908 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F57 624 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +917 0 obj << +/Length 1160 +/Filter /FlateDecode +>> +stream +xÚµX[sâ6~çWø1tFª.–/Ó§lJÒìt³-¥OÛ F±EPklVìÒvÿ{eËÆ6<8Èçûtî:vùÃNÀ ¢¡ëø¡ Ẩ优w\É€Z4¥ÞLßß{Ä aèÏ™Ì\DA€Iüáæî§Û_&£ñ†n<8ÌC7o Ÿ~´+¡}ܽº|ø}|;ôÝ›Éãû'»< ÝÆ£§»Ñà€aƒ'à ÀýãÏ#ûßÃøöÝ»Ûñðãäí`4ÙÚÒ´#Zòiðá#rbcöÛ‚4 ˜óÙü@‡!q—QÈ\Jë•dðÛà×-aãm mó £dñ[ Èü†1vaH|êø,„ %´ôàs£¿æY"†ÀCèæ ûàq¬DžO\Gói"sm׿þP˜löÃ1Rrðu&c°vÁ*^‚e¦t¾GV¬ôåð®ã°ÙP¼)ÈRPR¬¼\Nírý*#·äFÉÿƒÿÓJ¨
ȳ•ŠDÅSXÔ ˆ¡ífÅûãß’‹ + õCC }—º%ãwå«ÚA† +9¿g ÿnÙòc #!=ÉOŽù ´µPF çûl?\M‹wN½Àh‚!ö‘W)ÅN)žÍhr Óh A#² æÿ´âi> +h¹@¦–®ÏBµæÆ1([é>FÉ8¹|«Ô½•Eéh ¢DŠ´.Ûµ”ˆV*—kÑaÙs¡$O€Íŵ¸!Åy• +õ«ú6Õyþ‡f™2å}˜LY*€ø,¶ùZ><ÝTë»üÆäeÌÊÂèÒ+Ý+X[饱 Íû[[w§ÚZ¹tª{>¤>q[ZƒaÑZ;EK/mÔö)¤n¶›Ýì!;Õ¼cÕÌùLÍŽ-]ªæµ×óÕB Iyüî g‰—¹mGóšºùxˆžÕí¬ë +!ÁìdT½k¢jÍÐC÷ƒºÊMíœòÞFäÓLMÓ¬5OÓLËÙ¦Ÿ»ƒ.öÉëºÛÃfLsƒÎçè.Ó_ÏÑØ!%‡ç/Oò Xíöf½£ö$±mJ=e‹„°}=yòÈ/3’ìäòoÑë¬úÓ¸55~(þ›æKµ¶Ê(3ÓűlÓ]»Ä\óË3™Ô‡N·¸U)×f¿l‡(<•é‹9 ´PkžœõÕ\p¥Ÿ×} V¯RpÆ#ÑcŠ6稌òþ-3òÍU •M®íd®¿•Ê…™Šë3»b)WöÂas¸e}—äÁé¯n†7“^Ã[ñh~N|W +ý¥sùLhd,õ¦5P Ùº)PYÖcl+:yQл#—*[˸ub”4ãZ®{È׃LQ +endobj +916 0 obj << +/Type /Page +/Contents 917 0 R +/Resources 915 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +>> endobj +918 0 obj << +/D [916 0 R /XYZ 85.0394 794.5015 null] +>> endobj +915 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +921 0 obj << +/Length 3325 +/Filter /FlateDecode +>> +stream +xÚ¥]“ã4ò}~EÞÈDkI–-O ; Ç.· uuçÄJâZDZ³³Ã ÿýºÕ’?'Å̃äVKÝjõ§>‹àŸÏTÂ#Ì,51SW³Õî&šm`ì«îqi1ÄúâáæÅëDÌ 3‰HfëÁZšEZóÙCþÓ<a‚Ý +ÑüË·o^ßõã»—·i<¸ûæv!T4}ÿ;ê}õîåwß½|w»àZñù—_¿üþáî
%~/îß¼"ˆ¡æ¢ïî^ß½»{óåÝí/ßÜÜ=t{î—G7òÛÍO¿D³ ¶ýÍMĤÑjö ãƈÙî&V’©XÊ +H Å’8N ©‡íꑸfƘ'pp¾˜ë‘Ry¼fÀœ”óƶ
õŽ{j7e½ÌJê÷Û‚¶Æ6ž/ŸÐØœzË'jÑÐu ¶…ŸvBp—yd´ìàé8µ¢ÞÊÒÉ(…ló±à9Ë$™gؤóU]¡l7ÇCFÒÅ1„”øH”™ß¯ Øníá–ë¹¥‰È ‚Aá&›h¦áÏK6….˜þ‰d?ƒµ‚S&Z‘ಬWï©ûúH6[m F¸Ô‡£¡a<Š¶ñJ%L+cNìî³cé•î±(Kê¹ã‚‹yVÎRΓ™ç%9ìjÚÒbˆå a<I:,2Úƒ]µõá锲IA¿µ¾N9 MP žèJ$ƤÑjR¨ùc}x_Tú +@ÒRžœE2JÆÇI'(c28ƒfïmE ¬¡–öRº RM#3@ìõ;ÆírÎÝ– ÷BŒ 9¸ +ÜÍÑšN3jÓMZž„é™rÇí&¤ ÑÏ$‘ñ{c»_ÄT[A3 +PŸ Sv SB›S>„‰æk©w„ð¸-ÐÇà +BSÝ•¼zn@éEÂ1ÓtßÝg‡¬Lèã”CüÏp¤ $5*„Ž#DÅ%ßÐVÖæ6ÿ Y.tÐõ±ZáÁeeÑ>
'€½ J!ñ Zϳ &ž°û>'ç Ÿd äé‚IÈ<aÊŸ1‰!Öe“è°‹Ö9s*Ï<yÌt?C¼Ãš >òåÜ°²ï1yr5 «Pb J —¶ÊZ+¯‘*(,žO¡ë\»J¡T- Ðl3òZ~2lУnleQ‡ršá +‰su’t¤‰BøðíÝ¿'I¤t—‚¸õ}` йK²4Rãs_•ùc“ú<júÆ%>ÆÏ<á(MY ÉÜu†$$ÃZ³´ W6¬(û*ZZÝU‘HØ¥§Ðz€ö) @z $pÎmSôR…ï. G©® § o>œ¤J` é¤ÞS%JL9Û„0b¬2‰Öw® UýÐèa€"ª« `Éhièg!â‰,‹AeÒà5©à5‰ Àµñ O;!pÈG˜F†É8Ÿ^§+™€àg˜ß ‰D±Tu®d>Å€Ò‡'q:å[¬Ö ‹O]ª(øw )}"$»¡h,H@}%Êõ½,%sl/퉃,“NH…0FámíGÝTl|!~V…rˆÚŒåÄ>%..Ñxÿ9Æ#9BmÌ1îø”
6 Nª*ÝÐA¯²Æ¥‰Â õÜD¡$ ö@Œ8©O0#˜H’ w]æ?H™¨ÒèÃ"Ã'þ’,øIì#‹C˜˜I _¤Ëñ" õrÞ¢¹MgP× wHç”åyþ4&íkªtþŠò_—v.¾¶e¹£RI“@Ç ¥‡´avW½Š+ C“äÎêÑÕâ»h5—S 3ùR°È€EŒ ô皃®å®$h¡)Žs±þk1 &©Áº}ÕÊC–P§r +? ¥ÏX\tÅâ<’ó%ÇÝ~ÑßzMŽ3Åãë”;¤sÒc/œ°3ã!mÊÎd2*|4–I"áê˜j ¼ uE%âà>š“yP gK8.®©}¤4 +zEÕ´‡[=?®(i åµ'&M's°i¦MŸ<ÏTùÊëp•//xi•ˆA‚‡Ê¶öjP{}ßwôht\4Ì7é°n9=b!>çî Â(nþÌ#ž`P{êé'¼E·âb¸äùûœä°LlLO9h#›XÌ¡Ò•|x)7e$°_,ž)d†X—ͤÃrÑÚîð%¡hÚbÕ\2™0‰‰ÀU.:¬ 6F&[†â5 óá n4°üB›Á¶
ÃÁf@>pÒàÿEëœ#ôasty¨ñA ¿\·ß°_§öÄ*jíÇ¢ÅɈ“êjR]z'‚rLž&ãOŸ#‰ï?CufþT¦ò>
1^,ì’Â(ÅâD>“È ±®(LÀr…G‘_P›Z^' &H®nÀÿ$&“~˜¾x!¿šö÷2½_ \ÖôN5ítÄÝý´þ:Èßj¬lã÷¯Âí¦½© ›} ¢O¦§÷öIÔ“ë 9è²êüÜcð(Rwï~/B‰ânàO.=>d‡‡cõ‚´Žàù‚ +“ü‹CS¼sqI1vï‹R|ØÁæ{Ôì A‘”’4k8êŸI¡· ÐÄÖV~ápÎSÕɪ'zê +ÕæUï9@ºì<Rx³¿ i±‚S:½J¿C:g`\
j–@ q@.4Š‡.¾jÿfÙ†áÎ…Fqì\(¾nî÷`øþ!sPÝŒšZŸ’â“çIJ:@Ê}Ûø·K* 'rR™²(>½¤œT&ÄÄTÀŒc¦”¸ÅDqÿCð‹³Ç®Üˆpi6|¯Nä… 'üóq ¿ÄOn?MC +u?;úÛ¿tëˆ Z‹iÕ©f±†E<S(ˆ8:·Eÿ“¸sÖÿOÍ Çendstream +endobj +920 0 obj << +/Type /Page +/Contents 921 0 R +/Resources 919 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +>> endobj +922 0 obj << +/D [920 0 R /XYZ 56.6929 794.5015 null] +>> endobj +342 0 obj << +/D [920 0 R /XYZ 56.6929 659.6382 null] +>> endobj +923 0 obj << +/D [920 0 R /XYZ 56.6929 628.8211 null] +>> endobj +919 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +926 0 obj << +/Length 3376 +/Filter /FlateDecode +>> +stream +xÚ¥ZÝsÛ6÷_¡é“<1¿ +'vE|\¸¡ÁÃfFÇ û ý¢ÿÁ)û§ó"ÿO:mòª´ +×là-œÏ[Ò[" hY¤œ +¨õ×´h3>CÔ§óo`ôeªûÊÆ›ueí³†hèÐ/÷K‹0»/k¥Š×#T´³aHþêyÁí þ}ÃÃÐüé:öæ u~~¿#«ˆ]Ÿ>?Ý}þ„}#wç Sº£ñö#ˆdþMÙ†¥óÔP:“°2 ur£Ìã»L÷Ž›Ås×l뮹ƒ¸²ÝÙ×ÿ¼£ƒ-M,Òà”¡Ó®û
“ݧ:¯D •I®ò3ŽERlª€iWŸªë(W^fÁM°0P :¬ö‡[â“.Ž ½È ™pá°Ù öØ5cÆ·âÓ@Và_¾5#DÇÆH†bþ £µÅx–Àó‡°ØSÑ ‚Xp|1-Ì‘ ”r 1ôù +ÏlH˜¡¤hô¡¤ä ^wºÙV—Ls04ÑùJ£P›ÙITÎ #[¬!7”q)'áêW| Q퉜’BSØÀzSqYz½±þ*ùhb*EV{_A žä<Q_'’«Õ+y5càƒgÑ{]O ]9®Ñÿ~tàì]NŽ>x3rµÝŠ%I ö×fVjór"ásR…^7ÔÅsó/š÷Ñb.‰å£†r¸ <fÀçzj”PYúER¦[’©d&é²h÷{M龤tùx´-oJ}ÉÎÒ[â„HnÉëRß0ç–DÙj m÷ý¥#Ð.&ÊL9£"MÊ©º SO0Ω} 8µ‡î³ßà:êæÏÀVš€¤Îwy‘ ŠWž¾©ÆKÂ#öû§órÊ*]›taͽ¶ ˜‹ˆG4E£2;¸‚lŽ[ó}ÄÏY î)Ï ÁF^¶à}ªó¼£ê)Õá¸Ò h·‡S3® ¤ <y™Žj‚='öF|<¡ÑX£JÉh¾Õù¼eºÍÙ•¡- á8rK·Ü‘ð—\X I¶Q›¶ß…w•ÆðŒ|`a•Q̹ +“YÒnwÊííÕ‹*g§;€"Tá1ce5Áº Èà”wk:¡Ý™N%ú¦“k*¸~4Ô +TPsã€B *ÉÅ>ßC@w^öÏÌZ Ñdè\ÙA#*IÉ@ðÍH<Š‘°sQÐ& +`<G=P¹x|oPJýýt…5k,L X ðw"ãï ãçï¤ý¾õ#Š#Ñ…ßP0V’R1 +`ˆ?¡;¨¿©÷ì©'üãMvò%§) ø‘öb ?M€G½ÑÑòà½kEÀ‚æ t»†w©xM¼¦§JɸÕö¨2ºÌ‚ŽŠ™ÍôáaæGN¤ðG[}ãÅg³ðÃp^äåt Êë®q¡s?Ó0qT™$Ýn¶
Øï1íÇçà'"ô
8ŠM^&
Å‚@Ó»5Æ/èÖZƒ»z8{™
C&UÇɲœ¯üøŽ£9÷›.?tð‡XÀr;ÇòÿÞëøc¸@buç̯| KKË +?cλ †²þ_¬–ÙÒendstream +endobj +925 0 obj << +/Type /Page +/Contents 926 0 R +/Resources 924 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +/Annots [ 928 0 R ] +>> endobj +928 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [250.9056 758.4766 324.559 767.8862] +/Subtype /Link +/A << /S /GoTo /D (statsfile) >> +>> endobj +927 0 obj << +/D [925 0 R /XYZ 85.0394 794.5015 null] +>> endobj +346 0 obj << +/D [925 0 R /XYZ 85.0394 227.5287 null] +>> endobj +736 0 obj << +/D [925 0 R /XYZ 85.0394 201.8676 null] +>> endobj +924 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +932 0 obj << +/Length 3418 +/Filter /FlateDecode +>> +stream +xÚÍ]sã¶ñÝ¿Bo•gŽñE‚—Äwu¦¹4Ž34É-Q‰TEÊ>ç×w» H‰’œô:½ñx¸„–Àb¿° “þäÄ&"ÉT6I3#l,íd¶¾Š'ðÛû+É8Q@ŠúX_Þ_}ñ.Q“Ld‰J&÷‹Þ\NÄÎÉÉýüçi"”¸†âéWß}xwûþÇ»·×©™Þß~÷á:R6ž¾»ýÛ
AïïÞ~ûíÛ»ëH:+§_ýõíßïoî规çøòöÃ×4’ÑãĤw7ïnîn>|usýëý7W7÷Ý^úû•±Æüûêç_ãÉ ¶ýÍU,tæìä^b!³LMÖWÆjaÖaduõÃÕ÷Ý„½_ý§£ü“±PxuÌ@£{ tRØ,³“Ôf"ÑJ{‹k馋bÖ6ב–fšÏfõÇæeõHCmMÏßëªà‘—
Cy5GÀNgu5+ªv›·ÏÔ.‹ÃïÖyYµE•*
4uÀÍ[‚J~æ«Ë|³)*ž³¬hµ 9Û¤™µÊï¥YÖÛ%¤¦¸Ìö)_½¡×Ú/ˆPñTl_ðc`N_»¤4Â(•Âœ8ղȷíC‘·Q˜‰¿0T gMŸxNàËzS,v«Õ ½Îw[ÏI„=Kˆ f°O{J¦·L{¾B®(PÒf·ÙxYM\Å-GÔ_¥©>Øz½.H7ë=y©xZÕÛ5ïáßyÝx( ¿Í½*üÇjæ)Š§÷aŽy±Èw«–^ʆxa]*Ñ"M ó¢ªGØè%AÛQ©©Ö ¼2™à¸ðˆŒ@oËx‚y™¯v›‘u´Î€žZ½iË´Fe62ɲÀbz(èÙlŠY‰{/æ4PV„ÚŽ“b0‰‹<•Åó%Ê‚p¶§ £›rÚiÆñ™ì:‰ƒr6-ÙŒyCr +´>/ËÙ’ÈŸå
ï
+Ÿ5h> +8bÆ»v™¡ mË9šï@ WõC§ÿ}ÒS˜!5é+ä¡7”K_Æ(«Céß‚ +›˜)@€Ô!Ð=ÿÌé±Î°ÎC$ø® +еœòhf pŸKô.4Šf‹P½ksøîþöÝO“þ{W4Œƒ.Ñã†y:Z›UþĶzàž~‰m̆ K ÚîIÛ Ý×n…Þ4Ak, ‘Zÿâ i¶ˆl¦D£F¸Ú êlYÌ~£é¼«ìí)#I!ÏR?•ìèaØû^Ä¿®ttÄÜ +ƪó-²aÄN H’‹ÞBÛÔ pcÑÉùL&”íÌ3øÛ V1΋sÅ©$œO +Ð(´FÃ\–bÍyô…ž»† :dš +•˜Ë–‘Κ\°ÉâÄ$ „p×
aw¯A«òÇʱÕ!¨v]üF«óé¨]"ÒL'C¾mò¦¿3fkBp+(4qG—‘{º`8ÐE¿PmâÀÏÿHþÛì9 $¤N‰ xl¯ð°¶;„·ð)~v¼‘£«þŽdvL#ŽÒ>"
ù°™Á7þ¬À1¿k?#ñèäÇaâ ™Bãæ¦Öuáß«Ì-ê>lºgxoøÜ NyÀ\k…sYˆKÏ(‰Zët¨$8í¿v
Ÿ2ó²É V!ë‡îGœÁÁ![Åa:šAòh“dbAúJËWå£:…€TÚl˜þ¹¯ =ß{’ú.†¹ _ §ŠÂž"«à|K9žìfÅ“³„KQ)ªçhWÎØólÖ±Ô¤EªÑ ,™êôkïÏúB1© áLÿ'` 2ßÈÔüO¸ GV=&«1&«XdqšœÉýŒ2hþA q³rvú‚ZïbH€a†s"žj”y{²>cÞÅ2 pç™;˜FÏš—¢á^fDºä:öì9ÆŸrªGħe•ü„¬2 +M ÐÙº¾‰aLÅœâÕmWLÙÇ#û8§Ÿ çý—Cß®Qp¶Ø¡ 7}±(ÁÛ׋"W+E*e2ñRK>Ñø ¤¨u¬´¡)Óaùü?ÿˆJÌ,Ž4 |tJëó‹wX#«ëƒÆ‚‹M2\þ“vz¸ãäÌÔaŠ‘a'ij ~ë*×ðkQaZ0§ šr½[å-ÉÊY.˜ +ùºªŠïÅÇÒ÷«œï‡5¬(Ÿ¸Ÿ¡§?ܾ¿¿¹ûö
½ñ&éå þºæêvˆä5 Ò
•:5Ôô¼zác“ ‡}ŒmÙÍ«:¨ÃÒ>Ceg®gErè ¤¡öꨯ뾎ª˜F« >¹uFÅ–/Äå°‹Õ<šJì\ )–Ò"ÑàAÏÐaP0Ø,L‰„@u@·ÚÒ¤sÌ?ç<X^Ëi Š©õ¥e _oV¾ÝêËÚ8À_’=#„‡·‰¹kàQÂœUݹ Z*‰¾Í°èÜôþ:SSêQEŽˆ¯jëûâ§|^p)uƒÞÁéh†“¦‹ÑF$s _‰‡/M/£ Ñ/nà3±¢®:öü$·Ïu(ünr¼0´z¡Œš†Á +« Ê›ïÚeT}œ×x‰a„\0d)âì é1N¶Š…QÚ¼¢é s»˜) »C)9Æ,ð} ¯NÃŒ±¡^\ÂÙVäó“)!Ï\|Áé÷±N[d‡åå^7m„w ʦ-gljNEgÙy:¬ +† – îmH‚~¬ìŒ> ¶2„Á +RÜ‘î„Mý.îŸ}\ÖuÉN›^é´å$oxeU®óU´ådãØÑ¢q$-Ÿ[¿C:&`x´€˜4 Pp»aü.]òŠ#ÝõŽt›†‹ Ö†ü GЮm(HØd[5„¾Öö<¬
·@à ¾ecÍpœ1 ©`oº|Ç ûÌÀ‘ØÁm—5Dã8³Vœ‡i9Lµ + £–!alhœ7¨ýI&!²h8Ü(÷™ ¦›'…xôÖ…>fU<ú:ˆWzmÁ ðÝg¹Z
yE÷ÂÎ&£t‡‘Ž¾ÁuxkŠ/ªìïv Ý e!°‡ùƒ7= „Ô±ÕÿÁ…¢x·yDßãÉÅÒök¯Pïï—¬¼:5n9èa…E¢p£Ž]ßµ>&ý? n}ÿendstream +endobj +931 0 obj << +/Type /Page +/Contents 932 0 R +/Resources 930 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 907 0 R +>> endobj +933 0 obj << +/D [931 0 R /XYZ 56.6929 794.5015 null] +>> endobj +934 0 obj << +/D [931 0 R /XYZ 56.6929 553.585 null] +>> endobj +935 0 obj << +/D [931 0 R /XYZ 56.6929 541.6298 null] +>> endobj +930 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F58 627 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +939 0 obj << +/Length 3586 +/Filter /FlateDecode +>> +stream +xÚ]sÛ6òÝ¿Bo•g"Ÿ8÷”&NÏ‹sç¸3½iû@S´Í E*"Ç÷ëo Pü’”»v4#‚Àb±Xì7È ~|auÄd¢&Q‘f\/²Í[<ÂØOÜìЪõãÝÅë÷±X$Q‹xq÷ÐÃe#f-_Ü[¾ýû›Þ]Ý^®„fË8º\é˜-¼¾yG= =Þ~¼yýÓ/·o.ZÞ]¼¡îÛ«÷W·W7o¯.WÜjó…ÇpdÂûë\Që§Û7 >¼¹½üãîç‹«»n/ýýr&q#_.~ûƒ-Ö°íŸ/X$«ÏðÂ"ž$b±¹PZFZIzÊ‹OÿêöFÝÔ9þ)m#-T¼Xp K5Ïe1
\[Å"+¡¸¬f¹ Ë›}ÙÛ2_eUºÉ›ñ®yÌ:¡}Ô:¨ +d Ç‘4ÒI¸{*`}¢—õ¶-êŠÚϩ댗û&_SWᇼ@ËH[ÓkZ–õ³oÒc]oRš/qƒÔàŸÒ¯¾'° ßÞ¼ùp…¬ +¹&ˆÂﮃģýÁcwÃäÄ8¹“ä‚E‰’v¨þ(ƒù·,ß"%Ró¡:+€íNV ]¬êí‚# {ªÑÔO ßPãC0AÊ’¼\ñÖš¬‰›WÓ3^úË5ôÒm~´)WßH°¡¦eS¯6btxšGFiå5‘¼Näí½ aŒÀÕóã*Ÿ€Ë3A›óo۲Ȋvf1e"+˜ñ€°ag¾ Wкy
a”
ì®+´õØr.Ëô؃aÕ +ˆ=TrféjfíêIÅ’?bÖ´eñÉ@¢D +{PdçÜ\|˜Š¼90øþeŸ»Ã…&i/t4mCPÞY^u~°"xçT°|Ny.ÊÒ¯Ô‚¸¡ïÂnŠéDü~ øÉs½ûì<&dóAý—}A
Ü
#ÿ$À«¦Uóì(`Þ×aƒ¶Æ9GÓ(… uƒm'·0tg¦<Ó‚GÇžn§Ð^×Np™³Ž~BI¨Óõ |®\Æӧʓ +Îm,—KrKãØßóQXO×8xOûÝ`AÒ`³³GtX.ÔÁ1 ÂÒKÑ̹ˆÄDR›ÿA´"ŠhnêÖ/Ò>¥n|jÛyg9ª£ô(v½S +|¸øâ˼JIP½¶Ûì ®ãõõF,ÞÕ°¥EWóªÚí˪ÁñÂ- +b AJAå©ç´Œ]¾\ +^^ŠÍ¶t¡9ÙyKõ>xúZ*´’Éá+pرŒå¢ÇÞ?w`ÒbEÉÅêPôþsâaW„ƒÄ€çæ„q„å9 +A6‚àŸ)¾(4`ɸ²%LWäMÐ7¡`;"ƒ\Ç5añúHËÑ‹óàf™fXúpìÖñÑ‚ h xƒ .»jÑl\tN¼”ŒTÒù0Œ~µ
U"œç… +V\ï7[êFm|«¦1’Gè K êìê‹ÐOFÇjJ‚Ð,Þç 1håñÍda4Ǻo±djÇ]¨=œ¢Y¢ÎÝ.„`¡>£ê#œƒ›º‰àl#n¦· ÎçÙ>9S‹€ÎP1Æ5œuF, +Õ挑íA0²ªs~ßÀêOb pº äØ'Wî ¦K= èDñpmò|@R¯«–]ßqÏ—Ìzrd”p…œ÷Rï©QåTªõ7ð\Mz_æôrýëûÛápJmº1Þ—éŽÞ»ü‰ô5áÅ£ôŠ‚‚ˆA ¼ÌݤA ÏyÃó2IЯí®þZ¬‡5V-PF«âQMÛ_ûŽ¯É8
–`†Zr‰'Ôªƒ_õ'Ì\˜MðΫ– „A0ƒó죟ÈZ +à +Õ_»'¶J@t¤õ(V¯ò粨º/#û ¥ *j~Z•¯_¾ ì¼È\M¯x¬j ûYêHͿƺº÷Ÿþ>ùðñ¶‚´ÌZqÜ}X‘˜@òGM"V
îW[afHÿ/¢Lendstream +endobj +938 0 obj << +/Type /Page +/Contents 939 0 R +/Resources 937 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +/Annots [ 941 0 R 942 0 R 943 0 R 944 0 R 945 0 R 946 0 R ] +>> endobj +936 0 obj << +/Type /XObject +/Subtype /Form +/FormType 1 +/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf) +/PTEX.PageNumber 1 +/PTEX.InfoDict 948 0 R +/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] +/BBox [0.00000000 0.00000000 27.00000000 27.00000000] +/Resources << +/ProcSet [ /PDF ] +/ExtGState << +/R4 949 0 R +>>>> +/Length 950 0 R +/Filter /FlateDecode +>> +stream +xœeU9²,GôûeË@@Q ‡!é¡%bd(dèúʤ—÷ÿ(žÑ¯ +’$¡T¬)ÿ®ïë¯ãïãÇ_¢ýþÏaíÏc‹®½Ú¿G—=ûÌöÓ1ÄF¬lÖ]töö×ãqu‰Ý¦‹÷5š”<8Ç—ý:\;âúãñ‰ü<q¸Í;.\ži2c¶û~ð¶e¸í×qc¸=7Ä+Àg
¯ãã×ctéa³ÙL1ca·cu™šm QOƒ½¥ì-¡{wñ¨¼&kñÄÞ +¨9xcH +¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\Ê G Tœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ*êè JE¢]8hÍò¤p0R±ˆ$Á(+Á nÖN¬ +qª„Ñ«ò^ÿï>‹«>÷—
.13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù +г2"ïE9~ +n*Œ1½÷¨¾x¥Æˆpîâ‹&Xîܧ³±è\í D¤ß ä0}#XŒûž˜ ‹¸À>#^V °¡|2Îi‰9ÊÎr ) `˜¢Xh¡Ò& „hb—H°Œe"Ãê +þrÓGçX 5¾û û8‡´ÕªOª«t–Ô ³$Ây°‰—BÒ›ÀÄ5©/¨vp÷o`kA“ôr ±ñœÓ4N.4Žæ +endobj +948 0 obj +<< +/Producer (AFPL Ghostscript 6.50) +>> +endobj +949 0 obj +<< +/Type /ExtGState +/Name /R4 +/TR /Identity +/OPM 1 +/SM 0.02 +/SA true +>> +endobj +950 0 obj +1049 +endobj +941 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [182.6146 670.4177 231.8861 682.4773] +/Subtype /Link +/A << /S /GoTo /D (notify) >> +>> endobj +942 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [108.9497 246.9384 182.6031 256.1538] +/Subtype /Link +/A << /S /GoTo /D (statsfile) >> +>> endobj +943 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [293.8042 201.5839 355.0043 213.6435] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +944 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [395.8905 201.5839 444.6373 213.6435] +/Subtype /Link +/A << /S /GoTo /D (incremental_zone_transfers) >> +>> endobj +945 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [309.3157 170.8346 370.5157 182.8942] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +946 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [305.9683 140.0853 367.1684 152.1449] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +940 0 obj << +/D [938 0 R /XYZ 85.0394 794.5015 null] +>> endobj +937 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F84 848 0 R /F56 618 0 R /F14 608 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +954 0 obj << +/Length 3752 +/Filter /FlateDecode +>> +stream +xÚ¥Ërã6òî¯ð-rUÄ +t:eßX–:Êév˜HcÁÀ?›Ú +›ú·0Ô½ßÇËØBãt(±ðà™¾?ËÈŽ4g… ÆëA Ï +†‡ºªˆÂ )Äo¶è[â‚d_ +.Å$Éâ²j”NpÅsS®Y4w… J$[b4ô7pÜY“»ËôT¸3å„ FD^Öî-‘À~Ï_gjq¸ÙÛƒ \²ã/û¦mKÛo{[·2DWuB†öVzæœæòEµMõ,úö²¥±ÕôÕZ´ë¥lW=úîYžK¾+€”õXí'þ”û¢ì³æú¥ +‚8\±Û“ÀëcƒÐ Í"ŠYÄfÑ>µÜÚðÔŒÜ >ý‡¿"×ÄÙ¸}¶MÛ‰]OÇFÛ˜ ÍòT¬ö¦i¡(XºŸZù üvŽžñ…l[Ü…xûžÒ‚„÷O À"€ +q39€p":”ô”;ó‡ƒÅÂá^DUÄò ß#ù™Tø¾ØªB>@‚⇠§ºy©fŸÉâ<EÿˆfB‘=}•e¼†NÝtÜ(ý KÐ"ìîlסe¢C»ƒ ™ Š`t¢‡bI «LâàT&óÁJÝ̉Bè²FY—-:–7S«Q&ÂÅ6¸©§×2Ì›7¤°&NбqÕ¬8010 F4!/ClÈ ˜×\,#¦fWJ±` #µÜqîzÖô¸hÛ˜Q4!4HFgkìÝØè[?Žßi¨}²äÃãøIô¢1{Q„òD3
<ü,³x.íË( þ²ëìnßáuÌF]' ¶`kw~èT(T©1ïK… ²TE^‡Pàeõ ©l¸·«ró*ò:³ 49=ØUh9àƒEf7…Ì)…‹Ÿ*. ¯ +b6nÉ×0/e#”uãUù Š”!óÒ£pxPŸXì6ªæQ â‹Cͱtv`ÿŠG;+Lwïq#Ê‚L%.#˜O7!ÒÕo܆J•xûX¬ š¬86Öc•œBƒYi‰G#“Ý:AªÝr¬˜‘(&2ë&'I äé‘&²ÂšY×<õ{Ô¡Â4”„²¼`‹#V DLÎi +Ê\°E܇ï(øbÀ”âhJ±€ÈpœU£tåÐ~תš·¬êÒÏŸÜÞ–¢Á8ƒCº!GÇ9(f“S|H;‹5†‰’È#óe +—€´û†ÝJ&™Wîòx€øbÏ춌p{}óõîúCÀp¶|4që³Lô0ÎÅ3Έ «Þ¬Á=ìÄδ,PØœð~È =ïÉ,
žlìÿèsKÁVs82y>Ñì‡b´Cœ”ž¥¾kÀc›ð/jÀ#¤·KÀ‰‹nµ]îŠýÞ®—˜Ò +zà6+¶FÁ,]ví,ZQ| ÐÂeŸÏy{âJ_"ê–G + `â ?P"Î!Å®Ž#ãÅ ^&X»ƒŸæv`L)zƒq9 8¥Æ<é{6ÏBÃXu@‡`ÏÅóµlËÁ·žIç ]·…”ªoyHÈ‘z=BVEµê«¢sp†ò›ô™ ùbHŽŠWT©ÓXÔt EÖ ê39;ÀS‰ü#¿YI
.r5¸(&6~×2ð¿ £\~‚Ž»l‹Ibg¤‡"|€¬ ,±*dƒYŸ.gWv£€l.|×´ü”k‹ìƒ"ÑòÄ¢ç\¡ýH$¦°±HÌf?bTˆ²è ^±wºª4=´Vº
dŒéš[ þ¡"€ô®_!‰)W<Bo>èŒûB…[‹íVX +"þ,Bp¤Ž—;ÞïÙÞ¶IÒæ1ýnC¥'óLµuÉŽ·»}s(¥+¡rÈþqÉÅk<eÛ¸'6Q*!ñ¥Jyè„×®Õ½J¨(‚\#ù‹¤iŒõv(á±((ë«®\Šä G* ÃŽÞßÝcÍl?‰ 4 Ú¤Óý% †;óIp¢åÍX‰œBC Ä¡õÚôŒ³•WgÅgØW®Ggi'O ¨'>nö"2<n Å· ò9³ 6òb…ÅìH G„Ók•×Þ]±Ú‚˜Sv&˜ Xâ$lbAh=}[vÕ[hpÍ:ÓŽÃ2UjJ÷2\÷»~yÖ æ]Ô¤3)!âÂ\Ì$´bÖËÇŽD”åþàè”b[ÐC¼ +Ù½“ŒóOa|t&'ÎðI6ËÞ}©båMåÈÀ eÞ×ÒÛªáè>kƒ•dŠ'ªÂœ¥*wotºùT1â ‹žì~]K}
üÒ‡Ïww×Wî·"{°H P…0äº.V¯"H%¿Ö|±„lqöÇNZë 9~ÿçN!\AæpDpI*¿[Ù¨h… |ŵ®+#(Ïò^“½GÇ?QsÇByáóÜùD + K”%Éß)WY‚|ÁÌÞjè—øÛ? ~W¥É²7 §N38,"D!áQtª TdÒ3¤ÿÆ Hïendstream +endobj +953 0 obj << +/Type /Page +/Contents 954 0 R +/Resources 952 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +>> endobj +955 0 obj << +/D [953 0 R /XYZ 56.6929 794.5015 null] +>> endobj +952 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +958 0 obj << +/Length 3405 +/Filter /FlateDecode +>> +stream +xÚËrã6òî¯Ð-rÕƒ_Gg Y§6άíÚ$Z¢dÖP¤#RV¼_¿ÝèDR”|ØÔD`£n4ú
«™„ÿÔ,„4™%™‘TÑl¹½’³
Ìýt¥gá‘}¬ ¯>~õ,Y¬ãÙ㺷W*dšªÙãê·ù§¿Ý|{ür½Ð‘œÇâzÅrþãíÝg‚dôóé×»¯·?ýóþæ:±óÇÛ_ï|ÿåë—û/wŸ¾\/T)X¯y‡3 ¾Þþý ~º¿ùå—›ûë? ¾úòÎÒ?¯’òçÕoÈÙ +Žýó•&K£Ù>¤PY¦gÛ+Yc<¤ºz¸úGØ°7ë–NÉÏF©ˆ´g cEà “R–BF µEe"6Ú)ÛI){,”òŸûb÷V5›ñq•Ž…”Q{ŠrÀš mz¤•‘"KãdHûá¥X–ë7»™ ž‹î¹Øч㊆ÀÛ¦¬7ôÑ>7ûjEã§í¼íò]W¬Â.5ê|ë®ß¨l~»Æ“Ž$c”©Ñ j,“ÑA¬6M<bÙ2¦cJx¢®ƒKbab…RR"‹"í–ü.¥&¾ä¼cf݈áà²pÉ”ä|UtÅn[Ö~‹§·Ñ/»k•Î‹¶¨— iÖ#”ÁÆ˼+6
ÐœJ,…µ¦/•²h'„bŒH"£OœX«g¢bTûŽ÷°.è°ÇBŠËçbù}Þž¨1\XœfïXÔjlS'rDþñoÇØlÞ¼teWjøƶoñ®Ò5áêvå²ã¼œZ>ç»|Ù¡ ¼-®ÕœqòzE8í[ÝåïÖ+v]^2åU³¥1LPˆ¡šõ2‰¶v¨–Û¼%ª&v*Z¹Uðd?6<ñùî|‚—¦n= –EùêŽ µ5[ú¢# .ºC³ûî¼q +²cðªXçûª£×Üi1°\6n§•ÓY·WãN"ý(^ìÛ|ƒžfóœ¸ÉˆÕñü+lpªÞ‰V[¯Ý,€Iå6ÊXFûOS#cH„ì uü(Û Ri*²$ó¤ÖyYMR‘°™J‚ëÉÖ5St¢„ÚVùk1±!øf¥eôäüïê)BFh«'8‡}SÐ ö@’EŸ¨!ÀƒÐÊ7Ô ôJGÝx.Ö úø]Fr‚c¥µˆ¢4cnv¬¦S¾Ü^ï¶`;5"wÙó)±8‚‹ÊQnêf7y™0&Kúr›&t¤Y€Eš(bg‚Ä-T:ß;3%¯4\›¼¢ásÓvlßøù‘0·¨]@~€gÙ$x<9É·>ʦî¿~¢Ai^Y3b˜Jµâ)ænÛ¬Jläëõ1ŠÖÃ@)И iÊ¡(Fn}$SN‰ ‘8y©œËЊ –^ÏÐ j—YÈà tM ›ô}ssC:1Ìüò/°‚² jAÃuÏo;F¯Z&x™ öËîò=÷Ayg-“¹óßÒ»M +Áßâ)ÐíÝ#úœ)C +ÞÓÚ-ê…SA<Z–UÙ½Æ2¯ üÄK8HÇZ²äðÚ1FNÓm¼ah[vÅâP® +š]æKÏDÃræ©8ðŠb‡÷2u"²Ú/™Q0†]¾F ºšåÔE4¯.‡±pëeý½¥¡ãÚdóâ/ð5:O„Ò∩bBâmÂJƒõÖ£'^À-»ÆãT͆>K¦o„Ç$˜ §Â8ZñrW>àà™ùø\«’Í +ñ ¶BNT´- :e+Àmç,:#øè§}G‡²}î/IœiÐ
qœŒJ—ïÔû#¤X¿ ò·k¥Æ÷ÈjV¿ž&V³\îw¼¢©«7Ú´©§¼@Ö×+zÈmbèw‘‡çrù<ŠÈ$ÈaIÄÅÜ öÜ•]ÞApcPÍ Åª)ÆèNØÃí9U¡í٨ˮõ•(ðÙâÆƉ€„ûrmÓC:_Úx$—*’ŸçJD‰Ê.R
H§di'ø‰’˜].iÀc…’&Só +qDêBƒ^\@
1–«Xx,©Øü”Éü ŒœŽ0/«™îšòJî°‘=›¡ª÷ˆ‡ôÊ'Tñ°À‡0#Šû8à¬^S"䦚åµÙsfBÐÆãÓÏ å¶ ß„qäm‰Y6œ*j$5í ›ªyr ÍžðGþ¸åUÍd½…[ÅÆeC»rµr¶ [Šh +Rñ-ÿvÿòâx$ÖEé Z°}µC}Hì-d” c½L£-ðVÖç³am•ˆµz' îc˜Ë¥cáíñê‘ÒX›dÑe փؙ@ÞËtÈÅ všD±dpäk&~Ä } £pãIêtX’¼ä +ÁÂuµ"í†3œU$^Ä„G9Gâ‰FN›(I}&œ…º`Üy¤0˜KÉ ê8%‘°Rû><—@’DZ% i_WxõÔ0_ùJ:Š€¬ š_•\”áÏžx\‘ËhO…k\•-ÞÒꌑ/›í6”ÍÉ»í…ØLynfø*æ[±ááUÎvªí®D’Õk»O‡ƒŸO!vOõÀ,‡ƒ›ž >5u·kª÷›aa×k`Ú|| +ÿÎà êk‚üðÙ,&NGô‡ V¡á¦µ‹ => ÜñL•ƒðËGpk !”
‰fl!†{d3ÀÅ·Iš…”§Þx†¨~r´
È€E¤õèýÚE›ÔwAa@[âˆ^vÛ)'“¹×Mÿ„4ºÓ÷&£Lž‹ßhwnÃè‰éõšpY ó6ñ^i´ÖƽgÚ©> Ä( AÄÏ +rYp dÇɘuðkqQ¿ 6)}^Dñ FƒÞb G~èÙÛ
Qh~¿5°,sÇW‰™‰õ0‚Ž:L—^} …þ¼¦9F ü˜4ßí±ÀœzÍæ@<ÿÐútÚýñØŠ8÷ggñoÅ&Ü +™Šg +j£³áà”õÿÃA'endstream +endobj +957 0 obj << +/Type /Page +/Contents 958 0 R +/Resources 956 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +/Annots [ 961 0 R 964 0 R ] +>> endobj +961 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [367.5469 342.5455 428.747 354.4457] +/Subtype /Link +/A << /S /GoTo /D (zone_statement_grammar) >> +>> endobj +964 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [483.4431 140.0267 539.579 152.0863] +/Subtype /Link +/A << /S /GoTo /D (address_match_lists) >> +>> endobj +959 0 obj << +/D [957 0 R /XYZ 85.0394 794.5015 null] +>> endobj +350 0 obj << +/D [957 0 R /XYZ 85.0394 576.6195 null] +>> endobj +960 0 obj << +/D [957 0 R /XYZ 85.0394 549.9907 null] +>> endobj +354 0 obj << +/D [957 0 R /XYZ 85.0394 326.4739 null] +>> endobj +962 0 obj << +/D [957 0 R /XYZ 85.0394 302.824 null] +>> endobj +358 0 obj << +/D [957 0 R /XYZ 85.0394 185.8791 null] +>> endobj +963 0 obj << +/D [957 0 R /XYZ 85.0394 162.3886 null] +>> endobj +956 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +968 0 obj << +/Length 3222 +/Filter /FlateDecode +>> +stream +xÚµ]“Û¶ñý~…úTÝŒ…_8yrœsr™ÚqÎ×éC’J¢,Ž%R©»¨þ÷.° ˆ¤(3IÏãáX.‹ý†ø$|¢S–f"›˜L1p=Ylo’É'˜ûî†Î, ͺXß<Þ|õ6“Œe©H'«-Ëkùäqùó4e‚Ý…dúæÇ÷oï¿ûçÃë[£¦÷?¾¿ LßÞÿã¡ï ^¿{÷úávÆæÓ7ß¿þðx÷€S)Ñøæþý·8’áãч»·wwïßÜÝþúøÃÍÝcÜKw¿<‘n#¿Ýüük2Y¶¸I˜Ì¬ž<ÃKÂx–‰ÉöFiÉ´’2Œln>Þü vfý§còSÚ2-T +’”ÌÊÌŒK™3Ã9 •°4å6JYJ9`9)ç›Mý<ûíPìà s.X"U烱Å#ÖÈê²³:ç†%<•ýå?îŠEùK’ˆ¢ù[;}^—‹µ³éºnZÍ÷·ÜN ÷,Kœikl>ã@íQ—e•ÃŽüÔ·ï?âì²i˺j˜Ûê@:"ÓL¤VÀ®Fä2Ø ‹à)'Üm~$67Mí°'3i-ËîåÃ2…Gœ» €º5q×K (+|¶ëb„5+€HWûw]#, Å$qš6o‹mQµ¯ cI¤ ¤ à"oˆ›²uO9ŸŠý¾\ú“¸È · 3VÆ…ê(~q]f _CY˜d‰¶2 }Àý +²ª[:’{…#ŽM,‹U~Ø^ÙÐlOÏ‚Ž¿² ù•×–z±ðªÇÎ\ +9C 6ÿ¹¥‰ Uñ5‚ÿ ‹Í’A ¾y…äƒL CEî–cíÒ
>QB8»ÂTb†²&c– ݷΰ}´ge¦Ï¥wÊ¢`dWìÒ¶X’ {¼ÍÄ´Fœ¢Êç‹KÜ,P~…ÈÞ«ŽcrÊ8ãZôs—Qå†} îÀc’hóê$ûõ‹¢u™5¤Û ‘-t2™>囃÷E +]“h?… [ˆAÅQ9@±10ÀpØ›ƒûÚNcEÞ ‚Ësu…Ï ¡×ò#!Æ8اâ~ÙßwuS„AÜî y4ájÔd—º%}2Y5.Bÿ #÷ (a\.IØ”OÎ!«^Ò\81íô¦ê W7/mÛ|ñ¹ùš²Û¢F içv&²: .²àÜþÓ‡N( +è³.þy$:£êQ±pÉ<²b˜ ²¢ ‚ÓiÚçå¼d
X/° Dégšõy@݇õ·uWÞË¢ÍËÍåŒ\e†©Ä¼P w±.ç ëäJŸÒYs¬@w S½A +%Â\ç!b0ÑKTʬU}& 1 6šÊ-„Ÿs?˜‚z¶Ñ aA©IŽ&&¾zÚlëÚ;7¸‡XRi/™ÕÓ×ðGx5¤øÌ«åàïýR¨œR}7ñ‹ª*çÞà“M>/6Åw¤m¦óP©G '¡lÿ 2œ“göäDsN{I‰·4ð6Fáç"j”[~]T¡" Dy ê…Ï@‰s »“‰àø²±©ƒžviù„œÅ &B%Z~ªHËÉe«vž Þa•}=Ò<Jþ©¸bJ0mø sëŠ!¬“!xÅYûóÊü‰åúúúk„ž(HÓ!½<Y r:Rž¬D§2uã1Ov/NãÜ“N¨ð…ð D¡ý“]øÉ5au«Òó‰Ôš¥®ÕÙMÆ(MÈ ‡L!ïïkWG¨g~Ú%\Y¯Ï$³ p +\žö Íuñe‰Qç-'´ËÿCs©£@Œ/i,I ç-_j,u±.[oÄòÇ
dëzs–^ð„3
AçúÒkdížá&)S™ ,Þ3\)„Oáà±)} zE§t*àR"願ï Aå–ƒ°íáˆ@Þµ#øÔ<—N¯ÃI>KXܺâ Þ<],œ³Yªú¶‹ÍNÎù””ê§ËÝE—?gycÀ¥Â±«sÂ> +Ë)ÚšÖ{¼¤¡ç%‘sP& 5QuÙèÝýF¨ñÎÍ” …€oœ:¤LÛLÄûï· .PaÝ»Bi•C<²ÄW(íUªC‚ã çSâG¾PÁ »zï! +‡°_|Ì)(ÿ¸óG(4§ØE5««‘Ï"nOÐç†Hm¿€´’,µÁÙµùg,Â9ÈŸ¸F¾ÁRÖIÔU|š£” ÕÆô*t¨ðôébT×Õ5Ã:ê@m!TË$aÆ@ýd‚eÖÚñë±Y¤8ë’ôN§ÇŸàœÜlDÃXÙBT2©…«9ä_Èd ø“$ +N½Ç¤÷€/›à ´mÄ Rt2(»ƒP1è +<bu0p +ÁD:ì]õŒ-„±à`æÇA<+uQ t‹‚jŽ§eÃì÷b´=!k9tŠÁ‚»^Žö Þó+w›QóL@Ù—˜`ÖÄ|+& A@Ý’”¤EÛ~êÖâ÷| \¼1¤™•L;S&¾Õ€ ߘ¢N¤Ì0ÛkÆ
«’Á—(=Av§zÔþÆÁ7K¦ˆ ¼}ÅÓk¾Äé3Ë„F=¥c€„76,Mh'Á`•oi(:bÅâR†S…ª&4¸èŠÑ¾Ÿ3}%sŸ œ‚˜,Ôxc´qÏþsE·‘Õšuÿ²u(Öm¾X—UZ?¤µi&È.F~I³IÚ5UƒÍ±;hP¿Lýa=
\É_ãÁôŒ*8n³ëÜÃLLbOŽƒÅ€1îg Ý>ŽçúKRu¶ÇÙS:Ö‘…\–KÕ« ¨¾ òà€í6E©v¨„VG\‡z¤ëëdФˆ#!ÃP´axBes˧xûÙ¡eéŠ j÷wd £+lIOfôטA½WV‹zKúÞutãïêÐÏEŒûOé¨.ýËõ0ÎýÌÀ1~Qï{@Ù‹71ƒT(±Óœ&b Ô[Ù¨|ã.d +þ Rȉ͘\þé Î:ÏC073`÷qÝ‹i‚à ªã¿ŠÃHð:‡€ÂD³ ‡—r
§•†´=j÷\ú9$ÀSµÿ²ÑAlzFçÜ OÉœ^ +endobj +967 0 obj << +/Type /Page +/Contents 968 0 R +/Resources 966 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +/Annots [ 970 0 R ] +>> endobj +970 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [369.8158 524.5277 418.5625 536.5873] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_security) >> +>> endobj +969 0 obj << +/D [967 0 R /XYZ 56.6929 794.5015 null] +>> endobj +362 0 obj << +/D [967 0 R /XYZ 56.6929 355.3526 null] +>> endobj +971 0 obj << +/D [967 0 R /XYZ 56.6929 331.517 null] +>> endobj +966 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +975 0 obj << +/Length 2574 +/Filter /FlateDecode +>> +stream +xÚYOwÛ8¿çSxO#ï«Xþ—Øž2mÚͼmÚI=‡Ù™9(¶ ëU–\ËN&³o¿û%K¶’v·}9ˆA XL8ü‰IjWNO§™áÂLæë3>¹…¹·g"ðÄ-SÜçúqvöü•Çœ•v2[öd¥Œ§©˜Ì¿E¯þqþavq=¥á‘eÓØX ýxyõš(Ž>¯Þ_½¹|ûËõù4ÑÑìòý‘¯/Þ\\_\½º˜Æ"5ÖË á‘o.ÿyA£·×çïÞ_Oÿ˜ýtv1ëÎÒ?¯à +òùì·?ødÇþéŒ3åR3¹‡8ÎÉÉúLÅŒVª¥”g Ï~îöfýÒ1û•2“ÊdÄ€ZÐ8f•TÞ€Ùb±Š4ʛήœ‹.—pÄÄE»Uƒ”GÍC³Ë×D¬«ò¨«¬!RQÍëõ¦ÌwýüÃ%M4ûͦÞ¬·D½üpgŸ!-‰Võ}~—oÑÆÒíy“¯²»©ˆ +¿ EC_â@éÙ:ð‚"p
`‹X挑þ`»U¶£»¢a +¶[µ| i700…HSÏ?åǦÈ3ÜG=ÕˆÐ;Ù3¢Ð¿·™ÿ.J˜ :Z ¿÷« 4’é‚`°È›‚VÁä&Ü%nMÒÎß< I ǽ±wûrW€Óá ¸y '4g0r°Éjq]ÅpsÄÜ cY":æz³+ê*hç¯ÓëÔÙ7ùcD +]?ÂT0"ÏœJ Ò°¬¯¼p +B6¦˜9Þ v 7ýäÎ ÓéÖj$Àlb†{¿öíÊÊw#dJÕsÝ–õMV)üP#‡0K•tzÒÊí±„ö
PBû†ÈÔMõk»®†LÛßP€!tC€võ~vùæW¯a‡ì6oB‚P#}Ðõ¼æ~•Wyh pjˆP¶äÍŠ¨ózó@#òÆö·Ë;—ç¡Ã"¼£RS!MCüøľ $ ÿ£êI9œÕ†~ß‚8Úõƒý~;]} kè’êóšZXRiOÒÊW»ŽG«¼Ü„¡÷døæU³oÍ*hsþä”ê¸ðCŽk£ØP—0ª`‡]¹bþɇŠ_^ÝQê6B*Z GÌJÌ‘Øu꼪Ô)K Ã_9G\™wo÷7ÿ˜zÀfÀÓ”Êñ PܲTBÙ ”BÓëäXóîW×SÕÿ ’úžçendstream +endobj +974 0 obj << +/Type /Page +/Contents 975 0 R +/Resources 973 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +>> endobj +976 0 obj << +/D [974 0 R /XYZ 85.0394 794.5015 null] +>> endobj +366 0 obj << +/D [974 0 R /XYZ 85.0394 532.5775 null] +>> endobj +977 0 obj << +/D [974 0 R /XYZ 85.0394 507.7956 null] +>> endobj +370 0 obj << +/D [974 0 R /XYZ 85.0394 170.1477 null] +>> endobj +737 0 obj << +/D [974 0 R /XYZ 85.0394 148.8279 null] +>> endobj +973 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R /F84 848 0 R /F86 980 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +983 0 obj << +/Length 3570 +/Filter /FlateDecode +>> +stream +xÚÝZÝoã6Ï_‘·:ÀšÇQ" ·Ûl/Åuwo›âp×öA±åX¨-¹–½iÎP_–wÀ… L‘#r8󛥮%üÔµME굿Î|"¬Töz±½’×0öí•bšy$š÷©¾¾¿úËûT_{áS^߯zs9!S×÷ËŸf©Ðâf³w ?¼¿ûöÇÏoo²dv÷ñÃÍ\[9{÷·[j}ûùí÷ß¿ý|3WΪٻ¿¾ýtû™†Ržãë»ßP§¿3“~¾}ûùöûۛ_î¿»º½o÷Ò߯’7òÛÕO¿Èë%lû»+)Œwöú ¤PÞëëíUb°‰1±gsõÃÕßÛ {£áÕIù))´Y +01=:%¬÷ö:³^¤F› À¼Â= +^9(Ü÷h 7õC¾™Ô‚*iwòä´P™µCÈÁì¬xk!ga@¤-<dÇ
É +Z >Þß½ÿ'µ·°ƒü1ìžVõž‡uÎĨðFÉÙýš§Z«ü¸a‚²‰¯ðh±Ý ž©ÉìBëgi%È;´Y0¡ûþYJ½ÈŠÝ[@¯Ä‰Ç»Q*½Î¤ZfÙADó>9ˆI©PVÛü÷ùaŸWͪê Êm1/«1#ÊJaÝe>˜f‚Ü +^ žJFlÑ»ÁSIÂÖ
bˆGØSI‚Wx‹E +:»ÞÓÎ`ÛÒg ¢rÒAJpΩ$༷Ée§Ò§:ïTZª‘xqoc¢œH_Xi& xmDš€G¬~‡êÑ>‚S»™Cõs©…c9X¸<ÃûhÑ4:I’0hA*nÀz¤~èéÔ½úa ¨ ú@¹‹ãž t ¦aWDïp|SŒ÷üP, àyÒ¸FÆ€'Ùlê§bI#èñ?DMø Ø À )D#õ(òBƒ«d8†Ù+Ö#3ËÒÄqOËšÖs¡ÂÈÙ¡„e×¼^Ü5ŽÃ®§ì¶ÏY= àÄ7GŽGœÇªæT¢ó5• ªõmAé5ªUR§Õ²û¹« Îää÷4•÷î.–€—±»KÐݯ jÔ‰‡3U6²Ü¶8Óm :W8¨åMÌbBlCEãã±!rgB™DòÇ|`–dn$3îÄx)Re_(ûô©Î»“–*H§Ÿ +L}óáêáZ0õ†{Ù
Âዢ߻ '¹¤W¢èil9µ'
öü'¯D†‰jkß»|ñ+óž7´b8ÍQí;Õd“Q)é”w²ï
uæü¿«›¦|Ø0)d`5Ó ËHLâP çÔkQï„TíõGÉ«oë.;ÍfE°ãP /ùêG›ÙC8d süR]…s ´šãnWïá@ʱ •€ «F1=Gnò„ã
÷UÅ5ây +8Î4‡&‚o¼_„’sÐÿj¬.‚A“KŽÐŠ—ò4ç +“Í‹5äaÙ÷Ô‚5pmsW™ð*¯D’¥ö2 +ûTçQØR
Q#ZuZºÑN$‰Q—¹h©&Ø0£Ï]8 ùàB_¿°]팋'Jvî ¸”«×ᑾ•ŒEìz`Êì
Þß³Ó bupp âpEWÈŸ—!ÿ„¿ø…‘ØÙÖ¡ +endobj +982 0 obj << +/Type /Page +/Contents 983 0 R +/Resources 981 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 947 0 R +>> endobj +984 0 obj << +/D [982 0 R /XYZ 56.6929 794.5015 null] +>> endobj +981 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +987 0 obj << +/Length 3209 +/Filter /FlateDecode +>> +stream +xÚZ[sÛ¶~÷¯Ð[å™Å àcÚ:9î´IŽã>œiû@K´Í‰Dª¢dÅùõÝÅ)A²;=ã —%°Xì~{!ù„Á Ÿ83Y¨‰-T®×“Ùò‚M `îý4Y$ʆT?Ü^|ÿΈI‘F˜Éíý`-—3çøävþûôÇÿ¼ýt{us™ ͦ&¿Ì´aÓ ®?üD#ýüøñûë÷¿Ý¼½´jz{ýñ
ß\½»º¹úðãÕeÆæð¼+œxàÝõ/WÔzóö×_ßÞ\þyûóÅÕm–áy9“x¿.~ÿ“MæpìŸ/X. §';è°œ…˜,/”–¹VRÆ‘ÅÅç‹ÿö fý£)ùiérí„MPÉ +PV~Ãj¯«“¿&ÐQ覧´ýa÷Bðß_/Å䧎4ž*®œ
—öçrjhŽèpP€ýZKfp-Øôùþµ[ìðé¼¥Á¦ÝÐÀ®î iˆ4 †¼Ý &Lƒñà$(à¨Ô¥°ZeÐ+¢+ß…U@Iç ºÇv» g$zg§acEŽÊN +\Àîð°WjlDÅ ‹„‹\h A¶\Öí +¸†0¡†C- ‚P‚¬
xäÅù-MD6±íe…yµªš0¸]µ
Ù_¿U`›¢ì‡j³!@¶Ã ÿÓt(½]8„ »+gxˆ/ÔC!ú_ï~ žxÝm¨³®î×^vþÚú[@ñòM V€JÒÈÉÀ$þ‘I+¢gûÈúßA@&Š 'A×r)%?ã“Àx‘3 xÖ%*yÎ%¥b +x Bê Oz¥@”
©^É™ÜX+Ǽ W–
½v÷^ {C¯$,§œÁÆp
@#z%l§½s9ç}\Z Ü;Œ‚”{&ÏxÚ3PZfž‰¬B"C‚¥ÆÆ|&F8d4‚yÄ|É3ŘEY
zî^l†T§µ¨§:F óÁ
^=#ç™é©ÜŒ© +Ç÷*“{•êhº
+àëXC2° ùÔXš6qé¬q u©…óÁ=…p·Áñ`GÍÒ;r&s+Š˜F=W]j/ qŒŠ40Í(õÕÃbˆ‹IÒréÑ]½¨7Ï@ÊO+¡8˜”p@uF #ÉkSß?ŸR;Ö‚yÿÙí{ªöç\ApzžÃ¬FæR›˜ Í+PÉeÝ ÒaEc÷XÏ0Î`z +Éh¹ ÑQSå|Nz×uo0§wä ‘´]azZ.Ðscÿ·Ÿ>Ñ3«v½ Ä»z¾«‚oFMв8 +)pUCþ;ï×¥±Ó o¯ßýF—ÀGùPu`&ÆÈP•Á‰Ÿr‹>ÚOVU¹¦6&Û¸&EV¸Í¢|ŠÍjý„&jÕô»Tb)M™e .K€ûuJ±’%¤8¨ +VâTÁª¹ÒœŸ/4y5c +’ß‘š½¢rõª +Øÿ»r%µÌ{©r5¤:
Ï=ÕÑ]¤âK0
Š³ ôT F¾Ë€£tÜyø¥þR%˹uîµ:Ð/$ צ‚0·E]í]¯ÿ
hàÛ1c´ÖlÆ´X™ +Kí!66pÃ!¯Âº†´„ +PSÉ¡ØS[ϳ'•mç« ýG +W!•–²/§ƒ_ˆïáQ¶aYóŠe£~ûÈÊ ¯à F +Šìi ½§š +$è¦Â¡!:84hG?»y,ÃäqÌg±81
# ›òÂùz'üBÆþ ®gǺú¡! +>ÎV`6r +&”avt +š\?„— 7ƒð²§Oð8R£uqÿÏÕl/x“ó£‚3 ¶àªqsâöT/ðp¼ò¥Óç˜eIõ +ìPqÅqÂu‡ß¯t[ìØ ì—8ζ ŒÇ·Õ\0±ëâ l´üSŸ €6@¨ýÂ{¢3 "ïªÚu•‚9“ö_œÙ¶':Þwä …ÁÏ‘Æ÷ŸìA áY‰¸FARLu‡/þçÛå*@äí ç£D=˜h;ŽobÌ‹ŽA½©>ÌO}¯%uŽ Y%$ÃúW®ÿú[®ý‡nàW¥s'òaÉ +endobj +986 0 obj << +/Type /Page +/Contents 987 0 R +/Resources 985 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +/Annots [ 991 0 R ] +>> endobj +991 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [389.4645 148.047 438.2112 160.1067] +/Subtype /Link +/A << /S /GoTo /D (configuration_file_elements) >> +>> endobj +988 0 obj << +/D [986 0 R /XYZ 85.0394 794.5015 null] +>> endobj +374 0 obj << +/D [986 0 R /XYZ 85.0394 332.07 null] +>> endobj +989 0 obj << +/D [986 0 R /XYZ 85.0394 307.6688 null] +>> endobj +378 0 obj << +/D [986 0 R /XYZ 85.0394 231.2958 null] +>> endobj +990 0 obj << +/D [986 0 R /XYZ 85.0394 204.4238 null] +>> endobj +985 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F84 848 0 R /F86 980 0 R /F57 624 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +995 0 obj << +/Length 3216 +/Filter /FlateDecode +>> +stream +xÚ¥]sã¶ñÝ¿Bo•g" œ>].¾Ô™ä’úÔö!ÉDQ{©ˆ”}ê¯ï.vÁ‰’{Óñx¸ +ùóî·?Äl
lÿx'•={…†dš†³Ý]¤U #¥|Oy÷éîïÝ‚ƒQ7uêü"m Fñl¡¢ÀÀþÓ§,ƒDJ@JtÄ*TÝ)G“§ì±ð”׶µMñŸüœÝTI¬’ÙpÉ‹=ÒÄÆj°1H5‰´ o¼Üæpâ©œïì—bwÜQÃîêcÕ\oð+ ‰ŒšïêÉàÖÏoòÃK~ðkñè±ÉAð‘ +û}ÖùÆ K^»háo?èd@§RÀOšh`Î
Opˆ#†"˜HIÆs)Ø ,2Kà 1 é )ƒTëС;^ô|k÷ÒÌ×Ô*‹]ÑXWôíùŠŒk`Í>;æ"=ÜP Æp’žÛ¶Íwû{8ª†±j (Ë:³-O®]ðÞù—,oxVÝíÁ|‰1?ŽôoîJ$žŽØoQ3ñüµ(K‚6¶( ¶™¿n‹lK½,¸˜)ˆçíñÀP™Û^µ[¾g3ž +»*=BMß}~ØÔ‡ 5¾ÿø©ŸUdpv#.¤WG' æ¹/ÒÊç¸^¨8œ×{baßw !æå‰Ú v›c‰°š[ƱôyµŒƒç‰_wnEõL-ÇšCg ¢zñkÚ`¢=ˆ³'DÃǸ U:_ QÉÚ}ãyf+p±œ@Ú!wœ€}°Eà ¿†#¶D>b4§”†Ø^rŽÅ{ýÆE·–!g/ +õ²füuj‚ôœhŒ0@‰Qß'Ø<ÕG@)hYƒúªå(‡ ¿/v9å¾ÎÇ@§SnèëŒ +¥MÄ«‘Ž7 +‹ +dj×ÁE$äpë$ˆô[1iˆu=&uXHÅïB„eÞœï›hH! zÜÜ×#Mì;dÛˆ 2* ïK¡B%ƒê¸[9_°Søz +]£õÓ:¯ä–p +lÀÏ¿ð0˜LEPVW 5r U ÎCJ9w*®{"úxéx•¨ ÂøKÂ;VNÛóõ„˜5F6£ºˆuM¤a™¼%ÒÖ
‘z,ç‰Z›}žÌ3’ †˜y{g4±óI) –B·¦}î¥ +Î +_G$ãz Ëǽ|Ýb<J™†’¢ß¨— ZÑt¦!#´ùêLãÒ ,"p:ŽµËÓä³gC¦ +I±bþi@ûSÞÔÇCÆÔþ„J3åÀˆ:H´ $l*L盂û+E®Ðô>Çš¼% ¤U £¢¾Ö¯àüè_x"ÐqÈÁã‚4ǽnË{pð¥MòŠ#wæâ# U› *ˆ('jƒ7Ÿ “҅жõ0ìW)Â0øáLü®•Á%§ Ä›F5ĺnT –'Å—ãzQÖÏ‹)“ÔF*Šn“ÑaMÐ121e‚H‚⎡ÔW¥ªO’RN’°oÕÔeÞæ…œ5Ž\ê1 ¶Y–ï['4lUk ~®8ã¯è*‡8†:²z·q¬Š²h;_š€ï]rZ„÷P#Ïq¦õÒ¤” ”‡Aûß`/ IWö Œîü0'Ÿ E-ëØCiY¥6Ç*ãÜØÅYúöWTsU—"#ƒ(Õém]b]×¥ë—çj$ôx¤ ΕH@ðSð)wþ‚¥Oç¯U—Jb7é +]8Õ!ñ”•¤+.v‡‚ÚŸ‹²^Ú¼AsUÚÏKæ/¶<ú%6Ô5]‘sF_T,®W%’ª0 U%h+wï½è^]hÜسâö:Ïè\-•Ê)>Š0†{Q¬ÎŒ ÝHãu¬Ý²>²G ^)µ¼fíp‹”1oXû +:¬ ÆY©¦êˆvXX€DB&jàZˆaßnC1=n¯?èÜ\ +€]Q±Ë£â:Ï}ÜŒ Z +WŠC•—7Çý¾>¸r'³>C
ÅÅs°‹ix9æëwë21l…a„~‹½Òú„ 4į’ +á® ·öï. Pg7&‰ïC +œÙEŠÞãñÙù@M’
B}iÛzàÔÖC|ÅðOˆváµw¸‘¿½Dîá;ÛúÕ!†Ÿ¦ÊÀA"äëÀÝÁù‡ÖÈä¬^08ÔóÚ\Š¿ò '8—#§6 WžT2È[±ál ¾± ï•9}j
+L
¯mO®Gº²(Ü}ÃñºT'ä_®#ô×ùœójgŒðßзª»ëù@íý¹_âë îø” \û©8xü}Ô„þÁ? úÿý3¬þ7jQ€³»ò¶&_Œ•' +䲶¬¥ +endobj +994 0 obj << +/Type /Page +/Contents 995 0 R +/Resources 993 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +/Annots [ 998 0 R ] +>> endobj +998 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [329.7108 477.6902 386.7943 489.7498] +/Subtype /Link +/A << /S /GoTo /D (journal) >> +>> endobj +996 0 obj << +/D [994 0 R /XYZ 56.6929 794.5015 null] +>> endobj +382 0 obj << +/D [994 0 R /XYZ 56.6929 607.7231 null] +>> endobj +997 0 obj << +/D [994 0 R /XYZ 56.6929 584.5979 null] +>> endobj +386 0 obj << +/D [994 0 R /XYZ 56.6929 145.2693 null] +>> endobj +999 0 obj << +/D [994 0 R /XYZ 56.6929 119.4941 null] +>> endobj +993 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1002 0 obj << +/Length 2505 +/Filter /FlateDecode +>> +stream +xÚY_sÛ8ϧð½)3•Ê¿’8}ÊvÓ^vnÓ»\îiw ›Ž5•¥ÔRšfwî» @2eËioÚé¤"AÈ @€æ ÿø¢Ô“F- +£2͸^,·glqcïϸçISsýt{öú].&3¹È·ëHV™±²ä‹ÛÕoÉÛ¿_üóöòæ<š%yvžêœ%?]]ÿLCŸ· ®ß]½ÿÏÍÅy¡’Û«×D¾¹|wysyýöò<å¥æ0_x '&¼»úÇ%µÞß\üúëÅÍù ·¿œ]ÞŽ¶Äör&ÑOg¿ýÁ+0û—3–ISêÅtXÆ‹í™Ò2ÓJÊ@iÎþ}ö¯Q`4ê¦ÎíŸÒe¦…Ê©V™Ê >¿Ë,cv--´¤Rã.«Ù]\¸Ë[í†;[
iÝv÷¹j
çyžÉR–‹Xú‘#׌2R‚<“¹æS-n7ö<U¬LzPÁî°]$OuÓõÁîÖÝnKä?»Ö3o+Ô¹Ú¥¥¡¡ê?ö4üD«‚œ×m[í>Ú‘«
>Ø*)‹L©€m¨Þª®šÇÏ[“OVèÒÀðÌh- ÿÓƶÖÙ!‹26u-“Œ[ìèöËC½;çÐ蛹Ѵ
8´²ë걨fçŒúÛº} Æ97¶ê»¶ºküTÿh{jW$ž¦ƒ¤NG_NäUõŒ†¥Þò¾ß¸«R°¤(tXˆ –•eAªº¡êK½}Üb'§Å‰ŽZ#I”Ô‡u<E+&Å Ùyrµ&ÆÞÄ‚*#½‚o)’¶#:AGb(L¬¡qh@ç 6¶·ÔôxÀ&!
[Ýrù¸ÃÈ ù¿w²¼YεyÙc®Óž8r¡Ž ëji_ðD ìêeÓŒ +?Ì!²-§:Щj3ú¡È÷»ÔeÕRkŒ žºÝGâ M ±¦îj¡3<Ïø™ b ɽŸÍoÁæ%ϸž¹÷)K§>ž> +qÜhÈïDX',>Žq,—ú(È©Rú$í“ŠxlQþä3Œœ… + ‚ë,ªXh©¡” ›÷:BÎwŒp9J¡< +>@¾Ç“[ø_$—G;2¥€kQ–™B¹[ñi8R6ÊqEmgì~ áõÕV,~îÀ¤ElUœÆ¢Y¥Šq80%C
ÐÅŒ÷¬Î¥peò|.Xb}§Þ>4vkÿ+Ohé‹å9:veŠ,—¹\Äû}g)l–(ãÒ}õõ}Hš ?¸£|9*™CE—»]Âê”çpÛ3¸Ko]8î :ðƒç™ð +€ï|áN6²F§9}ãUg¢ÞïŽA½ÇÏ ÐvŸ¦ƒü +·çMÔûû "ç~Oá +öLˆoûA’ c´z±–üÿåpÆA&±ÿáŠec§J9¨ˆ +^B*#LÆ ÿ!¥ ÈTX>• +–)~\!䦑à™2 + V`¶$ð¡„ +,:f +žñÖjYfº{¶Hùÿ#v`endstream +endobj +1001 0 obj << +/Type /Page +/Contents 1002 0 R +/Resources 1000 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +>> endobj +1003 0 obj << +/D [1001 0 R /XYZ 85.0394 794.5015 null] +>> endobj +390 0 obj << +/D [1001 0 R /XYZ 85.0394 452.263 null] +>> endobj +1004 0 obj << +/D [1001 0 R /XYZ 85.0394 426.0265 null] +>> endobj +1000 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F84 848 0 R /F57 624 0 R /F86 980 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1007 0 obj << +/Length 3047 +/Filter /FlateDecode +>> +stream +xÚµ]sã6î=¿Âo§Ì¬µü%jú´ÝfÛtÚ´Íææ Ú>(¶œhjK©%ov§sÿý +N“û»×Á‹èñ—áz!Çt‘÷媫šš˜ñï#9âÉš8JŽx:z›=ÖSœ Qcñ£©<e-†VÛª—”WØ-iÎ6kÆkï›Ãv âû}Qßwè +ŒX…\îŠnu?åQƒMMlb¿ =Å'xÔpI¦Ó1“'nRf±Nµôò®×t9U
N”RÇVut‡`ijÙ5Þ `¯}(WjóÊùx2¹Î’h;Ö`0ªø¤RyÂÑ¢$yÆLuÍC³mî>ÍpŸè\Êœ—Úëƽ²T9<ö¸‚E :¤àêEfžô¸Œ¿ ÌyÜ)ݱÇƼÇUÇzàæ º
·˜ñ¸Œõ'GÔ«“$º(@m隶p¹[ÚDšÕgoL& G¹4Ï2 R' qwh=ý®-·ÒšD +; @ ž%B?•H€ƒ|ca´ŠÁ~›/H0ÅeHr.‘б̀Lö™LÂÅD™/ÇdOñ &Ñ)H-õ˜ÉÓ™„I”ec¸èniΊXH¥ŸÞH¦á=Ö²¥_v8»‘‰!û¬1ƲɬéÀ“'„žEÛVwµËöS2²Ð¬á”Õap°^á/Œl8R«©e 9}Ç0EqÑiWÕÕî°›Û³bÂøêýîÍiËaÄÈÌy•±9 ¢t‰·f-?7 +®£î”(Œ¤9w\m2¯“ +ß"~š|ýšf.ßá7\Á–»Ç%ÐI| œ¦
¬·_!¥4 }óÝÅA›jï™ÝT „RÞx†Ò“ð }ãé;ž—ãÈÄÜõ0£¡ö~5 ÒÃÐ[*e±ËóYÊžË\ÍIØ xµ-Б#øv²~NØòs;¥vVÞ‡–/3–¯XÚ{ P“¾~Ryþy¹©ÊM=[nê¹rSS¹É¿-7ùÉM¿PnúÙrÓÏ•›~Jnê%rS/“Ûdƒäx3Þ ‹åw„dr$Ãg~Ø“¯ «Vt½Ušó€žßYIÐäÌOCÆŸÕ POC#ˆ]Ž›©Ã¿‡ +:aœJ\Ì\—ÿ‰€ÕýÝ[Åß®é@ÐLT +endobj +1006 0 obj << +/Type /Page +/Contents 1007 0 R +/Resources 1005 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +/Annots [ 1010 0 R 1011 0 R ] +>> endobj +1010 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [213.6732 702.2957 286.8984 714.3554] +/Subtype /Link +/A << /S /GoTo /D (rrset_ordering) >> +>> endobj +1011 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [209.702 621.4019 283.4678 633.4615] +/Subtype /Link +/A << /S /GoTo /D (topology) >> +>> endobj +1008 0 obj << +/D [1006 0 R /XYZ 56.6929 794.5015 null] +>> endobj +394 0 obj << +/D [1006 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1009 0 obj << +/D [1006 0 R /XYZ 56.6929 750.9506 null] +>> endobj +1005 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1014 0 obj << +/Length 2676 +/Filter /FlateDecode +>> +stream +xÚÅZmoÇþ®_AøY„›}I>)¶ì*häVfQIPœÉ“tÈñŽá -«Eÿ{gwvwä‘’›…ßr_fgfgfŸ™›PøÇ&V*œœ'‰¢LM–ë :¹‡±w,Ι§Ióþ¬ï_¿Õ|âˆÓ\Ow=Z–PkÙd±úqúú—^\ÝÎæ\Ñ©&³¹ÒtúÝõÍìqøyýþæíõ»¿Þ^ÎŒœ.®ßß`÷íÕÛ«Û«›×W³9³ŠÁz )œXðöúOWØzw{ù×·³Ÿß_\-:Yúò2*¼ ¿^üø3¬@ìï/(ΪÉ#ü „9Ç'ë ©QRˆÔS^|¸øKG°7–ŽéO K”åfDrTÊ-¸ +ô23M˜ P +:¹mòe|¿]åÛ¢º÷B)Ñ#E's.‰“L"{È+X£Õt½+ÛbSæþ—žngÌNóe ¾«§dØÛŸÑî¶U¾Âá¢Â‘,R̪æ1ßƱÇÖÙv|ŒdvM~·+±¯ñ»¬«Ÿ(å÷»þ~íCŽ£‘'¤¬§õ]\üp‚uЗš1â”âAêM™-×R +ͦ®š ÌJP;]À*³.L0•¶@ß“ÝnáæµWþˆæ%Êpç6mÖæë¼jqËM¾]mƒŒìåÏÚ¢®pF¾ — üA‡uGSÆTÈåÎ$• ;†ÃÓÉðÓ³ø5¤ÓïÛ+‰Ñé‡<ÎÏʦÆV;®7kÀ7¤Jº¨·mY4íˆÒ„$”óC}uè½BI¢šF‰±4¸Žmï'ظíù]š>ïÏG·l~HÕ3ñ!_ÆC q }P 2$¹&B(;àèÈÿ»YÏ0rLÍsBð<…#t¢03Ä ˆ&~ð²Ó»öqÄDuv†Úgœq?üD;N¬4ö%‘g ƒóŽâ¼Oò8È1îà¬å~ãpä›|9bœIUò»¢ÁÓXåÞm0 y+ŒÝwuYÖÍ7HG™ ¹¦D2n“îpÓe™5°VCP
ÍTÙ,›qèhŸ69ùV›~äÕª^gE_…CѬ5nèr¨ÿ°¢> °ÁX‰Õ +Œ5ñk¯ÁÕ…rÓªö_›Xö]ÅŒMcÓk¯ð:ÉW_AQÔ/Xåwøx\ÒŒ \NÚ$%_Þü}ü ´“É¢’CældΦ€¥MÞíOòæú¼Ù¼A$ïÈ9ÞôyÞðÔö¾!8 Ëôðʲ›B[4»È®ÿ‘lñ'ÎåãÔÂ!¾@¦þ0¶ɄŒ<™èçŒ "¨0C[]$.Êü>+±ù)+wygüÛ6¬ +JôÁ¸õAl1®»´" +[I&€• +þ³®ò1 äW•99ºÝ +xé_!X%¼;Y=ðv}³GjغÄOª=ÔMK"'dY¯_õ +GÄtŠhÙ-dQ´ÈD†Ÿfwç¹
—§GY†ùš@De€, • @V>fO1||ÖûÏ„Ú¿^–@Õp1nÇRß/‹61˜ˆ,‡Fî‘é õ>†mÒA¶)_\nÐÞ÷Rç$Áf“g—=š}®ª#®…s…(™$„4(,*NõX"mRyCNÕÚ|æ +ˆÖ½¨ØÆ Étp…Ÿ~Æõ— +ø˜Þ3ÆSS4ȧÓÎ(ôÜùv¤&ÇľÁä|ãÉÓÉÃ1½Û•åSœè_ç1tTøÅê±o9_
¦¦ßƒŸån;Ç€b$ZØaŒÞU¿
7à«u²ÆF'€F³Ûl|ÀõÐ{|( áj&€×UŒl0¯æË¢÷ÇHÂíÁö“¾ý6³õ¢ À¨/@çjè ýôtqšsE$©ƒâ´ŠÅéÅŒq7ÝU1Ë DJ¨?òEA*(iˆ“æýY§yéfy^J¸íçm[ —ºÀ‚%hòìÎݬ‘ÅÀu$îF÷þcQ—ÕnýÓ5 +¶ üfYW˜ +,ƒCç2[â îG)nÁÛO‰HQŠe¨Çb5ÅþUÑd Ë<RõÔÀQØô>Îú‰*ºx("{£ea¡ÍºÐuó~1V ’T‘`&OŠ÷æ u•¯ìÆð–}sP.9Æ ð“6m ðj¬ºCu†ÑxծͿc¼ØÈ>ëݺW 9·»qdG™Ùñí5‘”õvc»Ÿ2ué ™¬xÆÔ{³Î˜zšåYgŸçU°›Qƒ–$wîüþݬ¯@Þß ,fÌÚÛ”6°Ú-sü]åíc½ýÅÿ +~]ü ZˆïyxÓib_”U7žöŠúè%†pýUk‰‰ñ˜Ž¥DÓ4õ÷7Ûǃ—èÇ©îùfÔÛ Ñ¶« ƒ:›à‚]÷\ÔKà5¸ 6 êÝvïw‡î7 •üË8Oþ½Ìª„
dË a°™š¨¯˜ƒ˜`Á˜®ø§¯ØAÅô®—¬4E™ ‡ÓÛ™…K‚yÚm|G‹h{Õe;E̺7ß43–8)‘ aïdDPw×3wooÒ™7ê8)©ùt4 +q–Û³{w“ÎoÎ ÛˆÍÎï~xÆœçlgU˜±}J³wSß[¤Š ú$t=>ˇAÄöîé¸Yw•«®`[TÙ6žº7áMÝ>R…kk|Í ¾u1,Ük‹³O] ö˜ç¿ì·ê™Òø%•²3À3bôŠ “g«…/ý+‰=Æ”þÕÅò/±©à™òªPG®ÝŸS ³þ ‹åL’endstream +endobj +1013 0 obj << +/Type /Page +/Contents 1014 0 R +/Resources 1012 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +/Annots [ 1016 0 R ] +>> endobj +1016 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [353.6787 706.9749 427.332 719.0345] +/Subtype /Link +/A << /S /GoTo /D (the_sortlist_statement) >> +>> endobj +1015 0 obj << +/D [1013 0 R /XYZ 85.0394 794.5015 null] +>> endobj +398 0 obj << +/D [1013 0 R /XYZ 85.0394 769.5949 null] +>> endobj +696 0 obj << +/D [1013 0 R /XYZ 85.0394 749.9737 null] +>> endobj +1017 0 obj << +/D [1013 0 R /XYZ 85.0394 600.3746 null] +>> endobj +1018 0 obj << +/D [1013 0 R /XYZ 85.0394 588.4195 null] +>> endobj +402 0 obj << +/D [1013 0 R /XYZ 85.0394 240.5427 null] +>> endobj +1019 0 obj << +/D [1013 0 R /XYZ 85.0394 215.3468 null] +>> endobj +1012 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F84 848 0 R /F86 980 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1022 0 obj << +/Length 3569 +/Filter /FlateDecode +>> +stream +xÚ¥Z[sÛ¶~÷¯ÐÛ‘g*†¸Ó§4qRwN“ Ç휙¶”DY<•(U$íª¿þìbŠ¤(¹N<!.K,°Øýð-(6Iá ›(hÇÝÄ8™¨”©Éb{“Nž ïã
2³(4ëJ}óxóæƒæ—8ÍõäqÕË&©µlò¸üyªžÜÂéôÝçO î?þøðöÖÈéãýçO·3®Òé‡ûßQéãÃÛï¿ûp;cV±é»oßþðx÷@]:ŒñÍý§÷ÔâèqaЇ»wwŸÞÝÝþúøÝÍÝc»–îzY*p!¿ßüük:Y²¿»Iᬚ¼@%M˜s|²½‘J$J +[67_nþÓØéõ¯ŽÙO*›(.5X’'V§rÜÊ,1Œ‘,Ñ’±ÖÊrÔÊQ +¼-ÊÙa·««ázYšÂ›ZLºƒž©n¥Ft‹Žn–ªÄIcúÊ ×9ZÝâ,Šm³ÅŠ›–Ívž ¨c·¢çá–AeW“D• žóCE]õ:«©TTÔí…óß›‚ +Kê]í˜Y_*¯ê@MÓr=v uG"ó
7™q™iÑ",qJq¿¾l±È÷u¾ ,¾ÏWY³©ÉÑ +oñ7 ”í˜ÉºD0áÀ¶ø:'‰ž!ÁŒÆè 7ͲD9§&IHiÿŠ— +ëƒÎŽ{i +; ƒè¸8½—ÂX¡ßè5‹³›ÁZ£•îúJk7°‚I¸±|¢J“ʯõSÇ +<ˆ¼*Q‚Ë`Ï·3ͦð?Ÿž…¯Õ`8''Z‚ÃZ +¤Éï–¤Ò9AB²_ëɾáÍý–OÞï`E“î¢ÂÀ³îÈ~QVv€‹D ˜½–&qÎZ”÷-®»Ýoòm^ÖÞ[±¡¤'â–;Ûg©]³“®%ÿÙæ°ºv +Î,JÌ£d +!Ôyx +õð±ë0A~Ö}á|ÎÇõ»/êbWÒÜd‡³(…´º7›3Gh¥^™Ãùh8°£ ¼›
Y&ÿc N"8¤ctìykÆ_hÓƒ
•h¦M€8‘Ž LpAh’zWB> áÐ d{N@ÚÓtºÍþ C+8Mh/*z²”žÇ<;„&Üd¡5tpç¼*\0. (V;pÏ;Ø%ž„´;P‹í@YS.v%Ä1ˆ ÅòÚ¯$+ Ú@g/8e™Sa½kTšçxŠ“^¬‡£<.šµ—áü¥)øRôî^¨¨@J\!nŠmAÐŒmÛ]G!~Ãov‹ß¨Xý–¿Ü:~~8G¤SB'Êju »R—á°•j¹\¾:äÕz†ËûŠ&û<Úì¥ëÃñ\66žEò–jy} ÔÈz¤±8aoàEl s`\ï1UÀ=jâcjð[‹âe·À@§ÿª³Îâ! ›çëì¹ð[+ +Û¬‚csª0îSñLë…Îj“=¹¸i~è嬿4 ݹ¨À,õŽH7†a]ob@wýÁ‡"GA_ NRòQ²/Æ»®&´8¹šÐ2¶Ó¹ŒmËÎtBߎžÞ^†êm2ãÛÊehmÑVŸùÜ@´uj‘8´O^ÀìpRL÷¹i†ûŒ¡,eÛô\ ùfEÞ(ùôi³›{ïb°IÞçl4Ø+§½‡Š'\T$?ƒBÜX”-—¤ ª›95ᤪ >tC˜l²í~Ý#d“kCáÌZ …Ëe·×[+âzÕövĪåiá]rð‹H-9ð #Øu¤îJ]FêVÊoݲ¬fÍr?«Š?ÏP–qàn†¹ëê[©Wô#ƒ°%½26k™—‹‰(x¸Gã öq áV•·$ÔbIO|ÿ5Í›nÍŠÂ\MQRð‚Ÿn b +°oõ+ÛR–µ—ƒ/ëb±¦aý51C + +› +«<ßôÒ3-sâáÞ žË¢Êæ›ÞÈÄ tš0aœ 2P¡-æ<P2 Nä ¨É<GòO|Yhãù2¶¯‰CtßkCzdÿሀ±¯A
KRe¢—PÀ‘¤t™ã™YÒ¹/1E gþÇ~S,üù
µøž"Ì–Kn9ãZ%Æ:Õ'WX`„Öø¡o êÅ:²ìl³‰w E›j±iHJ'¥¾Î¦»R—Ùt+åí¥ úÔÕ‹÷rêµAfDk×N%ˆf_+}¼2¶Uï+ulm£Ëë]³ ûÕûÝ!Üü?ƒÎ=ÈtÇ,³m>rN?H”Ã|’ ç¥Á/±i¼.|$2h9îÇŽL©!\D©Çÿ>Ž!E ñ«pùÈ ÉA ^„K‰=
ÑM¢y{0cÎêx EP8Ñp¨xî
Ï:ö¾·¡Z»eXiù
”} +Øf‡ ¿oû]z(ÜTdQP +ñF•"<éÒIN.”5àµFúÙ' s +I×~Ð[ YUeR§ß!hºdÀg¶¨›pYŒ5Ÿ·R@õHßG4;A„§ W¡ŒÃéo-o¦q˾ ?\ Ó--<a˜fç¦Y-ÖÞnC怹ÜÜ¿Šl qž¾†l ©+È¥:\ïQ‹åÁЉcÀ¾¯jB#ÚÅ|;Ñ× °ÍLïßw‘ÈŒ¡›é › › ›9G7ó:º³vRÇ„êþ}òåî᧻‡±ä@«b€m â|ñË`,Õ‡eø/]™r à ôüè/ÃÌ‚;ÖÁh=aB øŒ™ë`B`!ø¤¤…L +œ°„þÿŠÌÔEÓGÓ¢ƒé¢ƒæ¯ CjxåtCÜ?ØEˆ +_ýIæ›ü¡M£‡åºÒÿ(ÇŒ|ßG: ñ¹Oœi£í ã†Y DRêbàcáæÍD4èžË9à«´—~ºÖ^Ma®%Æ 4m#ö{yº/“&”¸ô;ð-ia0)œ¸’ç‡Pšp˜‘©ÿ c5Èhendstream +endobj +1021 0 obj << +/Type /Page +/Contents 1022 0 R +/Resources 1020 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 992 0 R +/Annots [ 1024 0 R 1026 0 R ] +>> endobj +1024 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [297.8955 586.6375 347.2449 598.6972] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update) >> +>> endobj +1026 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 306.9508 116.59 319.0104] +/Subtype /Link +/A << /S /GoTo /D (view_statement_grammar) >> +>> endobj +1023 0 obj << +/D [1021 0 R /XYZ 56.6929 794.5015 null] +>> endobj +406 0 obj << +/D [1021 0 R /XYZ 56.6929 374.8758 null] +>> endobj +1025 0 obj << +/D [1021 0 R /XYZ 56.6929 352.4787 null] +>> endobj +1020 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F58 627 0 R /F84 848 0 R /F57 624 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1030 0 obj << +/Length 2589 +/Filter /FlateDecode +>> +stream +xÚÍZëoÛFÿî¿B åKÅã¾—×Onâä 4Îã + ×Ëê*]Ry `ࢪ©ƒ¤ +»t$c8Ðà<ÛQÀªáÑÁÿ.úû#gkN¹ÓéðÛ{±"¼Þ9 +Ìöá¶è°eô¬ó.ìk½@ep‘gÛ ˜0‘TFN42+ØAуPÞìDlVØp-Mdylöï€æÅ@ËÃŒmR³Ž)« $b± M˜‘BMt öo6óyÞ4#fŽQÒx+¢3à ;Æ ŒÈ*àLðD›%µÿ¼ñ Ž•Ušù©h2îK´T +ß,ÇP¨tiý17™@qSÌoÆ` ©ÝÔlpa ŒÃçüýéÅÅ{ ‚ +iP³®Ê&§nïý8¾¥ïN[_$àƾ²¹g÷â"ÚµU ±¤Ñžµúu–‚6) ®‡xRDÉ“Áó#’aÆ~ã“1¢ŽxÆø”¶$q]狼®P2>Éxg|XFã“LôƆ¤XWôZ€GCÀD¥¾Ç¯íhPËlô tjnžÐÏ€ñ¯æÿV?páÉsÚ +Œ ¡¼¯ë&o„k{h€²ƒïtÖí`q[;Ø‚ÚÁÁÕFÜdèx ú½ç¹{ +}³´MŸÐV'†o«+ù-u%Lò «NNå}VáÑw˜º8Ä7ý(F†o§.¬xuaq[] bØ¥’ŠçÿzõþÝÉÙù³*Û¯–!Çb'’ÚFR'Ïœ´2ŠáÇ"-–›:?Ћ”pjÙ:G‚ªs$5€9¡:˜Ãö GRsØ“R•6n¤ê +;gÅ0±“ÉÛþ‚ƒpuoð¼«<8蜴½‚;wž}¼. W\ŸYM³¬¤ðbLº®;¢VvÖñô”÷ +¹Ã›´†S‚¯ABqÑÒ¦©æEÿ–Õß3ÓaXµªÚþt¹h—« ¤Î)Å +aƒhkI++žfÎy +ç\.nM-Ëü6_úñ‹A _Pr×›:õz…Æî™gxòEÙ™§œŽ°%œ%J„‡8—ÁÌœLVÙG\a:Þ$Ó³Å~ú˜8ˆlŒýÐÂ÷¯cb.ƌń'g>DÂfÇ)4¬ªþÍäÑe!Æcíåqˆ w—oÜ)ŸÀ’t–Ûþ²e¦ézݵVÔä#s ‹p¹ ¾=øAÕzF&„JTdY²
Q=ìĢϣ‹XN‹ëÒóšaÖÄNn
¸Å€{ŠJ/6 gÔˆ|ŒÁ×Xu€|tbù˜|3Ä.²ÅÛîZLFÜJþGב]Ê\s3x½U Û6:ÿªô8ÙÑEú*ŸŒüÎ î€ø«ÕÐÿäCÂIg- ¿}t·¿)d@©Ýw?x¼õÿŠÕ“™endstream +endobj +1029 0 obj << +/Type /Page +/Contents 1030 0 R +/Resources 1028 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +>> endobj +1031 0 obj << +/D [1029 0 R /XYZ 85.0394 794.5015 null] +>> endobj +410 0 obj << +/D [1029 0 R /XYZ 85.0394 769.5949 null] +>> endobj +929 0 obj << +/D [1029 0 R /XYZ 85.0394 752.4444 null] +>> endobj +1032 0 obj << +/D [1029 0 R /XYZ 85.0394 624.285 null] +>> endobj +1033 0 obj << +/D [1029 0 R /XYZ 85.0394 612.3298 null] +>> endobj +414 0 obj << +/D [1029 0 R /XYZ 85.0394 362.0579 null] +>> endobj +1034 0 obj << +/D [1029 0 R /XYZ 85.0394 336.0649 null] +>> endobj +418 0 obj << +/D [1029 0 R /XYZ 85.0394 167.8903 null] +>> endobj +951 0 obj << +/D [1029 0 R /XYZ 85.0394 136.123 null] +>> endobj +1028 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1038 0 obj << +/Length 3695 +/Filter /FlateDecode +>> +stream +xÚ]sã¶ñÝ¿ÂòÌ %¾H`òäÜùÒË´—ôìLÛIò@I´Í9‰TDÊŽÛéï.vÁ/Ñg_Óу€°Ø]ì'@yžÀOžÛT¤^ùóÌaiÏ×»³äüƾ;“<g'-‡³¾½9ûÓûT{áS•žßÜp9‘8'Ïo6?/R¡Ä`HoøøþÃw?}º¼ÈÌâæà /–Ê&‹÷ þrEï>]þõ¯—Ÿ.–ÒY¹xûçË o®>ÑPÊ8¾ýðñ A<ý=ƒôÓÕû«OW ß^]üzóýÙÕMÇË_™hdä·³ŸMÎ7Àö÷g‰ÐÞÙóGè$Bz¯ÎwgÆjaÖ²=»>û[‡p0–ÎÊO&BiÕ© +Êâ‘ 8Ðÿݶ^¡5XXÚPgfû™Ñ0LÃ’Ñ<™7cÉäìTó‘~Ñ3I/ŒÓŠ99¹<˶¾×‰è™”Sä™Ø-)'{·„ƒ, ÝÂF¬|ï–p^à +&å<—Z9 •Ç©¡yÓªY«ƒc5‰·c©‘RY:Öc»¸%kÛñ i³ŽacŶ>˜f˜×{T´L—²e¦¬aeûf( ‹Ú +£õmOÃŒg4ª Z/ ›K퉶ö’Ý·‘Z€tõÄ7ÅÀÌ:Œ¡ø@ÿ#¬ÓaèD Æ +°™ll¡P"ä4ÕÅÓƒFç•)äu:‚ ™Óœoá¬UÙ ÂØi…6é4‚÷¥™ÀI¹ãÍj í4:%Å_¹¸Kñ{¾ÃÔ1ÒX2E䀱qÛ?c*½– Êêxw÷Äž¤bײ>äÍ},1¢—ZׇÅ[ ÷-`ÅC-f Z,œ‰ÃúºêŒŒ¾¸ØTsꯌÈL§]R/Ý(tj™
2z¤\ 1£XWèA›ót˜·m±Û·¼¬¦Þ$[\½ûxÍ+(ÏغÞíŽ8½x)@Õê¬ Ÿeû¡t‹a¡ßGÁ/Öt³å—L3‘(i¾"ÍŽ˜*Ó@îä âö9§îÕEì V<ÖæbÄéa1‚† +æ÷Ë4X¶1£š`öþ,ÚwòoÚ¼
åm¢_n$B§™›Ùª˜Ô “ðÚc§tð™Z¹¡Mf]i‘I¾H WÞ…D*‹Ñ +Õq·¢ËÉu¦ÕúȾ¯âeµªÁš kD9®“Q8Ød$\6Ž‰0ƒT‚,³2RÎj²L93ÑŠgÄ£u⦕ù ©+â(šG™
g È×Ñ%Su>¸ÀW,¥’AîÛѼܳ:ÏjYf„2áEC%ͲR$ÞËW^³J«¢¼>OÏdb6IÕ43›o@HF
Aò9KÕÂô´Â&Ó§•À¹z°#ÁBñ9àJxçÜüÓòø ¢¤w…1ÿàÂ]šö;cÙÌ%TJ¸þ˜6r]×aØu˜çj+-NÛ‰ +¤ +läÄéÌö/!%çúc? £4J2Žžâ~ÊGJ¹˜-Œ/·ÿ ï •%$"±qwÈw»ü@ Œ¼qt.ÔyÐb›¾à»HäÉ4bÍ·Ûú±¡vp"ØØAåYî·<qb±¥ ¦åp^OE£N ¦R£²|±Me,H …¢ÞÉIš9H+¶,E®>¿öVA*¥æ2B,ÖÅ\…È¢¼{é KK™=wùÎ †Œ +õìäJ žcQ L¼3è‡ ¸@ ”— ‹?œ²ÙpUÈ8©DJ¹D²ƒwé!TjiÆ™&ÅÄtÏ‹vô¼hb¡pz^4“7E;}StÝÓ'ºó‡bõi „½¯ùÝ2”F€øEȯ9Ŋ¹ZÇB0qéW ù²[5VÂ@–¢wDü x5üÄBe‹kÈú¶ùÙBÒ ›Î§õšÏ !#¶Ôä×>ÖJS‘ô–ý5çûŒÿ Á‘ìbΘ@¾ä&©Á €Sm^n›7Ñ}»)šõ¡Œo%Ï~…`-Ô=Ö|µ™fÝšçÍÔfúš’:¢¦çaê¡}& + +6«’ô…4¨›¿ .8MBNñŽ!ú´G Ù”$“jHE¥‘t’
u³^ ä[wa$Ü)¾H$@tæ<¤äVw 2I±” «Ã±¿½ ñ(°qÝ—Àá[&q¿ÍÆÅJ…vÚñ1¥€ûßAY•†HL®\›ö +¸ºÄ§c
ìäe'oêÑ£« –ºJwï@0ÀŸr±?®¶åšÚ!Ľhiºr†?üd%?BÖ ûå˜ ˜otÒíî}ë°åëa +£ÓR¡^AÀ¢]bžEì…¤ Mo¨U”ñýó§u|iJé»>É_Êø¡¥F/2ìq.z ãÙçý=Úx]ÜéXQq!æû¡Z‡‚)¡OÆR,Y܇ïÓ,Ê(”žáI¯Âó»;v¥Œæ p^NÝ6¼ú5m ŽµK¸~`9p„«Z•·ctIxÄ qÁ}ør2Ðå‘$ñ«r3X\ñ¤øéVQ¹–ü²{údßG¶]AÇo{ì!;¿A_IâÞ}’ävÛMž>}–U¬JV›z:Õt ÎðëŒó²½óÏ}h«->¸ÏÙÒƒ?ünÿ…²ÉÀÃ;5ïHTæð«& ‰ByÛô„òøµî)éÿÊ[¨-endstream +endobj +1037 0 obj << +/Type /Page +/Contents 1038 0 R +/Resources 1036 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +/Annots [ 1040 0 R 1041 0 R 1044 0 R ] +>> endobj +1040 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [87.6538 396.2754 137.7628 408.335] +/Subtype /Link +/A << /S /GoTo /D (tsig) >> +>> endobj +1041 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [396.1961 286.7149 464.8681 298.7746] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1044 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [432.8521 109.336 481.8988 121.3956] +/Subtype /Link +/A << /S /GoTo /D (DNSSEC) >> +>> endobj +1039 0 obj << +/D [1037 0 R /XYZ 56.6929 794.5015 null] +>> endobj +422 0 obj << +/D [1037 0 R /XYZ 56.6929 270.2232 null] +>> endobj +1042 0 obj << +/D [1037 0 R /XYZ 56.6929 241.4762 null] +>> endobj +426 0 obj << +/D [1037 0 R /XYZ 56.6929 160.4328 null] +>> endobj +1043 0 obj << +/D [1037 0 R /XYZ 56.6929 128.8764 null] +>> endobj +1036 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1047 0 obj << +/Length 3050 +/Filter /FlateDecode +>> +stream +xÚZ[oë6~ϯ0úR8Ö‘x‘Hô)msÚÛ´{šîÛŠLÇ‘%×’“fýï;ÃÊ’#×)ZøAˆÃá77ÊÉ,†_23:Š¥U³ÌªHljž›‹xö +ºi$V^Z„§H +lQ¥ƒ…ÿ +„£‹”@,˜cà Y9Œ$R¦ó›º ë7ËQŠ¨µ+>r¬¶ ŽùLmâo‰Ìkµ'#%cñ‡Ú`*¥õŸÑžÁWDï‰ò°ÑªåÍuùÇ©ts!-
l”Áœ¨Aa«©V~OëKGŸXQQ÷X.Ñ R9Ï9?Û¸b×e»¥X’-zB +IJ’D·/Ž° +ðå}Åmoåz€YßI¥ƒî1KS0Y‰$>‡3ˆé2
‰N#‘óÏCé ‰›± *«ŒJ4aý=uxø û8Ôúú»êžò°£Ë7A ‚¿ƒ0ö¢Æ¥)a 믪¨ 9÷<ô +é£{
ìû8>¸ Äm¸ áj–Êf_‚5#U¸P6 Õ·ÆKõm^û»:É·x2˜tlù~ +A@–õaâÀU%Z L&òxÈ¥˜À8òæ`*û`*é4à Ù×’¨`k~Þ”(Ú@–‰óî@÷‰X/‡? Âï¶9P +é„8ºDÉ·[ Y¬
1¨§µWPWHP‡.¼–)}}‹3a/H™à o ”Îæÿî™á…^˜°èmÁyµwD–ÌÜ Þ›Á…Âñ¼z +°'Î +@•ÚóÇ câ²LXÅb©p’Öçô¤'¢¸o%æW +–æ”J2 Ⱦ*vÄÖš‰è¼¹Ì +¨yCÀ@|LÞNÅ‘ÒýÕÛŸÜjˆp”/â ëk7Ô@ÔRRãñgev¹ÝóýL’Ë|ÃÇ$Çiô¾å+¬ãºêgÈþÂ>.8a×2ŠÒãøxø"ýIHö?~sžü2ýö-M¹óƇT»nöÕ’h®ÙÄ/*ž¼©U»î©Ù}l£?÷Y;‰#ÿ{køûîïýggØ›w8’îû _Aacw¸PIù eYp£k¦„ I€asRZæ‹.?l¿^¦œj;ü1€×\±xk bF^û`G0¸c¡Âjö«=}& |Ãwí˜ÿxÛµuíÉOì •$C´Lý- +ð—,îJgÇ’÷ÿíy)úÿÓ +endobj +1046 0 obj << +/Type /Page +/Contents 1047 0 R +/Resources 1045 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +>> endobj +1048 0 obj << +/D [1046 0 R /XYZ 85.0394 794.5015 null] +>> endobj +430 0 obj << +/D [1046 0 R /XYZ 85.0394 728.7887 null] +>> endobj +1027 0 obj << +/D [1046 0 R /XYZ 85.0394 703.8893 null] +>> endobj +434 0 obj << +/D [1046 0 R /XYZ 85.0394 574.0702 null] +>> endobj +1049 0 obj << +/D [1046 0 R /XYZ 85.0394 543.3965 null] +>> endobj +1045 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1052 0 obj << +/Length 1252 +/Filter /FlateDecode +>> +stream +xÚXKoÛ8¾ûW9Ù ˆ)Qô”flŠMÚu½§naÈ’œÕÃ)'nœÿ¾”H=-%jø`’ÎÌ÷qfø€ŠÆPÁ&0 ä(–c +}ÔÏ— ¨c½CTÞZÅn”ÑäRÚâKJ OÍ×֚̉öAFoè–,GîHÌÚ",[·6Izï¦~kÌÂàÖe<ŽÕ:F¸e(Z‚\ Ë2ÛÔòüOîUžïd³o§¦ïóȦ«"yW!¡Ò«§¦ÆÎú e?³ }/],ucº)I{•º&Îlëóhx³oBºMx +¶‘Š/+ñe•fe> +ymÕQ@¹×“bËR;ÆÆð,ê#}êcQ¥T8Œî Á¾Óh®ÒøÌÜ8LnUJ~IÐqËÚ5ÀÖCUâTâGƧ¢©IÆ^3—‘h”Y80u¼Ùf êÄá< myá$ì%üàS-VÓâPûňÐÐ$K½Æ¦M¶F#‚Å\hZ@·ÁU +×÷®Áo0ùcDÏ+„VÝ^ÞüæQ?ñ+nÛ¨zÎ0ôÆY60l®D:•ãÃö‘çåãȱëÿQví}endstream +endobj +1051 0 obj << +/Type /Page +/Contents 1052 0 R +/Resources 1050 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +>> endobj +1053 0 obj << +/D [1051 0 R /XYZ 56.6929 794.5015 null] +>> endobj +438 0 obj << +/D [1051 0 R /XYZ 56.6929 516.9892 null] +>> endobj +965 0 obj << +/D [1051 0 R /XYZ 56.6929 489.6463 null] +>> endobj +1050 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1056 0 obj << +/Length 2937 +/Filter /FlateDecode +>> +stream +xÚ¥ÙrÛ8òÝ_¡GºjÅ€ +’ð|n¼½º~Ϙœ‡w?__^}øõæÍywW?_3úæâòâæâúÝÅù<ÊlüZ$¼Àpyõ †>ܼùøñÍÍù w?]Ü
gŸ7RòŸ³ßþP³ŽýÓ™ +MžÙÙ >T幞ÏbkBã1õÙíÙ?£YbÒŸ5Yh3N(Ц#FQ æ:5³Ôæab´!
®w÷®+Ïç‰RA×o«æá×x:Xb Ean&òuÕÌ·år[v«y_…ÙïËí—ØÜçïc‹F«õÛ§ï_ë{™vu_Í×®ë=ÙSÙ}j·Ÿšö ûû³|šÕ¶\ôíö‰é6®_}jܺd†¹ÎÃ,Ks +~íÜC9,t0XGƒ)ÄQ<Z'Œd¥
+Ýç †MÙš9Y’Mã™M@j +r¾ÁÐMnÂT¥'†þÿqù(¯Ö/¸ó)% ç85 5·q·E/¸‘ŽBcŒ…ÃGa¢t.FG–ÃÊ6#ò4jpIEdw+Ômlƒ®Ü>¢¥é8 V®c¤ãÁ[!‹vóÄTí’1½žËSËv{2'æ‚2É€h_Õ5£îýÔ}]NùBßòýo¶çQ´U!ávýªÝV`€Õ£G5ݾÜvüÁû +ëÃÂxð4î‡ð¸Vû0¹Þ>1AQ. $¿¡è8è·à‰ËÁ
*'QäÀ€^²G¯¿i·=ã‘õ›©,GÚ0CÐê^ãF ÉZ!´Ð‘DB¬\óPŒ¤¨€€Ã +" +Ð^ÌJo˜†wÀqøç ä¿ŸÌ<{H.=ŠÑÅ(
¥Vì 1~#ïa¹’S(ҒæCâ”g[$?Ñ’Í{«[ð‚Y瘼Kå‡=hE†‚8ÇŸCN”\tï¶=úÂjÌs-¸€¢E +“9çTÄW
):aý&• ¼€¼><q‚(Á’3 ŽðêäPédï¾ñË<µ_•’ož¯ +ucz´èW¥‘Y™4ø÷ŽÌ + Vˆásn, +…³Ò“Â
+BïߓƸ†ÿ±¾`Ôj$&T‘I¿G¦gy±ÙHÀm ¥×0Z‡qžK¯Ñïî¿¥ÕÐPº-@ÆÀqª9üŠéƒR®6œšâ!„ +s2K³L<hÀı/4”—1f¸‚1œóâCÍ è•PbÑÀ(ÉõqðPï„ +o1Ç7ÍsÕd%ã8ðoDOMš*¨²8d0PèÒ>o ZoŠ0® ÄøãwH&ì ˆ8…u(ÊÁ4Ij£’b`‰ËC¥U¤ÉóS¾ÎNOÛ]dàãž:»MÂØ Ý7 ++BH†Ë _·y˜¦6R¬Ýµ†ÞŸKônÌ=ÈN*Y—S ¦F•ÄÇG:);±Ä”öMGx¯{ÆÀvÐ v[2ªŽâB$Å$ÌËû;°äŒèvlã:Fríj}T@ÌK¯“(@+ëi3ð±w÷ÙŠ®FËŠ +¿oò BáÉE â|õ…‡è™‡–àq[½ô-x.ì‰<?‚7dB¹wDæ<HKHkTŸAH)]zßÂWÓúÁëùI¡ÑÍA( ºÏe9ŽA‡æ@êV(UR³ŽLÊA|“cfÿTwÕzµ Å¢áDÀŸOÿ¶!ɺT _|8 ŽŒ9 œ +uà|2/úVTûß#𤮈l5Ê$CâóÅÁRÐÙ ›mõÈoµÚ4?Û?yf×
¢n.ßEy6Ùá2.‘Ç_BŸÀ+ÃñÔË¡!öXºªŽ‘Ò°Ÿv›¾›ät ©°j渉ºMIrÛ›j©sD]¦Iä2MêŸgøò¤DÔ7å¶q5cEÏfôàJÌòÆ#ÕñpåàAÛáÖeó²Ÿ#
?÷H€ ™àË?þŒ lžbmBèÈ tEšƒ<ým\
?¯þð/ñ‡ÿ¦C‹•ezhÖŽ<QI˜é<¢,Ô“ÍŸéÃÿd/T£ÿX‡™endstream +endobj +1055 0 obj << +/Type /Page +/Contents 1056 0 R +/Resources 1054 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +>> endobj +1057 0 obj << +/D [1055 0 R /XYZ 85.0394 794.5015 null] +>> endobj +442 0 obj << +/D [1055 0 R /XYZ 85.0394 636.8504 null] +>> endobj +1058 0 obj << +/D [1055 0 R /XYZ 85.0394 606.7365 null] +>> endobj +446 0 obj << +/D [1055 0 R /XYZ 85.0394 606.7365 null] +>> endobj +1059 0 obj << +/D [1055 0 R /XYZ 85.0394 582.3251 null] +>> endobj +1060 0 obj << +/D [1055 0 R /XYZ 85.0394 582.3251 null] +>> endobj +1061 0 obj << +/D [1055 0 R /XYZ 85.0394 570.37 null] +>> endobj +1054 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1064 0 obj << +/Length 3269 +/Filter /FlateDecode +>> +stream +xÚZKsã6¾ûWèºj„àE¨=93ž§2vÖvj·6É–(‹Y‰TDÊŽòë·
R|IrvR.ÁFh4¾~bf¬´“ÈjrNfë >y†¾OÂóLk¦i›ë»Ç‹o?9±Ìi&‹Ö\1ãq,&óŸÃ$»„xðþîöãͧŸî¯.# <ÞÜÝ^Neȃ7?\SëÓýÕ—/W÷—S‡"xÿùêÇÇë{ê2~Žïnn?ÅÒãȤ÷× ¯ï¯oß__þúøýÅõc³—ö~W¸‘ß/~þ•Oæ°íï/8S6'¯ð™°VNÖ:T,ÔJÕ”ÕÅÃÅ?› [½nè˜þ´TÌÈPM¦BÆCyb]ZƒÃº¾)„ea(¢ÞºÓv"8 ŠÑ1Ó8ëC £Ö¡XÉl M¢Ð2£`a<“E±}M¶sÔÍ· µjqGS +Η;¾+Pfă_¤Ô4äRÄÁœˆyŠ ô–•ôLèñšì©Qôœù/œËç›"%bkÎ,&Z‘w&Ú¤®:/ÖI–£À ÚTfÃP:Ÿ’2+ Ö*—vÔ%(<RBù ¡Ô#Û–†) kÏTVI•®Ó¼ºœê(Š>£ ÚoÒ‘âck• WLº“E¶Y’Óä ˜ +wæVHF¦7ãÚÚ³ÓO%rZ!ºêIòù·Åvd^z‰bÕ7Ý–#S‡š)!e_;ïÀ$¹ ^—Ùl ò‡ÐÌV+l‰ ÙlV{""ðùû.Ýf—"HËš¹Zú#Z¢ó°<Gµœ( þð]û9{I]ÓO{"5|îp]+OÖ)`Âp Ü,<©Q‚°`D±ß¤Å@ÅÑ#8{VÒF¤†avaC¨/ »ŒR[|Âçôž®7Õžš«¬ôL‹ÑsR3)¢7I,™‰l}ÄÎDaZ§A8;iê¼yAõlÒmJD†ÅÖ¨î¦è°•àÁj]8'§á,›t6®Ž VVÒ ÌÒ•3û Ò®½HgUIÑú°#É÷Íܵ„~Û—@ÀA¬H +PeW¦µD™ 圉£ ¢zý0§wv¡£«öÙ2ÉŸQYJz)'°L^2§t ;•ÕwËàyU<%«10¨c!Î:eY fÝÑMý yµL*Z1+ñxC5„# a04=…qaë06]8Ñ©ã@ F °¹"_íîˆl +x_²YJ”ÀGâ{Ÿv~:è7 +¢ÐéÔŽ)%¸1`•éç¤#ñÏ2¨AZ™x(ˆâ!Áƒ<MçÔ"Hð€<´ܤ³l±÷}nýf&jwáÎúùŒŽà”„&í,à+3 ç¤ ƒ|O`ðü SúÇR•<I$âÓ©ŠÑ ÒGnœÊ!DTgó”ÇèYžUj:é`ö HçEá©#¨Õ +2e¥'âÉ 6ñä°+1z9‡o‰‡?àωèÆÖ9KTþåЬ¤ðv)ë…‰fë| Ðw4#eƒ¬¢N€¨ïòc;›7”¡æ(ˆ„²çs¢%ccò“( #1} ƳS¦©0*X¥'–g áB¶œækZØ4š‡9¼æ1TƒÙÝxnŒEø¬Ï¾¯Iï)a_ΛJÕ=,ìp³UR–Ô¼¹}GÜdg-ýc›TŒÝ‰ Y¬7Ù*O]8Â<]$»UU Í9sÛÞ0¾ ü$©î¨`ÇZ™à=JçÖ®äÚOH[ºä +²±ù˜º\Tapûïw_®nnQ
Âø£ÅŽy‘úVî̾XA>ž…?Ulx_]É&ýg³qk¶‡Ïw?ýðaLÛ»G +àO>¨ã*Y?
X¥É‚Zîœa´ƒìžÊσÚjàVu¹¶D„œÐiàóaÓ;ªŸÏ\»tC¨ !—¶¦~oS_¾ù»õÁ[²––M—88žÃ=̹‹ ñ¨w±óÿªPÊÆ&íÒb!ÚBƒ‹!AÒ£æ´QLðX7ÞMݬi(^´nîÕ°¼œ +e®‹$#`àx1À¸ê) Kpû¦¤6ÅclñÞ”âc6KïOžaQ¬VÅ+bÂQ}oBk™)Æò~5³zU4?l´‚7º0^í¡)(:lÑCãpÃ* Õ. ]fSGwæ³\ÖuôM^¥Û< K5uÄbɣÄ⠡ +" w¯ÖÏšò ÜÓ9£¢Õ{Œ7ý³bë¬jý^ð’”¾oüV{Hx+¼Ë˜%¥wÎIÄ€ï$ ëÊ·»ehò°VÍ2-³âH±Çª drJjJá‰x™S“ +}h$¹çÁø¸öî ˜û¸ŠÌ±7Nß¾Ü<~ã§ü‘:~sÚ@ ÞúB–}Su °Œ-Jv!Ä.“V†1³ÖêÞÉ´Es牢ę—d›®¢G@îK¨õKê™'Uò„ŠÆ”œCž¾ÃÛ.7Üs€4[ê…Êö±ÛÔì›m†Ðò3»tÇ”=‹Üe‚‚ )ÿM÷¯Å¡j> hKŸ Æ,@ƒãöµOHªXîó"߯{#,0_¦ûñ D]åuzªÜÁa‚iú’®Š
݃a[
žï?_Ý=€=¡A«Ø-Ô ®ni ]ˆU1+VÔ5k…uš)'V² ¬³9¸‹ˆ£‡QIý‡"3ôà3mGWDÀ{Ö±Kcoaݺ˜ò ¬p¨ðý!¯Uë69f@’©(6mb#—/S!CÇÆ@ôÂ;äXµ »òŽÝo$º;\Uu¾h@".À'J-!–@ý‚㙦m®ãq¦ár)ºü)œ?^Tôàn…ïxrõ†kdùrqxÑÜYþ!M{~qž–³mæ/¡¼C ª×FŒK]ŸUý«Rpªù +ñ¸þ> +%D°,ÊÊS“æC8¾ÔE2¹« –»§µKc ýa9w6#†·D¥M–D¥Ô¨k¨Rßö— +`覮 nª6ŽeÿZ¡¾Ü4¶ùšïD÷yšûïù‡%|ÈæÝ{wSd·KwIeƒÛ¢J‰ê±x¥þ@?Ì]˜hω^ÿ€Ì¤0ðÑe…[tð uóãèMÐ|î?»ö*¯,/Ó™¿qûGý
gˆˆÌ‘ŒÑIÌ°è<m°
ÿ´=`5ƒyAò×1ÊÅxÕ‘fèÏk®32@†Ìl„–Ó–¡©æi•d«ò¨íÚF‹3Á¢ÅtÜrk&\ž€0Ý«l6’J@<‹B{rí†i¸¸ê}AÂHuVïší¡^ÂÏ9x¡éƒÇC zÿÉIíï^|!DàKÿ‡!¶”-Ån¶ä< jöÓûÌ: `óÃH +endobj +1063 0 obj << +/Type /Page +/Contents 1064 0 R +/Resources 1062 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1035 0 R +/Annots [ 1068 0 R 1069 0 R 1070 0 R 1071 0 R 1072 0 R 1073 0 R ] +>> endobj +1068 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [284.2769 238.6772 352.9489 250.7369] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1069 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [282.0654 208.0269 350.7374 220.0865] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1070 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [299.7586 177.3766 368.4306 189.4362] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1071 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [184.7318 124.0912 233.4785 134.8756] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_security) >> +>> endobj +1072 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [330.7921 92.1656 399.4641 104.2252] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_policies) >> +>> endobj +1073 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [401.5962 61.5153 470.2682 73.5749] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1065 0 obj << +/D [1063 0 R /XYZ 56.6929 794.5015 null] +>> endobj +450 0 obj << +/D [1063 0 R /XYZ 56.6929 446.1352 null] +>> endobj +1066 0 obj << +/D [1063 0 R /XYZ 56.6929 419.8946 null] +>> endobj +454 0 obj << +/D [1063 0 R /XYZ 56.6929 296.3851 null] +>> endobj +1067 0 obj << +/D [1063 0 R /XYZ 56.6929 270.5629 null] +>> endobj +1062 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F43 600 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1076 0 obj << +/Length 3397 +/Filter /FlateDecode +>> +stream +xÚµ]oã6ò=¿"èË9@ÍŠ%R¸§ínÒKqÍö’w‡¶Š-'jdɵäÍú~ýÍpHZ_–Z´E˜93ä|Kü2€?~©#„‰¼T‰dQÀ£ËÕö"¸|†¹o.¸ÅY:¤eëëÇ‹¯nbq™°$ñå㦵—fÖüòqýãâý?Þ}ÿx}µQ°ˆÙÕ2ŠƒÅ×·w ’ÐÏûw7·ßüpÿîJÉÅãíÇ;ß_ß\ß_ß½¿¾Zr qX/ìgÜÜþóšFßÜ¿ûî»w÷W??~{qýèeiË˃ùõâÇŸƒË5ˆýíEÀÂDG—oð0ž$âr{!£E2 ¤¸x¸ø—ß°5k–ŽŸŒ4‹„Œ/—€,%ÆO9`A§¶T’3‘ÈП² =e‡…§œuµ,«&ß ûóP" ¿lo; î±F¨‡-ê<L˜PQüDz8±‹d±ÍÒ2/Ÿ7‡‚žó
ò3! ᬳøÄv–€a¤‹–×´cºjòO7՞͋›þ_Uf #a. _,Z54¨6–Ëtõ’—Yí§vþ-/,ßû+®Ù*ó¤Rb0RmãˆI¥…åðÃÝ"Á}ó€© +ÀyË›—±`"Šµ=Õž}ôn@‚NGRY\ô0Z-ÞYöª}C£mjÙ{Êz¼\ñ°CÇÇqðö<È &Íéf y#ìʘ…JD¿‰ÛH°PÄŽÛÖ…¦r—Z®-„.N;K#!=ë,±7LBÀk‚ j‚^¬³Mz( ê†fÁÇH¸„ £ûì(ÊŒ¤œ) ¾¦å +¥r ’&ÐMíÝ>=^ÖYÙäK›[Z¾;ÎÂ$Dh‰²6ƒÓE0\ä— ïE˜I¸pP žêìסgÏ¥Å#ùéa—ÖæŽÍDáù°… Õ4;vú)s~ƒSäñÍoJ?o©Ò>
[Y§Põɲw§Ž¨fa¨mÜCÉ[¾ œ/‰tÛáBÆç&¾Ø?5_Œ—/ZûòåKÜ/t•/ìœü
¢aMã2µ5
R,—Ûl[íôH‡°^>)d
=:N`¦ÞQ6r‹Ž´*st u2Z”¨eu/koÒW{Fûì –"oñÑæ…¡„ðV (¼…'MÁ‰]U×ùS‘ÑT¾!($¬9æiAð¶?‘‹õ>·¥L½`80à§,+ Väå+Åd‰jRÔú+iKl +˜ÌÕvTÅêt»+œ‚8¢'Ù3§s«â°vHi|W·rtUOÊ”c—§–ÙÈ–N€¶J? ;aìlà‘ªšÏž6ÖùÀ㱌£Ìáwƒ°Ã%8U%¦éz¬Â°.Zc‹¤Cù!˱¼^íóÝéD«± B¢X ¤³®ÿä'Œ}«’ƶˆ" „OTGDšÜ?_Òà¾%¬ÇŸv¸/ »:‰…Í, 3Þg \>ãQ2sê k†‘án“©„š+ µžÑ°Ö„†9,sCY‘=§(ý²ÂnQ_Õ¢2Ádš¾C¡ßQ´f±®é0ðèÚ*ÂôÙvJLãÊT¾»]AYzøú%/›VÌD<ª-äjK©ÕâÖv\L§Éî0Œàša,]ÒqÌê±°ÁY$.M«è·_\HÛv•aêhÙ€ +9wÈ’D÷šP6~¤>¨¦Öë¡w6¿½²˜6n…Ýþ=ú˜z*¸Ï+W°8 ¢åjaM(—Ã2…Hµ‡Œ~=L›9‹¨ü$a5B¹›6Ç,Š é¦ÖgFv„‰N‚ÛØù”WB`« ”ÒñoR.ü¤m>@ “FuGj§»Œ¾ä¬jXÒh®\Ýcb5Ñ\¥[îÊ‹EU½š."ò]Ѥ«òÀù%œq,¢º=œ©µ…=Ø Mž.·þ\áp’RP˜|ΚÆ/)+¦eýFA ³&c>]Œ g±Ö®2t9ôÈ)˜î¼¯þªCaé§X[XžRVû-æ&rÇad«æ L(Á ,ÏÖg
Œ 4Ös…cë¼x¬–àùŽ´ÿ507IÚ!î7ÿ5â Ú?P9ÀmR]Ȧö9v¥
ôŨN‘éÃc†YTOæ¬ÖU†åAbü*Næv¡qK\Û +cÛÍ{£IrÖp8‹ ~&
§uÞp<VÇpšínisð +endobj +1075 0 obj << +/Type /Page +/Contents 1076 0 R +/Resources 1074 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +/Annots [ 1078 0 R 1079 0 R 1080 0 R 1081 0 R 1082 0 R 1083 0 R ] +>> endobj +1078 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [259.4835 478.4263 328.1555 490.4859] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1079 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [387.5019 224.9363 456.1739 236.9959] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1080 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [381.9629 194.6431 450.6349 206.7028] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1081 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [398.5803 164.35 467.2523 176.4096] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1082 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [393.0412 134.0568 461.7132 146.1164] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1083 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [255.0796 103.7636 323.7516 115.8233] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1077 0 obj << +/D [1075 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1074 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1087 0 obj << +/Length 2798 +/Filter /FlateDecode +>> +stream +xÚµZK“Û6¾Ï¯ÐQS"x`öä8cï¤6N2žÔ ’ Ò°,‘ +IÍX©ýñÛ`ƒ)¾”ʸ\c’à§F?>4Ø‚Â?¶P! # -t$‰¢L-VûºØ»÷7Ìc‚´Qß>Þ|ý.䋈D!›–,C¨1lñ¸þuNnA]¾ýñûû÷¿<¼¹Õrùxÿã‡Û€+º|wÿŸ;¼{ÿðæ‡ Þ<ÜÌ(¶|ûï7?=Þ=à«ÐËøöþÃwØáeDèÃÝ»»‡»oïnüþæî±±¥m/£Âòçͯ¿ÓÅÌþþ†µxJXñÅþF*A”¢nÙÝ|¼ù¹Øz[ýtÐŒ.ÀW}JÑr aDE‘Zh‘PpQ90KѤ]¯ñ.NýM²M³ü–™¥-°¡|²x“ Ê$KIÏzF4cáBsC”alD[m*;íå”ý+KmP”q™e²*.ûgœ2=@ƒÐ í.Æ1ÐÒÑà~ã:ýú2-$¸“ Ò âd „t…i ^c¾º
ÕÞŸQ¸,lþls¼Iv;¼ûdíÁ¿¯MŽý«$Ýdù>vQÀxÄ›ò))ðÎ9«êÈ,_ž’Õ¶®bÿ‹?|ßëãþ`×Nep#†Rç#F"¥x¥l™£†µãÄ5‘&TÞ°sl‚ß(å;;à +`ŸTÍ/ÖÖS[s.½ Z㚆vÅ(ïB£ˆÒÒLó®ç]ƒªÌJ¶Ás¼KÖIy +’´ —ì“à + ¼šT£A
èÑ!ŒâDÂíèñÑÚ ÷¬m±Ê“ƒ'‚óÑf H‘&”˨Ҙ5*DÒJ$ý¯ 2 ÈMFKÚ–àË|»À›‡–é
~Æô¾\´}u¶Ò¥}¦.u’0h•˜¡B
šÑ£'Ë©1N>¹Òð ùZ¨ òÕ¨jüåqZll•‰ƒ";æ+ÛO|€×zF‰5 E7ñED© -þõêÄ7bË…&;&ˆG
qÄ:æN¯ÆÏÞ—;F<ÝSIKb8dµÉÀ¤KƒF¨b|†, +5÷8k`©Á¤éØ<ÉŸ±¾/÷o°FB AÚdT‘áúÊD£B—Δâ
jÂÉCɦs!aÝÑî¥Oœ5 L·.2D@¢îjóE‰3œq¢ÈÍÜ ¸è wjüŒúr¯çŽàîb:ÂP*s5wÌÖÌD3Ü©QNÙcaƒk³Ž 7wÖ¶º G
hÓ!O$£œwÕy©jƨKM`3fÂqúh3Ì. çèSãg\З{=}$ÐÎd(DìÜvå|%añPÏ,Æ”Ó5ÍÊdsã ,´)nËíÓŃzïÖÁ° +Ž´èvÿ:©¦gÄEß!'† =J‹3ê>:´M˜ GƒŸ±¹/÷úö\Ä´ïÕàTvmv‘¡Â.œY/5¨žk‹_J ¬.Ú¢ê
(Сˆ+ÿ`½ÚÕà PdxÒ`¿bã,œŠLÇÖ©$RãgÌî˽ž%FÃÔ‰i÷7¨9EzÒ&×èRhPJÉεPœ«Q®Ç}’¹Ýä¶x +Êdï¾»9'ìãσͺÌO}lÝد&¤ÕPN›Ð lèÖ!^w¨hË"O[wÓ¡kèSLB—,d¦£ØÅüŒŠ}¹ Š9eF?)¨s¸›™§ã]£f4éK›æ
Ý_Ìp¬…šàXª†÷ç
›<Ûëdã аéÊö?…Àjøå¤:
j@ŸnÑ
™I©°«ÐëÔM³f]ÖÝš˜É²[@]N»†O–Ý ?ゾÜÑ’ýo’Læ.[NÅ¢AÍ(Ò—6IGWïÑPÌ”amÔ8 ”ëñ“=A´rp@–Ÿ†Ê0¥åtï5h ÷nƉR0Çvº òõŒ¸,Ã`½ ™™(à ŒŒ¶ “e˜ÇÏØÜ—;¶¡oòBj1íyAažêÚ"LH õ2›Yâ5¨jB<îÊ$ØÇE +¡ 9èÈå¢-w€ 5Ð}— °áP*wú z\ZqÉæRg‡‰H¨CÕ1tŠ 5~Æä¾Ü«s‘€hÁß´ëkÐŒ=YM"ºp*Ð vdÚJ£óÞ=—DÂlN)]~wJã}²Bý9¬ãÒGî§l—¬’ÁÉ€‚lWSܪôû÷2¬öïáR ‡,/ÝŽ¨TËò%ÃfX§Û<ËäÙbÃÞ–OÙºÀ FuÝÂJ¾LnÙ2ÝbÃj—Ø´ô($ÜäÉö©ômvt°¹ÛŸÅÆuc< +»Š6 Ô©v_i½ízÞëö¥á*KÝ&éöˆ»ñ~«ôÓÔ¾,s³CHMóik—½ØûÈr“ÊzVu' +r¬›Ì×¥•Åƒû¤áçlPŒûb¯爤<º bYa€kj_|ƒÓKðz„CK„<ân üÏöþÜ +>რ+n4$NQ»®FIj@æ± €µquˆã,Ã7'¬ _Ôäª:ÌñýÚ¦‰õmgêø†M‚0wÖøp 79¾8F!ùŒÄã$ðŒ>[ûÆ6¢pw“ã‹V€ 5ˤ-Áw’Iwʦ‚! qΡMˆ@1 mQâKP¬ˆ·þmâ•,’-F –.Ä »0‚IáSTRÖÃaµ;®ëóOgOÃØÁËãÇû÷~PùÐຠ𠂮ý«‹Aæ pêÏó§¾çw\úoêšÒ5uÄëÓOµP7® Z|s
!°PÍ&L@5yþÖ=?°µduaô† „Ÿ§ÍüÈí*“oº;aóÞÆi’n7Ç >#UÝ ¬Ç*¸“íX#B¶üï“Mqx2m`>SQ?˜õƒ¦êzË"¡ÚÇì bç¨zºézv(à…³5Rȧ"ÆÇóÄ^ å‚F›cbÊñÍ6c‘á’’¦ŸÝ'²AÝq kG«Ê…Â@
ïŽû–aÎçZLÊNÙß(t¤£½4¯ù ÅÒ~Ž Í lÇÁÍÍàpà
¶ÅøèsÁ¿ÚÉÄý"ÃBje¯×Þ®‰ï#ÍJÏ'.`^‹x—Oø£}Ž;†¦ÈÄ'Žúú”½t²G+Óú$\r.âwYö©øÆ 8Ôݲ·^¸¹Ž\¾¹
B¨¡«ü·ÿà d–ÞaBrwçtãž\2/O{~ºug$!ÿ@c1vÂUÀÜ-¿dÀŸwÒ?>ýz>,5Æð‘õ wi@ˆWªZ\ðþL¶¯úÿà Žendstream +endobj +1086 0 obj << +/Type /Page +/Contents 1087 0 R +/Resources 1085 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +/Annots [ 1089 0 R 1090 0 R 1091 0 R 1092 0 R 1093 0 R 1094 0 R 1095 0 R 1096 0 R 1097 0 R 1098 0 R 1099 0 R 1100 0 R ] +>> endobj +1089 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [352.879 681.7691 426.5323 693.8287] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1090 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [307.1508 650.7179 375.8228 662.7776] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1091 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [334.8268 619.6668 403.4988 631.7264] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1092 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [337.0185 588.6156 405.6905 600.6752] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1093 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [364.6945 557.5644 433.3665 569.6241] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1094 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [374.6372 526.5133 443.3092 538.5729] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1095 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [292.0276 495.4621 360.6996 507.5217] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1096 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [319.7036 464.4109 388.3756 476.4706] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1097 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [460.1655 433.3598 533.2211 445.4194] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1098 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [362.144 402.3086 430.816 414.3682] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1099 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [293.1435 371.2574 354.3435 383.3171] +/Subtype /Link +/A << /S /GoTo /D (options) >> +>> endobj +1100 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [288.6803 340.2063 357.3523 352.2659] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1088 0 obj << +/D [1086 0 R /XYZ 56.6929 794.5015 null] +>> endobj +458 0 obj << +/D [1086 0 R /XYZ 56.6929 323.2894 null] +>> endobj +774 0 obj << +/D [1086 0 R /XYZ 56.6929 296.7987 null] +>> endobj +1085 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F42 597 0 R /F58 627 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1103 0 obj << +/Length 3157 +/Filter /FlateDecode +>> +stream +xÚÅÙr#·ñ]_ÁG*%ŽqÎá·õZ»V’Ò&]‰¯‡á'&9\ÎpåÍקݘƒ .×^W¥T¥ÐhôI9ð''©„ÎÌ$ÉLd…´“bs%&Ï0ööJ2Î, ÍúXß̯¾z«Ie±Š'ó§ 4i*'óåOÓ×ß½úÇüöáz¦¬˜ÆÑõÌÆbúÍÝý·ÉèóúÝý›»·ß?¼ºNÌt~÷îžÀ·on nï_ß^Ϥ6VÍ$~|wKHoîþ~{ýËü¯W·óvËýcI¡q¿ï¯~úEL–pº¿^‰Hg©¼@GD2ËÔdse¬Ž¬Ñ:@ÖWWÿl öFýÔ16YF6UÉŸŒ ã“Í¢X+íùt›+8O O÷×éô°vÔyÞçÛ¦¦vµÇo2]ºmé¶Û— ʵ{v5ðEÛtún[ðÔœ>W×ù³£©«œçÕ‡¢€§Ãzý‘ñò¦X¹å`.oåz‰˜6+¦\íÜ>oÊjKDËÙ<˜IeÖ* r³qË2oœ_ Íè(~4¥³ +†AöM—Bªkjå» Yå/•gmë¦ÜlfNI†ÌX¯ N9 +›‹2¥“Ë,µ"2*•',õ+×
m¸¨¶Mîn“>MTÓ÷Ø.€åt
NëÁвÚàDÏ ›H[™ßiž3šïôd2‹dœd¼ßV™ LK©Oú–Ì;4 }>äkÐ_Û_-•‘ÖFõVYI¯Ñ{"¤›2&ÊR䄬ãÊñ¦un¡ºD*¬Å¹ {*I”*‘´”üAÙ¾ ‘Tp-:
¨µ[?]<dtìIJDÆ&fKÁºÉçø’Ú¤Q"’#_òÍ +!¢šó; yhq3 nHjÖ jf3©,ѧ:` 4:Jµ¶“XXhdòSÒ’|™áŠoË‹fæ½ xÏ è1·ÉQÙâûŽSP±ÞòâH«5°Óú Ø!MCL@š@añcͼpåö™„¬gðNøE¦(ò5û(Õ‘Ó‚šÀ‘«mÉŒ„á1%$#xóé…×GF éŸñ2 $1„Qý‹ø²ËE1ÒyѪ¼Ä‚¥Éq± ^2p·/ª…¡ÌH(Û7$Ð鹤2øìÐâ«“ÁQƒV+²/rÈæôñ;š;ùÁ›žXµxoL€n¾@‚d +!²QæO• îjþ,ÒðêckÉ0ã¼ +F¼wpJV™íÆO%Ù7úGý„8ö.úË„§“ÇTGq +´?Ÿd˜qV ‰Aâì%h•Š¤øžÄ˜2“pñí…Ê,î.GèB±å™‹ãt]â E`{¡ P`õr¬Ç:]¤•¡ H™3º(Î"0hŸãQC `2}¬àI«3/$ݤF_|yRg'/ö[òþ!@®8d ñHf¢)dxqð¯ÓBˆY èùZŒ}á< ¤- KÂ÷ŒŽ6 À6µŸÅƒœ?fLlMǘ¡³ ξhý3ò4SuI%ãáÝvy ÐjÓ 56UÝ]a†Lßz]½°†@œVYT[¦Ä‘²šîÆ`¬HRCÊ/Õ,– Þ@»âR!'çqVÜ ²€MÙˆþßDª{´ûH#jŠm½ŽÛHš v +•h4_¶h½ÌG{Y@XÉc˜ÎÇzøÀ¥/‹!”v v‡Åû>ŠÁ¿cøÒ‘¡Ž¬ ²ƒ§¸ÇÀ á[÷B$ x©UþÉ/\Ø9
¬^F^n{ßåf·v·mÎ–Ë „ŒZ²ÐÕ7½)ª«0–[v²>
"*¹ðî嵕ØqѼ(l¯Pë¤Á6»j"éó ¦±œQª¥óµ*Íeí +F÷õ
…sÃë ¬ +û÷ÿ‘ Cv¢.\Ž
åRð Ðw é€j0½–ÔÕžMGof¯ôPÏ+Å<A +endobj +1102 0 obj << +/Type /Page +/Contents 1103 0 R +/Resources 1101 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +/Annots [ 1109 0 R 1110 0 R ] +>> endobj +1109 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [341.1654 116.9088 414.8187 128.9684] +/Subtype /Link +/A << /S /GoTo /D (the_sortlist_statement) >> +>> endobj +1110 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [434.6742 116.9088 508.3275 128.9684] +/Subtype /Link +/A << /S /GoTo /D (rrset_ordering) >> +>> endobj +1104 0 obj << +/D [1102 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1105 0 obj << +/D [1102 0 R /XYZ 85.0394 626.5613 null] +>> endobj +1106 0 obj << +/D [1102 0 R /XYZ 85.0394 614.6062 null] +>> endobj +462 0 obj << +/D [1102 0 R /XYZ 85.0394 327.2191 null] +>> endobj +1107 0 obj << +/D [1102 0 R /XYZ 85.0394 295.1135 null] +>> endobj +466 0 obj << +/D [1102 0 R /XYZ 85.0394 295.1135 null] +>> endobj +643 0 obj << +/D [1102 0 R /XYZ 85.0394 265.2577 null] +>> endobj +470 0 obj << +/D [1102 0 R /XYZ 85.0394 208.5998 null] +>> endobj +1108 0 obj << +/D [1102 0 R /XYZ 85.0394 186.2886 null] +>> endobj +1111 0 obj << +/D [1102 0 R /XYZ 85.0394 99.9723 null] +>> endobj +1112 0 obj << +/D [1102 0 R /XYZ 85.0394 88.0171 null] +>> endobj +1101 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F77 703 0 R /F57 624 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1115 0 obj << +/Length 3081 +/Filter /FlateDecode +>> +stream +xÚÍ[_sÛ6÷§Ð#=S±øðÞ\ÇNݦŽOVgr×öé˜YÔ‰´Ü§¿],HQ¶I&µ2çvZ +'ƒŠñdÊæ‹~®ÂkŒáªLp Úsµþ²–et”÷¤PQ¾Z”YžaCGÜñª¨©rŸ.ïrê«oÒ@¬Öù¢ø“1‘WDðŒöcüüH*¯ u‘`¦Èô‰“ÄV×pmUyçÇ,‚ÐèƒEéË!iuØð2Ön¥ +à³ß0eóE¯´ŒÕq¢ÌØ€~ƒ82Ÿ¿aé$h2,-ª‹[_K¢º$ʲ¸}žåØÓ žÍbªÌoPó±ÏKm™™ˆ.J©O +j’ð±Uç ñb/œ¶^ÑÝŠ–´~XV ¹UVý +I¿*—÷ù&|§›ÖÐ)²ø°_üÈðh‘.ü‘‡êlVá敀͒g'V²¼ZlŠ+Ô^lÞ”XaѲ\}$RÚLÒÌ»¢ÊU¾» +Œf–…ËÞS;h +rvN¢À½KƒGÖC RIÖ +)¦dº¡ëìâ™ßÀókÕ3ç÷MðÑYcŒƒxO© Ñýg·Ë’}Ýrì1.Ò’ÇÆÅEv*lˆ‹Žà 0Š#CïM8U;b“œ³Ï93À¾Îºö +Ýk[†¡Zwƒ¯8}'‰…IÆ” J+‚
bÐNE³|½L^˜Å%õR€z›È†zÔ¶ÖŒE}C5Z}ãSã;_ +Û¯a & ‰º9„N 2"Þëi#Š +¥¯€ò!VŒÚnâ¤íŽ n²$-¿bÁh ¬gcoò’˜ âß /áÃ;|VG*Å¢¦„ø*W5£×@(®|^]5>X5)\Å:>˜5wËçåÙûÏÞã3˜Ëêìÿe,íŠ-Dý°R3eåsKÁ&£øôkÿrcû×+`p¥ë áÃó:‰ñÌþxE=ùÃÎb!h‡uÿ?³Y¦tendstream +endobj +1114 0 obj << +/Type /Page +/Contents 1115 0 R +/Resources 1113 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +>> endobj +1116 0 obj << +/D [1114 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1117 0 obj << +/D [1114 0 R /XYZ 56.6929 579.9063 null] +>> endobj +1118 0 obj << +/D [1114 0 R /XYZ 56.6929 567.9511 null] +>> endobj +1113 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1121 0 obj << +/Length 3408 +/Filter /FlateDecode +>> +stream +xÚÍZYsã6~÷¯Ð[èªC +6ÃTžR•– + µ/ES +e¤ Þ±Ÿg<wÎÛ|0kÞ¥¬÷Nʳ|iÀ¾"@X³¥cƒN ±µ¢¡›.A_T N¼^£ÿ Í&$ñ
%äŽ{CCtóŒ-b @òwüL +òâÂþôÛe· LƒÁ*«? x@9œŽœ\ò€ø¶ˆFÇ c㪅ƒ Ø’/
Bë®ByR°·ßÓÕ +E9þ@ürKM§«ÃÈÎ¥8çØj[¸ NX_ádE6/«Ýïö4Gµÿå.½¢o“‘Cƒ„Nq,ÅÏãD¯J‹À†S¥¼b•‘8ßÆ=¤Ùz’÷¼;XIE>4Þì&õ q3jm[s°pU›US—ù¨ý¾îsô¼¹·Î¹h 9}ZÏ8÷Ú +2Ôñ]ÓË}ˆ ˆ7lqm‡ï + +˜÷wÁÄNoˆœÝ7¥ã +Âb‹ªÙÃ'àl-Ch4Q<fä
é5Tè„‹ÍHlwg/Ð)Êö7Lñ¸J\©p8‹_Ýì*Þ Bo
zëÁaØÓ$CÜz°ÈÛÀBc„ ` ~ïØq=þ †$õ8 x¨`»Þ(û¬ ¤è3Ón±¨‡’\wpW +endobj +1120 0 obj << +/Type /Page +/Contents 1121 0 R +/Resources 1119 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +>> endobj +1122 0 obj << +/D [1120 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1123 0 obj << +/D [1120 0 R /XYZ 85.0394 552.4093 null] +>> endobj +1124 0 obj << +/D [1120 0 R /XYZ 85.0394 540.4542 null] +>> endobj +474 0 obj << +/D [1120 0 R /XYZ 85.0394 225.1659 null] +>> endobj +1125 0 obj << +/D [1120 0 R /XYZ 85.0394 200.3885 null] +>> endobj +1119 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1128 0 obj << +/Length 2798 +/Filter /FlateDecode +>> +stream +xÚÍZ[sÛ¶~÷¯Ð£<ãà~é››8:“ã¸g2§éMÑ6§©CRqüï»À%Q¶“8s2ž1@\‹o‹€Ø„ ›(M´ãnbœ$Š25É—Gtru¿ ±Øæ$5:¶úùòè_¯5Ÿ8â4דËë,K¨µlr9ÿsª‰ Ç Nÿûöüìø„+:}=û rLHŧ/=}wyv:6ýyvþ +K &/ßž¿žýòÇÅ鱑ÓËÙÛs,¾8{}vqvþòìø¯ËߎÎ.{•‡ÓbTx}ÿwôç_t2‡ÙývD‰pVMîàƒæ Ÿ,¤DI!RÉâèýÑ¿{ƒÚÐu&F +[3”íß·øZ,ÍQú¼
z°ð°7îü#Á+îŒÞè‚;@²Êš®Ì×°}Äï²<
ðAº5…Ðõª^{{ š¤¤;Èö[äý–…¹TÑHI‚Ȩĺ]g Ø·ÄMï1BM¯P4t®c&[Üe÷0ß)áUž‘‰émÝv0ƒ0#‰< +ÊÛÒ¯…Ö3ˆE ‹=UðÝmYýE<Æ“@1å?½žþ;Kiìx¿ +>%«¬l°EˆpäÃmjÞû +Ô"$>ˆæ (›FIHp”ë¡ùŧ,¬.àÖKšT@ çXØ»_üŽ4Ä×ÔÁƒPzk†ë2)Ât°fÛÔPX¤·ÅbÅÜ·]±l£ +ð¨eYÅîw·Eê3™ÄE¼UMÑj8©Qê˜0øÀŽócam(‚+“@.˜W -êVÌ‹øis_Á^`œ…¿åU"zŽo.7}®]‰Š¼üH)O#cú‘Rómõb£¤%&«¦¬›²‹ƒ{aíL½ÃH©uØ>Q;(È’z8Ïë»Ô0*ø<|¢LÝ (Ì ³x|ÛÛf ˜{ÕsïÓ†%7 ŽâÏ°ÈF&’\Ø©°iÁÌ'@¦³\\Ü— :Î)Cÿ½¹†¼G…æ_>+dŒa6Æ_lPÆî9Ä IvÚ +Ÿ
+EÅ·ŸYž bb(1Mkn»aX{*Ûç®Ò°¸1–Gf]äizÀ]„“„ú;<$^ËuÛ0 7À×ulï`˜ q +wp +
‡š|Ûä<ŒÌþìx ,$1ܪwØòVI8ÁZ"X\O»è¸„Žèð'ÀÃÜd8òóâÞ ͉1B>††Ó³rî +endobj +1127 0 obj << +/Type /Page +/Contents 1128 0 R +/Resources 1126 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1084 0 R +>> endobj +1129 0 obj << +/D [1127 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1130 0 obj << +/D [1127 0 R /XYZ 56.6929 726.9349 null] +>> endobj +1131 0 obj << +/D [1127 0 R /XYZ 56.6929 714.9798 null] +>> endobj +1132 0 obj << +/D [1127 0 R /XYZ 56.6929 546.8104 null] +>> endobj +1133 0 obj << +/D [1127 0 R /XYZ 56.6929 534.8553 null] +>> endobj +478 0 obj << +/D [1127 0 R /XYZ 56.6929 435.1867 null] +>> endobj +1134 0 obj << +/D [1127 0 R /XYZ 56.6929 410.8471 null] +>> endobj +1135 0 obj << +/D [1127 0 R /XYZ 56.6929 210.9925 null] +>> endobj +1136 0 obj << +/D [1127 0 R /XYZ 56.6929 199.0374 null] +>> endobj +1126 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F57 624 0 R /F42 597 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1139 0 obj << +/Length 2707 +/Filter /FlateDecode +>> +stream +xÚÍY_sÛ6÷§ÐÃ=P3! + ö-Mìœ:SÔ¹›æò@‹°ÅŠTD*Žûéo P¤LÅé%7½ñŒ- `±~ Š‡?1ÓŠq™Å³4‹™âBÍÖÛ >»‡±7Âñ„ž) rý´ºøá*‰fË’(™î²4ãZ‹Ùªx ¼úûË·«Ëå<Œ6UƒŸ×¯‰’Qóêæújñæ·åËy«ÅÍ5‘——W—ËËëW—óPÈXE @:¿ß\_ÓÕâ—Ëù‡ÕÏ—«~ËÃc .q¿ /Þà³N÷óg2Ójö +úQ¶Øê §Ÿ2¢ö¶ìÜxÝ™{³§ û¹ÐÙQÓòRjjuÙµãå[³nê¢}¿RäuAë•s¸¥wûr›ïËêÑÉhA*¨ +Ûüs¹=8nþ¬‡ì©3T ª‹;Õò@R.¹o½‰+.7¸é'f®¸fQ©ohßfdhÎr&Ätɲ/f¬'"ýŒóv Z'ê9»•‹#MÊý›
ðS’že¤ MF)D&ºÃ5©óŽÚŽ¸1û숂ȼ Š#Ø£8Bèða¬ _ ûAê=,ÚºUÏ›qaîòCÕ¿Þ( ˜³ xK‡N Ê Å¼vgÖ%ns}"¨5Ý c ño»ÅSÈ¿§a¨ Ì MÄs†!S"¥€æ•eQ äïT—àQÐ
FÊ%DèlrëvÐË©!ýáï–Z +j‘r €úÇÀ?Êú„s¹DäA Ú”~e’píc´;o ”Óá>Øñc°ãÃ`ÇÝY\àðéÕwÊ/ÁP»ßËŽèó¯H«"L§€WáÞOÇ0ø –<X— ViÄâ,;cg
+ 9IξÄë”™ è‘E¨òÖ‰L‰…ÈèÜÜ25Äá0'’h¾`ÎØÆ¢æp¿9at×8ëÖ-e>ïªr]Zl„ô> ˜ÂJJ( àùœow•yAP]¥c¨>4>±‘|;è£ ‚¸·\ÌqŒ*‡Ðó„R1!xÒ—±+ 5š®3Ï_óÝî˜ëœ /Þ~ŠŸ¯'–ÆÉ‘dÐ “ªÔÙi º²©i#w·± +lVaœècÝã‡öW¶bÁÙû² § bgjfQ ìô€v)9ev4‹Q\F©ŸÈ6Ú;óŒNÍ3rö…B$‹°d·\1.çeýJ`GÈ[?¢E?¹øÈY}¿ÐÄ‘$¬),~: Dõ°_{I*=–š@u»jNk¼øÛ»öÁvÖ††Ç&Mœ›¦uÃEÞåD 3ÚájÿÐ0Ú Õ£Úûç)ö \‹µO2LÉÑ¢0”Ø[BU[þå®rè0Ð9ñD"–wÔÒ® cƒâ×ÛäŽs{,Ù-?YìÁsâyдd\YH9Ì +E ¦4=yÌ>Îã + 4ñUu „,ë#„´ 3¿"r,ùÞ
ÝáÕ +Ô ¡4^yÙ• £#öG€XÛ{²£4uyõŠ‚KE=ú ¤µCcÀÔ n[óñà¿QÀб_w g>ȧï#Xtþsƒ»š°É xõGi£?‚}ÔiMu7~ ^WyÛú:º0;\³öO…ôÎ'@çÓ(ÓËovkÆŸmú}·¹Ø¶{9>‰k(Úej9-üõðµ¶ßÕº:¦cDZ ¦ŽÏVásd#>#ȨÄ÷bB -¤´¸~õËo¯/§Jì-ø(‰ôU"Á'$@A/Ó~î°13J ™e ±G‚MúèL8è¿ôøqäÏûÁ»ÇºË?ÿ8±/‰O¤ÉdÎIÓ'JKF¯ ¡-Žž.ž +endobj +1138 0 obj << +/Type /Page +/Contents 1139 0 R +/Resources 1137 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +>> endobj +1140 0 obj << +/D [1138 0 R /XYZ 85.0394 794.5015 null] +>> endobj +482 0 obj << +/D [1138 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1141 0 obj << +/D [1138 0 R /XYZ 85.0394 749.4437 null] +>> endobj +1142 0 obj << +/D [1138 0 R /XYZ 85.0394 707.9711 null] +>> endobj +1143 0 obj << +/D [1138 0 R /XYZ 85.0394 696.016 null] +>> endobj +486 0 obj << +/D [1138 0 R /XYZ 85.0394 527.3014 null] +>> endobj +1144 0 obj << +/D [1138 0 R /XYZ 85.0394 497.312 null] +>> endobj +1145 0 obj << +/D [1138 0 R /XYZ 85.0394 408.0188 null] +>> endobj +1146 0 obj << +/D [1138 0 R /XYZ 85.0394 396.0636 null] +>> endobj +490 0 obj << +/D [1138 0 R /XYZ 85.0394 202.1472 null] +>> endobj +1147 0 obj << +/D [1138 0 R /XYZ 85.0394 177.8748 null] +>> endobj +494 0 obj << +/D [1138 0 R /XYZ 85.0394 109.157 null] +>> endobj +1148 0 obj << +/D [1138 0 R /XYZ 85.0394 83.1291 null] +>> endobj +1137 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F57 624 0 R /F56 618 0 R /F84 848 0 R /F86 980 0 R /F77 703 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1152 0 obj << +/Length 2290 +/Filter /FlateDecode +>> +stream +xÚµYÝoÛ8Ï_á‡<ÈÀš¿ô±X àMÜž‰Ós¼ÛÅuû Øt,À¶ Knšýëo†CÊR¬¦)z‹å˜
g†3?Î0¼Â?ÞÓ‹R‘öâT1 rÝ›oÎÂÞ=¬½;ãŽgà™M®_ggoÞF¢—²4Qo¶lÈJX˜$¼7[| "&Y $„Áo&£þ@è0x;¾ŠK¥EpñïáûÙhJ ‘cýu<¹¤™”†‹›ÉÛñ»ß§Ã~¬‚ÙøfBÓÓÑÛÑt4¹õ?Í~;Íj•›fñP¢¾g ?…½X÷ÛYÈdšèÞ#üOSÑÛœ)-™VRú™õÙíÙjUûi§›xÈ„—œúIuúI§,’BZ?ßLÇïÆ4Øeƒ]ÅL +à ÈWšªDãyP ‹b“å[¤E°Í6Æ/gQùzMÔ!®l·3Û…Y8΂ÆlûDÄaûpÈÖù_a(ˆGû>O3/ì¸(áœ$—Á‡•qûfôåßÅÖmŸ;-QȾ¬Ð®ÞÀ›2àœ¥Z k‰Îp#®kŒ` -¸é’ÆÌ.Ë ßìÖù<¯œ¿šîå\3'©sX˱œ7 ‚;¾_ˆCÇ
Ž˜Å*ñžGÛÖ¿§¢ : ê¥ãüW‡V-Q¬ã˜5S:õÊÌVÎîùaOnØv™ªKâZê !d-ulµ+A€þ.j¿“‡]TÙs“ðH·®Ü™y#HB:;QÆ©²QÊxœFßV‚„ ¯mfÍ¿?lдËÒþwIã¶pÙ]Y¬•a ' +DL¥< +P*Òª¥Í +ÃÀ|É º ›+4iÙýáÃÿ8/&ÃkD²èëáx2¸ Mÿ +U.XšÂytª +
T6 §¤%Êf¢ ñ`6ØLÀY X®Ê œ(WÅa½ N,ÐqnoʪØ7›-+ +Êk‘¤I¯™«?–þ4:…ùÁ±éý1pj"Š†Ž)ä/wÈ2Å £Fu*OªÓÙìêÿ^™Ö7 +?ýÀʼnª›µ…Yf‡u5¨ªuÇÎ ŒRüµ…éwV’ð!\l¡lßÒ·¶ÄH}Õ +Ãów£Éh:D—ÎFÿ\F´v9
æê÷Pú+¾q6ëUÙUo –„âµÉÑa<f©É÷¶lë¬ìÒH¤ š¢´™fÏ{RP9ñ:WO;gà¾Ó@ç
ùÿ¤ÿ³ƒ‚®*…B,}קÖÆ'Áb Éf€ m¢la-¢`îŠØÊÐ|FCiö¹q ÙD…‘8Ëâ` [Bƒ€Sœ@éÔûàÇÛõQ hAeic ~/©#Û“ÍWî ª3¼sŸÚçAsHœ ®~|.îÊý·º…$ßt•b<âþ渙Œ"ª¢Øù gÐg8š *¤'¢ïÍur¼6kqšÞs‘²E ,ø iòáÑÚ'HÞí +l¢¬Äà o„j~ mVéŠ)oHËú…Y›û +•äÊù>¿{äxì@è“iM¯°èðòrʆÓ÷èÌ¡—ç7`/½ru¼ÈA³å„`
¹ÃΧ9w‚3÷Æ arK#=Ž×¯cmQ¼[1‘ç'/nç,|éÍOÿÀ› y pê‚.£øWŒ/Èa]‚Ä‹‚øK‚ž!¾ož ¹\¼R¨xPÒ”±nDüZ çWöëjçáÊÄ¿uü‘(¬‹ þ“T£˜Ž™LÑìÎ÷Yœ0¨ˆ¤WÊÖɉæþoW§ªÿÛ°ËDendstream +endobj +1151 0 obj << +/Type /Page +/Contents 1152 0 R +/Resources 1150 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +>> endobj +1153 0 obj << +/D [1151 0 R /XYZ 56.6929 794.5015 null] +>> endobj +498 0 obj << +/D [1151 0 R /XYZ 56.6929 653.8847 null] +>> endobj +1154 0 obj << +/D [1151 0 R /XYZ 56.6929 627.8019 null] +>> endobj +502 0 obj << +/D [1151 0 R /XYZ 56.6929 405.3123 null] +>> endobj +1155 0 obj << +/D [1151 0 R /XYZ 56.6929 382.8411 null] +>> endobj +506 0 obj << +/D [1151 0 R /XYZ 56.6929 301.1931 null] +>> endobj +1156 0 obj << +/D [1151 0 R /XYZ 56.6929 273.8371 null] +>> endobj +1150 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F11 785 0 R /F57 624 0 R /F77 703 0 R /F84 848 0 R /F86 980 0 R >> +/XObject << /Im2 936 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1159 0 obj << +/Length 2375 +/Filter /FlateDecode +>> +stream +xÚÕYKsÛȾëWð X%bçAnZ/íhË+od¦*Ç +`iS¹¼hÛr^ ¹´‡ÍC]l‰¬³uDSéä0k;æ6*ÚfçˆÅÑè¢qÏ<pnè9÷“4+ëŠÜ +ÄN@iqw]?Ž1 DmYßWÁ…úZ€€d”T^žË!‰AÝÒo ×ó¦j‰çCÙÊiádzÊ ”ŤÑ~ñ°B¹ÅkÃe^÷Œ$¤¢7c UÙ ç^6§O$Ê®p'A#"N¹HŽñuèÖ +¦}ɪ À|bÁ?fãTD
ߣÓ!‘Ñã’ NTî͇ͮÛìüÔÇfGD]¸ãq2™r^d¿dXM¢hû¼ qù »ÖK(@ÁJóc›ƒ¥a3%Ýñ•ŠæÙâßm•µ+bËU?€B‚SÖx¾õÀÆàK–óC|Q §"¾˜I¹-'ÌÄ9f—/톦I„õ!I”\ÈgU° +ÖÙ#)¥ÙteSgUõèµSÐø²©ªæÁÙN9h„ X&…mŽ4¼nòƒ}±EïTiô°*+$Á1W.W¹art ÀóÁøKŠæð¾t0mÖ´d?
ñëà Õ †òDºœRT¹ß¦Ì»‘Ø‚÷<kÑŠñè—þ!…凖H::C¾sþ„Пð[6`[nXl¹]%ã8Itðõr½.òÂSå™’~ 6q¯aGà‚Å +Â3V=Ú%k˜€W˜*6sl´Ë© ÜÔ‰Lg{°â§+gŠOW¨ïÏŸ8§<6F'~åýw@]ÔŽu ’ œ kå© ò%A‚¤Á®äU>ÀG€Óˆ4}æØFÀ=gQ»›wÛlѵô*={H‡7ou0Œ…X!NM´Øm £5ø‰HEhôf¢Í0ÛÒ8•\©tWùYKã½æÅ¢\gaüvsèõ劆7Yž;? +LìñùuÐïŠþ˜Û!5ñز½$ÿÌ,{wwÕ= i·ÙàÌ( Z”Y( xäp¦HËŒ@/‡ðï®X 8MÀþj§
ØvYõç/Euˆ4(œk^”:‡%‹S¦Ógë6W|`ù}lé–ºéºéˆÈæmSíºâŠ^Ésèûú-1{ïãÌ击›w7·C²AÕËE@~Ø=“Öäϸgs²7–ä¡j6+˜°Çîý–:¿$Z4ëMÖ•ó²*»Gò®T‘m«²ð3¿ † |mêa4`Û`‚F/‡2Ðöó´/ +ðm»[=$Ccp_—ßœl0–Ñ£¬ór‘u¡ðµ`rcí@]è´CÊ•½\ÒÃÅȾª(†ïû-Ö+û¶C3ø'Ü:h¬â/´‚Z§è,N_]º1ZhG
dÂà¿Ií"¹‹ +h8®@>H¸»‡þ—û¢Æ‚ÏÙR<iüœ§ +òTøJ Äa§<ð+ýž„aCo?P !Í)VŶì‚ìÚ=4.ù*`ƒpèpë²zágmÇ6ÚUE;T´œdÌt CaD¨"; «óÁCß á°5@P(ÜC 8áÜŸÂ ù t@zîì|ÁNš/\þ æ{Xú£î?þȃWƆۗn? ‹9ødÏJà-:=k±Ó(׃¸×&@H^8æßÿÖG>Œ _$á>¾Ó•£²n±" ûbÒ `NJŽot凙&œŒ¾ôOŸœB¾è¹Ô«¡lþŸ ÜÇÈ e!ãôÙËò',ÊóP†ô™0+_€²² ¹{ܼ|a|í.Bh-¨p}‡ä¡#‡/Mý+µP&6ÛŽ.mÇ¿¥/ûz ÇÝ]Ñð›Ûë_¦W4úÓž†Fájè‚øþ|v®½Yo?>c·žB^§äÞ¬?ÎïÈä~Åy»'Z¾”u•Q@¤þ®°Ú<6œÓøª=vb_ÖäÍ: A…žk=oN\žlÞ,Š¶
~Ô–kh߶îÆ¢W6BùûŒ!z¾NkC ~ú_üêÃS裼òilm’ö¤zòctæ±`º‰‚¦A“ l-~ÔSÜ4ØÚÿ`S ‡Hn’}©ünz;½sÝõl:Ôùʘ±ýýu^úT‚¿` Âãð›añµ+j,ØOünߺl²§šåIyÔB”“ãûU‡|ƒy¤ò4¶ýYç{
‹ý—îª>…çN|8
ø-N{( {NKs“Io³Ùû9Þ¼¿þøñp¤¢ÊŸâ8˜‚º’„âS³Ñ‹á{ý<üŒm›íÇsyÔ}zL…S¡žLúÄ¥µÉÐá©Fëendstream +endobj +1158 0 obj << +/Type /Page +/Contents 1159 0 R +/Resources 1157 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +>> endobj +1160 0 obj << +/D [1158 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1161 0 obj << +/D [1158 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1162 0 obj << +/D [1158 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1157 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1165 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0 +endobj +1164 0 obj << +/Type /Page +/Contents 1165 0 R +/Resources 1163 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +>> endobj +1166 0 obj << +/D [1164 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1163 0 obj << +/ProcSet [ /PDF ] +>> endobj +1169 0 obj << +/Length 1537 +/Filter /FlateDecode +>> +stream +xÚ•XÝoÛ6÷_!äÉ*Z¤¾Ûa@š¶[»bØšô©íƒ,Ó¶YÔô7ö¿ïŽGʲ¶ ‚@Gòøãñ¾iîxðÇ$džŸNœ,ôxèäû™çlaí—7<Aè³0ð}L¬º¡Ÿ°0±ãŽA^ÞÍ–oáE‘»ÍpVûÌ÷îÜ?ÍovYÝÉfáŠÐ›Ç‹/wïh[Àâ$æ¸Ís܈³€Ç‘Þðòí﯈;¥ÏÌû¦è it£ª¶XË&ë + < 0?ˆ„ÅK™ŸÄ‰Æ‹_¸Üó¼ùužË¶ `ºF•4x_´…ò”¥‘ˆ ’ ±45Ðq{HÛ<™D` ôÚg/ô®oÞ·ðåÏp*šgšWÒz¶^ÓÀ‚ù>ëò •G˜n—u´þ¨zšÊ³ŠˆVš¥¾6˜ÕšˆªÈï«loŽÚ¨†ø6}×eè[CÕ Â“{sÎÒ0úâYYªƒ[©®Ø<Nh)ŒXÄ1ìBægxKîBû«—Í$Xvüi`
zH þ0sp ý_ÀU™å÷;UÊ ¨ `‰àO¼h×dU» +7Ù2{:©”û-Èè‡þ¼h雑Âhd+‘2-ÈV[¥ÖfÏZfS®ÂY’ÆÖÑȬ£ ´ hÉSŠ\ BÔ2åãÔ¢Å1ŠGš˜£(œ9ª- ¦‰öE§}/7û—›5½z$·ƒ€áQpj 0#&]Rh5]aaRØB–ƈ5©ûAV M´µRÚõŒ5M²òæ¯Ô™é:;™m³¢j»s_ôĈ¿Êc~ó´)é(U_³}]ÊSÙ©:RÉU-›ÒT›¬®-‰6{n<#>+! yk9–K0ƒ‡U«#}¿( +~‡ 5‘W+µíÛJvíMPòGêP”%Q«Rå÷D~xsÃSžÐ ³\>› +++ËaW`Aƒß\í÷ªÂ»i[+IQYP¥6Ú‹´ìd 6uH–[ùì hø}<¦ÿ–É ó³±8_Oqþ—"°,Ð,“o™.PcÈ•‘žâb„Ä£„ùï‹Ó;ð'-‡Tku®éâ}™1Š¬¡xHk@«iJW4g™a’Ò¾ÐïW²ù‚íy'úýÊôßQ[ÃÿÆ•MH×Ô@,ä°9Q
c“B}cz\ÜÇRZÑ¿k…óbþ€ï +u¬écÄÁ]¿+“…tÏ”CÈÓbü*sÔ•É; Âíꇪî k³oŸµP,'Á7…½ÇÕ~9†ñ{dÕãéµÝI‰hq¢+Ö úë;íé>÷‡.iJÆÚ’Ø}àJ¡ë0û< ˜À‰¡½¡<¼§ÑÀ2T! ôUI…íô0tœÚefm%eEGÙºT`ãÓ·˜ûpz]´î¤êVè“ýÂêªù|¯Ž5G@ê„v{¯ß%´L_aë 7uFØî›Û¦h‰ÛÔɼ£[ +endobj +1168 0 obj << +/Type /Page +/Contents 1169 0 R +/Resources 1167 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +/Annots [ 1173 0 R 1174 0 R ] +>> endobj +1173 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [513.6761 73.4705 539.579 85.5301] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>> +>> endobj +1174 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [84.0431 62.7606 448.7754 72.9224] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>> +>> endobj +1170 0 obj << +/D [1168 0 R /XYZ 85.0394 794.5015 null] +>> endobj +510 0 obj << +/D [1168 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1171 0 obj << +/D [1168 0 R /XYZ 85.0394 565.4467 null] +>> endobj +514 0 obj << +/D [1168 0 R /XYZ 85.0394 565.4467 null] +>> endobj +1172 0 obj << +/D [1168 0 R /XYZ 85.0394 528.8591 null] +>> endobj +1167 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F11 785 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1177 0 obj << +/Length 3185 +/Filter /FlateDecode +>> +stream +xڥ˒Û6ò>_¡ÛJU‡$@Ü›“ÉÁN<ò #qM‘ + £(_¿ÝèEJœ²«Ö>h4èF¿5Á‡ÿÁ"Š½8
ÓE’J/òƒh‘ îüÅÖ~¸ gíÖc¬ï6w÷ïãp‘zi Æ‹Íóˆ–ò|¥‚Å&ÿm™x¡·úcóÓýûÔ á†¾…È#Î÷?~úøqCXŠRy2P!£½ýðnŽRì…"Œóô°ùüønŽT +á åÝÓÝ/ÁѪÝ:ûŽB + õí™…s4Yñ|.ª `Ï’ø= %³™Œè)åEñ`ZënæÈ ðÒ(r(ŽÎb-%î-r¸\ »¢®Ð<DºÜìñUD/3]Ñ`oÊ#ŠÃ‘dôbОÛÎ pœÀg}StgZÙò÷XêÌr†zFK©¢Mš¦xÃôq[ÿ…CÐ!£åi_d{B8eI£²8 þàf²å;~Èoåú w†ô6¯+ Ϭõc…楖¾Yíø;ɽxâ¥"TäɪŽÅÒ_öyîK Ëg£»Þî6´h5Uºç”ƒ5O†w©Ó¼~& VsÉ¦Þ ú¾-J+\ é;˜Èø˜\›ƒ#¬™Œæy_ ›â¥(ÍŽLâ":R`¨¹øÝ Á•ˆÄ9ãuO(Éœ‘”‘SwKñVAÁõK?™¨Ÿüå¿Wi¸äkûÝδ쬈ՊÄ'Î"æ ¾Î2ðrÚ‡ÕXy®L;L"/UA:±í9›†˜” Qpôö¤4k‘'8sVžÄâýhQüÆðµ,À×ü¥Ç’Aä •:_1ؾ<|ËZç4bQìÕà§|‚¨¾Ùg)/ "Ç ›æ›Â|¡Œ] ¿ÑÍ}¥³ "’£‰±@¥ „ξ=)’^š nt8œZˆwH“©*sP›aÍ÷_&L‡¢ÍX[B?ü'k¾m[»}“½ïÛ澬3]Þo‹ŠY_ÇiÁ6ìÈ1 £ïŒÂÁ]S(…§ +?r°€c÷fφ1â·8fÍf›„$ ©=¢×UbY[5Ì‘cœÚxƒ9͉cÈýoW H;D¾Uñ9~Ouó…Fìu¦)Ï)*w#BÐMWd}©ù¢9Q5YW7¼cH\p¦ôfƃ‰@A²N4Öé‘ðâ(’Óhòš6‡©§T’Ž\F$\žë ×r1 F•AÀ‘å ¾ 4è1´ÊÄ:œßJ wí5Š*+ûÜ´Œ äÜí)¾Âœã+ÃÛé‘dX *¡\¾ç8Gœ;^&„Äþ.*M!C+ì]@ m¬ÐKaNè¬çdœ¦^¢Òà[œäRI”¸×(ø<Ìð4—ÁØM±¿û~XÊB€3;Ë_ñRø¸ÎO +¨Ë|gém§;¾¯=¥ª—ïÁ0Eñ?Ï¢ø*&í5ù-¼a’‚²lÝVáæ0Ö%ã +i¸B½=ÄY&J©ZþXŸÐú±Jµ‘4w~4UNù
àۀę&úW¸»E€²»9æwèAŸ ›å¨l¶9“e[f#çqPŸj×^[ÁÄ/$‰§yïsórÿ·iê¹TAxI:”8s.Fbš&Ǥ°rh×.&#ä׈‰1±²ÞÍÙ&Ü?ô“QCeô}ÝÌEð‚Ñ€}oºŒ2…®8ÌYªh©ÎExsÉĨߔR·I‚+ð?O3Ü›úþ}_e踾ž,üÜu3¶¤pš„sÍqkU©ïA4Œ¿ÅªRg{T´X'!0£óæé'P`„áŧõP$ÎÄgx«Øw~´ï†ò‰ÊzÇR¶×ÕÎ8¸u¢.Ò´-WQ6Gà¡Î DÊt7ÔnøšC_$‚¶Añ:5+H½Zt@ø•—š£>Í=€r±ž C@v`HÄl—|–…pj « +Nˆû„.W:hÈ›9Ϩ±È<‹ÅÀi?€u×áÛæ´¸eh;dà‘³q€^Tƒ}}äì +‹Ä´>Öe‘çËÆ(ñµ´¬!ð`k†æqîÿLÅPýO['OõÁ8
èèá±[×-ƒåÀ÷‹1GZÕÖþÄ~Œ] +endobj +1176 0 obj << +/Type /Page +/Contents 1177 0 R +/Resources 1175 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1149 0 R +>> endobj +1178 0 obj << +/D [1176 0 R /XYZ 56.6929 794.5015 null] +>> endobj +518 0 obj << +/D [1176 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1182 0 obj << +/D [1176 0 R /XYZ 56.6929 747.0488 null] +>> endobj +522 0 obj << +/D [1176 0 R /XYZ 56.6929 613.0366 null] +>> endobj +1183 0 obj << +/D [1176 0 R /XYZ 56.6929 586.6546 null] +>> endobj +526 0 obj << +/D [1176 0 R /XYZ 56.6929 473.2336 null] +>> endobj +1184 0 obj << +/D [1176 0 R /XYZ 56.6929 445.9291 null] +>> endobj +530 0 obj << +/D [1176 0 R /XYZ 56.6929 376.148 null] +>> endobj +972 0 obj << +/D [1176 0 R /XYZ 56.6929 340.4845 null] +>> endobj +1175 0 obj << +/Font << /F62 634 0 R /F90 1181 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F57 624 0 R /F77 703 0 R /F58 627 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1187 0 obj << +/Length 1975 +/Filter /FlateDecode +>> +stream +xÚ¥Û’«Æñý|…ÞÌVY,à 'ÇÞÛ—].ŸJ99yÁH" Œ ƒ”õק{ºÄ‰S•Ý5}Ÿ¾MƒØð/6yâQo²"ö“@$›²}l@ûö`ž8‰ü$Ž"xX¡n“(÷“<Ì6Û¥’¯_Þ=~‡›0ðÓ4L6/ûÉVšå~ÅÅæ¥ú‡÷t”'£ú‡m˜^þðÏ—¿’Xìgy&P, +ÞüžŽúB@)ÙÚ3ý| ‚ð0öŠžôè¤òJí¥×ÝáKö,Ú~‘†);á)bS@Ž )Š…·Sƒ!hÐÍhj<$>=aÏ,ûPwÀ,<Ù4ræ”]E@©;örA‡aTƒƒ¯uùÊ^œú‘{ê¬:²gƶJ#QXr÷†GÃÃL1‡Ã ÊØ„nÃ,óÆþ¦^£‡ ‰~5¨);µ×¤õ¾û ¹( ,w'“±ƒú\WÌ& ?hr°d´ÞþXw†ÍÙø ®îÀn˱AŠä‰²
ÀN] PØŽƒª(¿ºE9ØS¬”CNWÖ}x$—–å¶ÔûoF Y3Ÿ kÞÿDÓÄ ¦‘«ùÐU|Wöª'ê;ÃÐÁÝaBO¦>¨¾–
Á?Žíz|½”sè±"²öþ®;¬—(„: é(^g¥"H(¤ük´hæÙ‚ù7¢1c÷sTÒ° îVL ÷±4Ú¦ '¥O
KAeL´„²Å>-}X«j®ŽÐÙæ UVhU ü Á +e„æ|#¼Å0äèËP¿Àß?¼ÿóÏ>‘¾"<{s%î΃¸£<+Âî”êg`‚P&ÉÖ ÖN3å#Lt„€_Âï (u{j`´Ô²³”ºZ€dÉ +fqd"‰½ +pTÀ4 pјéß©ù^5+“³K™›-“ç9Ì©ª.±ð?]”00%ýüf»¡£ àÒ +Ç
'\ÞÝ0 ™YhíŸ#:GqÚNªçÉ5…q¸ŽíÿOºùEºX€BÁÝ Ðe[f€¡ßt¢Èª"B(â,Σ4Έð1H‚ðc(‚Hl<ˆ[Šs¿Ûñ ¹KFËꆓ»L¸mB`†^™8Ì{ +Ýv?v•ÕšÁ>¦ðÎÌspÿ +/o“¥9”,‰Ãà«qP¢ßÐý'À_U$ò‘¦Á€aJ"۟˹–G¨“,_å ¹ kÈëÊq©‰+b~êÝë>ì)-=ÙH!Àï:Ê®ƒÔ•®æe÷tÔD¥©í‹ +endobj +1186 0 obj << +/Type /Page +/Contents 1187 0 R +/Resources 1185 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +/Annots [ 1194 0 R 1195 0 R ] +>> endobj +1194 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [348.3486 128.9523 463.9152 141.0119] +/Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>> +>> endobj +1195 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [147.3629 116.9971 364.5484 129.0567] +/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>> +>> endobj +1188 0 obj << +/D [1186 0 R /XYZ 85.0394 794.5015 null] +>> endobj +534 0 obj << +/D [1186 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1189 0 obj << +/D [1186 0 R /XYZ 85.0394 576.7004 null] +>> endobj +538 0 obj << +/D [1186 0 R /XYZ 85.0394 576.7004 null] +>> endobj +1190 0 obj << +/D [1186 0 R /XYZ 85.0394 548.3785 null] +>> endobj +542 0 obj << +/D [1186 0 R /XYZ 85.0394 548.3785 null] +>> endobj +1191 0 obj << +/D [1186 0 R /XYZ 85.0394 518.5228 null] +>> endobj +546 0 obj << +/D [1186 0 R /XYZ 85.0394 460.6968 null] +>> endobj +1192 0 obj << +/D [1186 0 R /XYZ 85.0394 425.0333 null] +>> endobj +550 0 obj << +/D [1186 0 R /XYZ 85.0394 260.2468 null] +>> endobj +1193 0 obj << +/D [1186 0 R /XYZ 85.0394 224.698 null] +>> endobj +1185 0 obj << +/Font << /F42 597 0 R /F43 600 0 R /F11 785 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1199 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0 +endobj +1198 0 obj << +/Type /Page +/Contents 1199 0 R +/Resources 1197 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +>> endobj +1200 0 obj << +/D [1198 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1197 0 obj << +/ProcSet [ /PDF ] +>> endobj +1203 0 obj << +/Length 2607 +/Filter /FlateDecode +>> +stream +xÚ}ÉrÛ8öž¯ðéªH! R¤æfËYœ´=.Ë™®šé9@$,aB‘ AÚQý¼
”ì°S:x ððv@ÑY¿è,Oç¡Z&gÙ2™§a”žû7áÙp ßDB“¤jž&JÁd;KU>Oó8;›.rùðæ݇$>‹Ãùb§gã^‹l1Oãì¡üOpѶ¦.íóYœ†ÁÅù >3_2Ïò,B¾öÈçÑ"KN9 +ãFâ(™«d ñb1T–2ñ<:ŸEaKßêæ¹2åvoêþ„7š/ÓÔóª6R‘ç=r³|—5<üd]ßtž4ìw†W·k èºÖëÛ+ÙT-çËE¼=ã|ž(Ð íYõ»fØî€G-e9üÇ ìåÁŸaVWaÜæ< +ÌÖÖµ· !iNÙ¯š½¶5oõ^ ëƒëÍ^XŠbè:ÜÀ ¼*<}´Ìe£gÛ¿–« 6•-to›zÜΈ§õ +§ºÿ°B%$Á2ßòH4•EÃÛâL‰"G´ +jóÌç¥à³v ,+:»!™N2dV<bˆB „%Ïc‰e¢æç3‡Á¥Ù«$"MÃ, +T“¥‡RD¡J@ʼnJ([øG†¼›šº0-JŠ0R >èÂV¶·Æ!›¬ ØüÅòéÛ)Õ¿ØL-d³ë}[™7T*•EdÝš‚ôË™ƒS"ŽfDúƒ!rd÷±€4¬ +Á¢å“oC +!mg8iP¦ü oð?SP (®ÐDŽñ04È•ï!¼¿Àzÿ:"èòà윓BiòàK}%õ;QóVöLæù\ñð¤@ =`ò@= |ÞÙHTö>«š};ˆcgÒ=JD¾:/ ? MÎ1
Wëûlc6 +ÿDï}ðÁ+ýd©µ
ƒ{»ÝVx¨ØÇ< +.8bxÝã)´¢ei}K„(É-0š®`âŸ1„âcÿ<V'„H +¦¼JW[¾,…{L
/cW<€õ‚ßÈÆœU†¨rè¸9È߀"#´ðÿ`Ù1ýáÎY£ÓäQ°ê´Ìî`ï’ò6¢Öû¦‘•Vº«&CýÆöÐÂWYWÁôj ÒÈÍ08R\ Ÿíž—UCê %bˆpdY;ðÂþ/ô <ñF sJ4P7032€=VqÃÆ™ïƒ}Õ=Ý +Q}¯¿qÆýiîOq;¸3ºþ6ÍÓàng+ ]T{Ж£¼÷Óûfc:Ô[¾ÞW ô¢¢,
ä—ZÞ,zÏ!ÐRÛ{–Ëî0òSìŽÍ6®WËõöYÄWÖõy`V;±þtét ˜Y$=1>"Àõw»Ç{WUYÂÆXçú]S•Œ¾Óôªó¦Ü û‡² + FÏæé{*úú§3/Å‘÷‚Ÿ¨Ï(ˆòÞpà® ÛjáòÌô¢‡ÂþNŠ<´û½¿O3¹:M30;V¤¶G(F4µÔó’ç;ýd˜hc(„&EÄ +endobj +1202 0 obj << +/Type /Page +/Contents 1203 0 R +/Resources 1201 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +>> endobj +1204 0 obj << +/D [1202 0 R /XYZ 85.0394 794.5015 null] +>> endobj +554 0 obj << +/D [1202 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1205 0 obj << +/D [1202 0 R /XYZ 85.0394 572.1453 null] +>> endobj +558 0 obj << +/D [1202 0 R /XYZ 85.0394 572.1453 null] +>> endobj +1206 0 obj << +/D [1202 0 R /XYZ 85.0394 536.5761 null] +>> endobj +562 0 obj << +/D [1202 0 R /XYZ 85.0394 536.5761 null] +>> endobj +1207 0 obj << +/D [1202 0 R /XYZ 85.0394 506.7869 null] +>> endobj +1201 0 obj << +/Font << /F42 597 0 R /F43 600 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1210 0 obj << +/Length 3135 +/Filter /FlateDecode +>> +stream +xÚÍZëoã6ÿž¿ÂßÎÖZ¾$‘é]l^M»—æb½C[àd[‰…•%×’“øþú›áz$v²½Mq»‹À|g~3ä ‡âÿù Œ‚È3ˆ +BÆÃÁlyÀwÐwqÀݘ‘ 4êŽú09x ‰ L$¢Áä¶CKLk>˜Ì 28 +løáòÃÇË /nŽ¯¿û×áH„lø+ ÙñÕ)UÆ?]\œ'g®zsv|zyuCøá(Ž __Ÿ]^þ“ú‘*kZOÎƇ¿M¾?8›4lwEãL"Ï¿ üòÌAÂïX Pa7F –*”A¨¤ô-ùÁøà
ÁN¯º*Î!–çX)1à* +:»`…&:,q8â ĺH‹tä$ëéÕؒަ봘¥T½,nËõ2©³²@ái ˜0´K°ÁH² Š¹öÄîÈ_^ßGD#™Ï×iU¥UG%ðÏâN4eGÅ@R¨À(®,IGFÇ–Ì!×COJëaB
ÔÏ… M³šz²yZÔÙ!‡Õ˜H×n<ÈBc³¢N׷ɬ!TÌ©£JëŠJå£Ô ÙláŠi»¾ h«å|3Kç~ ê«)ŠŠÂ5èp„zl†uI¿°N–guR§T¯fIžLsW»DVŠ´¦-¶©³â Ušx8Y´ Á€¤[©TóÕíÊ +E+(ïâ{Dš £Žf¤ŠÐlR ó?Ù,©ê *”<ˆe3î BÄ´ i†Ôâ„ 8#k˜È=F´»Mñab"R±V%ßìàR‹@j)ÜâÇÅv “Æ©“2’–I\Ï$¶XÓÁÅ=?¨, |=¦ªo Á +<ßÁ ×a ¥ˆÝºßäõ^M b.ß‚C‚W± ŒyÜ·Á–o´"ΆߵF»õÁýÎÓj¶Î¦®†öl wy9õgˆ7ˆfÓ;k¢†j¶H—©[ãÜnDh]–ÝŲö´yçf¥®ëæü„ +BÆ*h6S )èð™xž’»;"z—Ônóü!N‰Ç‘kKš¾</ h{ìò‘TAÌA½Ÿá +BPC,LØwÿÛ,ÏGç€ÙËÍc@ËýŒ>©Ö'GBqwüL×L#°$x E›V Žà +ã !t½™æٌʓC#†åªÌË» QüXK³·8çQ +'¾né(ÐfÊD̃Ð(¨0pj:ú<ÆY>WÒh‡^¢¨;ñÛ½ößaóë…<œ‘‘Þ¥Œ¡ Æz +®( +Çý Ú³‹š +K°"¥z¬‚tŠÆz1k †QÙUúX¿‘™u˜úzÍ,Œ7 W‹ (Š°ëG÷:
v
½v ¶¾^ìÖòè„Ù‘¡€òòjrvs~ÛñÉY ¢â²5À—"Ÿ½pµœ¼ZŸ Çü¾››8€p¿„¨\òÏŒb +Iz¼mkV òl¿P]RÕ‹Ø L‘ÇMê»sÖØEŸœ5O¯kpÚ°¸Ÿö"맪ÔVÙVÇ…çyž9o’Üå{…4„yý|zÖ?ÿ¼ÛH\–4»O]‹ÃÃelÑø> ÃaV/ÜÉy} ½{–Bõ¯<Ó4/t›-.}z·ó”õuR/ü}³^$nÝe2[dEZ>F·W
6);‰^ÑW.ÖgÉ*™âûÉ–êv7íß dO {‹‚–Nj ™>f”4ÚsE¥úUu„Æ`v0âf妩ïY¯³t¾ë1¨ÜÔ}•ÐcÊM1O`^õÎé "1º y»1(sŸlû¹ë“<©ª¼Is[ã<-—‰§vCIí=éäòô•ôµ :Z`QÏ¡²ði*,76Õ¥©›²)²ß7n¼•Ú ÀPj
.âà ]Š¶âŠÐ±€p$â(“Ð0ÀÚ N+ª6·ËX€RVíÒ‚'bz=Á!+¢'ïØSöFÄöq]5óÚ7¨N·µ5{ DÔ™· —ºùCûb'zï(¥ä˜“Qçççgøk›Ò(žð™'¯±÷X؆¢Þ.ÇCAgЕ—)½§ÀfÈî +«Ø5u“%CÁ®ïY2 ¶¥l ÐX”›|NNDìw“får•ƒ§M—`jé< g¯ãÞ!ԓʽ$za¤ÔÇuV×H+¸CP )èÛ¦y9ûTQ¹JW V]عö Ä 5ÌÀ%öŽQ¸€}yšÌívÂÿ!'X:‚öѦ¡v-jY¢Ûõ £å[ê¼y+}¢°ô1HÒ£æ¾÷žÞ=<Á‹ò£ùT ø5G cPºEÞnnSÍÄTŠÝÏòÝÝïŽTóôùÌpðÜéÌé “Ê
k, †äÙ§4ßR‡ÝE•ZÔtá +~ÏI‹ƒ|ò¬p÷YB…ó >,s5Ä +nëÕÑû÷(wUYÎ7ï³bdUó ?®°ö—…Î5“É +endobj +1209 0 obj << +/Type /Page +/Contents 1210 0 R +/Resources 1208 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +/Annots [ 1218 0 R 1219 0 R ] +>> endobj +1218 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [401.6435 61.5153 511.2325 73.5749] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>> +>> endobj +1219 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [55.6967 30.8502 511.2325 44.7979] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>> +>> endobj +1211 0 obj << +/D [1209 0 R /XYZ 56.6929 794.5015 null] +>> endobj +566 0 obj << +/D [1209 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1212 0 obj << +/D [1209 0 R /XYZ 56.6929 748.2826 null] +>> endobj +570 0 obj << +/D [1209 0 R /XYZ 56.6929 748.2826 null] +>> endobj +801 0 obj << +/D [1209 0 R /XYZ 56.6929 720.3635 null] +>> endobj +1213 0 obj << +/D [1209 0 R /XYZ 56.6929 647.0664 null] +>> endobj +1214 0 obj << +/D [1209 0 R /XYZ 56.6929 635.1112 null] +>> endobj +1215 0 obj << +/D [1209 0 R /XYZ 56.6929 529.3677 null] +>> endobj +1216 0 obj << +/D [1209 0 R /XYZ 56.6929 517.4125 null] +>> endobj +574 0 obj << +/D [1209 0 R /XYZ 56.6929 180.3481 null] +>> endobj +1217 0 obj << +/D [1209 0 R /XYZ 56.6929 143.7717 null] +>> endobj +578 0 obj << +/D [1209 0 R /XYZ 56.6929 143.7717 null] +>> endobj +644 0 obj << +/D [1209 0 R /XYZ 56.6929 116.6563 null] +>> endobj +1208 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F11 785 0 R /F77 703 0 R /F57 624 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1222 0 obj << +/Length 2590 +/Filter /FlateDecode +>> +stream +xÚZ[s£8~ϯð£]µV„lmm•c;wwÜ;½³³=ó@Û$¦Úà\æ×ï’@`{j·ò! tÄùÎå“d<pà|† ¸ ¸ˆ9˜
6‡+gð cwWXÉŒµÐØ”ºy¼º¾õÈ @G¼Áã“1— ßǃÇí×áäáa¾œ-þ=æ 'h4fŽ£{§óõh̽@ P1ä9ÛÅͧÅç»Õäá§_åK¿9Ì™,gòaýåîn¾~œ«ÇÕ|2[,ï@~üp5¬–m~v¨Xó W_w[øÂW¢Ï¯ðà dp¸rEÌ¥T÷ì¯ÖW?W£å«]¦bÔGÌ'¼ÃVŒwÙŠÈ£„–¶Š“±0Ï0I‹(¿n¦¢”ùõ;] ¨¤Æ¦X¹ +|·™â ²ô˜æ‘ö”K AžÀܽðL©~ì*©*¼‚À^VÕ5xgº»Ák(_$YõËR8þ'Md# “üI;¸Fp¶\wÁçb„=ßmÂw¯àû¼+BÕ59=ŸòBx½1ÃD +%Åú 0=Ž±WcA^c!f1±ƒkÕÿ¸Kyš¨Þ_ËØTC«èû®€å®ž±Ì¿bè’L·RÜ`º7é)ÙjÌ™Nå +U
ùÿæ”ïdk¾ÿS¶ÓþýG0æ0¤,Hh© + êø$lª
$Úº{0•/£g0é‹ÎjáfW± +ô*~>EYí†í9& é.E“d+ ß«æq÷rÿ»ÙUv÷ûíDÂeÀRìv7¤,v×R•Ý}×B¬ª
»·u÷ØÝT¾ŽyŸ²áÇè]6jnT¢ ”Š¤ˆ«¢’²‚AC
qÚñ¸^TçKg•‰"ÇgØ@ ^ªK<@:t‡ñUu¢Áð³º;m¿r™ õ‡352ób,_¥¢‘øöáw]ëhùÕ: VÄõF¹Š<ßØïÁ ©§ôŸÄqœnÖ Û>ŸºøÇX§zŒ÷*I¶šqÍ¢—hŸ CëóGêäòK$É”ê÷ÇJª"I¾o)ÂVÕµ?žéîödžò*ÈçoE”äçI9? i¦XÊâAþ‰²¼"I^Wb +²öÉÙ R˜y¯:§ªsÊ<.¹œž·sã$c&ÆÏm2§Ëû=0¬jŸü×\û‚
õ—0¥ú]¢’ªO¢|ÒïVÕµKœéîv‰†ò5ìŸôÁßòT³™ äƒÝ!zßy¡ÉsÏw¶Õ6¶e}s«k;`:Ëô˜{ˆr¯ut»Šòô”mT}ZE›4ÛêËÀ¾ £Þc\ØŠKÛ ÖB•P… ö©A‹^À–â ü ÍËè¾ SÎÐXTG$'’¸è£[Ž‹<1MaIŸnÅvÉ9æ/òšzfE)€‡ŸÔÐDý¿%+Ks%°R_ö{ˆÛDÍ+]ºëX/›·)’›éU5¼ ¤NoŠ›fâÛáeúÑU2¸Ü±dl‹ÒÛ–Önh
µ?Y®'ÚÓ…ß—§
ßï„—À.'à‹½§½dίjt˜NÓ=ìwÞ éöŸsD¸‡/ü¦ê7¿ª÷ Üb›Þ€¶ânLÍ┞ðá}–;Oâ©ó
蛿 %WÉsiGü”VG! ±H@øPuxò愨“cѨè6 *º
½½'ÇÔÁˆCã¨Ë2)& _ä•$ôÕ1F§É’*éiT„ÉO}%µ«æB×Ôxó=NòŠGµîÝ,×”!ñ{Ÿdœ*ÑÿÏ?+2Ûú=×oÔñ º®%¾›ó³ £èß /ý¿‚¨¦endstream +endobj +1221 0 obj << +/Type /Page +/Contents 1222 0 R +/Resources 1220 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +/Annots [ 1223 0 R 1225 0 R 1226 0 R 1227 0 R ] +>> endobj +1223 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [84.0431 793.5053 539.579 807.4529] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>> +>> endobj +1225 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [84.0431 756.4942 140.332 767.8862] +/Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>> +>> endobj +1226 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [507.6985 756.4942 539.579 767.8862] +/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>> +>> endobj +1227 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [84.0431 745.1168 199.6097 755.2785] +/Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>> +>> endobj +1224 0 obj << +/D [1221 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1228 0 obj << +/D [1221 0 R /XYZ 85.0394 694.0474 null] +>> endobj +1229 0 obj << +/D [1221 0 R /XYZ 85.0394 694.0474 null] +>> endobj +1230 0 obj << +/D [1221 0 R /XYZ 85.0394 660.6469 null] +>> endobj +1231 0 obj << +/D [1221 0 R /XYZ 85.0394 660.6469 null] +>> endobj +1232 0 obj << +/D [1221 0 R /XYZ 85.0394 660.6469 null] +>> endobj +1233 0 obj << +/D [1221 0 R /XYZ 85.0394 654.2654 null] +>> endobj +1234 0 obj << +/D [1221 0 R /XYZ 85.0394 639.5008 null] +>> endobj +1235 0 obj << +/D [1221 0 R /XYZ 85.0394 635.7135 null] +>> endobj +1236 0 obj << +/D [1221 0 R /XYZ 85.0394 620.9489 null] +>> endobj +1237 0 obj << +/D [1221 0 R /XYZ 85.0394 617.1617 null] +>> endobj +1238 0 obj << +/D [1221 0 R /XYZ 85.0394 557.6417 null] +>> endobj +746 0 obj << +/D [1221 0 R /XYZ 85.0394 557.6417 null] +>> endobj +1239 0 obj << +/D [1221 0 R /XYZ 85.0394 557.6417 null] +>> endobj +1240 0 obj << +/D [1221 0 R /XYZ 85.0394 554.1294 null] +>> endobj +1241 0 obj << +/D [1221 0 R /XYZ 85.0394 539.3648 null] +>> endobj +1242 0 obj << +/D [1221 0 R /XYZ 85.0394 535.5776 null] +>> endobj +1243 0 obj << +/D [1221 0 R /XYZ 85.0394 520.813 null] +>> endobj +1244 0 obj << +/D [1221 0 R /XYZ 85.0394 517.0257 null] +>> endobj +1245 0 obj << +/D [1221 0 R /XYZ 85.0394 490.306 null] +>> endobj +1246 0 obj << +/D [1221 0 R /XYZ 85.0394 486.5187 null] +>> endobj +1247 0 obj << +/D [1221 0 R /XYZ 85.0394 471.7541 null] +>> endobj +1248 0 obj << +/D [1221 0 R /XYZ 85.0394 467.9669 null] +>> endobj +1249 0 obj << +/D [1221 0 R /XYZ 85.0394 453.2621 null] +>> endobj +1250 0 obj << +/D [1221 0 R /XYZ 85.0394 449.415 null] +>> endobj +1251 0 obj << +/D [1221 0 R /XYZ 85.0394 377.9399 null] +>> endobj +1252 0 obj << +/D [1221 0 R /XYZ 85.0394 377.9399 null] +>> endobj +1253 0 obj << +/D [1221 0 R /XYZ 85.0394 377.9399 null] +>> endobj +1254 0 obj << +/D [1221 0 R /XYZ 85.0394 374.4276 null] +>> endobj +1255 0 obj << +/D [1221 0 R /XYZ 85.0394 359.7228 null] +>> endobj +1256 0 obj << +/D [1221 0 R /XYZ 85.0394 355.8757 null] +>> endobj +1257 0 obj << +/D [1221 0 R /XYZ 85.0394 331.806 null] +>> endobj +1258 0 obj << +/D [1221 0 R /XYZ 85.0394 325.3687 null] +>> endobj +1259 0 obj << +/D [1221 0 R /XYZ 85.0394 265.8487 null] +>> endobj +1260 0 obj << +/D [1221 0 R /XYZ 85.0394 265.8487 null] +>> endobj +1261 0 obj << +/D [1221 0 R /XYZ 85.0394 265.8487 null] +>> endobj +1262 0 obj << +/D [1221 0 R /XYZ 85.0394 262.3364 null] +>> endobj +1263 0 obj << +/D [1221 0 R /XYZ 85.0394 236.8919 null] +>> endobj +1264 0 obj << +/D [1221 0 R /XYZ 85.0394 231.8294 null] +>> endobj +1265 0 obj << +/D [1221 0 R /XYZ 85.0394 205.1097 null] +>> endobj +1266 0 obj << +/D [1221 0 R /XYZ 85.0394 201.3224 null] +>> endobj +1267 0 obj << +/D [1221 0 R /XYZ 85.0394 141.7069 null] +>> endobj +1268 0 obj << +/D [1221 0 R /XYZ 85.0394 141.7069 null] +>> endobj +1269 0 obj << +/D [1221 0 R /XYZ 85.0394 141.7069 null] +>> endobj +1270 0 obj << +/D [1221 0 R /XYZ 85.0394 138.2901 null] +>> endobj +1271 0 obj << +/D [1221 0 R /XYZ 85.0394 114.2204 null] +>> endobj +1272 0 obj << +/D [1221 0 R /XYZ 85.0394 107.7831 null] +>> endobj +1273 0 obj << +/D [1221 0 R /XYZ 85.0394 93.0186 null] +>> endobj +1274 0 obj << +/D [1221 0 R /XYZ 85.0394 89.2313 null] +>> endobj +1220 0 obj << +/Font << /F62 634 0 R /F57 624 0 R /F11 785 0 R /F43 600 0 R /F77 703 0 R /F42 597 0 R /F56 618 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1277 0 obj << +/Length 2680 +/Filter /FlateDecode +>> +stream +xÚ¥Z[“Ú:~Ÿ_Á#T¯%ß ÉÀÉÉ\–™œs¶’<£WŒMl3Éì¯ß–uA6²È©- Ð¥¥OîOÝjµF.üÐ(0ÁÉ(J|'pQ0J÷Wîh }Ë+$d¦RhªK½¾ú×MˆG‰“„8 =¿hsÅŽÇhô¼ù2ž9ž3ÜñûÛ÷Ÿn –«Ùã‡ÿL¦8pÇ_ÝÀÝÏyåéór¹xz^ˆêj1›ßÞ/AM¦Q˜¸ãÙããâ~~û7Y]Õz½xš|{þxµxVËÖ
¹ [ó«/ßÜÑžðã•ëxI Œ~BÅuP’àÑþÊ<'ð=O¶äWOWÿVj½íP“ª”ÌÔóð/(4HœÐÞR¨ï™*¥˜B¿¬n®±àoýçEtôIÏ •Ô9vjØGN€£.öl2õP0žß?±‚?^xÃKYñÂÓ¦ÙË[Vly½ÙQ.ù©LI“•o._„8^³”Ö{–ÞÃc7q‡1,›A¿ƒ jig#—Ç|]‘bSÓ‚@™÷<NNÆBìÏIŒ³_à Ҧ\ÓŠÁ¦ +aŠ“n€øÐÜK†à8¼Àª&eaUJ)VQèYXµAk¬ö±Í¬êØŸkÎÆ‚/(Ü
+Úð'œõ—¢!«›*[ !~wû÷bÅ‹×eÛaO +1v™—k’óòl³©&( ÓºãÈáÀÀÏé÷üÄñ4è÷¹Õ·åSΡëp˜—iºËÊwÜU|$Å‘To¼ôƃô†Ðâ NP&W +iÜÆÃÜÚpOÔöÌêÀ+Z—ù‘› öÂÖì°?£ˆ72¡cËJJyËí†MöÕu1jÞtä[„
n·k›—{’‰™ïÉžòº¡{¡®çDq Š½d¼rÄd¤ÈhΧhM™5Þ9‚d9´Cò %yË’, ª(Ž†)cØùÈ»À±&e!YJ)–±çZX¶Ak4÷±Í<ëØP±»¿Ò )¶BsšÓp»í™JÓ²Úðrë²YóÉ¤ïŸ ´¡8p°§³Æ&rÄ!Ü|ÏŠº,D³ô®]`B<RĽ€ßý¹aíEŠ\þ a9ýúÊ”3âÔ
à„.œµº”…S)%9EÈENmЧ}l3§:¶ÒÇ¢HË
7?¨µ6 ÿ÷´ùYVßE̯îiïÔ'¨xž$xüv +Þ¿²³C•å’ó8´¼ #;KºÔ0KJêĶœVèKgØF–:Ø+úã˜ñ3m^³î×éeµe-%¦Rw‡<K5Uô= ‡²jLŒÕ$“‘É¿¯¸m³!ÚH7âºñÓÑ¥,¤H)EJXLÇ +‘ÒÇ6“¢c«“I˜†Ð(?™x¹©ŽiÃ=ÚÓ¼æ5
î0 œ0òü®ò? +ãx‚i.ï?UwÊ úÃ4°0&H.Ù†&e¡AJ©SÉC‘…´FC ÛLƒŽ}“ºÎÛX¯µ…ûél>_9³÷.³ßQ7<TÔSö¡ìE¶)¨tBKѸl.[Ý—eó®Çnϳ®fÊâ#Œ=oä aZµTîƒñ}ïB¨©K
®¤NvçY·BŸ?Ã6ÞÁ¾.÷{éÈ”.æ¤!¼t“å‚ ¸#°ðr{¬4×·¨8gUm C"Ç}ßrL½§´'Áˆ7h|~9qr‰Š“… !¤ˆHåžnÃÕxè›iЀ,¨ IòžAüs.0 ǸËÅ\Ò@`läË溮&ñ¸s¾_ûà?<?¼p¿Ö¥,dH©SÖY¢s+´FG Û̇Ž}¦ûë*ƒ° #½`aîêìТÕ+ÜÂL Aä†àßdœFŠB¿çýúc¡És(‰Ñš4) MRêt‰B‰…&´FS ÛL“Žý¹¦Ý[Ï,ÏHMû±]'·e²àêïD¸ï»î È>Ë›³øO^±þb¶TeÛ]ó/Y^Qj tO(íR +Y« Yëó!4.EGSÊ’õͪuÖT«ã½•B˜5"afô¨pº¹ºCõ`N¶Ø,«²¦Åš ÷¢ýŽ¼‰ü¥ÕO_Ÿt ì ]Šöu) RJÑ!ËÌ +ÑØÇ6Ó¨c Bʼo §„®Û9Ï÷mPbß8gŽtÉ{"Óˆ÷å+Ýë–7 ÎM`ñI|AÏš”EÏRê¤çÄf.6hMÏ}l³žul¥Ny5íjûSI62ÈI‘¨Ûó!vèç“ž™““ñC•ÕiiÊ-ÀÕkPá®ë øRVO—²(\J$ß7X¡5…÷±Í +×±Åé\r©Ù:;ÛåÆËî,ÏåSäàA9èr𠢂Éq»#ÅÐÆ Î®â±·E6¾.5̃’:Ýcý`˜+ô‰‡3l# lu&„¾Ì´±"㸤x; ðÒŠ%Éè+pgJ#`ÇãHóø‰×¦ØÈ?rZÀÙÔ¶be ¬ç/FN™¿ˆj KÑÿ°…ûöúõˆb¸:.fÿ¼~ ‚ä@Àx!ÎÓ¥,tJ©¶—˜VhÎ>¶™N {¦î=¯ì=‡Œ¼n¤A‰° gzzŠµ6[žñd‡3Æý®1¶.ä <ö&«t#»u]æ´é'³>Ùþ·¹Iç-~Á}$c-òÙV«ÁÀűƒ.ùUMh˜)¤… úm¸'öûÀFòu`~†áPOªcñb þ—´ÜVä°ËÒV5ÐòÉâECìÄAè/´ÐøÚáo¿BÓ<=mÀ!*LwÇü¿T´> ùÇœfMAÕÕº8‰Ð72p°nÊ"{'ìYâwìy J9ÛEìK¯ŸÀb kàɹn?u=¯ÈKcÚà.³A'ö Sk£â@Ž‚²ß~ìq;¯ù ¬“¨ì+Txº,aºacx#»^qŽ`ü¦L2Å óOØ?Iý]äEñ ¥• ðw ¤þÎ…oJñÆ4ë#èÝQî%Ý®6ÅßÇí!Eìõ5-RÞšð{´‡ªŸß& p[ Ûg¿@cÝm{†@¹ýFnè+ÍË{>XQ˜ ñ4[–ƒie”¾ØÀ”´ïu™M³jÁ2-tÙ} îòøÈ-Ÿm*ØdÀ/´î,òÆ2÷™Á‘Åv`,ÝHÔÞÞ¸T½+¹hmQYaMùÿcÉÝ ¶îÚÒL4ù~ZÄBLÖ~(óF_¨ ‘9fòiZî§&~ìµ1› ¹ãõÿç; +$sž®’ ¤Q"Bø´ ¡ò"=¶çj^m— ÿœEð âÓ‡Éñ.®D(ìÈ«˜„ð¿<{¡5,×ÚÝ +ÿuö‹öeÑìÄXØïr‰?ÁõìL*V è+nÓÝÌç Ç®TÆʇÍéf¿~S/T3á`ûìJ‘W2Ôþb2¸_W¹‘ÿûƒ*-U9^<tã„› .0‰XÓGŸ ¹öBlXúÿ +endobj +1276 0 obj << +/Type /Page +/Contents 1277 0 R +/Resources 1275 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1196 0 R +>> endobj +1278 0 obj << +/D [1276 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1279 0 obj << +/D [1276 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1280 0 obj << +/D [1276 0 R /XYZ 56.6929 771.5874 null] +>> endobj +1281 0 obj << +/D [1276 0 R /XYZ 56.6929 747.5177 null] +>> endobj +1282 0 obj << +/D [1276 0 R /XYZ 56.6929 741.0838 null] +>> endobj +1283 0 obj << +/D [1276 0 R /XYZ 56.6929 714.364 null] +>> endobj +1284 0 obj << +/D [1276 0 R /XYZ 56.6929 710.5801 null] +>> endobj +1285 0 obj << +/D [1276 0 R /XYZ 56.6929 683.8604 null] +>> endobj +1286 0 obj << +/D [1276 0 R /XYZ 56.6929 680.0765 null] +>> endobj +1287 0 obj << +/D [1276 0 R /XYZ 56.6929 623.4385 null] +>> endobj +1288 0 obj << +/D [1276 0 R /XYZ 56.6929 623.4385 null] +>> endobj +1289 0 obj << +/D [1276 0 R /XYZ 56.6929 623.4385 null] +>> endobj +1290 0 obj << +/D [1276 0 R /XYZ 56.6929 617.0603 null] +>> endobj +1291 0 obj << +/D [1276 0 R /XYZ 56.6929 602.2957 null] +>> endobj +1292 0 obj << +/D [1276 0 R /XYZ 56.6929 598.5118 null] +>> endobj +1293 0 obj << +/D [1276 0 R /XYZ 56.6929 583.8071 null] +>> endobj +1294 0 obj << +/D [1276 0 R /XYZ 56.6929 579.9633 null] +>> endobj +1295 0 obj << +/D [1276 0 R /XYZ 56.6929 565.2586 null] +>> endobj +1296 0 obj << +/D [1276 0 R /XYZ 56.6929 561.4149 null] +>> endobj +1297 0 obj << +/D [1276 0 R /XYZ 56.6929 501.9076 null] +>> endobj +1298 0 obj << +/D [1276 0 R /XYZ 56.6929 501.9076 null] +>> endobj +1299 0 obj << +/D [1276 0 R /XYZ 56.6929 501.9076 null] +>> endobj +1300 0 obj << +/D [1276 0 R /XYZ 56.6929 498.3987 null] +>> endobj +1301 0 obj << +/D [1276 0 R /XYZ 56.6929 483.694 null] +>> endobj +1302 0 obj << +/D [1276 0 R /XYZ 56.6929 479.8502 null] +>> endobj +1303 0 obj << +/D [1276 0 R /XYZ 56.6929 465.0856 null] +>> endobj +1304 0 obj << +/D [1276 0 R /XYZ 56.6929 461.3017 null] +>> endobj +1305 0 obj << +/D [1276 0 R /XYZ 56.6929 446.5371 null] +>> endobj +1306 0 obj << +/D [1276 0 R /XYZ 56.6929 442.7532 null] +>> endobj +1307 0 obj << +/D [1276 0 R /XYZ 56.6929 386.1153 null] +>> endobj +1308 0 obj << +/D [1276 0 R /XYZ 56.6929 386.1153 null] +>> endobj +1309 0 obj << +/D [1276 0 R /XYZ 56.6929 386.1153 null] +>> endobj +1310 0 obj << +/D [1276 0 R /XYZ 56.6929 379.7371 null] +>> endobj +1311 0 obj << +/D [1276 0 R /XYZ 56.6929 355.6674 null] +>> endobj +1312 0 obj << +/D [1276 0 R /XYZ 56.6929 349.2334 null] +>> endobj +1313 0 obj << +/D [1276 0 R /XYZ 56.6929 334.5287 null] +>> endobj +1314 0 obj << +/D [1276 0 R /XYZ 56.6929 330.6849 null] +>> endobj +1315 0 obj << +/D [1276 0 R /XYZ 56.6929 315.9203 null] +>> endobj +1316 0 obj << +/D [1276 0 R /XYZ 56.6929 312.1364 null] +>> endobj +1317 0 obj << +/D [1276 0 R /XYZ 56.6929 297.3719 null] +>> endobj +1318 0 obj << +/D [1276 0 R /XYZ 56.6929 293.5879 null] +>> endobj +1319 0 obj << +/D [1276 0 R /XYZ 56.6929 269.5182 null] +>> endobj +1320 0 obj << +/D [1276 0 R /XYZ 56.6929 263.0843 null] +>> endobj +1321 0 obj << +/D [1276 0 R /XYZ 56.6929 203.5771 null] +>> endobj +1322 0 obj << +/D [1276 0 R /XYZ 56.6929 203.5771 null] +>> endobj +1323 0 obj << +/D [1276 0 R /XYZ 56.6929 203.5771 null] +>> endobj +1324 0 obj << +/D [1276 0 R /XYZ 56.6929 200.0681 null] +>> endobj +582 0 obj << +/D [1276 0 R /XYZ 56.6929 159.3692 null] +>> endobj +1325 0 obj << +/D [1276 0 R /XYZ 56.6929 131.475 null] +>> endobj +1275 0 obj << +/Font << /F62 634 0 R /F43 600 0 R /F56 618 0 R /F42 597 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1328 0 obj << +/Length 550 +/Filter /FlateDecode +>> +stream +xÚ¥S]oÚ0}ϯðÛ‚´xן±÷ cT0ȤM”i-4 šº_?;†4´t{˜òbû~œsÏ=!ÌG˜æ(Ô ¥;Љ<rÌ NIA7«Ÿx >IŠ4Ö’J”Üvz) J”l—~4›Å“áø[/ ü÷pz Ä‹^Jm̆$øýqÿz< Í£Ùçï®èD“¡»,¾ŽFñ"‰×y
Ç“‘I!½UråÅIK»;f9ÿô–+@[3ᕘi%Ð/sL´¦hçqÁ°àŒ^ +oá}iv¢Mé%©SX(^ЊSDÖBÐ3±„Æ’QæÄ2*°^@ÀH4ï³½rX¦‡]öPWG7å¡vÇþØèbævÝ9f\6Ý °&ºi;Ïn³}öfÕ›˜ÿÇöŸ“Ü@¬³|Â4¦¡Pm+ ¼$«—ˆD +UÈÄæpb<EAøë‡=È®H]Æ’cÌ2›ª÷®f¶>®(*6yýû¬“ðû<ý‘Õ.ã:?Ø*ÂýAùø´Ïïîk‹‚Hh,À¹²6p‹M >á ü€bc}ã”NÞ1̪„b +endobj +1327 0 obj << +/Type /Page +/Contents 1328 0 R +/Resources 1326 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1335 0 R +>> endobj +1329 0 obj << +/D [1327 0 R /XYZ 85.0394 794.5015 null] +>> endobj +586 0 obj << +/D [1327 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1330 0 obj << +/D [1327 0 R /XYZ 85.0394 752.4085 null] +>> endobj +1331 0 obj << +/D [1327 0 R /XYZ 85.0394 717.7086 null] +>> endobj +1332 0 obj << +/D [1327 0 R /XYZ 85.0394 717.7086 null] +>> endobj +1333 0 obj << +/D [1327 0 R /XYZ 85.0394 717.7086 null] +>> endobj +1334 0 obj << +/D [1327 0 R /XYZ 85.0394 717.7086 null] +>> endobj +1326 0 obj << +/Font << /F62 634 0 R /F42 597 0 R /F43 600 0 R /F56 618 0 R /F14 608 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +875 0 obj +[590 0 R /Fit] +endobj +1336 0 obj << +/Type /Encoding +/Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis] +>> endobj +1180 0 obj << +/Length1 1628 +/Length2 8040 +/Length3 532 +/Length 8905 +/Filter /FlateDecode +>> +stream +xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä0 00Ì ÝÝÝÝ ’‚R" ‚´t ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶ ‡Œ5Ü +¬‡¹rðpr‹ t´P(ÐWç…CfL9g0ЇÉ]Á¢ +Äü{fX E +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 +~"ÅVöè=”Žòíí`õ§ï3 t;k‡–Bf?õ[¼„Y®¤¾ša£„+ g l’ft]ÎB‚²w3ë‹,£ªˆôkêyô’úÅ> ¡ï„móW¯µrÅý¼0Ï”dË#»§BŠ¸ÝUJàž uÕ ñÆIÍôaòÔã·×¸§ ™ žL¦€Ädô<cË-8àÒ—£t‰Äº4ú£|©D„¡¹šŒ]¸ãÏßE¯¡ >ÓR·9xyôöŽ[Ìï`º~ͲûDœ¨'ˆº5e[-0GMÓ=KÊÊJþ&â&’PøS¤8ëãin,õ 2PU«r`ZÅÄí¢v8Q—ÁèÍ ×ë¯oã»o[2ÝO2Ó¾Ðm/Ÿß×Y¿üìvV¹"_=5Ó›é¶è áaÖ™7þv|g “y×&"Yæ Ж(¾+ÐM oûÁ|°>›à¦± vZÎI ÏW´Ä%^‘›üˆ¯Ú]Ö%½ZÆÁ_Ï@ÄRdçÒÄ9è©‚†õ‘kãC¾¥HzõOlnÕžÝÍà™>{óbÙ7U^|ä-)G? +8òÞ¼x“mì¾%ÿjã=!•š[žž;[#ÆŠ™ éJ©/A%Ñv–µû`éióöí؜njP~^z•çQ•7˜¿\扯â ÈÛ.|âùúÁèéá™ +¸È÷»Œq„z`²\F棖ûEœ!~õT¦¾\Ž'4/ ýCîe– 7,î9tãÒ¾Â1 ¦’·IM^y/¢˜kIm;˜¨½}O«•oÐHâ•¡Ç6—]í 7ôh`† JTÂcweófœkÔ—ÕRÐÓ(9%Ö¯c +Ó·_Ü€¡èüêr_7ýGmÔ&œÐ‰lÞÆŽ +Kê#Tð Ö†§øñÞ ¿šûDE&ñžËœ^QH¶!’Þ»¸>à áÉà̹ç$ÚxþF`Š×Í4IŽ@N@ÒÖ>_9²J¾ÃEúOê +uÿ'¢ µ?s_¯Ð‡öÿŠ˜'u +BêH—‚?ý +$OíœàÅ€DÈ +¶_O®ð -¡;…® u§uªºXÄ[AŒù××¼^L ¹ê=_󱑵ħŠfJ—äÌ;7œ1¾,`_q” ¾´9›Œx•±tþ” +>C{(©¼Ê°nwð,K
?EÚ7þBq&‚´”jɸˆ·?è¦ú-ŸCØüƒ%¥uXcýøââBïÅ ´ ;ÁµÜ3höŬ ¶÷Ét(‡„šœì :î´cØ¢>:ƒ‚¯úò‚#ÑǤ_VItSÏ$ëŽ`ø~"ÔܲÜr$ŒU–Y7÷“ø?¢ê¹iâ¯ÉqÅõãÏØISª5ñ4Â…èÑb“EÝêÑÑn›p³ú†-.ä‰ìošå•Hû~B»ÎÂî‚T§Z§Ï_)© OqÓzèß÷>ë˜Ê;dpI¡rr1ÛA +öÝPî2Pw]¶u¢èúä»(£ý/Ž¾ªˆ§þßÜ¿~&æ[1¸Aé-KžÚEО5JÃ÷.føzßwi°h“bLñB³ß6ˆ +ÃÐÙ²¶©HÈ 9^©;¢Ìœp»Ãm%{r7E •€ÏŒµÂE±…ʨ*o,„ó QÞúÊ䦀(ô$íªy{Çgk9©‘5Â1ª0Û˜F3ŒÛ!s0¸4XàŠú#r¥Æ2á\8nqå°Ãs}䮀„s–è5)q…i¹C9ad¼¿`u
^<‰2 @´ÄR×$âƳ—xº>áÈïž¡wdª ‡}Té†×ÎÂËõ€Èøt\1Ü~‚9 ÿ½8ia D9©ì"Ð!gÑßqÝ ùA“ׯøŠ +»]‚ÄÙªAÓ8ﯙÎd@Iî?_ɽŽbÎJÊ8&1ß’bçy·ÌJü®J _ƒ|¡iïÂC®¡L;¡Æ–=x8"ÆÝù\šGd'—®®ðÖ/B¿ÝÞpRÆ'µsñX'MÂÁd;ŸäÕEûtGmý«†g¾ ¿¨öùWí},¾Ï†Ä›tÓk„fªõžÑ »›&oô/L¿ÇGìü²•âBZmÎOw݉Úñ¼>–¶ü^Ý všÉŽHk6Œ´¶DM0¦›}Öda'¨šßo·é˾xWp¼311ïçdÏ ˜9óÅÔ §?¯jò>*§¨¦‰Ð:’-+X}7¿$ÏL \œö¦nD™ðì¡ÉX˜vWŠñ=mç¡|'M}„ç‹çÄ_’øÏ£÷rci%Åës܃ ¨ÄÏ,n±±ˆ" 5Ù½6ìÉ6úQèÒõmŽ¬öó–à+q®Æ¾ùÃ$ô|Òî]¾öÒñÕäË&æèñ²€Õ„KfVº”DfƒŒåZóbúä`#öZ·< Ò_Ç÷-¦ªÏôª +_˜lg˜¨Î>«ŠTÂ7 0¡ðW~—ÛC!<ZüòþÅ#(·3¨bæ:ߨn¢Œè½Ù$ÞÄ‘Îf;®Ì* =ËnÙ†b…ƒ´ÂVE¼Á<öuBgˆÿׯxî×_òÌz—XˆÖ`©Ö4siÝÏAí+<¾ŸãÁE.Q˜ÒQqúÖDõ”ÏÓ$`dlÚ/BŒñY<xŽ%Á„+{æÔ¢´®³N‡”TøTõ”V3Tj+"}âžÂr}©Xž\L$ÓÇÈš÷ŽEh®Š-xù +>_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë± ‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~ÜFYYy³]ˆ:¬aÔ_|žjÓM+ý‚0@îhÅtÙl¿Êgšê… µAbDå·Ôw¿þ}ûYÕ× iîB Õ*jòýZö˦ÏN’FéT/Hn±úÁÖ“4ÑOEìØœz~Ÿ
Þ88‡á ‹w|q£ªšîF ªãÆÇ +TT>/5—䬽%‰”dðqÚnCÃ%Î4ÃXDmeß:#ƒU¹Ø •l1~à 4±GL§%ÕëEЈ®ìÒ\;ãÛ8Å+§êJZdº×d¡K©¡ZÅIŽf3zV#W•c[Û¡*_-߈¯Þ—¶5k
ª€º—,ìd¿»Ìë÷S/úò¢×Ž Nâ)uóÒY~ ]ßjÑ×Ù˜fšuž²K,tÊ÷“\'gy¿÷5<T Ï4CUMà£Æg ÿ3Q£8Nð²Ã‰ËzN5\/MØr® ]SÝé}pæ §VD@™:]¬ÔË7>1ÌÈéC•'ÛEÆŒ!…Ù7aVì:ASQ×µ{|ãÇj9YÈ4Ö|m η*_íw4ø!D1 ñX¿Ù¤X•³ç +t‡Í=žÝbóÆÃwî6ß"£“˵?”JËOP2RÐ oQo+†â1) ©w†¦ÜèådîI½È Z¿VÍ(e÷åû È"[vQÔü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³êÙ} +endobj +1181 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 67 +/LastChar 85 +/Widths 1337 0 R +/BaseFont /SPHEIW+URWPalladioL-Bold-Slant_167 +/FontDescriptor 1179 0 R +>> endobj +1179 0 obj << +/Ascent 708 +/CapHeight 672 +/Descent -266 +/FontName /SPHEIW+URWPalladioL-Bold-Slant_167 +/ItalicAngle -9 +/StemV 123 +/XHeight 471 +/FontBBox [-152 -301 1000 935] +/Flags 4 +/CharSet (/C/D/E/H/I/O/R/S/T/U) +/FontFile 1180 0 R +>> endobj +1337 0 obj +[722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ] +endobj +979 0 obj << +/Length1 1608 +/Length2 6751 +/Length3 532 +/Length 7596 +/Filter /FlateDecode +>> +stream +xÚítuTÔíÖ6Ò’J Cw·ô€ +3 383´t‡ ”´„ÒÝ
ÒÒ-%)!)ˆä‡>ï9ç]Ïwþzßó×·¾YkÖúí¸¯}í}íûfg1 + €RRRDì +fgp™™róòòýËó;`ãþÈÍI4Ìà¸ùp‘NŽPæâ|…0öP€- ¨è<ÖÒÓ +ö‡†3†°û> +jg‚À¡hô
Ì
öïéü«OÀëÞÚÉ îþç4òOÖ?9À0h(ÜV€(|SŒ¹©mC þ^-„- +Äé +rÊ4~Ÿå[‚lñI ]’*|vQ$P5(}Uï>±åt¹ªÍ³ÖÓJçlI€îf2x±q·eÝçø(Á»æ/h•Kš´mé¹7®³ˆk..ôhí뀡‘UÎ ãàGÁÞOn_6—,_ª'Nw¼Áo+¢©É«°(ʲ·¶9b¿ý<áììíîúÔrp»m•ž7=š]Æ—”#Â÷E:½‚¹I¡ç+› `lgI\kp› —ÈüôMõ¢À|ƒ°² +œ…›±Ø§Ï«Fc³}m½}ä®V‡6Gr\> "KªYIó½1Ÿ·²Ÿ÷9Qg††1„K<O›ÎQî,,ÿxtä’3¹ÂtÐ#¦»è+Õ8+ì ǤÈF¾‚¡Ëñê>¬”(æ33óÞ5±§Kí9uæêMæŶ¯’–÷O÷‘™÷Å㣛RðsZ1ÆŒ^&}ÐùQ íívRæXnúv†e ^êÛ¤J³T×_+'wßsšßÚ&ŽŸjUH§¹ÿ0Ä~QzNÂí#(êyžJéêAB¢]±\ꞚǼû¼Å‰#¢ +»øã}y{ꔣx$󙹕Ä7ì) –/ˆ„³Îé4»×c§zœïÈjYÔRy°©ûJæ—V‹V¦wß“ó
ÚÞÆdêˆô÷Ô·³0øò…i°sOí?¡Ðd˜ ¹ò@ÏéÞcxL +çÚ“9q93š¹“Ù10Îd6NÞ”QáW}Þi¢ioRŠäqY"ã¿› &Ù‹²'IU{ö+º#Phq"!Ô}q§t°<>J *KI ý s]/wûW3´¡Îú㌜LgŒq~2Ê΃U.{ òªÄþ²Ô²LPšPPn +%5èëÖ,»;e9øüNŠ Y‘
vÅ—/<<vǨqA%EªŠ ·Y +GáÊCÚÅ*¼ä7/*§Åín‹+¤½oèg¼cèÿ jÇ7^9 6Ü@xÕÙf}¡ñÂSµË¸õh‚AF—GÌ‘ÿZÙx~åÓ‹ú®2OBëðғͦ´z+! v2gÅÜ‹†‡´©h ³+®,:®1wJ:ŒéÜÊéxK‰ûžq³¾ êüX¢'ßV IUm;³ª€‡HS@ž=T_ê ÙöHWçËm_åè˜#hc WÂWF– ©R8O°rD›ö +¯Àäzú~ø£<)¸4<~v +é‘XÜ…AÉ/½3JÈ…–ÆÊ¥íÆ„›€ˆÅèažÜ ‹[òú6!C“KZvââ‰Ê¨\ïFfþÌIòÅê ”×½]’À"ÒÖ0ìª:ðžD¢Â“P•7vîÙú¶ß‘Øݬ¢š³›Å1]»õ¢[Æ0áë¥z‹Þ°3éØ)ÏuµO"n`·¥(mèž<p=i9:
sPSk_ A8ãÀ¯Ì4د¼#t H$Á›¥®k—f¿‡§7'2̃æä¢XañîÖ:ô”ä¦ò[ãDäfU½•Íß«š²íYóå/õ$´PìHK׋~(¢‹E÷I9)°I4áüÕæ=©Œã5öVQìºÒ +hY$7U3~ñ4päáÕLÔ +U¿ÍCh ùLð(+G ÞNÒ±˜¸å yB{v€SÐjñpÅʦDÀú´ÐFˆå¬ÞõËþÝýKxŠ|¢[ô‘tU¯™ÞUgkÿ*C‰wt{® Áå;»ïöøͪÍ%ç‚Ý'× k®DzÓ ±ri;Ìi/[ˆ?–¡zí¾ï‡÷$ƵèÜi“¤Ï+õÎqMÆJ:¯V£#NWßÕ}èõ˜ { ¤lŽ.NPGIÀ}5Ù éŸ8rè“2–î±"`ÅîpMûspÏ~ÉŸr Õ[âÜ+\øv»•èkIʦEæÑØ./îœN3ÅEÒlÜ9‡f²AÊ“!ü¢µö<qÕ §>›¹Jjÿ˜¸{…öÚ1U÷¼05 §lî¸:—ŠÕ¸”ä&öƒÝ]Ôßû%gÀŠ%ÉëO¶LK¹]ŠT”I¹eÓõ–FAh]A·Ã/@Ú>Pw"d:¹.ë”19M¦àÑ£ðs?Ù¢––~§wøÆÌ°£_ÙV ŽÏ^¯ÓåÝ_ì#ê97¸›6!”UñuŠÞE(ÚÃkj't…×É¿è9ÑSLy¥Ïyîqk·s»ùµ¾Á’yˆFQù¤ [Üëĉåûæ‘>s \N«:òܵ„Ø™³=7ZQØ··B¿gð*ù&¯½Œ}^&¾óDžgçµ|ÿODKoââÕ¯Oþƒ¤£j¤óÅʬ~Ö³Œ_ñådNT_/üd¥×’ÙH *$hç¤2/û-0Òó)Ëÿ ¸’(4æd‰nÿœLõIÊ =·ŠQª¢|kA89Ç»=¯°ãá>kŠv3ROn&Àñ‰ô9DÖ <}£º‚P³Õœ2~„û¸¶wÑ·Q±@HfÝÑ=RUˆ`¹”~k+³x˜’x·Š}Ì;a—r‘2`å-Å0{ªÎ817™†Ý€)2hô»}hïë õÔÚ+W/5¼zæÖm(³ìxÿ›tŽú9B*«tË[p{•¾ò3\>ŽJï,ä6>à•ð좒 +É7)¬G»ýØѱ†ùÛ#3/éµåhÈM +Z²Û¢:
äL²%T1ãͨ—¥^‹?BAI_ì¹øŠ\3& …§Í- 0ÙySŠ¨W³4¬«·;çæ±û«ˆk U,~уûáNp¾÷Uê¶]RÏìŒ{g|õóÒî8,-’-ë÷síKiØíÒ_zQP¢Y§Ï>3Y«ËÍgAg(æ)„ºkß-µE¤çÂuŠ¨émº.?}&í;!æ&B)ž(;H…uz\J.‡”é²ìQ ·óˬŸÑËM:Û{gjÜt|ï¦Öz½ ÚŒyfE.:ð “+ÿŠ~z=ŽóJñ¼Á@ÔHÈ:Âû¬º,À:¶ìâ5ôê ¾]؇ðI[í2ñêá×nÞ/5mêÉ«¸¿-Êä’8\ëã“ãÌÈ º)ÓIsN ~{ØE§Ÿ)n[,÷Úix„Ci?éÍÿ)ãTâëu|SÃ5^¦V²…÷èû ü¨HÖ°GîxWÖ"/‹Uí ®lF³“ƒ™¨Îý@ÝZ{¤ë;!‘› ±À]¾dOÉ›ñ«²àýa0ØÇ««â}£@Ýä§oºtÍJF:ܺ²8Ê^œ1‘û l§ªæEéRûošD?÷®=¼»=ÓX#ô +]‹g<V³-£¦ŒrœBBÅ–ù°\DÍ`>kh ¢.@3‰\§NýV ró²C#Ô?Ö¿`죋žÚªJò‘ +꧛qÚüw…£·ñb +Ðj¥×‰"̨"Œ 'ËÑ7úׯ‡Ø:W¼¤Fü¤H®b¹j†CV¿UÜLzßìÕ‡OSS\W$?KÍX uçP(îVš#ÒîøÇ Ìv¶×{ª'Z‰=ìx©oïUë*^„Í›Ú\^OiJdXÜÛÖoQy>lÞ)ˆöó(ÏXäãè÷[nÔGÑ‹®ÝWèq±ÎÿÍ‹³n/²1EÅlæqéF0Ÿ‚õ—¦ìk#BÕibÅÓ‰h>ª +ʃsdLðén4r¼™¼
Á=äÖ< º<@Úúšg×ʶÉÆ‘*<ã#
bowP›$ÖÌç»ÂËlöh¼ŸrevVMRMÐ8t=j Àhqí»±¼bG P¹Cú•32°AöÍf»ïQ)‰•5W¤¹¶ÙŽà×¾€ ½>î‚ÒäÔC.ýR÷f‰9sï,çë„
: ~±+2ö$5è)ª8vM_wç¾Äè>ÉJˆûNn‚”ëäkƒãÀb6²F=kJÿÃÉ%1%c”oYfðkxÒ¶ZzhÛ~ ¡bÈÚô‘’ó͈7VÒ®Óìç¢j0·Š«qW;éKsF‡·ÚZ;25߆o›2ÜKÉMšyh|µµÞ ˜{JæÀT\]·B/âfÇ@xP™‡ò|d1£z†Žî›Seå]MtÞSø:WRÊ*ÊŽØ[cñŽð"àPE?îk'ÚÓÆê ù²ŒHûÀ#²²£×G®–® /5¿âiËÑÓP [ñ¹Û?1ðßÁm“·»×@ks)j[Q¡1bD"¯‹[ kbî%Ö”àbéÞ¾ÄLwðžî –“écʽ¾ÍÝÉÈQî"å$×3Ѓuq²wžõ$GM³þßviJ¾ÔË×d=5g»S–¦þÃsÒ;êiYŽÃý…Rnä®&nÇô;\·ªLÙqÄü˜²Ir™˜íµ½5e¶f""Áµj£èÓÒãdÂFÆט)ûó§¸ïôeQ™²ÏºùH{u׎ÈzÝsš…0æ=q<¨œ\¤Z©ÇûR‡\¾óc;™)‚ƒpt`õV«c‚pãøf“€60±‚]%]çtv…~ýͨ‚¢$ÙÔpœS õÃÐÍéóÂ7mgíq‚2ì¹yßÚ±œL“ªr ªÁ~y³Û
†o¼ú
îå ~ácìðdùÊöæÕ«“B¨U/‡¬S¬è
=g× +v +Åõn`ÑSd)-Š…ÕY¤Ch§ÕÍt%-‡ÃÊ +ãFaàÁ Hœ1a™ŒƒÍ°.Ç®üØí*¹Ô0y‰FÝ +Ï6Ý _Uô]#ó±ä +ŠŽt39‡nß h˜ã ÀÑ0½1¢| =FL§d’æsÙ_Ù£“-"¦‹Ï*³8/©h…—¨ÃçäLrÏ¢·rb¥{›±\&®¼ jÌ I_¾l‰Ï¯ÔB² 2Ýݪ'Þô\E–j“Ðò͈?Kåd—¡·–Î#·È÷!t%)G¬”–Ò¼çF–ß?Ï ¸ˆ¼' ùY3{Ä&v(£ÑÅòÌïPA¨¦,‹vä@)!~®RìõôÉ7ЙF®è”{¸ûäº2™ vF éä9" ¹nqx§Ä
4þ5;G\tHê!2ìM)Ä‚E,vµæ-ô¿üý€ÿ' +ƒt´F='ú?ö-žKendstream +endobj +980 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 36 +/LastChar 121 +/Widths 1338 0 R +/BaseFont /GEALIJ+NimbusSanL-Bold +/FontDescriptor 978 0 R +>> endobj +978 0 obj << +/Ascent 722 +/CapHeight 722 +/Descent -217 +/FontName /GEALIJ+NimbusSanL-Bold +/ItalicAngle 0 +/StemV 141 +/XHeight 532 +/FontBBox [-173 -307 1003 949] +/Flags 4 +/CharSet (/dollar/hyphen/C/D/E/G/I/L/N/O/R/U/a/c/d/e/f/g/i/l/n/o/p/q/r/s/t/u/y) +/FontFile 979 0 R +>> endobj +1338 0 obj +[556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 722 722 667 0 778 0 278 0 0 611 0 722 778 0 0 722 0 0 722 0 0 0 0 0 0 0 0 0 0 0 556 0 556 611 556 333 611 0 278 0 0 278 0 611 611 611 611 389 556 333 611 0 0 0 556 ] +endobj +847 0 obj << +/Length1 1166 +/Length2 7568 +/Length3 544 +/Length 8381 +/Filter /FlateDecode +>> +stream +xÚízU\›Ûömq§Å ‚+(îZ(Å Š $8Å -îÖâîRÜÝŠ(ZŠC ”â.åÒ½ÿûì{ö9÷é¾ÝßM ¾µæ˜ß˜sŽ5ÖÛÇʨ©Ã- v´„<s„»póñ + —{\×Ö B +¿‡ \ p W''Ö† ]V¤Àú¾³ÿ¬ +wtòD@ml] +$Ôx|¿pƒÀ ~Wº§P‚À!ˆû¦Á¿s5AŠ`¨Ëïqì¶..Nb¼¼NÖ È}Œi͇¸ðrÜ7ªË;:ü&@âþÖLŠ€XÝåÉûOÝìáŽîpïÿ[Cáà?F»:ñêÁ¡Î®ç +ÿ“| Âý;fqù¢@~ +ññþßßáòñÀP+€%Äæþþf¿C¬ÿÜ«\PÀK È +ï]sÿàû¯–ú7ü¿ëŸ5ž¹Â`¨Âþ§ €{= +w~ÆÑJüµÝ‡×U²4îÜ›cO{„ôÎî\p#a(ë<¨Ýê”öÅ4Ù§"‰é +šÃ¶R/ÑÔÐPBbh#…ÝíEåÚx°ˆI‚‰Q•C©wyj$ÔÅð°ÙÇ=Ô±”É™ÛòžýÊûŒ¥gF¬Rò£Ä:!Žd~tÆß·œ50ièKsËq4¶f8Dɯ÷4”a¾Zb˜SCí +@»À7Éx* õ—l*Æxõ»ç$åmÄÓ3½r‚~S!J¸. ,iŒŠ…ÅÚG;ø¯lKZ¬¯ª†œrUžš:-<éË„×ÏÚ~¯‹˜oå²÷%ÂŒï+Š´ÅCÄ,S%7 VH0“"ü/:æúñdõ´ l¨2ÔÚ”OOkžÑ÷¨¸‘>_©QÓë ×F™3LÀÉ›l´¨WuÎõÚŽ dc×{¾j‡Cëš}Ú$<<® åß5‰r:x
°¶ ø' Ç|î†Ô0ˆ “jj?sSª\
Ow“®ØhF §‰èÙî½ì0Ôíö8\ Q2±Ø’úüTñqø&/_]4ç –@”·¯ÎÔ[Þúxù¶’-_å³- +Ÿw?P®œÓ3ñbO©µtª•‰•R"½
…zK¶Mç”|²²z”®¢æbÓÀ^:*ÌÑ)ª!v×¥^x4ÆðÔ\ý¯ ³[¹i½ZJ¬ïÐÄð
©žñVóà ãœëÇ =£›çf¶=Vtg@ù4I,Ô¬}®.ôéEkÚBÎ> ¨<>§I®8Ô ›jßhC&˜¶)#tðÍåm†ßÛSõ—]sÔæNÐ@ M?Û¬ëK*¼ò@Ö‚ã•ü—J{¢ÖþôOæéá+k›¿|Yß^JJ©ó§}cšP«xµ¦_dâåËÅ~{sR˜ƒýÑ| ?S<QN‰ç‹„·äèí°þÝŠ¸Ð‚nº Z¿O‘;'/’“lÉÆ”Ÿ¸;r@o}œÌÎÝû””ˆ³eC˜s8y6H™d5øaÌئ|mçûÕma¹”Æ#87½“Ff»Sφäö +P‰®|Z‰ÆBÒõ:ð}ûK\|?T<©án ÒÅ_[ Œå:ÓM[Hn¹<ø"—V<hUÏ!‹ ¬KPÐû®dØ£5?¬ë=j VþŠÓáw4Q]ºËY±I@ÉÙVó·Ÿms0hë„;f&u5R–Y‰—‘6ºÅEÍW²ÿñO´9- èjÙ¤ýÆ…t 1SB€P I”†j)y +%;³}«Õ!ù˜R"ÑãMä“´Þ¥O,7-32ŠGbG#á–ôüΖX‚C]´ŒÖ#iý?uŒ£ž +Ìxª1”)‘>Æc¢ˆ2¤ ¯ Qž¸õ ©4mO¸6u˜¸9[ØŸTq®@۪РMMØi# r™±§žÉ!ÐrtèõGÓŧvsíõ>8¡ gGÅP0Ynˆb쟣z]¢xÍ"ÍH´äX<öLfòú"Uγ",,Dø¶ÊúUåÉδæÎt
š˜¼:Þuß½‘°¸[®]汎 çÒ0@ˆFÚ<‹ëŒœ^PéxѼ¹²±k° 0íî|È–&,
&£$ô'ÙfÒ§m2WHéfÜßùVGº H8Ci¦cZW‹/)R#ĵ¤1ôíA›ì:žþ\4wmIεGcØh‚çôÖ8(ôòã|¿DÍp)B:[™LjÔ¡pkTÀFÕUNšÍéü†Î –kP‘U
'#Ëz9b„œ/E7[èÛ‹(VÚÅ%ÑH‘R'Gj½ÞXsÇ=io"I&ñ£”8` ÅFјúÏ‹Ö±(Aé3úè:È‚ýÖä†9kévˆØ8Í+{U˜NEsS9¬) ÓUâ•/´›vU`c¦jVb¬+64¡…#ò†å®m§gôXj0F§ÎNÑvÚï«Jí8?|ü Ñl[]טf~@ÍRÐdíyS²øÂç€ê +•0ž²Ü™÷.U:„{&û¤?xJ›ZTHHô\¼2Q¼y¹E ÆPÔ‰ãÓþʘ¥éµX²›æ(m +7sïTîT Ò_2æ%~Ä©kÖÜ3Œ: ZGíÞ•–sœ ±óéš(cœe¬2X.3¹qo"â}-ÂßȃϬò…¸`%v—ºþB’´ªL0Õ†çöõ7¼ /Áó²ª0–ÜçŸiq.ítð Å…º1w¢s:Ü ÍLË »D\h1qYÇ Ñ‹ ÚÞ4€k¾—!7_S ϘV?“¼#p}í>ãß)BO&´ƒrƒË7Ÿ)¡&Ô&²Ëõåuv/ÑÅÅké WŒeoG2¤(RôºlÛ¿²Ø2Kn¥* ƒ9Õ
Bžõ¼×¶©x¤ŸßUû=œ•p#úŸN&“p÷Iƒ;ï»Dk Cá!aºÝÍ$ŠÞó5Í(BIÉñÏ8¾·ä¨¶Ëy}'œúÊi"º¬Z>‡+Øv®Ç¯‚ÊEMѱ¹EEª¬%ÅŠ†Q¢ U ÊÒÒ‹èÓ…^%T‹ç¾Ð¨fýf¨³Œ1ùVGA«@`ÇJ–‹ßÓE T²‡ä zR…¨ro-nùŸwódËÍ æ“•¼“Õ-ˆ–÷Œ¼F“TåŒ{*éöFA×r GœWçÐÛ2 ¹xiaq
:Oê.«<U6i9#ñæS‹»
"W»ú€FŸ¡’:fZän†äŸ®cŒk˜údªl†;¡†Ñµ{xµ 8XWuMÚÔ$Ï™œ´ã¸âoMN®2ž3MS”:]}:¨Ê~ב—L|årýJrtp¢1½ð« O/¾4HÝÝ_ñ—Õj<ª]h£¬µëHø£˜¨ŠE~u‹ZEýÓtÀ +ʉŸ¸Ã¾ÌÜ ³BÑ'ŒVÞ¥‚½ þ¾øECÉunŠ”|Q!RsÍÅ~bP˜œ ¢ÊÁ]UQÿî Ãý^-“@ E ÐÉËwÆ%R£1ù³*õͨ”²u)ˉ}šˆÐ"îž²u0”iJ%J Óqc^GÝrTâÅ£YTìoN½æBµ'¦ Àүʶ®4ïü˜ÔД’Ÿ¡_(ó¥ ƒIòœÖüŸú¾[
‹O³(Áûc3‚á(&™a—`.qÓm·]ðS\ÞÁãlòX'Æ0eSË« ¿µ +'ÞÁÝ%·TœnKMõòw-Vקª¯ß‰”s[¶Û½åÕµý9ÜŠÆ2v‡z¸ +ØF”oýBtM®',ql|J +S&WÑ-‹Qc”É°¯ˆ"㱨¬:¹ïÁ2ØV·l°!r!¼Ô™ÖG§¡d7çâ"Ù1$–õDÇ\[ÓjøQxg]õ^áˆZ=fÑJ¹£
Qð${÷û"Ýз+ü„VpHÒ‚ ûìb äÿÊCÔVpÒz~)oôã\<£vö¥›Œ Kw B;€æôöF]®×mHVíà7H°?–ŠÒÿU–ãk¨ +ü•èÚz0B_,èPÏ?þL@Ê +шèA* aÑaö蹋¢£”<±àOUv;Œxé9¯Ûû¬EïÑè%¢®h”ƒgÞ|‡aV 28„Za”äJœŸÞÜ-bëÝÝžA vþ”|#ï³eVCØŒƒ´:dâŸÊZ Ö@©WvŸVnS›ègÍlÙÐ0p»¦^iÍ^¦¢ •]äœïC@¶/œýiì•zZ§>¦8ÑxÔåb*“³íh-ö0Bcåipù¸Nœæ¾ tLç&D•¿iÀ¿‘ª‡[øBttj°t’>®µJy7$áò\+KÒÕn0úƒ$E˜ÏEÿ)V!€¿,¬íÔž?Œ]×_ëÔ£2Ôëúp—±‰<M0–XÎ
‹ ‘ÿFƒ3®Y“t#%e(Î~¹Ùÿ%xÈ^/^2ª|ŽjƒåZiA¸ªðLÍÝf®”è5Å Áïj“ö—daEx¦Ò8è5˜ñ^aà÷5DÁ¯TK—EÓ†˜3ö +kEtº›‹b +r“ƒá?ÄwÍ ÏŠo>ò¯”)<jìò˜¸ )÷‹pÑG¹ØŒ‹Nœ3»n·îkÌ¡°øDu¦…¡ÎºT¤ ˆ|d›LN}45A[“bœFŒ^&±ñ,äQ~«Æ‰L2rrdw="á!·‹ÃšK}|‘·puù5aƃ‰ý 5Á2:–5êÆqÕ{ 2wˆ²#}@‰— ±Âøö@‡OüŒå ¸
ô-){’TòkàbTŠx^ÖRØJ%~tÒ^©¡ýå¦ s›ç0?&%Ÿð—ÔœžFSõÑDóh d±.wvV€Ç›ËMl=įRÂÙçûõ—§4”\q¡É Ë”Éˈ| iöò9øÖÝ+׺ doç3îùµà·æÆ›T< Î
*‘žåÏFÊ™ÇUvÈÄJ3y’?È(6è?ñ3ÛdÊO³+—Csuî“æ>pxÏfã0ÔX®fÚ Sm± ú$²î‰5·¬¼ë_µÓ¡|ª?WÃKå‡Z+5@Ê"Ùèð_¼û²¼*j_´: ¯y¹Ø-÷†Œêk-[)SüŽmЮØÞEÄê¬rê[S`–)¾™Ð‹ñ§WÏuò‘9 °w"3àŽÇFGôÞßgFÚÀBîÇ&×"CkjÃ?½®Èk@™¹É&ŒÇä[ûcI2™§ +]ª>úÀ”¤þÛE1Ûyô½Iå jë$aÐDx!}2ŠÍrÇ`úZL’F—àí¯–0±—t?{ G
ˆ¦õ^ðª¢Þ¡ P| 1; p]cÔ£_¼þ~ÌKÞ~å¹’%^ §Èüq„ñ3¸Ä´³Æ…ÏV Åo£õ‰Áƒ—8H˜-ߥ5ZÛ‘ÎÙš#žü]“n4˜t=‹
“ôÁ[Jï((ñ˜|Õî~úÔ&¶µ=Oèå wx°üOßTû>z ÚƘÆñTņÊí‡Ç Ï +2U*¢ +endobj +848 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 2 +/LastChar 148 +/Widths 1339 0 R +/BaseFont /VLBJNQ+NimbusSanL-Regu +/FontDescriptor 846 0 R +>> endobj +846 0 obj << +/Ascent 712 +/CapHeight 712 +/Descent -213 +/FontName /VLBJNQ+NimbusSanL-Regu +/ItalicAngle 0 +/StemV 85 +/XHeight 523 +/FontBBox [-174 -285 1001 953] +/Flags 4 +/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/three/five/nine/semicolon/B/C/D/F/I/N/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright) +/FontFile 847 0 R +>> endobj +1339 0 obj +[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 0 556 0 556 0 0 0 556 0 278 0 0 0 0 0 0 667 722 722 0 611 0 0 278 0 0 0 0 722 0 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 0 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 ] +endobj +784 0 obj << +/Length1 771 +/Length2 1151 +/Length3 532 +/Length 1712 +/Filter /FlateDecode +>> +stream +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ºÒ¿) ¬8qB\¬Ìû÷¯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Ãc 5œ-± ÷ùѸλ÷s‹VS©Ÿ¡Æ¥õcºýõáeÖþ£;/eGXh¾ëã^&.}m S?Ôa[žt˜+tiR45÷\¬*qü8F Œ—E(Úo§lY=,o<±Ûaç*§¤{naˬ…;7ÿìöxY–¬òë„€óü‚¬˜s¡¼þÀ9ß{..VPJîÉ¡bqÍÁ´{âÞðœç?| +endobj +785 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1340 0 R +/FirstChar 60 +/LastChar 62 +/Widths 1341 0 R +/BaseFont /XEZXWS+CMMI10 +/FontDescriptor 783 0 R +>> endobj +783 0 obj << +/Ascent 694 +/CapHeight 683 +/Descent -194 +/FontName /XEZXWS+CMMI10 +/ItalicAngle -14.04 +/StemV 72 +/XHeight 431 +/FontBBox [-32 -250 1048 750] +/Flags 4 +/CharSet (/less/greater) +/FontFile 784 0 R +>> endobj +1341 0 obj +[778 0 778 ] +endobj +1340 0 obj << +/Type /Encoding +/Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef] +>> endobj +710 0 obj << +/Length1 1624 +/Length2 5655 +/Length3 532 +/Length 6501 +/Filter /FlateDecode +>> +stream +xÚíWgP“붦ˆH•Þ…€é½ÒA¤W„$$¡ƒô^¤)*½Ez¯ +"]št¥H“"Üè¾ûì3ûž_÷œ_wnf’ùÞ÷YëYåYßš »¾‘€aQGÀ1"‚² +Ä@df0@ˆŠDdddˆ¹ +êàˆÜ114ãåç¿û×Í/€×ŸÖ
u€¸±îéc°ÿkG#€q„ + +µpÁbX2}ƒ¡ H +…U÷÷›-úÏóï‡@<! âéO\ˆSzf¦Š>§÷ªeg»~o(²°Öøe~@¢Í?=bQ¦Ôö¢2T°nXöò×Äòç—|«ýít0ž¶TÈN ‹ßmÞŽ|Êyî&)þÕ !ëB²Œm³ŸÝ®YH +›®.½30´.¸¸~k¸I uc÷„7à¶{~ +ä÷wvÇ«éRèJV¡e’ìr¼9ùâ‚œô0˜"Än%Ÿ•MsÒºYìÎUBu¨9‡çͪ¸qæ Íì}ÍlÓ} |e±ŸrºE©?G‚ü¯’ÍóEK0&•’O®&œ¾TÒ3©¢—]™7F=«Æo¬ÌS +8O,llH?I76µTèXD œö³Sè.NwiçD8T¥2u¼ÁÏÔ ÈCiÂUЛAJéTH®gÜöI”1Më M`*o•æ¾ÐbÔõô©¹,V -u4ý†ýCÝÑUOKz‚—âÛ ë—ëÄä5~%šct]§h ¤²ÛNå¹öÿ Ûö’ñ?‰·ÏÊ*åI“y[qo.oZqO—f4!OòìC' =[b°ëL‡ \ö ¬WK+õîI¢ +0…Ødgç•771ô|Ÿ¢‹y¾ÌõºbÓü–u0Æ_røªvùMc®ç¹ÃB Å\n}HòýÇHy ðîµ³p%Èuë@k+…–ß×ÏÔ\|©bû¬ ç´ËOª?XçsË,[Õ© EWJaoD’ןڪق(e T"Œµ6¼AhÒ7Y*¿é½|8 ÍÒäÒx5Ámê#)ѹ å€n_7¯Ë,f™·ž³ö -üæS17 É1I©wŠ—&ÍÄ°}ðnñô«ù\
t§kôaLs(‹‰Ó³ÅÇ?=1òJ8¹¬_Ãkv y˪7—‹´nK°°=içé0Â!O³v£þ@ë¬ QueniÊ<¾³ÕµÑ”ÒÂIm¶ŽìQ#wœïa8ú<z/gÈlŠår¢g4t&*ÀD‘@(-=V›HÑü"§KÀF§kìqDœ4F—î>á‹
ï¶ù´eöä—ñsç•2´9µrœ%´5“Å %:ø”rBSÛÔ†Çàš¶/BÄ)¯o½ÑäNÜèÖ|ÂvthùL—XÿUš^ðöá÷FŽy +ÀÛË Ï›ë"±¦ \E‚ñ<\þìa#®0G£Í¾ìÑž÷š¶˜œ ƧW3K2aØ•Ê/Õn$¦y½–î•Þç ùÊ1(µVÓ"bªùº©:¢OÃOò†Ÿ–Å°.(±Šb}ç”i¢Â˜¬ÿqî‡É{+_V®¸Ä´$¥¢P_[QeYjçWZo—¡ÀŠæUYþÇ»®i):q #ÏÙ@öN³…sèw^— ”ŠÖ¬®I)kæ¤Å‘s˲QMµd9^bU· ü½ çw£ +÷oŽCÒ^ï'‰¶>ù +ßX?zóä½ãÁÊñF—òû\š µæ–ÎÆ:Û}|í.Mœ “îL#Ø*ê>~CÊ<Æ“¸R芧æx ê2¾D0ùÜšãæÜh<U±n\ n:K›øš `9 X£9§K@Ø4½` ?‹x;˜" ’Lœùñb¯T íhSþºÖ©"/xý¹\ƒsûÈQÒZ#d¶(ùX@/ÍïŠ.jf#ÏÕù ÕõŒ ƒÈ¸ÑD/ù $³s_H|óÔyûæëä³ë *åµÛÞ!›…9KçdäÌó¸ñoÒ>—gIè0Û„^áÒ% ÃéRÃ~îïQñE¸È~R<™¯—ÆksRÜx¦õ4«œßg‰½V?^ `ÚÖݪ3G6PøAb+aDoU¯ ïN—íhø
h.Ó FPïÉÃàF ñä"}†ü»Š— á º 㜒žêHÿG¯2‡Ä
*e&è°Ôóå[CVÆk´ ø“ìtùÊœo$ô‡ÄÓ¯ûÐ< ¯Z ÁéEºð.œd¤˜]KȮ۰ūe«úž\¤Ã£ ó.¥õ—ïæ :@ Ú55,g|ßæö7úh;6XÄ/>¶"ynö#®¼QóÀ<³{5”–SÐ/8*У‹‹GO JøL©‚¼EzÆÄǪµR¥xÂ]åÁ½œÎ+ñ6ý§ƒ÷ÎÆ`bINÇQˆƒ›§ôý6†„øågÑåîp&Ã8”ËöaKÚdagØ[Ä~¢ÇS/e:¯|¯ñÞ昮¡»œY¶šÄÐî«ŒLnc¶{ÂÏzõ/+åæ_9@irø˜crûó—?VpK[´Áúùp÷ãÌWâi{m¶Ý šÍš^¯ƒkBlïøôô¾ ™™úN ‰¼·9˜¶Ë8ƒØdX'E?Šª!6œi<Á· +MwY}6ŽûV¶Œ—n:÷ymO}€KQNUÁÆ®2¾)õ¼‘A”ɼÆÅ…H?òês9úóØ‘)ª¦Ïý¥¼O8â‰`ù£4ýÌÍͽ"/㬂ìà ‚>ÂÇfSgL,D Ï\¤¶â2íÓ8MÇÇB3£[~„ûðü¡í)9ú{N»\˜"¯¬ê9AäÍÜBvLœ¿xa1 ýÐÙ‡?¦•J§®2ˆÄ‹"]¥ø4wLôn´¼lûÚ¡ï§.|‚ ³®2èEs^Þ=ÒNQã·;\Ð2>“»ÕWlª”› +ÉZI²L%g}W
f±½‘¸»= ñLù’óZۉ׎¬fž6‡û|vØz½¨ê¤Ù›«™œç«R};·C:)†æ½QßÈ›x» ¾ˆhQ ¤Ç¹Z&âþ±þ6(Õ†i”U·À·³•>ÖõðpÉúP9w1Oêë@Œ#Ú¢Ð\ÂH´èÅ “ˆ²]WúÔùýÁ—¨£ÐtGÓÑ{£ˆÜ +/%É =Þ0gè‚ž•/Š ³=K%äØï˜méð©_8êZr1OIE¯}}FºæÙ÷Qí0 +ÓKd÷5>£FÇíêN^)+&yä¬>Ki ?bKÃþÂ5Ih\ðpX1„¦ ;ñ OÁµýËw•¢:ÙÔãoŽgX÷‘5XË2R²‹£Ÿö Œ¼Ôö· ¾9ëȶÇ@‹këtÛ 6~lŠlÖúÊ› §29BÍÊS$ÔÑд¢Ý!œ_4ÿ’‹Ó§GÂXH×rcbé>U&tã”%…àJ6ì dÌ$V{ +ßѦ +o> ‡…~¼GYøüÈuQâ*³AÙŸK ¾ôµ‹«ñ–Åa d|KtY;…Ü©_–èe
5ÍŸˆ¾#¾ïE’Ô{Éq;_þZˆ 1ÔQ;—›ÎªD=!avhzìâ° l#<~á>Y×w<öì[oçü*Ös·ìûä(î·Æk*gÉç:]¢'‰!%y]¦Zd TŸšnS U ß\&xyu%S–9²îƒ'"šÇ†\ ááº*ùx8"Üé÷žäæG»éÊB;âÊ(â +¥~-1ßÊ·Sí·ÃÔ:Ö©—JZFß”-¦
âJ²FDDµ©›¹â1ËîÓH âÌäÅÖÓ~ì†Þr·ÂCÅS#\iŸ5뫃OË=iåw—3v0|¯†FHFú®Q…k<Œ"X1Ë”vuÔ 4–¼¶uèSŒöÀîÛ +Ú#ÎÝÅ) šjÀMs¤ârruRb&l^5!Í¢W# +¼RK ·=Ž–ùóoú©G–c£m¨fk +³Ÿ“öÐ^£²P¶yWmnÏÄÄT‹Ë^ZïÚ]:Ê>9mTl´ô£i¥OäáàÑýlú ±Ê(À•ªûjÊ,µrAAx-fLjpŒ
>¬ŽÐþÐ3ú¾3êÔ +yîoÜlŒà㹶_ µ'Õ ÍO.׸µ6}¾Â£×˜^N!Ý´’»ÒvµA±çþð
kOg +Ówí2ë ƒ'Î`p+p ¬ã™CÏ?dÃÉ!¸äëõé)§»Å8Ë÷Ó»nübçG®ú•u™€ùw¾jaŸKè\¨§*A䦢3$ÚˆåúŸ ád‡9ðÖB¶€Á 5
³m({ôTá{~·sF'[‹»zèêæ±Hží:¼“þ"2ÉaÊøàý´ƒ¸KðÒ‹,—‚aQú²¤þ+¿9PáÝÄúÈMU:‰b2Ù œÂ áÆ–€œÉ§mle,sm&,Võ£r— “Gf—nÇßí ¥ú2ÑÅu´SEÈŒÀKG9é ìT\?µì/8—ù +— +IÃ%¢§¸ÁMÏW[ö É%ä¢*¿gš]T›®æÅ ÖX=„~íuÊÌ»Ñi ©Xp
ÓYÂaE´=pÃõ{ó›óŽ¾™É"ö÷¥ F84ÒL”ÆÙžÌ[;ôé‹åŽ~ ¼ ãl¸jä!@šjUâŸs5ÌÃO ‘Å7o\)ÄÈ’±0øzi*‘ƒu[ä Ùxm3È!5œˆ £ x‚ +endobj +711 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 46 +/LastChar 122 +/Widths 1342 0 R +/BaseFont /BFFAIL+NimbusMonL-BoldObli +/FontDescriptor 709 0 R +>> endobj +709 0 obj << +/Ascent 624 +/CapHeight 552 +/Descent -126 +/FontName /BFFAIL+NimbusMonL-BoldObli +/ItalicAngle -12 +/StemV 103 +/XHeight 439 +/FontBBox [-61 -278 840 871] +/Flags 4 +/CharSet (/period/a/c/e/i/l/m/n/o/s/v/w/z) +/FontFile 710 0 R +>> endobj +1342 0 obj +[600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 0 600 0 600 0 0 0 600 0 0 600 600 600 600 0 0 0 600 0 0 600 600 0 0 600 ] +endobj +702 0 obj << +/Length1 1630 +/Length2 8144 +/Length3 532 +/Length 9011 +/Filter /FlateDecode +>> +stream +xÚíwePœí²-î®Á Npww‡à>ÀÀ +hàà +ºÃ¡¿ŽpÊ!Õ×®ðŽdÚ©Û£ˆëIÌå1ñ:–¹M !LŸ+ÏS·×Ö:çñkÏñù È [œÒ¡±Tlü+Û¿-ë•øET×—mÚ<oR[¼Óf0ïw&±½‰2eé²G$QnXß´gÕíÂ_ÙM0¿ ³ Ë]ûÛv¢^íH•%Ü’(ª»Mðîïp[¸x³ŒÎ¶imæéú‡¿ë'
Ú „ÔEÛ¬Ó]ö ~!þãømýgRj$¸¤g2¤’Ä¿ïßæBýôQ2í¡8¹ò*Ö!rEºg²Y颺.€ú ¡Yœày¢f°‚mÆ™¹@ aæt˺—X[Y¶Ë¦’åA$o,çí„Ùš”ÜÝU—w3&´|!| —
Ã8¸XÁ⨡ +µÚ4‹î§AmëÁ$‘u]žœ¢ ¤é{þé
o)¯vzÞ·þ° ŠÇ~”0†S¶_EÑä¿XA^Àe#Ì”ŒCš¹þvৠ+ýƒ¹`Z¤†.,¡®Çsõ *haç"¿ñíéâ 2üE 2î$ÏOt:Š«
ŸÛ¨C™`öQÄ–ìëñçO¤¶"æ$:lþa8§}îsž©j“vå°yD±^¦ã z—FŽÝ†ˆ© DÏ®BcvgÖ5XØw χ,Ðiu–ŸòD~i|Ó²DR8T‘ð³ý@(åÚþ{7ŽvŽa±Ñz]|vJUånÖ7ý°z -’„Q¡¨o3mïønò¶ÿõò"±ë«Ä(,XFµÞ.¸qK0I4îÇîÄ{¾4{_(ÓLéfÉIˆ*aGÏ]¬]¬jaáv… õªø²!]J +jEÅÖ* +Ý–”èíC›ÇO/äÊBEQwÚüEšm˜§/Þ ôRų#m ¨Šç öØ +o<sW,³âVݘ”43>Jªb¯-ûÏ¥š¯ :ÜÒmSÂcòªÄòGµ›½d–ÝÒ±çfÐ
‡ï*7? Œø¹éݦÕáˆú»2Âœ; ä!X25#ÐjÓ¯*™Zðg‰ æ²M¦Û&=N„¡#‰ñô¤—l.gýiŽõŒ'S"œ+€êæíFý=õ1¸nWQ5’F”ÕØ#Äù4]P³sÀ‚Y~ך4Á†Ç®~„ír ݯ¨¨è& K‹F¶òmis–rùÐe'¶“ná}%’,Rñ|ë,ã>aL¦CÁ!0Y1'Ü¥çýüªP XXÊH<–êĨŸer¥¹ãyPå`C—@Gr›Ô!à–Áa•NºÎÄ{eBÀ… P}jlî'qþ z#„y ڬȧ¯úc
ArÅþÃqf§7ÅFù{ ÂÎ;x’›¨ÇOÇ™œØνC;óA%‰|ó;ÚŒHö“IÁi²Š1€À+,lÙ Fl¥ÁxI¢ŠØcØ,ûœÐ×o±©yÞ<œ_4Žø &Ñ337c†u¯ëКuÞp¥Ò+¥ÖU´vûŒ±³Æ¡ŠyT$Aø<)^Ô1&‘»¿¶Ã †ídD™.w2ž¯œ$à°î„ !ðØÌÎfíàUœÚ¾QbÓ“›Û™¾ù*¹»$‚ññ8Ÿ°íBŒaº¹?'‡emj#§„böm«]²x.+„ä¨ð.]Ã8$Goÿ“1ŸjÏ‘¯G…%Z%½3WÈs&¾CÏñ= é>4Méݲk×]G ÕªßMÓN~|ð‰,ï0Jž±öfË”Äzž² "Ö,¨Àå¼A +/–Tª1KÄ"} žŒ"Ô,®ÿØm<n^Ú¯™»F¾*õ’ÝB>o¸Ny\é m< +~Ç€ŸFš[pcù¢3yŠ˜…Š\ØrJn‚Kµ ú‹ÙváçÔN_1oÞAM¤œ“*‘~à0sæQ@ÚtíÁ~Ȧ.ìó?–µçã’»ÿ˜ûnW¿ mCåÚÅ‚¯•Rî“CùW&Þ„Ù-’ˆ»[—CxþѧgT`&1|ÑJã—1 `~ PVƒs
ÙÇ„ Ú)a4»ZÇ[X€ÆF¹”2‡;mS¢ª&ä GÅ*‚b˜Xõê¬ÌyÏë:°íMhÛÔÑÜ-¨‚Þ¦!anPÏÇ”díFÚüÚI·«³J 95ò«‹iYïIôÉúqËñú“=ŸÑÒ~±úMuk°¿„‡dbMTß\4 6ê:Úq-u.Á +fežÜrßCï£Üvµ~~1«e¥#Zç»×ÍÀ n®hÆÎJ/_Rîd{!ÏԺǤò3ìóðæ÷`¹’„¾%1íc-qlÇÙ‚iW¶tc L{ þÂÄkIcl1‡E5Ã6Ѭ 3€wXGZ´/dÖýÞ=“?Â5¨r!>Æh~X ¾2 +×IÙ.C h’Ŭø^AQ¾f!2¥ý+RS¢°k¾R•]ÍmËç ëDuÙ˸‡è™¨tÓv-º'÷W¿6ÐØW #ŽÛBÐô6 Qº9É&˜7`~b8Ìê a²Èé’gΧñu NvA —’ÕW”Ÿm´ifø!:ú4$¹ ÷p_£¬eæš÷ײ‚®LO„yÆ0Ž6O Û—‡œjæýgWp„å^eÖTiDÞ6}Óû —FrV=+ì s¶ÔÈ·Þ:Û;§)^O¯©ótoibçWÒóÑ©„ #þ²])Š2ã°À7
-ZC¨JBöjü +|Ò‡ b9¢Ý—B”Óeß¡#Ï^+X¤½š^Ô€ã„R|ÿVöàÕâÞ¼ÒDNètúÁQµd¢L¤–²ž3TKâ³°Ñ.ëÚÑÕSÜO3†<—7?¿t—Æ<ôÆè¶?„^K” ½û‰ßè€wºÌyÕ…O=ÑaÔ]:»4aNÚYW¦$ñX“S +sÆ@es‘Xü> ¹eéN!I±rÝ<¥ImÓávL^ Vc°èé4%ÐvcŒ~ŽuŸÚ:æšÐ(^V©FšÉFÊ„5¦@w:¤ªO!¸Ò:¨M„Páüòo nñ=¹/ )‰=D¬™‘x™( ;o•94‡Í‚¹m.Ïÿ&yj:f•… +ã¯ç´½y5âC̆7 ’gj óÄâ|ÈÂÚÔ¤à¤ò„[ZÓôÁûòúêFù³‚V"vÏ[´¯'›0¡'Øüˆu‡Haq>æ–‡›äã#‚ +[ê©úɱշÆ#]ðN«³¼6m¥‰8\mm×–æO*Ídœà?Ôd&ùãͼbÀ`›ÂQ EÑöý¸R>™üý‡Âk<7½¢ŸhTª*ñ!þ™ï¹ûXâ%|‰ddu:Ò_'r䕯w–Möaª 4¸Í(#在žÜköÓ?%
sö)Y~;=N³2€†»F +Ø Ÿ;Â[·^[VÕG
ô…›Ë5a¯Õ<M±kÕ¦1±¼âÜ0°«Áé&%=ösݨÃ8àŽd*vHᓯÜh¦îÇm0²‘¹Ñ5ŸkÞ²±ê"Ÿ¤Çµ©éì¹Ö-w^þbYm(<rq=ÍÆ$fò»Qf?1áù šÖ—æ“|!Ž(]U˜Z²*¹¯êë ýe<®mÒ…œ¡—7Å~·À2ÂC®,0¸úG”ý
) ÛùáHÁšCEÅC2ÁL>þ·«Ê/qhÃP៻ AxàIèŽòÔ*a‰íŸñýi "ñ”Îèa¦J‚ãU«¿hè6[é¹Î]¶ú£^þ
Wœ
„úž@Ô ú<O#&—)‰fÔ—†Ã¿7EÆ{ö `A#£(ø.‘ÄâW¨J¦½¹}+4zØ4ûuÍ”[1[Èhü] ¯VÒM¬Ãò˜ìy /*ï³›b÷ ÎÎ/ÊèÒšiçWOcFb )-}q‰Ïœ# 6ŠW*Ü¢ï|Ë>ØÁq‚'QÞG«Á.·C—‡¬ö™Õš#ñÕY”…ý !A¦S3çìºâÆe²OÙð<è4ËÕhB\ÎÛ/f–Ѿ39ó6©ÇfžÝ†ÒanÂÁÏ×áá–>Ï€V=Æ]‘ïÈ|zˆ•T°¹ÝH’“=æö+•ÜÐ~áâ>è?¥ ðRM :Öª” ¬¯¤1ÕUÓ2jmƒ<ì &oÅ•M<Ã,Aí‹K oLÇ / ÝžKÅ7™ ¡„<¾Cšì+Í5Êhk£JVY+x°À Bú€ÛH¬æó§˜W+° +Ún3!©E:qg^˜½“ çEÉHûK뵋Ùãi¬r°"×$n{G4.ö5b +C'75¾c aÁ¢ãmƒž•å ûZ *œ®ÉÙ
@œË¼,A¾‚úqhîA¨øy#³ +1j ÚlÑ&³¤= +Øcîmë5+ ¨38…y-5*6Ó¼'G†I¡s*Éžš<ªf'&Â÷ ç)7+9Si|пŠ·ÖC7¿¦´kEª3¡1/`@;ý‚·ÕØ%T¿h¿÷m UBÉg €Kj2ç3gžE>Én+p×úˆl J<2A1ƒÊÆø 4œ/¥Epz¬&ôìÜÿH\tõœÓ%±_~MgþD õ*ÖÆÇûÔ³ K½?€÷£–ò>#¹ëlY–ýaIø +•ªÿ^²~wå0§÷>¬i¡”Ðer;á2 \ŸS2ûkÿÚÙJ=ñ8ªÓ;åȲ¦ p«.©I*ΪoFãÄjèŸ*˜®$rرpVxO)ß-.LòV"ëàÁËð:¾ßOw(ʽ +X£ÏÕ½ÞÀ
¶aøz·#
OÈ +B–y´S,¯K.Œ¾ÄJ'7Z¤Ýiõ•®G@QÀn•?—‰†Í_#ppÚ“úëslg°ˆ!PB0ŽÇ0!)ô j «ïY:FŒ›|ƒY Þ +[#’¯f•YÞifýP!`9†„øQ1º*˜¹’οçÿ1›†•Ò»=Iù NeõÉ #˜' g€"C-†óçþ9#Èï³Æ<4Wkë] +bvÑCª¶<áVÅák…î 4ÛFüÀãó´[OÝÉ›þ(œ6®°Gɹ|ðzCà"å:.B*´ +ÌÇý¦”ït†ˆQF'£•W”‚Jî‹ö¨RZ»å>Õ;v×òu"Bä—,IÆ÷ +?tBVå äÓÒ·&ŸõaðÎÑ3ã?ì‰ðˆz)ýþŠË¬MÜöõÇÈR‹[uYÊ â™xŽ(ä ©rLx¹d0©Ù¹9›—€¹`eîWœŠjÍ`«
rëáeÕ0Eg—¬ÀpÛco:,Cú‰–èÓT` T콈l ×ÓkŽÊ]5É_oÖÏ +¿Ø„× óF¶?0PA–ßâeP¼šxoyT×]ƒ ߯ q‚ éWëÆóªVüš'ƒ³DŠgªšµ©’((_«¿ª²*ÉêjÂÉÀhýìÀß,[Rz<™ð<ËXs×;åäÚg&Ú +¢…~/Œ%뺋
Í_g>êµÓ~ãYbŠ5| +ËÐÿÁÓ6æ›.æÏcÖ(‰…4Sü4ºÖ. ³îñ à“ò<¯¬ˆ.76Ÿ?õ#»Â oyù£ðc
™2 ô2Íû>Úé \‘ðc"l誤çoIk§†²ÇÝ‘Ïs§§+Û¤ßÈ„ÊMðʪìW¯> Õ ÅŠJ~à‹“ç—=6óÎ/QP<Ž}%´5*¦²ÍÌà‹r][¸„ìWMfRA¾.¼Ôã· v’ówØøÍÄVn®q»7OçÙ`°W¹(ã#ðmL¢mÚ¬61$"ã”’OãÙ¿ +F
]bI“•C·v0ô]ïsŠ×V*à& Æ:-H<c°1ñõZvO(M DÁ™UnçÖÃMLw¦¼9Ìʘ'f {‚HòZÆpQ¹e熶c08*k¿^Z¨¤ü”÷« jÒ ®íVÅFDøqÍGLÎL[Þ»@7U92ÇŠ ®•pTæÁ_Š6E{E-”»ì“¡ï–á䨓Ôò‰÷Aé‘E +ö;)Ó5†90öê8’ÊøïSÏ]m/‚ƒÐ _èìûD"6ÅÐ +ó/
¤¤IÝn×ャÃH£J©´Á×í£\^"^?m¸î#ÜÓã¡]?Âǫ̀ôÍÄ ?õ}ŸÔ½ºCCv‰ ØÕÅóØôÉ‹ŽcÄq ÙÅÄ 1È‚ ÓÏAK–&ÇqJáw‡í¥óðq-²º5{Ü9cúx sœ…vtàtf>Ø.V/èàl)]ÆüjEÞ)â0 6¦±/ ˆÅˆÅðŸ—Â>¦O9L:»åcþ‘o†,
1ÜÊ È6dðdrx·±+ + þuch`’W ZÔ6¿©Rì2oŒ`¨ÍÍj“( FM›c¢JëÊ<^=¢fÎ(V«¯|^z‹DÞ»©Ú Ç«×4úóeÍQCf¼5-LØñè‹9 ¤ÓlêÏÈßiÚNŽKš.¨¿’ò+sÈî/ ÙXй'ŠÝSu÷ _g““X® d–²žÃ2ÈÄÀÅtÑ"Ý +GŽ—z¥YƹQëкtšI–X˜‡1·Ee#§r}›áŸz±g˜$>ÈÕ&)׬H1ì¶SdrvëOËx0P(îée¬-ÒM `¢!03ðÜW‰M^®#Yâ +.„²5ÚþÈÖñ^ž /|†Saï½ ô»ØIvê +Ý»ê}€‘D= Tÿéâö·½‡žëÑG ]#ÂâuöñçP2ÀÂ, +ï:/ÿ©Aàé žµ@vô®ž å—þA·žÈFàQ=á'ê²_Z»ÔÙÄη+YS1¹Êƒ”ÞTRcÖì`Qœú}V› v1g1ÒŒŠ$| OI q
@Ýsêç?ú¾óã°!¾,»Ö.qðŠ ×þeËŠ”l~a;$gõ…<¾9K„‹DüÆ ©8®À¶IÁI3ýSȱ$FïßûBßP5åqÏ' KÇ|µˆ€€‰¥ÿî`Ëf_>´« Í@MãSì7nDAðùg·u{<úzoáiC&‘RÊVçÇTA¿Wb-ΟØ]2PÉ™Ð.8ÙË ÍÙ.ò¯j|ƒz]÷ÞkZlü!½989Ÿðd ¶aw¨É¾ ŽµQ
1ŸŒ¸9ŸTv2@&* •šíùAùÿÿOX€fήŽöfÎv(ÿgbjendstream +endobj +703 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 40 +/LastChar 122 +/Widths 1343 0 R +/BaseFont /RKTXHV+NimbusMonL-ReguObli +/FontDescriptor 701 0 R +>> endobj +701 0 obj << +/Ascent 625 +/CapHeight 557 +/Descent -147 +/FontName /RKTXHV+NimbusMonL-ReguObli +/ItalicAngle -12 +/StemV 43 +/XHeight 426 +/FontBBox [-61 -237 774 811] +/Flags 4 +/CharSet (/parenleft/parenright/hyphen/a/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z) +/FontFile 702 0 R +>> endobj +1343 0 obj +[600 600 0 0 0 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ] +endobj +633 0 obj << +/Length1 1630 +/Length2 15731 +/Length3 532 +/Length 16611 +/Filter /FlateDecode +>> +stream +xÚí¹UT¤]“%Œ»kቻ;îîîNâZ¸»»;…»»»;…»Z¸ÃÔûõt÷¬ž¹šé«ýy“ω ±#Nì8çY¹’œXQ…^ÈÔÞØLÜÞÎ…ž™‰ ¦¬¡hdccd +´—¥W¶·5ü5³Ã‘“‹8™¹ +rp²ÿëaûûK¦hïìâlâtpüͪ(*þouºX¹ü“ÛøØ›ÿõ4µ7qýgKÿÂþÒüE]Œ€vÎ +±ªVõ¶ý^ Nc_ñõiܬ槕Q¿ÑŠÔ+«ñïPYŸÌôZ#Ûõ½¼6SºßS7Cç0ÂþD¶X>ªO¯Æ¶aÕl¾JüÁøÒŠu wßùöüh¨ÁŽ7n- ª}»›ËÏì¯ò[ùwµ gïèÕËä‡× †¸ºŽïÛIZR
» ˜Yâu#1¯› t,’‹¤×CMMW•M¬îÓ–$IÁ]•Ð}}™ß×(+X{—üÓHï=s]Ô½í<›Øáb57U‘Ct¸¹# ¹@
²KCúFúØì¸5Ö0ë +ƒŽÊ©ˆtÝÊNõ‹æíùu§TþÝ4F¯ä‚™ ϸý§:Ù0Ìîz2.‡8Á¤¥"ð@b¹ð:Í(o`Ô¿kM.Z’#ï£2GYŠ nplwÌÙm݆øf[8³")Ý-Ì>ØÐÀ"¤¹ú,ï6çš#±VEÿú4Í ÙTÙ ƒ˜êççX}×¹F; yh ȱ½ýx˜!:Á<œ?-p©yó>sd³aEG2 ‰iħØä¢_,Ì:ý¡ÒI“ +È ú€èç“.ª¡Ü^ó!Ozü(~”@½ð¤Ê¨JïŽ ÷(ù)I¡É’!Ë[í¿7O’0 ™(Öê/Êó#?ŸòtssÕï“wÏgWWÂù;í +ivPS“
ÙL+ ¥6º:]ø¹à s¡†U²;nü[Þþ¥ºÈ…\F˜+6ØU«Iæ´ÿµ´*mg_^ú3Q;.~ÄHB/׌0w=>>b¦u¨„Ê>D_×$,?z^ŽÄ'dð1QèQïþ®Ä‡:RdDc]ØS +y)øM˯ìý>z¦ÓÁ‘,£¸º!6ãã +d-ãµ!2AnXî}uM#Ek}ÚÛÀ£>ñ´0¥š¥b˜)£9Ëà_dö%ÐþÄd'~}? +<$Œ^ƒ™yJŠ³Þ·|f¯¡_XÍé65È‹‡xȳT#¢Ê›c˜Fn²äjvb¡"£Dñuô‰ŽÔ7pô¨Þ3kµ¢ÃgnI\H ý•ŽxÅaÙvè#Ýü½ä®ªª Å9ñD“‹.š¾S2Àôõî”a½)m¾Úò~€ûó …â#_ôI\§êë•/»šžÇ¬"ñI4/á°ø¹;øë3 ËÍÄõ?X"M4Óþ0ÿÔžóë:i·áèÿ„X
µOTª—‚ w gÞZ%•ùÂkéúq¬4Ò7&Võ1 ;»:牦¯NªÞºŠÃ™5ÛUÆTŠ 1 þäX›V!ó™!*N4 3cÅß^uu”ûZ¹b«îÖÀì䱇R©ù)sÈ3:ð¸$®ÃÜ}þUœEc—Ìuø +ÌŠÚ ø,Å@Hˆ¹´z$¦“¢Rõ„¾®û£6pz ñŸZTyûÈ2(†4–²7h®GœÅ‰Ý?5ëË€ 7m›TÞQ¤‚+̇ßG.¬¿sŸ‘7¢ÉnYFV³œÜÛQ$yÄE%û ²±Q´…P”‡¹°ÝÜï…Žžb ÿ _0}}rÅZ¥¶ š¦K.…¢ÌUkÎÖ »iÖý MÒwÎûÃä˜ ‚ÊPÁ„Ð’ +ÒÀ^Ò6¾©Þ°´äÀ ÏqTÑíö® çŸ$@ÆOo‰…¿§ dêVM äáêh‘´B +ODµóš\ÕåQÝ¥Út‰f»G û*NèlÂò;Ö× y<n‘G£4°»HÆßy ᆣ§…‘ÙÊF -x/þ %³ znj·<Ÿè„÷ô
í ‰ª šR˜*¯xM®Ì6`C¨€qÑÂzýÖóçÑú;þ¨#f\ꊳpÉôâˆ9£ö…¿4ðÕ«är ã%MKÂê·³©3[¯ïm©ð–J)”úகç'ï”oéa} “S\±Š£zÿGtÀàØ +µùœw¡ƒ Ì´ç+;ž"¶ë¦Ñ? doû‘ööb"!äMeß Ù°°XƒÛ "b ±-`OX‹1Õû _µ²F„ «WaŸï£˜@p+ëakqÛ€ŸÐˆnYôbôóºL¨RÌaóå Çfh#-!”„pe·EŸ¥ìªäÂh-lS–Úq•—;`âB=)vÎ?{wÙh`U“m1Q2X—Y˜õœj‡ú[µ®æ4öZ$DT›ß°Ó5'B~´)2Ï#*pãŠCñ}t¬Akª#òô%ä`)~¨ä½{ZXܱÄÃÇ’@K'‚Ú3Œ…¯QÄüäYÁE›kÔïœÖ€w»î Tð³'aH»xÙ^ôÃÛ²ö³›úRÆŽæl帘k%Ǧ‹ÀŽ¬ßkN¶óš×„~Yy¬Öåwã;™¾ex±xª}Î fÖ†'ñg%·”Kkø“ +ü…ä”÷FT‹K¨âŸ‚øŠ RʲŽ[ Ž_n™N>ßÎ2rWìÐc”r…£ã‘ mµ%Ç}6 Z_æ6?ë¦VS¡|Y=!j¬å ÎÿùPÔ¶ÌÅì€Íˆëb޸ʮòu[É¢Ü%f)0ÅÊE6¾7 ô§N«E [.©ß< ¼ÆÓ, +ë®o|:o•ÚœÅSŠ%)Õ}ø=™)WÜÔµÑ;¦Í“Øøæ“úm±a
εVsJvö@K£áûç(BÂ^àwðg®Ð‰'cÃfBÇ…¼"(Q¦î†÷´sø¬kÿåõƒk¤3N}óx=©ZÍg´¼˜ù?¯…šÉ€—\E¢ŒíoAËLÕ‡õ©Û¹FCcËo÷³¸Ïá€Ò ‘îÚ~ÿü…On4G!>Ü-[·,3!E‚VQ¥H¤HÿÇ° ++¢±'£ë(‘gå]h’
v–i`PÚEÞ…W‰¨¹úmõ'>Më³&#kÃ^z’0†i¹"Qrå>+o
’BP,ºðü R¥ ¯0˜÷—Ü]ý°ùc‡’_´6iY"ëf¶á=µŽpe
îìI‹vfê".Ÿ£ËæDáišó„TýL-k,I•:ðkÃæ&ïJŽ áó Æfø ”fŠ×Mž-
æ,Eˆ,‹bù8#^à0T§L’‡Tvn轸ÿT,5 ÷S> +‹o7ëX¾õ±“¸K«¶CÕTå)# «: +W£Ì8DB¡ÏUÿ,”…œ'‡n#íÀ‹ªUI“ƒè®œB +ÎÓq$Mö—YêqH$Ã…ýuQóë®_¡Eë´½ó: `$ËÄÉ•!‹‰@3^[ůiF@êU›ÈxcmÄ*kâ\ yýqj_¯*]U|ë•ð;š:Ýc¬Qz +j* +Ô^Óã¦6¼ÕìÀU\{~t +¨2e¹ð={f´Wdo´@°£Hüd·J ¬‰+z$Õ²Õ(;Vœ¬~]1B\ ØLäë{u*ûä èrƒËWÆ¤Í y^ݘ˜Ó\2Æ,´Nƒ ‹ù}Ì3Ý ¿Úû|^žM‡Ó]¦ +áÙœ´7S ‡zõ¶lܵº"+7Uý dÎÞ2 jèá+ ÏÊ"eåc¯/äcà ñm¯h:ÙÙåUFñì>Ä&ûk©³=]§¬¨ßîaêÉv)£°®4Ê +pö–fÛ˦ȃâ²o•LdšŽÍV?H%ù¡¬éBi©WO.Gßæ@X¬Ù¬†ÐøÒ‹@jGxô¾±–rƒŠ%}ê0ÿB"jì
4 +cyÑ=—Ó2ÂÊnüžÚî`Ìëá(å9Úv˜t,‚v¤©©äX?r—ýØJH¸Œ›Ámò ƒ å’†ðº£Nk9'~µÕAœ Xs{cήz§O9M‡GÒ§] I-þ3‡Õ6Œ°€ã1bµ9ü» :ˆŸ¡ +ÝtÅ çÊzȆ¦ÏÇ3œ—5”Ö<ÝÊU½‰bâånm +l_:¾ +ÃY_ÂK¬ ìüvE\aÐNJðÿÞ¹nèbWo@ü7•öÙ58±£–%\É^ +òÌ%_K ì +w½Á-Bõ?ïmif‹:¯
í² ŠÔ|ÑŽé.QØ
l(è®!mW´»âŸ˜Å>2adQ”ÄpO}UŸN†}¤‹—çäsê2„|97pŸY^½VSz¯‰* ýsŠüä͸Î=¶ù
Á
;ݽZ¸k²[lC)Â0ÐÐx·8äý=ÊÕi~°‰Œ÷æ ¦j>ÝÏ cê ^´5»kú¨Û ®¢ð +Õ8§¥rצT~& ¾}÷+Z?/_Èà£w4E+^o:g’,¸ ’/f‚Ò MüFœ;xóÝ †—Åà`öÇ ‘y´ºù‡Ú÷òD€Õð•MU‰¸ÑµEh&¼¤(ÝnVŒè.lX@ÄôÑD vx™ƒïˆß†)~–E ËKNæpר0-Ô§(†3øÚ8»!¹ þ ÚY‡Lcù°ô4à 7¬wO[(V›âz'O]’ùÌ1Ô‡ãMÇ‘+¹Ù “}ï`¢7aj?ýÇËš–x¾1ß÷»0Á3ðy—œbHey‹é¶ßí“£…™âa44•bô|ëi¾«!Öø±w€fïü@åÀuƒwt—œû,a—žeú:o¤Õ”]aXS¹/Yv¶N£oúƒMUG9–П9XoìÌ‹eó š_•·pI^Ç|B/ôÏpüÊ[®ÒnvÈp×6Ó¼îZ™ ?¼ð`Í‘‹…U¾£ +SUŽDŸ˜ƒpj U=y(Ž~{×R'¶7UÔG.!ÜÃe®ÉA+ðÔ±·v0H7)m(pÍ~û%ƶ*¥â9êÊ<¢¨›]`Òël=šV¾ê5³ÝF2…2ÀG›±‘ƺ»8Öñ‡%…x‚©ÙŒx&rq],`Ïcj!¬¢L›‰‚ꌻx +—”tšJ°7ͼû ›¹yéÐjA0/Á ³ bHgn Á¯'Š€•é? d+lDVmË$;6†º—u™ 9>üAZØÁíšw`M íÙÝF:d”ç‚y³ñ\fË_3e4S +CÔ„0XWÄQ(8@XKp9ätñHkaìÙ¶[öƒ!׿oT_ N1;aµ<2WN¤øùÕBãAqÉBa@PNYocYÍ\Dç™ô’žÓ …¸ßëö ¡^uCGd¹êU¡RÌè>áëLúƒ¡¾\‹û¦_ [³$$ËÓ#¿%,8Kú—ËÀ
—ºé?ðZ;RÝèŒT@¾ïÝ;s|ûÃìÓöYÊ[(T ©ž™PLýMJÚ§âÐ×:®C:”P¥qg$)¦)šp4 kÖÀ§B´#¶á×çûsVÁ²!ÁÓ÷ú9ÅÂ|5/…}Ù¸W6:mº“Q7Œ£{PØUA%fBë*N`s´B1ÒMO‡b +„v‡‡²˜¯ñ! +^×ÞJ{u¢õˆ8Æðl™GÓÉ`S‡„d9ªsiã¼™wnÌäz3ÉÞ}ì #$ؘŸáÇ´.E‘Û<œÞ]oÀ×}¶ À åd“‰CÌ®™§jÈ{ò3¯÷bƱÒÂ$·+6ó(¸ ÍÝ%3^E‹Y\~Òˆv/;˜˜ßï–ª%—â Ž.’ +\1$x o «ñ—«zÂH•`öè€üFt©økb L"eŒ"Y ²ÚcQ½9O£Î &&¥-
É3íØ9ýz^–‘¥Áh†~‘Ó_ˆ xÃOZr@‰Uâ #1Ôq90½dò«§”-˜=H\2†PÅ^äÝ9jÿšY ŒÞȃ°Dêp4?¢ð¢F
y™;:š¿‰þÏ]Y›vÎý12ÿX߶ï Z˜F‘ê+¨Á+ª’³HÌ•éq·¥óþê— S¶^5nJ,ŸÐ=ØâÄàѯÁVdÙÑ‚ýWÁ^‡„5ÐÓJ <;POSgkÍÅ=Û‚Ç j^i +`‚Õ´¶È·ŽÈ:ã ‹
'ê#&nnv
¿qÿt”êÄæ‰ +ÝKž*gÍ)âM3íålÉ+VÂRa°xÚ·^Ôp«=„j°®¡HQÑ:8CiZ[ +J(˜LÝ +ÐýÛ¹\g|Æ\ѤÇ/1—«ÂzwîP|MF¦‘ ƒBXOèȪUŸâD b³N +ªõ'M˜CkC
Ú„àŒìŽŸÊsÚb‹ t&oYy•G %œ+šÏs/'KS8°È¿œf‰ _³(V›tŒðI'ìÚ +]RÎîà]ÄÖÔ6h Rû·@3¹9 ¦–P. áYä ’v7êÀ!çbkú26«&¶Ýs8ðd·Xå ëGⲶ Í +tþZè +, ,SÄ ³®Û·Q–Ú‡ Ý6%€¹·„SCTÛæ0nǽ]r U¸¥Îô ÿ×7u)“q›&Kñáè×D\Oì!Hç‚íÄV¼²¢8‡èä¨ÐM¿Ê- ú o<öž¿þ†îܬ²;¼½ :èå9ô“6s:Þ$ùÛ õ}ü9ß[™ÎáÕU=u[h†J ¯ã®`/Ô Å-!¼:G% …R ¾"¯Éç›Ø…¿{føšÃw²rT(Ú<e? +ÅŒ ò}¸‰2íFz¡;f$Mµ÷KvQJ~4 +ug°{ŠÌ™‘ùjǼQ>ýR Cþ 2U9BS×û¨þøDáɈ‚œmhºßa¾Eí¬ÇCøw[fÝQ¬ê_1ð¶ +㧣<¡žH4Ðé;7F9y¼Ì§@xcד;çUæõ<+sühUÌ-F$F=©Åòƒ¼»vQº%‡Óò0j1±dÉpQfVë tFçÔq!›5V(ð¹s¼Q—6 +E
WÎ^ÌË#ÅwÂWÊö‰·²mý$ïãœ9ž"ãabH¶Ë'B÷Ô"žiØ¥±AËݧå—F‡(È-'ˆÏÕ) ŸÔ38ÝH—ð¢9p
Ï«1ç•¥)³Ðûí4&P" tœ{#§ ˆ:’úa@û#¿½ßsÒ¢ñ4:‹â¾%lÊ[PLxUµY¾L‰à'v4ûd)ÿR +·ãtÛ”I67 ˆ- +ï3º¢\ïLV´m4ó +2c +·î:LH,rÍ̘}”©”ÏmôwqDUp˜¢¦`ï³KÜÂM‘C¸2Ò¨æLëQ{ÐC¬,Ë•ºõ tv@þýï$&|Gh–yšÔ=•€LÂ×þ´9QÞìž/ú¾dÊO +¥$y{o/ºÊ…-â^ ³7˜Þ Ìu7î×æÕ]ÞÕÛ 7K–ö
Llœ® èBÉ0ä]Fç Ã.Ȇ•O‘J®B$¨ QLJ ‘
IxÖ-€I¨9 +ý +î$aÉÚ ¼MÚÄ17œf +µ …¬÷TýMŒpqlî^²²jd» ¸m] +ÑL= &†ØÚ稺Y²?·SjJJ}-ôäÀNT ft Ÿ
s %–þ²8 —NŒ ÷¢—?³¼B¬ýÐã&~1$*nGTÌ1÷>¬œå4>‹šÁöm¡Jv6õg/Š0¦Î 2¤×¶j*ž™¥I ßëã¼é¤Tœ´g»ìr¦Âé‡Ô{vÆP>ý$ez.´r™Âòêc>«y.AžXn7ås"p.w¥Y¶üÁVc°rÆúÄÇ’QN¸ÿ‹)®D?â1œJŽJúwI×9õ €ž´ò3–\æsNçAS*Ö0a gîêv¦EËÕÔª +ÃÕ³5šQ^šõÙZf é©4ûå-Ie U“®é +šÉ,‹^Ì*hÞÔ@k +ÙOâî¯4*ÐHÛŠå«<Ôš>OïYò™ì˜„_ó×Kßž6ÒóÕ¹“äÁ;áfÐ ft°‰]vÁsò¾x¯»?N¶1…þªYGtìmÐp¥Ó¾ÉtZƉâ‚^¬ ·JHëƒÎE[+Í;þ ØÞ_׆ás·ÚW¾}Â]Ϫ'ÅOÍÜ“Ë£øЬããêd7
¦‰0Fªkº‘*äýêLk¬ÔE¦ÜXÚ@Ùà#Œ]ËNÆ›y³?}/Ø ÚÝö»µšqÁ§‡šMO× ÒNП +î€þ™X +â*áz ^.\¥„!Á“{d¿ÜÐ#ü +ïH +-|ò0¡÷ F¢$ßñGÊÌká{ËâÈÍL– ±¨ÀËäýŒÛª‡k[£·3žÐ îF§¦¹äð”Â-kû 4•5}Â;²©%Ÿêm&øɈ`r }‹¼
ÇZöŸNp±Q†}É |~+±Ú<¶Ð1öŸ m*ÌCÃ!̤A©„=í«(OÈnœ¥cã7äG“dÊ}O²º¼óçžê‹T&Ý&ÚpÎZæ2«æ\Y= 9xb• ž/PʹK¾âµm@0zõI:ì›`ßAhÃðæq¾g{o÷ ÖA;{Õ`ÓY£º\zÒUuxVè3óxðÛ‰¢¢3ØVb&š
m¦G3I §¶„¤Ý1Ž`°Êã > (•X‡¡=xô´¸®N×›ì€èLb” ˆC‚yÆG‡^
B[5zÜa¨(Ï:R7Ñ ÎœHüb^ÏV.»(…âKY ×÷¤M¨¬y0rôYÅOxÞœ“Ü‹Z¾ƒ4XÝáJ[K/pêٱ傥‰že Ðh˜8ÎS×R]öVa’ƃ|Q h Ú¡ÿî>†2v£O8xÍÕHØ媚:_øÓ秜ØGÞ8hùõáyQyáíšßål0ÌÃxñ¶ât× ½<•W°Fôä‰Yä)«Ë’%¦H¯ØÑä冰<–ý&Í—.!l/C2CÉ›ÿÃ’iWMvM´a¯à¢¨ ºÛåòÏ’«€G¯M+ëèr(“ +÷z¦iB‡®”wufX]¹©ô£~n¼N-ã1JtIà³7–›fãm~|GË×è§õE’N¥hÿÁ†‘ÿÜÖ1„Ö ZE”BôÎ&ÕaÁðÃ_ç€Õ¶ÇÍX¤kÅÇ Ä€%_, Å¥oCÝÃu´ +ù¹ñmá> ¬$=Þp™i—à +èÝŽòN½‡©*;€5'®¾¯lš²^~ÍPóœ1ý®Ëôƒ¹q[½ zÊhw亠êáG: É:JÌ7ƒ…?ÝÙ¢|³D2˹})ÔÍ4槄ªF?Îaâ[×’©©eÛKúyÛÜÞX]Ÿp w’“?…Z$ŠîÛÀÖ¬^ù¶ßu›¾3ˆ|
ÚãUi`TîjRÑÜšZkôúŠW4*™º´Rþ.å +HÇ’#Ñ6aGHÄÖËvx@³öÀþÑȪ /áïba·DI)Rá n®1.ŒxÏS[¾¼m(ß¹I$á(Á !Ý{æið¤ÆÙßuuòûk?–ÿ”_;Â2u9ifï› ïéÞ.WË,ß¼I•r +·Kæ1š3rÇÖC´žBhŒ/ 7¬-éËíâD™Ø¤Â½3ÇÚô89 ÝÁÁei?ääï‡à)gLÄÐ'ЗDvf¥#|8Ì{êc!¡"M?Æ"Wfßîé5D¤EÕ,˲üŠËÜzät*VõÔ„òp ¥ö7Ñý +º¶ÏŽmná›Á¹àŒ¹ŠF0„éY)Åšá«Pñ‹6œ0`z)ú…Ý«Èg\¬<ÐãFDQIòl¡_¨(¹XÀÄ.Ìšú¥ÎÛÏÕèU—æâïJ[èhÜîè{”iÐÍ î6®"#çÝcî]©%¡î!û1Bá¿^î:ê' \>•«wz¿Škb0 ç®OøñÍ!¬ªc!@¢ìp((‘åÏPCæàüùËóZü;(º›´Ÿ…pSõ‰Ô:®‚tÝîó7å²¥_!ÅZm¸Šý¶¬Î´ Eý¶5 |JZ®DÊC|63^âaµ'ÐϺ) ÞÉßB Õ]¯žZ$•OAž¥€¥·qàvlàê±xh¯ØŒ¾Æ\O@Á\àqc– $úfX›ŒMÿºÝâ Ï— _~ÿ¥Œ;Ñþ™MN¶í/–ÌlŽöŒó bDTh‰·K ,¹#To-—Ô‡ç·ÚÐÃ>¼—‡rùˆÏÐ $&ú"„Q.4éÎÿÖ¿v¡
QXʽ֟ÿžÍÆZ¦|Ï?õ•òL›ï!u¶øZ†w^ vOT˜ÿáKKîŠj *ìKía·iØÖ+TnÚ ˜.PÑoÐV-š°Ü¶æ.Uä:MP 6J·-hé |î›õJãH”jh·UÜáU4|‡†Í ÈlŠ×=F|•Ž¸RõË’ŒTL<“À>ó‡Hk;ÐØú!×½‹~%g E´·P”Úíf×$Aœ¦‘Gþ°u†Wý‡czfb
WÔÅXÚ´Ö\ü |+B›·ñS€)è7RD¬ós:?y‚Ã-r]þ
½^ónv-Ï]/žVcà· ~6•ažBÖ eÃH¸ïòYr£ìË$³°^(„*Œ©cÈ=¶1®waÖn÷ >¿ÈžQSÌ«¯UßÍ ™?œ +Ó2±_,¬ 0?$éýœEAíÓ!yyÊ$ð¦Ïœ6{‹1‹'®[+\Á‰ 3‡ŽŒóày p)BèÐ ãk3¼Ý (ì08á^,Ánœÿÿ‘^‰{zË0 +PÐ¿Ü ¼ST +þè»ÜÔÕòø9¾ŸØþžÅe´8kô;_¿÷‰³RªLϳ÷7÷rÏ’XÈàðÆZ +ªjDÒG@œ=ù¢0Vþ23qð8@R‚¢Sx†€ÀˆQšk>Ö˜IÛ»åÆnÕ@ Šœ+7ƒ¥ #xA& +V°î2»“u=œÕÏ"¨¡
¥}ŨRpÔ G0Ò|Ëÿ°Á÷v¯×ã#Ði¹j3ÍTâè(3Z÷†]ö‰6$ áHý.ù2rä"Šñ.Q}Œ[ô(~áa¼ô|·g 7LÜëèi GÕzBƒ¤ìò°ôÉy,<ri5¢Ó<øQ°–"ß@X1páJ9¥œÜ{5ÖXOù!Òâ™DŒŸ-ƒÞÒ{ßî|¥Þ‹|õÈ”…;°ßUÃF rEþ÷÷>£–¢€%ÝÞû.îcäG3*Ùºr¢ê.ûÝS²Z°¶¯Üi𥰛‰àò"ë8׊Ê[¬oœæiªÈtB!N²Ma3_#”Ö‘3?z25Q«û%Tb÷‹ºðƒS‰\ ”Ë`DðÌø¹Õ"†Ò»K$šù‘ W»P-$Ô"taâ5í.§œi"2a îÎEg|鞢³‹O-,Œ'²Æ¤ùp|’Ì”‹Ò7rž´‘€µ‘‹Üä!ðvƒŸÖß0ÕBöy\åqýXkÊ€XƒÆ;my»”(~aŸ›{á|±ob’ØÏÖÙxœ=†¤…` Ö罦(h
ö˜85]‰„C¬…ù×UÎu×ÞÃ4 + ?0 +tâï¯tãq·˜þ ?pÿ?Áÿ'LlÌŒœ\ìmœ¬áþ” Þendstream +endobj +634 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 40 +/LastChar 90 +/Widths 1344 0 R +/BaseFont /XTDQTY+URWPalladioL-Roma-Slant_167 +/FontDescriptor 632 0 R +>> endobj +632 0 obj << +/Ascent 715 +/CapHeight 680 +/Descent -282 +/FontName /XTDQTY+URWPalladioL-Roma-Slant_167 +/ItalicAngle -9 +/StemV 84 +/XHeight 469 +/FontBBox [-166 -283 1021 943] +/Flags 4 +/CharSet (/parenleft/parenright/period/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z) +/FontFile 633 0 R +>> endobj +1344 0 obj +[333 333 0 0 0 0 250 0 0 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ] +endobj +626 0 obj << +/Length1 1606 +/Length2 15226 +/Length3 532 +/Length 16089 +/Filter /FlateDecode +>> +stream +xÚí·ePeݲ% +…»;ww(ܽpw6°qwwwww/ (ܽpw—ÂÝáÕwNß¾ ÷õ¯îûëÅ[+bÍÌœ#GæÈ9#ÉwaS;c „3 #3/@dcìâ$og+Ç bgm +øk䀣 u9ƒìlÅŒœ¼ +’ +tüWƒ¨ÿ™š¿$ŒLíl= +F6àß àï
cüsÇü¿bl@Ö ÿ›èÿ¨ü7Ãÿ ˆ´³Ñß6Ûšÿ•‚™‘ùßF“È hú älb03²þÛ£ÙÕlMŽÖ [à_-ÿÕF +ñ½¿Ý¡$ý6;›˜ ½S‘F‡‡9Lq®÷#7ùºÞAæOy«Æk™¬0\™òã)àÚŠ¯Põýè _°ÏÈ𸯠ª+WX½À4qW%¸3A pÇ‚yçNјŠhÙFƒ´¼òàH«Qûv¡;±0p•]ßt’~xd,Š‹÷xÂÍ6m $ˆ¤bŽè›a»èýa–Qº ÅZCE{˜Í¸ V>$zytgC¿ Ëûž~^üZÎ¢ë— '¿4vÌ¢€œQ(߈¼ÚóE$9>RÛòvJr —Ž!V•Qê-¦
ç]kˆ«#L¹)N[ +Y'L + Ml%£:Tid„‡ +†{z¼*†ÆO0RÕ[|+uØ<»×xB–)ûµjÃñáÛTK!ëßP.GJ¦
šïHídϷÂó‡8ÍÈÝÑìᣮ¨¹)KÔ«£" [ßáØÓz' f?r÷g‡ÏÁõûd„» Ë}áY‘’¡žRÞÃþÛÈžiu MÛqÁÞÚÖ: ÏÝu)â ì¾ +´mg!™Õ[º±dúrTýÛ·àÑï;¾Sh4+mpæN#{•x9)Âv]² O_ÊÚ"¸g)ˬÀ ó6ÌúäT¤q6`Ü,ÎÄÊ“Ê.ÆmRúuZ} +u¯Ôeø9 ‰ùXg©v«½~ô¤™ÎbfÓ@ËZ€'púÎfjûµ+4Šð9µ?çyG Åš2Ã>öá¡ èÓÍõ‹æ ©íq½j]F4ÊQc &ÚWÊ¥Œ!¤)Ô¡W;êíˆkúë¥|ÂO!xËl|Ê/"Ë ¥Y8Þg™t‹}1ü¸ê²áüs,écbDŠ‚<ÕÔ&0S™2(Ãmz\Ì#wÔJ$G”ûs uQ#JöõÖ1Œsoæˆ •X 1K÷·XøZ°˜©T†f zUàÝô¤˜:%)=ÿ¢NýÌýßáB0$awϬ&8Ž÷SMÕ@: ÿ÷6²± ‰ðJe Êq»‘€¿Cø# /ÒT
ÚÁûB2cQ˜ãSŸ_1IãÛóù´P$O´›ä…™±<œBn|\©žêŒ.ymõ¶9ŠLrd¤¼]‰m æâ¥ËNÛ” CS ÿ +Ôw(ˆ)¸ôèg¾ÜFþRM–”T–VRƒú¡âÕ€ 9«\æÁ r˜.° ׄZÎAÆØRöuaÓ^z¾A}É €1X•¢Ä<”BÅ2Ý )×BöÔÚó–7L}ƒ.DMZÖËçÒÌ¡sìÕzÇ<ï§PÙpK`Û¶— +d„½-˜vNªÊ:&¬.U~ø +S–2¶ò¦,|Uº•¹åÿŒ ²]d§ûHÛ±^ 'Óàrê¥Ñ'Wží¼IëÛËlžœ‹¯‡ýôÊ0 àU\|¬¹.wÑ`7ÐÛå/—êâY쵚ûU¿ð½@'Ã\Û#ÿ¨tÓ"¥ÍSûã†ÖÑ Ö9X ³*¶?"D'Ö ótÉ‘mtå +6¾íè†i#¦‡¨#d]™P8-ÆŒt8ñOÑÇ,«ñæ¿V´Dze<
xzÄz +ÉËh¶*”z T©
:ê %Ë×úì±m,0¼Z©“`Šì£ç!(ÐÖ2Y +<«<Æ;ƒÎdä”4éP йë×¥ß"á§KHe +¬Ÿþðåg¿ÐžT1‚ŒÙ{§ë³÷<¥·qÒVÍïl—ÎЕÑi„¦¨DäÒ)ìW¾V “{©¬1› +ºs„ŒÍDÔTQóÖÉ_+y’‡2„æSu•P¾1YÙÑ"®—tI+Œ,r]
¤'Ü~ÙŠÃüó²-e–´cOKswfÞé¬yòÒƒâÌ’.ËLÿµ_·_Ú•bȼ±ÞõŒCⶓ Сš¬ ©%˜îvNB Ä3Àu®*ó^ Ú£e3ÐWE>qßiSgb`ÑÞXpœõ
ú~0èu†£ÆBß^ ¨íHßÿó1p}PŠÇ +ÿ¡QÁ{þ +Pä±\7Š‡òÝÐBÞz¾–ܶ< +hÞãBÚ'¡ê{üŸ[gq«JNi9ª J¡ö–”ÍÎBÚ &eš"¡„™G +0ũ㻢×JïØÄæv +®t·Té„Ã}5§¯kŸ1öÖ¥¼?Pe;ö•Pö‘rû0ï}Bϼ˜\ˆ É6ù·Ò šÏ¹äçMI9!Èèm)L(ãÌSŠ›öž ™{ÔˆV"X¡…-’?.ESö®žªAÝP! j#HA ±}…KXžÌÕ§ÐÉMŠ[¤ã('©m»Ÿ >¾+›™Q…ºCTmr9ðn«!dØ}û\ >KdÚžïËeš»ùØã‚„À¹b¼ôd *Ç£GhU×¹ +>3;J¦@ÝÀ¯ÓrZþ@)%È€Êz¤a¨ädèji|µ€) eãCÊuÙ.ƒæqô~l»JöUþ ŽžØóáxf‘n#©[6ú<—¼FL¨ Õ‚¢p¦áâþòþttÁo¬‚¡:ks_V]º¨ž*Yº‚ÖS,"ƒTæ{à':¨²Ãêﳓ+xòä½o»äß(!\Z,ÓræÁÚÉŸ ð µµV$n« BA†lmº'U'ž½R›~nØõãç":E›çÎy?ž ‡
?CÑ<,ê‹DÜ(8Óv}å~õ ìòÙ¼ŸêGF¾nƒU„]¢6¼ óÈ¡@¦]¹:@¾"¹&~žûÔëâÈm!Ê ê½–B¿™—´¢´ +]éû.@U¥”¹7n0B¹TñÖ€•Ü’ü=²Øü ;ApÊ|,êºJ CåD…rÿ}œ_PHqÆ»LO…NEt"†‚©ÛAѲ‚÷&¾½&WáõÔ7j§qÝ Ä ´Öoºêe--Cª±G.y– æQ12Ò7 C}Ϥ$)S¢›#qò8R|ﬗT%’„`Ô‡>{|ÓÑ(~‰M€ì¡öÔõ| µ÷•Ý RÙŸ¿°xðÆÜ ï$xÂ1
ùê”"B/J#_“ÕK`ô!™"WX¥ž]58 áqA8Rkªk7bfRCèç`…oŽRÈeé'¶ ‚©&#É; °õCd€nzc¦}ϛ«ó~×€#\K "™qø$â~FÛŽ›–‰K¹Zð®=¿Í<ÍšQƒT¼hçîuÈÞ Œ&©ò§=&—àÈjóAŸVË pý~‹ wåhß\">ÿĺrÁ I~¹8îÖ²Ø eçmב[~ _‡Õ)Úùá!¼G âƪ̣}^jèÍeìGHj{FƒÏDI‰áž>ç;Ž;
:« ^/lü²ÏÜ!*‚v5Bw®vªz ‚/{¿É!Ä)Ý_Ò½,0‡Ä83ËqPA¨Ï ÀB¤¬PA$.Z„^™ùà À_q\E¯§nT©E|i¢jHm¯© +mO´ø$ZEZ»ß÷êSùâþqÆtd±ã±ïäœ1·+ } pyÉi"¾!¼ÈÓ‹ÞBêI†¾y¨‹5Á·n¤l¬ î¹2íib’-þa/mBrZJ¨g“mˆêia1éØæŽÌQt¡ÓÆ˃¨ +¢j)ü™pÒŠb÷"…í¬LÅí^²0 Ôô{k>—
¹§ ‚ˆàêÒ|%
ýˆëã_d;lEO㷳ߗœ×Rfå +ZcÁ²Z!å5Zn;£°¤Êîž4Üb +“â7+:¿ßå²p€‘ßTî º½bºLJzù:˜cÇZŸQyØCV`ÔÖ .ý\ø£é¬—Ò8~û§v Yg“ÕŒ1… ·ÁÅzýãÚWÕºÌÚùYÞ‘G½ µq€¥Žh” G ;èXîÙ7š%›Š K–YtÙ ÷¿q;Â*ò¾¤ÈfRʽC@Óz†¾>ÑRKíóðdêZ+%{ <V6KiH|žz:]6•Æåý̧ (j›ÀM¾dxÅ]©äh1=[SîKØ{²Y¿×Û3fãï[4HâÀfppï}:´$ŠÖ‘1
`â;Ø8§QŽVê’ÝýIX† ò«ˆ¤üYL ^R3‚ŸW:o»é9¾5¾æÃÿÉ#¡ÊSºyØànJ¾w|fjvä|ðý®PRñgž‡°¼äÃ!Šì1¬è¹Ø”9qζ 3™u° œºª¥?™l*¼~þ²[q)7Š–% ñ,L2Û#Šôï[IÒÖÆÂJÏ®B*öç¥6ÙâµÅÀìÝŸ#zç*û lãoô«âWýr)¿/©Ê»êrBIö…Úäé]›Ê®ß@¾ sL .ƒ6ß!•}º‹É÷ E‹šÏrW¹ý ¿ô¦®V*sŠâʨîø»iaŽv|Ýj0=Ø$Q>SÚ¯‘n¾€ûà3µ¨¯¹|Ï‚·#ø2òJ_×Kà?ew5²ò!msZYÝþ³Ûš6·—O,o|iVð”@DOXå¡gg'\ÔQUáÏ‹wƒ§ tÔи7uû]J8IÓ~«]Õgb+©‚±ëõúZ÷0©ÝæöœÉgp£è½»Í¾÷QöÅÒ+*A¶3M{#ˆ2¡éŸ‹\®þK§Œæx'wÅw÷q‡Ø™³G›Is%ößÕlÕ×ÙYó$;ƒ"d™ˆÞ›3™×Vc:DŸ!H™ØºASöò;ªÄ‚3:¬§µˆ6· ¿+><Æögn% ãïcªKZ¬ ý ÒEÓý°¡© +oöw¡‰Ç÷ LN(Ú–Ç•ë|¦ÙV0f†BckÔ/ÖözåÄò«ÎMüPC‘&§¤sâQOŸîì?`øá +u€2DZT‡ÿan<øF¢àƒKï¼ ƒÒÞxpÂä_µB…•’Ä5$(Z£½X÷˜,Çn=F„I1°Sk€/ô¿Ñû’-Ú%6© `Û/XwܸýŒPä°X{]‹{ÁõIê=/uµJLÒ "nÏÖ9 + ÊnQu}±”ÇËÂo¾ÀxÂO¦ßi“Ÿž„Z”ž¬ùáXßâjøLƒMw®ÝÉ¡þ‰à0߉òÐaàð1͈o®ŒKÔ2û%걓ºîöC·wÕ‹Þ «WI±á‰šæN&`†[Ë~©à}ã‘ë!–{«-ƒÐKÜ Q>µÓ™ÚHh[“+ÊäŠw˜Œ~š ‘o;UK䊋íó¢/¯sö6†>ûþøM7f“ wcå wÛƒS^‡ãIÔˆ·œ‘‘O ¡"è£á²N´(*–ñYaZÿnŽš +/ †¿ +¯)$QF!ËêbVqâ!Š–i× ÛÔáZ4 z³2„«#µùjÆa0Ž¢”½¦wÝ Ì³
Mx¹c "ve·yäÒ0Ëdao†
˜’|¨äÊÎ |ýªm¯;°”`È$ùúgH÷ôT¼‰K6lºæð°1I§Áü<Mø—Ùî¹A‘†*›Ý ´ß4èN]ÐL:òs@ˆv.BBÓØ~©ç0ϽxØÈ ¸Œ§´zŸÌ¹1lðhSe@¦¹Kz˜$Aˆ"ÆÀô¢A $Õs‚ݸHªê mªœÒòûÜ™\ð€Èª&¿o¢újt§ã;»ô°Š lñëÒñLÅ –ÞÎÙ ÆòÛÞ¢bòê/Èá‡@°‹Ôp;C¹@˜T¯+,OëBš—UÒæ7v¾µŽó"zÌžƒu¸WÖŠŽ®‰Úƒ6äfôT!m¹dÒ«?¢-gÊsŒÅ¿î•n!yªWƒ¨¡õ…*‚´Û˜d®Ë’Àî¤a‘ð7Àãk¦·nÖdsÈãMU„¼Ž8ðA;²Ÿ‡–œGC¹éâ¿q…”½ïyB –þ|;kßá4\àç¹òNJes
æ¶3 ìãdœx1y¼ \ø<µè¦>°¯Ì~δ¨ñ¬
&d‰tñ‚Üè>øŒº§ðTÍ”µq¥|rüꆸ´åxùòr ¿jÖÑy„æOä ¬-d‘Òä[ºz@z6>"Ò(K)+è¸ Ê]‚éÉ ëß-Z¿¹ùÁßP£«•O ?.Ÿ7©`ñ §„nºn´ˆ©AÅ +®K·¶M“‹PÐ-øeóù(,•Ðqš W×,׃ ññ£™”¦ £W…á觇²H•ª£ën“¼ºUÕq/ßíÇ%–Þqÿ J†tù›á8îe p©SíÊw¥N¶oéÑ!í3ày<Áév…‡~ñ¦g‰ûÓGÃPûÅ•'ëyçÅÙö°ê"б2¦<N[—ŸeD·^¸Ï×C2'!ðœþ…`—åæõ¤Ó.Çiæ’,Ýã I~d¿z`4¤‚+õë5e>¯ge&ü¿ˆh8#u÷$å†7 ~g¤ ÌÓj7#)¸"ãbø=ËÈÓF7mõÏx|)Ê ¦R+ËY'¢Æ‹f¯ +é0; êÈÞ šGû)¼ÕÝÛ•qòG‚}¢v7~ýUÌØ{/ª//¶£@¢’BxP
?×㺽v/Ò"¢³¬É–²7~õ¥-°ú¾Yâb²4GáY±Þ\ÛêùÑò:u|?í¥LTj/Ïäœän” …xÞN[³Ö´Yg$<o8ó!¯S庅{–¸¾£“7Bb¤ÖRƒû°)©5Õ‘
5e 'îäuõÄ]ºv&cÀ…oÊÄ8büR š?òré +GZläÞ¢Åë6}oÛ,“Nxúœ½™§~ãIf7Ù,’y®KuT§Ä‹óˆÞˆ:‘¼ '³é~” *=Ï¥aæ½L
šá(ˆ#}AÀ·åÖ•INø™Õqy»±ýQÐBþtSè³í¸Ç +Oùl_t>»ˆ„Q@·z×À!»Qqf¢Y Îë"Ìãì ]/©¦pš¶¢þz¨´ «E¹f‘SÑ”,Y¸!µx·?q¼ÀRœh·×ÚâOÐ`8 Ž÷PÚÑ¡lŽ~ñ¢ª ”HÓVß Qk6˜qØ `?'7Àw1²£;Äk§ÕùI…²™e£ +ÁÊ ýŠ{Eoa’¥VÖôJŠD¢VØ+çòêqgkSÃúæœÖJ!¾íѹ ‚§š@.¯¡?4÷k¯ÆpHmÉK HÆ`ÅÀgç»C~\þëÔƱ
)m®ðrô©:ã.ÓŒ±þ(pôs° ¶†Yi†u1`kîxÍræ N6Ór§‘Ó¾‡‡8êaì%ª?áXhu*‹e²ö×VÒôbÝMcÚí .ä Ü
SߟýŠw×ë±AV‚, “ gBsEû&·9Ó3÷–òÎöÀ¥[Œ»ÆT*UD-.ô€]¨ô€–'OWsá€TO›¦õ`¡Š»Ù†ÖáÂuþ¾ñFl ©>Ø NRȘa»CSÔ—Ÿ¶†ËÆÁdõÜBx½oÌ«·†)Ô›.hþ¬ng¬ûÛöVhNÁ4ýÔ¦zçŒi=÷·ZÁ¸ö‰ÝbáÂóû=™‰¡-í§ç)Cm=Úy«ôÇÅ“SwCðï—9C$~™¤9Ï …Û‡_ÚóWs¸ ù0.n ' ’8_JùïMæüÝRÄbI’OîÚë;Ãwh¯“J¬J ´Š^kû³ÅJŽm™ªó‘'i‹lÛüŠßGÀCÿçù#K‰}¢orL-–cƒ9MºNöÊ^âæYj—aíLY&.þˆf$Qžþjõ0Cñɇ\›€®ì³¼kÔ42uR0Ó…µöµ©k)¶¡)–—Í …‚‚Tuº—Æ6°…5ÚÅ(˳«mÀšÇÊõ™¶Ôî^H™¯Ì¯ò,µêiÝò¸: +SþÅ•ù°?UÆh´Û Æ~‹Ü³µ´FŽ ̽¨
÷`2±Í¾ ø_ÑÛ¥¥†%º %B\aáPbs–’´¯xÛŠÍPßí"2¸'\sïa øçÑõØê +ùôÀ®ß`&„jsJ·ÝqüÚy»©N¨ªÊ‚a
'±ð¾•ìýÊ ¤hö\êøÔ<{,üág`™ÁZ±Mãêà7G¤¢œ‚ñ¹ÍÃ5¼tÈŠµÎ”ࢼ'}ÍÈž›¹cU{œœ”ñ’£Ñ8þ» *\þ:X)8ìÆäG4k·D«S ½ </psð8M´vÊ#'®È?Ý(æDœ&jž]RBqf„I+=µ×õ;˜AüÂÛ©4€…Ï3‘«)Ã`&ùÄ. 3Sª[‘¾vÒE&Q†üÕ¤Â3$H˜3ÈX)Òö +Û fãu¡ÀÐZKÏ¢ÊôG„“ ?î ]¢ozNS¥•oNüÖA797mÄÚ¥âFËë +!üÂlŠÏY™ Vß‚-#õÛ"òæ)ê§4|÷4û•¦Ç\£Ù.,u˜XÞçAO¯é8h‘$?³DUŽ$ÐN—ýÀôZO ¾h¹)8’]íPlÒó!ÌÖ¦¾óí3„@ÍÿBkjû"qJº„‡›áûÛ >Ä£c¤ùÄþâ<NI×–áä‚b…&yK`à3r€ ‹¶ôfæX: „¡'*?§ºnQ~ÓRÙüÌ¢÷¿Ãs¦ yÞ$Â9{¶Å*+'QÅö* §H(ð›xrPßÞÐFñ`$•†ÔXóþÈÖxÊ ¥ô*$ƒn%Õu{¸‡£Û"Ýft
/æ.;FÑ÷·ßà9èf¤û*
Ž n5ˆò§\S¨ƒÆ+’Iñ$ÉÆãЩ$ÐÈ~f›hD"°[I r·»FªÁ>ÂnÆmp¥Z[ÆóžC|ø{}Í°†¡P®¦é§ +@á–ŸŽšó‘ŸqJB¬Í×H¬íÅ]¦m š_-Áµd‰[…©ÝG}kÂ'†¹ZñEïJ/2Ž¿I¢Û¼Œ;ÀJ?ЗXÒ²se¥[ñԆص–3—ñ>(ìí,¡’Ó7¿oØc›ŒÆrOã·¨Ó½¹`Ò^ ¼>¼a ˆË;hŒ¹ÿÙÿå`@HZ a½¥×¶9‘àÕâ¡[Ü ·Å’Øß©UøgéQuz`@ÝD7… 6˜^³&s %qßÕ±%zs‹É«I) Œ—þ[~x4ir:ÿ•Ä5¿‡¼c@'dPí¼+ Ê-ußvxØ€F +‹˜>cîÕ‡¬òš¢úcÓÕVAcB8‰à–à3†(¿Ÿ->2$§‰#Ï ²f~µÉO R¢}Ì^Ô*ëT¦9Ï^°Q¦òÌ0Ò@§…×õ™Û¡f}O†kÞÜ9ìFÄ«òwÛÍbµËØq„ÂL™§ÇÙ宕NÔuKJL:˜ Ü
õÚšöÀÎß +--˜TÎÁ?åשּׁ~Ig.äs#IR³1Þdà0säÐl„ë¤)wÜÔC‚5ZêD¡˜A|aK]¾öQŒ )ŠÑßÛ¥fÜ-6wâœÌn¿Ô‘ëZ¬×ñÂe²€KQÊÉ!qäl †ä Ã;¼Â` ¯ˆ«Ýjƒ"àFd’(ñ¹%Ð¥å Ÿ¤:ìKÐÙÖ»ûúj?ã0GLÝå/—‡ÕsÉmtèŠ 7@F.°vš\õ`òƒ_¨à@ó+ß'9/þ´îQöñ;*œî~¿ˆ\Ý‚°¥ù"@Ãw¥> +«ñh²°þ;f&õÏý tYPXÉ(ÄÑ—î ÿ*ìRâ͋MI.riAÛ³eBapX,&L˜”FÄqOÕi/zÌ-JîÙŽX!|½ôÔ{/¥Êl“”2êL¦›$ôéy¶r×òèt A3È× ¸„–MT•Ë¹#“Ÿ_«ê±C˜Ä%3(ØBN®fMݱd[ï0i®§¬Þe˜nùÃ, 2†•³>Q~Eó“l¤Ñ‡d¥K +È ¿X¤ô á€S¥M†kh_v.ÊZ°XY–×~dŠZ£þq z3„=pÔÍ*SÈá£.rYÎ8xz¡ªm:è« íƒÂfkl®õ3V°yÇݪ"|pA´q+K¯ìñÄ5ÄÆòX”ñ3³S“K¸8”Xgúy6VœOÉÒÀn‹|@aµ»§Õÿþ\1-óò$jô½·Yâ6IÞåQˆÿ¨Û.† î†!ÿ" Žíë½#kÒŸ@nüšÂ.MV5âÒžpɾT “L$*jsK€k U3P "¢÷ÇÇ‚“\e,Ѷ™ßUeÅATIˆ¼Š#DRÏãþfž‡ïDŒ4ùä;¬«"_u´©+E¸8å´•È.a«MçeÉ™¸m»ÝbîBß_S¨—,ò5žL(Áœ½¼«lè„OÞÐë³,ÜV"éˆeÛæÅ—¶‡~,¡¸ŸÆü€¾µ¦gq8¿¯Z‹—Å}á/Å'laÿ†SÙq³t‡º¶^H·âœNwÌ útaES<hpFEž u‹F,p?º °8*ü²z"¼ñ…>«¬¾lfœêð~,¯±Ni`—…Ïg Cž@2|§ãÓ>ú6.ûW˜ï>µ½Ø“ M¿+Ÿ
$g;µÆñGïÞ—ÆøE×®Ú§qkERãÒÆc{…ŽZ²ÊZd;_Pº· t‡Èû/QOûIàÏg»–%E:)‰7‰‹zz÷Ÿt¸ZúŠ +É9û×ÖN¨Ó©Þ¶Gn‚‰å”÷,Œó¹ñ:Ÿ5Å=©x¹=Z©¥…»Qò‚Gc]qŒð_¿³—«º'í(åDZþ´î€J®‚Iç'«_ßÂ:ŸÇHjDõlÝå„,©qØ` G¾¬†\È@éø¦‚œ—éܪðX¢ÈQ<Ñi8ºÄ|#ñ°Åòõ›O(m£mŸ8½7¸r¯já—"Tày¨
Zì|AúßPqéí
[ÈÃù3Vì lî¾
™VÉlb¼¤.ÛžF
ûoŸJ¶ô +endobj +627 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 34 +/LastChar 125 +/Widths 1345 0 R +/BaseFont /EGFRJS+NimbusMonL-Bold +/FontDescriptor 625 0 R +>> endobj +625 0 obj << +/Ascent 624 +/CapHeight 552 +/Descent -126 +/FontName /EGFRJS+NimbusMonL-Bold +/ItalicAngle 0 +/StemV 101 +/XHeight 439 +/FontBBox [-43 -278 681 871] +/Flags 4 +/CharSet (/quotedbl/hyphen/period/slash/zero/one/two/five/six/seven/eight/semicolon/A/B/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright) +/FontFile 626 0 R +>> endobj +1345 0 obj +[600 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 0 0 600 600 600 600 0 0 600 0 0 0 0 0 600 600 0 0 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ] +endobj +623 0 obj << +/Length1 1612 +/Length2 18185 +/Length3 532 +/Length 19104 +/Filter /FlateDecode +>> +stream +xÚ¬·eT^ÝÒ%Š» øƒ»www÷÷w‚»»w‚»»w‚ww½yÏéî¯Ç¹}ÿôý~ì1öªª5kVÍZkìMA¢¤Ê læ`”p°wa`adæ(XÙ™¸‚ä ìåT€®€¿Fv + +Qg ±‹•ƒ½˜± 4ˆM¬¬ +€¨ƒ£§³•…¥ €Z]E“†ŽŽþ¿,ÿ„ +ähkìù7÷_0Gg«ÑpYÙ[üz€3ÐÂØÙÌý…ù‹ýOwþ«NÀÿV½±££ç¿v;ü+êq°rmÍXXÿæ4uù›ÛÂÊ éŸA‘¶7w +$aå4S²r1µ˜ÛþíÔ¿ìêöf@g[+{à_EÿÕL +pÊÅÔQ¯ôŽ ÉhB¿n¿ü Öìö6È£ Ç#´“{Q²È_³o—{K†ÎhäK’w–jÝ«Ò¾š›ŠâNšâžýñ¹îJ!Âák"øÔ3cC 4[O4|qEÝ +÷®µûIûÒ‡òc~dZ¹³´Þ½f‚™a$µ +E´ÕD᥷,"k |+Ë ·K|XÐ4áï赩9•3û¡ï\›õU‰ñ¤9ì븉£Ð¸ñZlà—ÜpPÓ•ŽÂ„Yñ©²g‡ßE”[?>yB¹ÜK”–.buú Sc©zg‹Ü¼Úcòhwqj›%þbpŽ8¹ wR8y< +¶É|öx˜îçÉÀa¦Ç¦=Fzåq ×q¨ë 6)ÂÌ|!0à‚‰§"ŸÜVØN«hˆ©ƒ²â¶ùQë[M,Oy*ILM±ÓëÈø*ÊTv8_ v´AhÇ *‚^ƒ=;ÃÞxÞÓ<©¿ó´Í«î¸Íó0 +¤Š˜B _g&îçxL¢±rd´« Þ’ÄÅ\I¡?YÔLÆ$ëhø0¸á´ðæ(#©Í/’ëII*É/%Ž`åÍÞ MJ͘]£í…ø½Í,Ž +jýÊDAD›oʺ´Ædü Ë”zj.ÃZ8^KïJ9xí–j-`Ûcõ1ÎzÉÀ¨cw]Û
¶mžÇ£H B²‘¼{™™Û +Ç¡¢ßÇ +Ÿ¯‚T¾ÒK©M^
o…Å+e‡»kñ' æj BÔÌ[ÒôÁÓùGv¬Åië'fMçÜÔµ¦4/íûOÂeu ÷yIýC‹F~Œ—hYÇiJÚ« ÞtB$ HÎDÈ89ÆÞ¾J»Æ1. rÑ©¾j‡~Žïb +@ì
œËîÙ‘SÊÞW4^vFñ Å ›`ã¢Q–wëÙdæÍ _DqWÕFv´±. ä ¦xû˜ e5eËl!•ð_Ü)_öSNðâ +¿CUFøØ‘P²I'£X}Õƒ›žR1^T{o£Ù5O§ÁX?—2ïL @˲&µ”UD¿|ïÊD 2z3ôx!ìn\Ó„ó>4¥ ž;Txé)7xr>om&äØœq$#z “T·²Ž Ë &QQ2_`ôÍbo~kh̾Õòœù +B1â+$ê .7f˜Ïv󎋸ì\¦ÞòÖÌ&†±Ê½€‚q9ÝS…ÆyðX¤¨«•IÝÜûz®üa=‘-Éc'µ<?†á¯ôü•Èõ\â;†Kgœ‘á
“[Ÿî12+ç;†dÕˆ3ñ¼n +þSÙR÷ex±$z¹„Äg\Ïpuã÷[áÅYUEã ÓœGÆÝ}À¼;LÅ•\tUÇ’Óâ3íAà’àÙ:Æ‚¸©ØÞàµ#.ùz]^¡¯¦ÔT¼½ OB¥Ì%KoÉÍd1Ø»[Mq 7u¨£<“KRÀ1¥j-²Ÿ”LxÔ;Î'Š¬ŽºbîU^¤óÛ§Uq72 q€yОô‡r2-î@˜<š=Ñ×¹îåIÁ/ ³íõ<W| {‰/‰-´é61¼»ªv ?è,TÐŽÊ„=ŋȱڎ+xöFáµÇ 5kû`ŒªTæ+– ¹lb³Š}Ö¬ü‡ÚÎlËZ ´„-½#¸HаyÈ%;¾ Š™ï #ÏEl0w\ôð䊫¥Í‚a ÜÓ\·ÜQH\?§ÀÞ5N¿8VVÈ&E\Nw?¬‰â|˜Wú³l?ÑÛùÏÂcwæ.LÀëojÐ s„†å^¡£~ÁwŽº:eÕš,A’¿>3é SúÔ»&ŒvÊô«Òî¯ÓkQÓðêF¬6}» Š„üíÞÈÕ ¼û£í>d ;ˆ›¶j¨ š)æñ1š}16§¢rzsµ™ +ðóOÈÌ€ºö 3ÊòsFdÐà ÏêþÀ öïÎtº[ë qõŒQ v$yÖÙbw +_Õ'ÙW/t¥)³Bk l@ÒuoY‘$žÆybP¤ÉˆÑinµdè—ô{Uþ6ÕËôÁ½¸ðLǼ«‰ð¯™ÄmÐFZ¯Ôçt5ìÁÉjq TWeec±²¯n B=´ŽÚÍkV7pê¬IÄu=ø €}~ µ}–ò%UUz&á꬯ræ^…+ "£‹8ízƶ õìù4Þ‡ºq’ÎŽqÈêA1jäáŠU  Ai<)釓ïÓÉ3ëÂSU#ìœdÅçsÄò17ÛbÉøÙ÷ 5°®;ºì’L•z]õ»ð…)} +3_^ ‡¶š. ’‚…)Éç Šá£ùbK§„pNšÿ +9’þ!î8IÑ›C r-ÿs[{œP–óe›&~b«I¨/÷cG@X«â}Q%´ÚkV{=¼{<IÛÙ +à š?qŸ6B˜zÐÓjõD qÍë`ãçy3:*íHAvfÉF ênÐMêŠ]T€w1FUe/»ª|¯S¥ ç‘äÉçÐV?—x¤ ¦D7&é¦F!Ò%cqdKÚsYÒëÉå-ÊYÞ}Ӈђ,øQ´Û¯Àú—m-ßµ†O6}—í¬pùÝ<ý)Ûb²Ïàš#*yp,só0ƒÅÞxU€f\±µrü¶…5j«÷WmºÍåV†¯Q²Ÿ4®¾ü™^7½Ä˜o‡g¨ÓŸDÙÑ—æ!ÎÓI_'üx벉—gŒY…-µ}";}xí{”l½ÓˆÆ"Ä(ЯNÞ¨(i@M‘{0ûPåø› E¹b‹ñºÛÂeûà¸ý · ²·Šâ9§O½P ²ÙÇ«›®§Ã³Øn¢ÍM É´šöÀ 1ÕʪgIÃý…ýó’\îKÊ·ƒBæ tÞ¬0Ö’Bë13ѽSÝü§žsõ‰™ 0ñUU¢H§: ÁV8§Þ¥(#>H ÷0ü "ahâx‘[Z0EvøæzÍÀ¯ qi# Q&û¬i$€?Á^,rP-j&b’ŠÊ‚q Ø•¡1à03œÏÞ7ñbäzI¬|â·ÖßG÷?ï=´÷B`Øm€ŸDÇ6}0i:ÆeÃùUp gŒ-}-§¼~`[ ç=BbW;’«š)FâuÆ,D9ýÂ4ZÅæÈúü±ËêŠ_5¾ó¥£74ª™ö4M¯w#íçNW51ª-?îÅò†Ÿ£+ߎ!±iëêxÐIUñ ôvdBYB½‰”× +,°ãzy—øg;Šy¹}ÂÿÌø±UûF¥’k'Ú¤#È3¾^* +•W½Š1W\ÁMÞ7ì’)Ò”Èã=ß›¥Ùµ ·`º¬e
ŠAÿú‡g¬µ¥ê˜'(¯Æ¨¼H¿
V€ zà´ +R*F/qY ¶Ã÷¼ ö"A±yjat_ȧÅfTEJ}Œ;íUýÊe„s—Dà¾Átµ +Lþ#ú%L4VWm.„½dlŒ‡`uÜ~¬;K|ìWwºˆ¿B¢ýàqŸÉL,Õà¹ê2âÛDOä¤Ï…Šª Üï?FôÅ6ɘª$37T:΄M”Ü|û*FÄ‹#b
Î-Âç {ýÛ…#CˆÂmbË:V÷Ê`ÏMFSNó|N2y]"cPiY +w.LKuûzrsàv YõLkôÊx¼Í! ðgÞzW 7)QâM¦°Ü8i¥ÔaëJn ’ÓóÌ +<à°ƒ>LUÆ4 ¤fpÚZ6½M®'{6üÝühÎv¾ sñ–7`ô>â'Ec©ËçÔ8Œ)ŒvND–·;Ó1µ¬Ðô«€1 lœiL‡?FßÞìj`ŒÓ/DX*›úMH•|ª¶xíK:"ñ œœ†ýúH™J$¾‘ËVd|¼’{‡äZ© ¬ÐðSÿ;Ü®Ý9îÒc)»âÁ|Qžn^KLæBuîû¬£Òî–“0ü,¤Ðï‚›¹ŸòJÍ^½¬} ÁÅL"wEV+*…–:óohåZ—àøÛ;Òl„Éñ£½zŸY 匼«}Ñ¡ç–‰¨O†xBùQŽºÏÅ *‡Ö<nWw"¬&ˆD^ªEÑ׶!‚‹oû@bô¤V –‰µÌ‚u‰æ„ s¹ž5[èµÒ¸¼ÇM×æÉÛÉêTþTÙ#±¤ãlÑXÄqÂûÁìرl=þûôÁ<Ȳ˜ý! ²ÇŽákz:¹o~·ƒÛŠ>+µ÷—¯žX"þ›B©Oi¬a +«UìúªAŒßDÌü(Ç€5QR«ÒÛ™^ý-5vò×Ëb„º`§[î¢JÎêKÛm-o“%Saã¿sáÐ ÿÞZÃö¡|œ^ŠþÊã9ŒR´k%¨X³i‰ºpó ›åö WÌXÈô‘›¦£5~ôHá(•VnWïç½~ÎÙ…Cî_Fh6“ŠüУD;0OW~½ ¥0^wyr÷OüU>?ò»ÌICÔ„üôjC{p“tÿÐôDIåöQ‚—ê!J¹iBÒ”„–—0)òÊ4w}QjL!=;Îi5”§Ìô>%÷³|jÊ)ÍY%Úß}Vñvï‰
!sfƒÁñ½ýÐùDÒ-(œOw™ ÆöúèÞ]m(ïâ<଩ªeÝ_ ~k§~¤ùLÇGxø_w™£×B‹'ØÁT“ íY2%‚ÏÔG@ ßçRÏ;üݶ²“¥4ÔŠ/he_q +.6Š¯AýoÆ%ßð‘+‘©gœˆÀÛ²ØÅ4%fæËP1 +½ÉA=Å + sE]©‰`ò6™=>î8é%ÂÐs>N´žô08òî~ÿ µûcUð¤¾Á.5Æ Ä*¬ó8/¤zWt÷ +}r/öewÿ¬É¶×•qk鿾ä**'âqùypaˆ'-K?¯ÙÀ–ƒÁØwMA»+²ÒA)u… uô1¬Ÿn…0ĉ»)¾TZ• §^ÐõbØJVíbsÑ`®¢•óäµ>–`$I(qÌø÷Ï¥CÍÝbÊ¥§Å.öBŽð¶/Ø×™Õ¢ß(² -aþ +¹—¥Ž²*?ŒO,âî N¿$Ý# +Û{Í6˜«¾·í'ÍÇ°8ÿšŠèKOå¬eŠ3«Ñ[s …¡Áà<‰–Ï´œt `Húýëu¯ÜØÊ_ kŠ Ñaöç{ ²\óJ$¢ÀmáþùKÒÁ†×~×ïâ¬H,ã§d.ý‘Þê÷ÉË%ú¤™s Öµû+uJõšÐÓ@×^#;¸r„
TÔ…šÝ¸?†sˆ«2ã`ñ +J½Èðo˜Ðæy‰‚áˆÛ¡9dõváïv¸ü:²Ã¾ ÊISc…öQ1}¤u¢Ð¨¤×©õ©º¾Ô,#mõp <>ÞGìaF™c›ßß*
‚¿ØÁVÙh4gÅçÃj·¥FÂtšöÞ‰á¿+ÑÚ0§Ï~Ì»ž&±k²àæ‘éoÌø–Öæ(?ÝãäjÍÞè)Üæ!,^š +ÎjªN§Ì‚¡êZ/(âiÓiÍmáú‡E´r•¿Þ` ]© «Ô†-UuܼMøIA
ÔæDr)|ò¥9Zvw¢¾2lÕÈ¥ ⨡gÍfs2ëéÅV|gÐØìÓo³’›ÌŠÎ}Žk:åwéf—FÞ´{çªÙÂ@Vžf#ÙUÞúµ¬Šˆj+·[i!ÊÁG1-¶5\{”ôã0Ò…ü¦ôÝÖæêëùd”Hæ Ò ·)Õjëy#ñj5¸ôŸ’LÒèÎQÚA£ug㞥iE7^å‰òæØo¡Hã…B€úÙÚë ¥éëуk’)Iï>Á2CeN£©e¾hwLñ‹WI$5>íU£n2úé+çLR'CßF¾] ¬¼ÍªŽ”ùÀø¸ +ÓÇr„>›jì‚é‰ é‡f´¸ñ°ëí
–Í„Z‰uk&0¯NRÒ XÃã'c¤û~?…ÖÛ ½2 q´ûº 7E)‡þ¸ÖjƒéÞ$YêƒkÕ” —äJAŸM)9€ÅíñÍ jd.ÇöÓ>±8‘~« kÏP¬íoÎP‚»+læY"áñ·8pó + ”±v“²Žk@9â¡i"›¾8üäs5q|±µ¸ ,´£êú5X_ Ǹò õA²‹‘ŠâðpøQÛ+é[¢ëù³ªüÈqêõBo> ‘îðŽ„©u§¼ ^ F¹èó«z[( <J…3Öoòˆ®v‹Þž(0YN3£ÂcçÍ‹Ç'fG$’:“ewwË6A¥8ƒÿâ%ÿµLöîT‘ +›½6(t(³rM¯ÆpŽ®KgEMIúbëv%6 bKA,ôI0 ü!Ð=ÃNîÐyjÚÇ:`¼‰ŽêÀYS§ýKñ[ýêþ˸ƒG6°Éðáu_ ŒÔ &DI{ÚÛúEƒ™º%É“€Óäê+žiàÄ|F É^u˜æÒ¨ú ((T! wì;/A +~_Êó-’wûH`ŠÛ +36ëánˆQyÖ‹ëôrˆû}¡ÓeG;ž[äRÂtCHó,5[ô‡p}sÍÝé†áV(VŽïeXöD òõ(DðOèR~ë Cž ~gGòiڽ߾_‰¦:·™×ûŠÈ÷—¿ºéö¨ßĶ •`ìýìëñöÂBÅëׄ€G)zŠ;¥1ò·ò |–†ŒYëÏég$ôI)wËäVbY©V Õ>]Ú&øK<ä„æpðW+xO*c.SÒa”}“œ‘þþF)J~)m‚P^1Þk Tù1¿{_ ];‰‘5¨Sù‹Üâããjð[â™cûMË·têÌ! ª pÓz Sª3y< 0âß-iÔ|ò–œ%_oU°~7¥XíÎ,ÊÇÂÚvS_}Ü]LçŽ °½¿zÈ=®ûêšm jæj³'ø‰²•ždZí|ø.²$Õ@=‰ùå–ˆÌw + ØÚÝ®-ñX¿?¾‘}ÑEµÞÄ)¦…‡!Ö †Žü™³&Âù-èo.‰ånUbÒHV›rjúx¥ÒP´^1,´àõd%%3ƽ.|<ÔçgÓI˜Û+<§0ƒ 5ÛVЗu™¨¡t?ÿ2ö‡Qü!‰@ú,cq!e¸èX:¿6°^ŠÌ¹¾ e%eG&Ù&4.³Ž{[Š8u^Þ¼ÿcÉöI¬1¾‰Sã+&wTwe®Fa…ÿJC`‡üjtË ¦zÄétø·^â ¹ ãX.mP®ÆÏ°àòÑ×IÓÎ$þq[M¥%;fH)Þ&•Ž7¥fjúV½Iо2K0^AloH€k9Ùõ.œZÀȻ褴{¤?\„*&¥¢Ñ¡cò#{ÄuÈsuÑ`©Ïœø‰3£¼iÉÓ®™CÁÀ¥³o[ ;Š,mÍ1é?)r·ä£_ 0ž žž~M¦ÔDþòŒoP"XúI‚ø<ªŽÄš¶•4Qr±Ñ—YW7¯ Zä*Ÿ?5T†¸EÉ¥+ÓÙV%Ù@ØdÅeÑ-M7êë ®D¾¾$ÁÿE_h/Sìžul<8E¢]'0JüzzÌj:йf\ÖÐøpu”V!ùäT?î—ûò!Öî)êaäùÁîÇát3{ íüÐþI»äÙ3¥eµ{^l&vãIÊ>Á«£v“ÖýÃ^–¾M_.@«˜*Æ€áM*DJwˆ}¯8þ”I»A¼¥Aî;Ü(áT¢#¾¥ . ª\bÌJ±¬ô‰d"7NÅ8뿹÷³…ìE$m_8Tâoݨ±ZvQÆ&MŸˆ6cqlê›NU°¸}™µ¥+H§ýðŒxHÄ„GJ¤JT…Ýξ©Ml}@=ÁV&rP‰’Ë™bäN_Ê-€}xŠñYpèŸÔEWÇ8í]eE³-dmÏh C†ýÛj=ÿè(3®–>é¦K #N +Ópà>¼àèÉL¦!JÂ| ?$°Ë h‘`G0oä´Ö È9Èý•í¢o†yI€û¥œ^i0+V+z¾' 0óT*) )ôòzßyׄfË£R>• +ßìàÝ'³ÝBû¢ÉEyc;8ÂVl®?'Å|T¼GÒp´˜´e ååD×Ò÷4îˆ-JG‚…L†ëAù¦ÌáUe~æŸwƉٔ4Ønf‡ª×& ‚êÚ‰„ÑÌ Ó4m!Dbô£û
¡šX𰚴߃¨E¼½Çü²ƒ1PVQycáÿü`J¼°i¾"ïSZ¢î`ƒ|LðBú•Q¥f°ZæØ2o¿;øéžK•½x8ÊÙ_v6^¥5R{C0ã&¨Sæ§,YHt=z!§:|aÿ°JüÅá +¤òøïl Ñ×ù>Tq@»È:…~Öõ2R y”άÙ÷A”µs¿oÍ8¿™Õ)w€C
pÜÓ t“ ûηwÉÜQáÄè-Äl)áŒyO7¥væÏö±0âª2/‰O–ßù†ô¥¢–¿¹dÕ…*\Vȉ\‰H*´Ëœ‡Ã‰D²¿ ™9\Qš‘ƒ Ö碴›ö¶MÚ [éÓumMU[ú©î²Þ~
p:LDË~bŒãŽ¦²§OäYC餤2¼ ¡böC„í¡Ñ Ð çYT9´Å3Wx«Žbhø“79 ˆˆ"x|:ø€ØàO7—_Ö ×´ +/9mö'z´H¤ò «xMö+qÊ×C15{‡)äxŽ!£/ñókÅPºÜ_RáÖÝÁÉMYTA? ¢-=?Ɖ Pßó{¥¸DZÕmëM9Ä+1¾´Æêõw0û,š£D›BhL‡T)ó˜Öº’wMŠ»pê/æp…;ÙuË×q(*È¡âµÁ àÙò yÃEË# Càž4°Bíø"pèT^Óèœt¤©§²«TãÃI;†ö–à“5ö … •8?¨Puãgs¶yXOt7ï€Þ’tÙåñÅ&%l‹Ç{õÅOІ”óù²”®'Ø9ðùW#Rã¥V+SlF¡zEi¡8š¨é¦vF"qIø| ÒpÜ7:O•ZöN›Wö¤R1O´±ÂA—Š˜òÃr»U>µvXW^Ë9·ô"d‚õe›Ö‚´®–ÎWO+©ÃU1{´–à/íw¶[¯ìKô¤Ú”ªÛ&¤ñnœ7úv_˜n
rŠæ+¦”Þæb"éÆg6 Ï “öÝñ¬Kà-'Fšá£K·šès§ñ¥7x\,S¥ ¦1 ERÍçŠ}-j9V®ùu©‰I ÷ÝßDó¦!=dt·PìKÆg(ÿ€þF‚%'ɤ^»WñŽI÷´¢ÂÓV" áÁu»¦T
ný‚kpqƒOr“\é*9Õé=–ø»}ô”ÔÈ…jÝâ3Ö×»"›`~Ÿ®u àÙÇ俶 ICNè1ÌÂT8¡'Ž–¯½Ú–äæŒ `ê§ùNj“[–ÁÉ0Ããgá÷IJ6†RÒ-;8sµ±x‘?¶Jœ
Lü¾°ß +`ž·»IÃ^6ì ì F!Z§éý&ØÏ:6 ’—(ü²6 ÙŠ¯pÖól’²^Zgié^íèéÓ_ÉfñýI lnŒ´«ˆ7T^® O ¦–ÝX7Bˆ|ý.k¯cò®õ +5, u\âuºS˜©G +¦3\磈[°élµ(GÏã©Sø#Bgñyn©>³}?źæ9gœ©¬‹Ýªµ; Vö¦PìöîxÀÓŒw.é W ÕØrÅEYÞS&¶p;N~銤€4·§jòN +|ÓØÍ Q
Þl £ +çK±le‡M D¥ú¦—ƒG!úÇu5Wå’,:µöùÒÉk6ßx
%LÑ·'ëœt/ÄCç䜿râ!•Ò-Á—:–ío£3mg±F8 E<>pÂkÜâH n[yÖ€‚Œ=«zÅÙ©êg=:$bÛ&°§Œ. +3•˜pÑܲWö‡0ÃüÂÌì£VäZÏ^„Ì΄|¸œÅ¡§` ô/_ò,fwµ«¿]îÄ·ú…àüû0 ¶pc9쮶|Ú[5ðX*Œ‘tUJ¯¶ÍkÖć¾ob–3ÎYEÎ{Çç¼ ‹†ã„7ÉtíX¥0ÕŽmÐÂxÕ†ö÷ Ó Ü¢Â[Ö7`ÌC¬ ³i¯Ù‰Úµ +ÏY‹}ÿà¯ÈCÚ5¢8¥>$Þ uh©@[ÿ8•®êLíjûÐþîb ømWò,_ÁÿöÜ×·•&#û%k_º¥êÏ©–$¶6Ôcä®Ä“ÊQ†)w€aÐ)üÖ–èóŃ5:•°Hf(NÙva‚ð/byÒóé|ýï'§°˜ýæLyk¦ÅÌßô4M(2™Ë:ó"÷–D&› ©š‘½Ù}~e&œòU•[Ö4É‚92åôBG(¬2ÁÙ;°4¸‚Jp¶6 6Óž¹X¨Ã€Un[кCaÐNdÆ4£ËüÇI”¬~fä½\¤†øö×æxò¥ÞÓñb,Šó7:ܘ‚Î/ó„¤ÉÁ:_¸|hfp”ëÞO³ÿ~î:··Gû_<–âé䧷—Rr”¿œ 'æ+Ð8ÿ Z</$ò=ĸUoßèz©lZÏl®êÁ‡-iÁ*Á«s+ið÷>"ÖÕ+À¾Fz‘@\æCȃyèȹì ïŠd[…=ßõCÓb ®™Ø@<¸ºñ;*Í’Ug ›.h"+DÜýJ +¿®îÁùª]= þð>+û§ tEŒ%üQ8v$3 ;øüñÍ¡0 Ÿ(%ã¨ÑóGßõ#~ˆ?ef ò½Óù=EoGKñ=™ +¥Bõ&ä"ÝûipÈ[9l{6¨C ˜•*ݳ¸ +é&»ÜÂoø0]þS*(:‚‰Îüí'mn¡ÝòÕWnÉ
|Ur²30£à¼Ä¡tI•ßö›m0l×o§©QLÔR,óècʳ‰/Õ>‡QÉcöYUÛã w‰ à;•žöz µ½Ží›'çð¿}©Ÿa8Œò’ŠPQß‘·Ïý4‡Bឧ5nD'7ÜmݹJÅ«¬Ä¦9cìa„à^”T
P)¯ÍNÊê!¶k*H{RwÃ!- +“jÿQ$6]ÂÎ׻،õU…ÙI´Ú ÑLÌÎQEÒýwu’å OËôiwïèc¨ä<^_®•XÌx÷ñoù 6âZiÿMmþ†Ÿùå”áƒ_³ÇšÐ~8¬ëÊ eSœbDƒüÄ¡ð»<¦Ý„¡´ï‹ö|·Û"#ŠR:¨¸ŠŠ ´`•HÞ:ë×(¤
=ô!üˆ ím péçö+ÂzL!â<èÚ¬bÐJÑ8¸NŽPÝ8û‚aðŽ +5{V¼ƒëÁ¤}bªyñEg(+TÍúïA/ö1å Œrâ-ôeÅø<¨YÄ&ú²:¶j´Õ@ß$Å[?z®
²ÇáÅ9í)DÖ a{t:7¾"eÑÜØ¥¬î|<ü‚,þ$²©î»ÜÏv,’"?Ç1èÀ3J."Ì |ý‰ÖO>ü4?m$¨¾™Òêb ‘åàV¥— ž¯v_¶ÞQÞºÙ,‹y›Lñ2™¶b‰‘´}•VõÆÞÁFBv•¹ý&ò!‡U„Y &ÿV #ŽØ_ €Ús. +ZËNêj̹ØÂF‚ÍÍSxG\â½»¥]!(Qq#–î \zË÷šéB4ŸDö3zëCY»lÁ«z›b%J
}?LDª EÊOÇŽÌ0ÀÙjöDöí¶Dx×›ïí|moÇÇüAjy˜/QÚ0ÊEÔÓùv›¶ß¼É…¨ G|×個ÔÙÓ̘’sø{M,®^.š +v‹ yIF†ù‡VBcðà-Òæż8šFaëòØAJ|ÿ=5>ô³}œ?ÔÒˆ½ XV'ëæ/¾9;kEséjãLÌ|ßã÷;&Ô[û á®ÂÒ_6B¥E¿Ê®¢wÀ—Õ¼v)£™µWåw‡XO;zpAn…‰Šþ»Ö41ŒO>$,_?¿2’›mÀ4e\Ú¶ÀÝýšSÏa ãåPWbeGWý=‚Ûsõ8ülÁ½]x†V’²“5!Ù1S€‚7+ý‚œ´X¼RUûôˆz¦Þ¶¤8;-½Ç0"ôv »§ïp.‰Ä×»B¨õNåyÞ Ãï§óE^É«» ìÅ%çÞèÙ êÊÕŒâ›çRææ”òïi ¬ML÷É87â诺9ýèî¤NbÝ2t‹WÝsT{´$8˜ë§òüŸ-ÈRÃt GÓh¥ìÈJUSÉU °Kˆ+.´By`Ö-ŠQ3gföÄêüQCp +c2 +øJGT˜âÿ§ :ÿgÂa + œ Ý£Àá²&<"ê¶v| `PÐr‡•þÉï(*È?$ºÁt÷ùG¦Ò=“®ÿŒ·õ:Ã,]9Î ,2wAÛÍýGu¤Vä{ÿɉ݅N RWÒF¯;ÙߣˆiϤUqÕyymõtÐЌ͘<d1b‹ND¥(I0}oŒ¬O@Ñ)méEåª%5´ n¢ÞÙ°â–Ÿ „Ó•›Ø-Ö¾hiÔÕ§¨”û|)ÈÑnÿ]:ú›Œ#–À7£“$ž@/4ª\Íy(<Bf¦;z”šSÀ¨×¶ä^3^ö¬ÁýJÁ•6šµ^áñ•îór}µúÍ£ ¿ÈFs4™>‘F¿}ÑFÀÛÁ‡J¹º’|µÖ¿¸ðZ»l݇\ šµrü!NTã“LW +wZéðÑwuɾ{Á÷Ü<
Ëb¼ÖÅÇ'Iª0 +?å¶ ÷Ð9ì,ó +Žµa‚BØÇ )“VÝíµl +Cp?zõ ú+¾¬P\þE8v¿DœÇ<Ѫ ñqNš`wÍÑüûkàC¡QP]š°_œ'ðaÛA<è£y<glÁRÆÊf Ig»r$–AÆXEœoŸ{'ÄiÀZÖ´ïX<(£ –²®‘mšŠ7}ö Çÿ0 \Æ‚ryJgi+‘cׄ=,ð¼{5ͺœGÚ°EuC€ §Ç +e1ðž6¨ÒT‹‹ìo#ÛS·tЬ3Ã'ãé7+>kÕ¦ sûÿŒ–Á¿ˆöꮪ={mÃÅyÁc~ÿ¶`ÙséÉø9´œßçÀ©2™uIžµ7ˆ á¶Êu‘ôÜ/c"çí~_OIïk8{µ¢¤:¸Ýô‡²(š÷\QßZå5 (²îÿr¿óÒÆÈÄf4<W=A±æ!ù$sF¬E‚û$ëz=nÉ}lVJG •XG²a +ºr”ýW§F»@1“ÛËí§BßCßMdÁê`É#3綗U- ±ÿ5e(¿g%ê‚jUÙʆŽµÒ½&?QÖú÷Yô +Q´Oè!Yè…¸‰ý©‹øžÌzA4`(õm —R¾_üÞãW6µÇA:1<à#EY’‚vªÿŠ“ÆlâÁ[–n&ñÇm̱ QO·K7ÿðÖ&0ËázH»/s»éZÄ +„ 0`I™4#pv +Eàf›ù*f®[u÷z‰¾!9 ü6ÌÙ +CÒ3ÉwÙ_&'€›ÏìA¿.ï« ¸E
®wð“3e©g±T×ÎŒ!ÝÛçC4uº¹už×Å›ý 4Þ7’Õœ±¸2¹¿3½¾„c¶"!4¦ZŸY•›S>Ó¢<€$Lc'occ”÷ÑçgØGwtm†ÉEAË9Ë?,râÃyç…ÁË@ã/€7-PÕYòÄ»¼×HVì çÙ4aý̯ø¼!9²R‡KHàP'áX|Àú[ +]Aîú26ûZSQûuR‡èᲘ¦)95¹¥#²B=S\Ƽõ v·CW×¢)&wÉíâÙY]>Fª¤º0F +üòãV a ï‚-Â}‘#Ô–oÞ >ã·8'…SJ6¨î£’s¹5Bùè,͈®x®*·‘|â¶\T˲PÝ0 œB}±n{ïËPò#í½·/¬o‰.4Vz´cš×ÌÐû_t§ô–¼’ßÉspãMüƒ +Âý,š«»omž§t~®»MzEåQÒZEƒ5tUàÓógó´iN5u}3ïÌ ì±ONâiZù +or)vúm˜„Æf|!¥œ*¹Ö~Â’Y]µ |þF¡œV +îêõ´ì“&©jåN[N/¸†³ˆ=õÞ~¸kÆ~?Í¢ðH1{Ì)ê++?< rnþ›ò˧{Yb€œ¤ 'é0@¨u–-ä¿ øàðDxÃÂ"‚aaÀæíÀiendstream +endobj +624 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 33 +/LastChar 125 +/Widths 1346 0 R +/BaseFont /FNUUJC+NimbusMonL-Regu +/FontDescriptor 622 0 R +>> endobj +622 0 obj << +/Ascent 625 +/CapHeight 557 +/Descent -147 +/FontName /FNUUJC+NimbusMonL-Regu +/ItalicAngle 0 +/StemV 41 +/XHeight 426 +/FontBBox [-12 -237 650 811] +/Flags 4 +/CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright) +/FontFile 623 0 R +>> endobj +1346 0 obj +[600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 0 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ] +endobj +617 0 obj << +/Length1 1620 +/Length2 19156 +/Length3 532 +/Length 20062 +/Filter /FlateDecode +>> +stream +xÚ¬zSx¥]·eœTlcÇv%©Ø¶íìضmÛ¨Šm£b£bÛ6»¾ÿïÓ§ŸÓ}Õ}.ö~Þ5Çœcb¬µö¾xɉ”éM쌀bv¶ÎôÌ L\ +´¶³·Ú:ÿ¥øTÎæ@€©…5 ,¯ ))' —SˆmŽ›Pp1²¶0ÈXm€Ô +Ë(gçü7%€êÿMe†ÿ>‘ÿ$þoø¿EÞÿ?qÿ«FÿÛ!þÿ=Ïÿ•ZÌÅÚZÎÐø¯ ÀÜ1 +Hk + +\P3ÏØ©®â%ª«Q¶°sy1*õŸƒð3›Wž®õ;7 K³y²mÇZÉh\HÐçãîäÑ|Àÿ´_˜D ®á!)?¬oöër$q0>°±ÏO„<X) +V¼TC ÝÐÆÕ»ýÈû]…:€n&)‹ãº}°Äk’…ÀUꜹþ®æSM¼^ž“O›@õò.ŽŠå†"5sÝ€ÐV›¿eXšÑÎ I´Üû‹#k•ÚÖ®§alaUÑbPh¬4'Û´~ô2 þy×DEã) +É{<D¶¤
}[DY¶¤T±ê-úcØ'Ÿ[z‘.J(›ôb#Ö¹_{—Újå1ãysœÃ +-0ñö® ˆ(É0fö‡óÁ0–\ Â9Šüµn3ÿ>J¾™ Ê +Sò¹ °žô9w:%x ?RŒ¾÷å9:…œÖÄáöýŠÞ‰M b*x:lô -1Y+„ -0ÃÂâÒ +Ú8äWó <'Æ–©läÍM*iÞ3E2 +r &Õ}Y ðù0qLW*€2V:ãJÙ™³œ +9O¥Ýò“O.2&ÀŒp&'¼(5 +r ØàŽ:—UïÃ3;&^ƒ H¾÷Ä¡@\³cöW¥ËĤo9z”ðq£9ÊÂɶÒ]èä´|Í6ّ͸;këá²êäQËÖË”W¯˜›} M;¦ºù“ +nƒ¡”CÓÓÚëíûDÌuU£–¡b½³i»´lÜUšd¼mîRiSgC¡-kÖ;Uõü§3ƒsèº(sT
ØÔw{vUˆ?*?Èñ'f27ØÄbLà×I(~o뜫’°P/>³ŠÖ²,9Cæp6ª%"Sš¼ä¿Õ +ý>Óv¯"žKa†dLWA¤ ;a#
>ûëöêÍ¢®Ú:¾"
)¸-!Ó#Kþ=ñ]õû3¿fö™ † › [ý9‘3Q"mn±`÷Hé-ɦ
‘ =]“¤GÇëÎ'*¨j
¦—œ1*\ +Úâ\ô3†JÌtÂD†‚V¹˜=ŠÛXüh¬‹:L›m8}äœZ¢Z¥UŽâý“kZM<íYáʦ¬b”Žnhuë²fè@–KüT‚GÐ_2žŸ=\kAõÛ;Ÿ¹š@tå|#Žì¸bK]˜ÑÕa1%• ÓÞÑÑgñ÷½«É®,Ï |ÒKp(À·ê»²“£K ¶z7÷›Xi!P0L#‹ +K™ázŠŽï“ÕOG‚î +é5[¬xv”C°‹S=ßPWâ±GéšæiúaÒ~öäÁy o¿ µþ¬ís@q+@ñ›¯0/<ϵº¸gÆ+útÊEQ”§ÎOƒÉ!qÝãÉ›¾e“Ø;E†èÏð‘#VÃèlµÃwÛ‡ ¥Y¿ÜºDöâã§7™“m*<„"É Sé0 +$¦äh]™!î;Ö¦ xµ;5rÀDW’GT>—0Nzœý¼
èè8FÃñ;Ó‚ñ-ßFIüëJvë~-bñ¥=`°Êvýlö¸E‚æ!Äím â /º=ü1Ÿ/ˆÍX)²È<w×Øߣ¶ã™÷‘/‘Í“ì%mFÔÈøDÉÄÄRߎpHÀÒµÎÍäŒÊ‘
"X9€ãv-Þsçþ
æ¢ Ô'ÕžQ›©(Â8ø„˜º“ lŒO!âàºBw‹IËd !¸_a§\ünÉýùâH ]«y8û"VºÔìJ\+ ;£´ñ¦LÖŠ
ÚhHõtñ¯^v÷Ý}²p¬|ú•¾<îög—#á5ñ¥ ;QÛöNW³#M²Ž#í³?Ð_ÀöÐGR¤0\.%B +À”ö¢+ˆÞ) Á÷Ð?ŽGíL€êd´-1ucÊÅå âzh4${Gg¬Øÿò ¾Æʇ’NÌå¥fdã€U{h%õIí®Ïyö¢˜Iw¯e,á#ooó§–Êù’¬°<ã5quèËîЂsºêJ&ÆŠ ÙÈ…_+LCi¬Å»oGö"ÑâÕ2þn¿ÆÇjPÁ¸:’¿¶XS0`ÕÔ*‘>Ø“}‹ÏÔ»•…w2øÜÝO1<¡½¹†’Œ8 ++ˆC:S¡€5‡a|°k÷gHƽ´)2t•§©oš5O}ÞÉ({9nŠ5\·iøH@O°·ôŠB‹#"—r;uî?Û܇X©>pŒßú’•SŠÂòq¾Uãt´} õåùb#1,Z±jçX@7¼ •§ÉZ—rc?™”AUäûÖ»+[ä»zÄ+G ÓÖ_ÍÎðv_ Mól
‰YKW£ðÌ”‚ 4vÚÖ©.æÛ™@ãÄÄý~´¥Ôx+3Ê +Wi7í”rU¾µ;a‘ +ž¾\’’ ‡†@™´DÍ_7w[}æ˜ã£ 1™dªÓfGÑïÙä’e¸¡cî–\‘Aú”÷G¨ùøã¿ÇØs£â ‚|cˆ¶zÅr}¿¡5o Å_¯ÞðP2þYìŒR TËašÚuAC¼ ñÙEωt¸²ž5ŽèÖä~ì¢ÛœD³ÅD“Ùµ”ê R/ÍbÕeŠ%Æší ®*²(D
lûUczﲎT““)ëûm?i&lëlëWà<ÛZ¸ýd´GS€•/qV N“=ŽÂÚ di¼fÑa2ð ú‰{Š›âÄÊRm!ƒt‘Ùé7p‰œ„—ƒs;ï÷ÄŸ¼Ý¬ÎQÎ2¬ fqÇf!>ZSäÕ‹Üq{ àðŠi^ +Âhû'zO`Ícõ¤õ0P±rLYβ›G^¦È¥Þ#©ì +ºR…ÒBnÖÂϾîÆ¿ +y5~Psòí>x7ªU•$峀ݪü´vƈ´5@àƒ³ä¡ïý’8JôF~¨FGÃü‰0¯jiô …q°…Ü€õRVË#»“é ¦mV!‹·ä0B0IÅOا$—Á4à¶]ãN áÙv™Ÿ—³#1z l»,¹ ãÄ5#\û‹zQÜ‹Žïi¬Ö#nÝÕ–¯µ(¾U¨“„fp/¡Esªjˆé^©n6 „.ëÖ^+"®ÏeV¾ ¢ +8ðÞaí"Œ}9£tÍ\ÿ*÷Ü^"ªs/ü.Äöì0_ +ØÁ({0/“GÖ-m«Ôá>ñÔ‚Üb¹ýQ»ðÖk¦«Ô «sö28¯âªV–Ñþ$JYÒ3ñî—ðZk‹w½¥·BJ¢?mÁ¢`g?% uÓÂÄ9§‰.‘älʤq+4ìcXä_¶=né £fóѸ5){_Ð'Ëš”sO+Ú¢{~Œ¹#Ï\%5ɸ„êdʺÖZ ²¾`•[%UP+âóJ¬~g½U8n( ö
£ó·( £Hž7á$m¡D¹µhOëHíW„;hKÈß8φóú †H~Â$+·CO‹-yÿB©˜R"g[¹dIP3(EÙKµSÄcm% ==„ÕÅ»ÀrpÔÕRÈ q¥6úà +Ú,ë…4|¿‚
¯Yì-EI—m4’ªiE+D¨ZD2£BÌ%Hݼ³‘ö£~·ã»]bË 'ò|ŸÞtÿ½¢P)¯…¹'ÆÝ ±¿IÒ/)>€j¸u ™T-gí’;l´Ë'ÿ(sQÉd #r¹ÀFá3€m°¨^LuRñom×7ÿ\ _+3‘ñ›‘¢Ä1öXá +^õÙ´ bš:®Ý~ì +fÂéN~aŒ? á°¼¦‡·®_"ÎI¨}˜ÇØöµ`u7ñ›9“p°”¿MûKJ¡m +|•nýÒˆÚXýyaݯℎºé„J‰ÇI^}m èD„·_GN¢¢óÉRs±ì}o†| +Mö¨Eçe€z§½Ð@ñômú³”ÞÇŨ¶¼+D쇕a<¯‡»A´’– ¦r³S¿ÀóI!/LÕ¯GK^X"âQ¸ê9µ¦›µé‹º +Nl}MI{kIËJß. ¿&ëƱʟ˜„èºã«mL²´,\…½´PνᆤyêÑc„MJ/›ÎxÎS,‡ñ4C«uÌJh[Ž0ïoZËëûo=‰XR¯ÒFl0JøÓŸ;ýQ +0ª‰ø³»À5F%n{zY„v¶näâk‘†,¡œÊ}¬©©ÂåzŠ”Ý/ð)H\ +á ·óGÿ-ãæÄ`öS¢ç¤^wS‹6ÁŸ ù×õÍÔýˆ_h±rà6zó|:è X£«~c&#ôÈîhzó'(Z {+<†r¹P®ï’8%·´ "™[n—hsè7ßC'Üo³íV¤æYò›Aè| ÒHnŽµÉ³“&<ÆÔâA—„w#ŒNH +üzdùp»ºÇºû=Ì3j<óòSàìlúÊÖƒÛf|µæÎ÷eìgûÝ™0±H{4Ê +
Èo÷mxÖ ¼þÒ‚âÌ×åBÍ–9Nh é#Äy»Ò«Ã{ÄÈTŒMmS +î:Ó¯+1³¼+–ý 0§ŽÕ’Ä:[”ð‰d覹,J„ŸÒNE‰Ý Ï q5þ&ÃîVwmÌð¾ß;0´Œà0»’Âóüֺĩd¨¦M ;
ÛMM;4²¡>š/£û3/r3¬Å#šÙç¼ø•èwW˜Õh)¡ŒÃ²Ïæ¼³öFlò„ ºWR†é^mLÉŒÂ{ðsLF6¨.ûžŠè,¨ê z¬·fo ++ý¯Ü—Û¦@¼kn‡–°‰Ë-ÏvCø +W²žkFV옘r ºË^ø¸ábçvœ»š±¨K?u4ŽP ¢+‘ý—ÃT»¸ÇaÁéçytQ8árj”ôH¸
¥²b®I5íÀù¼Uù¹Á[صuuH ´éêìœHjûµ{Ã">gf'y»[8. ¢|¿lA˜$‰æ¨èH!K¿»Tl]²QãþßI +»y¼¯ÈŸùt:Ùå6 +ðš$3:ÁHªËÖx×ÊÐùŸ'O&©>“ús)pCŠê–¤‚埌Ÿ÷dðqøÌûúçlsËçÆÓðž_pUwôûß;^š”ûÀ¤à<“¤TµzŸÁDEdká6]A=5ìƒË "ûDMOò䃛½%[êÓ×*{=F¹"ï£Ã? +‘X E†™xð†Itò ö~›sóUú ˆ£©Ç“µäÍC]0𬼕”„€¢
ƒÇ‰?§×N®ÎA Nš±D¢¸Á1ø=Ði!íø'(ßMêá—ïRbøÚá²áCPþ(¾8Lµ:$PøÍ¥×èX;—Ý1'?¶dUou±K…w õÔˆ“x4êºÓ»Ÿ*Ä·"+ìiÎU k|º;ÀÄZ2۽̹ºz×óä€ÍÍÄø0]*bí ¹àżòªìš16 +¾9¡¶çÜ@Oƒ+'ÔÝ{Us~Íxeoèí×}ÔûhµÙ<rã. +’/=ÿÀÔèÍD± Rî9œÓd -(‚*’NE畲é^:,SÄÔZR·âj ɺc ]žŽ’´’ ø¶V ¬µ=yf§F>Cˆ !AÿqøL•z35G0ÿ3TxY¤ñYS“Ø»äOö –VÆÅ}¦×ºXGˆÈ° vŸ8»úŒgŽŒ‹´ëuZÛ‚ì@ËŽk¤¨éN“ú|›EILœpöêñïDMfG ÏSk‰úº ÀWVú›õˆ< é5§ü”Kù iã“#OiÝcäM²RA+Õ\ Òuä8/)ˆ3ôž wû›eÈëDñ9æ7 «³‚Ü1µóL8”(µåD:lU
Ùg> ‰>ˆ“9°-A–ãÒ +é3ž¬¼·µ9ŸœJ#iy£LCpøWØJñ¬fHêÐCÚ¢ÀVÑ
é^¤Ç‹oCÔ‰bêb΢Bê7A”$qIË5iÔò`ŸØ LtuŠ·ÂÍ:Y‘¨:EÖìò¹fì…žÔ&Îœä? FQÈ +åF¤ zÍÜ-E¬%õ@ÄÄ: ƒ}Ñ„dœv4KÿÈ«Ùø€ ìîrµßõ¦…!Q<u¬:\ ƒ| 79l‚MVþ˜
ªfç·„” +[‰Wèû áù©>«OæI¾¶C‡KV;%Œä¨ðò%rÚàŠ™"ßj@d+ËÔ5z¢fvrÃÕ¿uõzÆ‘¼Å–=]çÿ êÌ
ikðšv)ÝrrÊJ¸ +¥¼¢ÏÉyÓ½¼Þ2Ÿeþh +,ÏsË(ÙÁ½Á .(s8…›oAΖ¤*êæî¶}‰ý'·—õ*ÈQðUXëjúé›úŸ8æ!õ5* |÷,ÚÜGïËopŒˆz´¾¹øãGRê
òù«M³t³”–ŸLæ
At,c…Èc¾7]Aèùù¶£ÉN€ºÉ + (‰ª¢û.t<bÎ2o;ˆ}¾â³±Ãã¤Ib$æ‘"é[” ‹ +Žìdh +´D¨1a2(iégµ;x{‚7\©A0‚’yyáóäVv¾ªÙ Dâ û:MTƒÔ’í)‘rrê7׋?, {œt˜O3q‡©r¥…Û”çÎÕÂLéÄ*ÝûÌò¦°Ã³·¥À1`äuÔ›¹$pÔ …RûmJ +‚¶=ÆŽÍÉnù-40 +7{¢Wk¸»× 7µÇ†»jåË%‡‚óºÉ×E&¦ ܦžüâW†gÔ;7ŠÎ[R'P¾¿ÝÈÍèÒO¸L^¾óuYÎ6ûÀj/ÎHÌ5¬¥ØÔ¼ºÇ`jT!I9%f|°‘"XÝJî&3ýÀþz›&ƒ¶q¨ç¬&6Žäå ÙäcŒ˜L16Zó 61GŒÃÛ).1äÔSz‚(ãu— -ø(øi~pçrYÜ—6^
õ\𛪗.ü]øš1‡½}l¬]m:¯|¥?D² sWFÇç¤>§Èù›ýtÓáX ö§È%¦‹òf5T]ĨX;ÝöŠ Ö–» ¡Ç–Et0ÞÛ8ë% +EU¸ò€d+uQꞥ z²™j#™f‰« +ÊË'5lZ)c®wŒë¦éCD(¬G©ãe²µP³´5~PÏi¶L™æd!ɱnO;Ë}i¦$²AbDµ[¶¿o3 ˜g³!©\#ö³FU¾-Þ¹ÿæí>ú9¤ 2áUÉkûª»¦|óíDIÀÙ Þ@ ¡Ä +»_C¶Mãl@â:}j·@Ý´2¥½Ú² •¿…à9SäfƺyJ-gj"ôøÜû4A±ƒÿ!=Ò]¥õ"/ïäl•N»" ïQE¨û]'œÌ¤O™|…KÄeЧXšcõ»³ö ûDCïJMÁ“„‚b` úÆĦL$ýšÁ·™³4"Â-c ®'•–äÇvŒZ•RæêêOÍ/Ø5¾¥lÌÂïkiLÄ Ùf°k9rÆü³š#ª¿'•Õ +052BÍ6¸~ëϬ*“Þã“׫BL^x¹bÂ~;ý°^0æè
Z±!拵Å=>÷1 •/µþÁ…Ÿ9y.×›kôÈ ÷=r¼†=Eq‡q·ýçžáБš? ÃMÒ ,:ä§j4rŒ
E¸ÅlôÍo Þ¢‡5fBµþFo˜@ÓÒJ1xÚ>véÙ!ùl"Ô> <|qbŠúÇ”›_BŒ=÷úÖÏ#ð4Øvg{ÎŽƒ`#µ“‹ëEB1útȯ _y +ÐV×p™%V ˜5ÞÒîm08ÂDyTø¤—ûAQe +.Ú¢6‰Ài¤õ™qUÌGŒOËç”AÙ•B¯ß8¾?‡6Ë5yª4VBô@ý¹ŽIÉõ*'Çïy•Ãˆ>qѦB-z¿:ÙýW– ÊW‹;_ºdð°
«&µ#h™8†ÊŠ®Išëmw÷ Xg =sSi§ÅÄ5ãÈôÓKB?Ó›µTÉÌ]~ð
l{ü(Œs`.¦¼o]çè_“3x¼ê_’o 9å÷×Z•“ÒêȨd6Ê +$bðê0eN½™•âÉŽÓG2f*Um‡}÷WEySV8!#CŠØ§¯é(¥½óÁ9¿;-Z [3ù* ³ôVžüzãa¬ïÆPcÑ +‡À/Ä‚u‚’í|£.襡=͋¼ÉÄ38:¢•¡j-rç·
Ã(¬¨ L8;çFû>´P]bð®NX1ZÅy.Ê°>®®ªŠ³F7”åõÒ÷ý!ù†’½²ú®Y ±¨Ñã?S×ü‹žÃÛ¡)ì(ý&GÔ ‰]¾2 7t‡{Fn*+i{wBŒE0øÕ¹žà2Ý+y y#ÏnÕ 0 ÊÑókóôìN¹‘૬¼í4Kã*ìŠÛg§n4L”l¹{6‡Çá7t¬ UË>_šS .u
á¬r`<>¸ÆÕ>ÛçïWgdØô’Ö³2å˜údG_ÇñœDßzn*q×ZŠÄ ñ%¨ó/F‡Fb‚öÙÀˆž&Ú%5ÄíÔRÍüÊgfêûWže‘ÞéÒšÏØtôük{øÙ¿b©½× 춨q¯.Y©¿Â§ k qçîW!öÏt£œìçL×ÀkèbmÝÑ:g= G½ÐLk·þçÛ#&Êßnø`‰†Á&·»" +ž°ÍXVë/h$S¶ƒŒ:Añ¾÷TS!Ê!Œ?Ì
¢-®%ÞöjÈ3”\uèD¡v»[M¯ TªõjW,‘@4\2‚¦Ür² €$ðã©Ü“ƒ*íÙˆH%ˆŸŠEgó¨è©~°ë +ýqž\Q\²Ã‹±ûÍ—˜lËûâ¸æp h]ß,‚Üžúòš¿Â6Í%•¢ð“;‚)¬¼*¡¹ÀÜ'{‡Éõ(ÍÜö\CÈWýÈîƾýÂÓË +†bJ6¾öÕûžõpIËÄZõ¶Ãp%}Eœ7*X§ïcáÄOÊòµúf3`#û¯é9 vq ñ„§x§p b%c»šÌØ7¨D³ ¤ùF|X1/§¬ñFÛÌxË./UÅß4 +ˆ~_È‹õì盽ׂR¬£ U«Ö퟼¿52Wëýà9ZOÚ$a߶mO¼ësm@ƒÏJ>4¹5Êe3iöÅlê<$ê;4¼&™’ãÄÙОiÖÜtþùê;^1]öÐP½†Ä +¨p9¹¸L NüÒÇÀÍБi'ëVên_ÖËX¼L+ UíZ÷¾÷\£–/ܱ šeý‘ne#x=XJ ±RúSô‰ÔÑ{£¡otdKaðĤå d@ˆ›Oà š595´ºà³Ù‡ê”¨Òõ÷ÍvJH\µè&©)rp´T{þ-mñ¾äšuå žÏ(t6#=êåV§¨øBKFôJ‹„vÍCÐ’Ã +¤ê +¾Õx;xŽM„}ÌÅȺéf‚øL¶Ãpr6Ë(ÔTà£'ŽãáÜ–½‰Læ‰=¼’cÉDÛ¡“â-‚¶:àž k„Τ/ýjº‰/®ÙÉŠaÑ¡&©£Î•4#¨–͸ÒÚ‹¦b-ùÜu¸ò ]ΚÊi^-6Š¹ÇºCè×Êu} M={ ØÁj"¹/¶Îž\].¼ÜkYèä$U6“ B¤l÷Jß"bÈÊ";„Fuj§&0$¼ò/Äé»c†ÈÌkñéP/¾I”³,[R!&À$µ'¾?Á¥1Öaи¡€f(9
ÿ&œÐò +EÉÃc9²ÎÄS‡õ <z™,ÿZ^‰»;ôAÃÆÓýÕÙRÞìÕËï³xvvZ6ÿ)~— —sÇéŒm¿ƒ)çÁK͘Ã"¹æhae™MH!Oî1¾ÂyxÅ aà…P£ÌMv]ZÞ…jTH™œ…ÂÍbdù`7ˉlO˜—K›‡h”¸%Ì›uŧë×½'EÙ3ú]ö@
ñƬ‘aÊY‹^ȸ"PÙóÂ(¿*Î8³h[d)yLšOãg°Èž f:Ì>(.&{>AY›uS)/âȈ† óôi‰‹V<èXÞl˾)jÊ22ø~ÁU؆ҰfNmi%:iš~Vò]moòãªkYÞB5òûõêÃ4º8Tq$1òUé¼y§lP6Ö_ó½c^yÝø}·øš£”™ãD6Ûˇ=Sœ/ƒ‡ªKȶº ‹áÆ#JŒ 0âüØoÛÖmf¼9ŽýS&ç ùÍ:\Ã<ä¢B©"H{f¢y®«Ÿ· d¶uzýØüøD…ŸbÝØ/”¿"ΦU_³µ/!0?Ù”Ìa£zêÙëDÔH¿îBqi›i–Œ`HËöCŤÇLéòñK'oùºæ…–à@(ê×-[„rh–H~BV´Ü4è¡@O€h‚œ±¢¶—ÛÛ/f¦¨–‚p[—È"„ÇzúQòüÐ; äš/èN@öµÇ¶æwÒ$é;ÉYP›:r=Ñï9„EÿBx'aËdzI–ᵇ^ÕTä摨 ¬-Xœ¨ðoOòW<[z9sá›p
ß:—¾Ûl~(æ„B²b ø>KƒSÐþ2•ŒûÄšåêx꼄JýX§;{B v + +¥&ôÙÝxK”ætªü«*Ã}Eñ($
kbAk² +Íï!VS@ù¯b;8
~‡ ÛUgžƒ¥ÎŸ“ µ~ÑÆìåÔú<ÂŽ}¸K ¾jﮣj„Þ²’ççIYBÀõ<K®ß°”—ÚQ…”S" Ð<™—ÄÇÈ ãÚnÙûW-úÕ9ôTæ¹£;4E&x%v˜ˆZ Éô± zÏBð„¿‘Á; Ž)ÎÈJ…5ÓKÚ(1d¾>ðœ{û Z„Ì¿ Q>3¬ +®Ã±U
,m;Œê* §Éáèï 7‚§¯¨»×¹n[¡Óˆè¶bÌž þ$”ŸÏid÷cvXqh@ú‚DmÛâÄWÅèôsÃù£í«Ó: +kÅAž—v|étå@òó0´U]¼Y¨ß©ðYôsÚ÷/þGûôý…ã8pÜ ÂÙqöÞÎ&ãì¬d 22Îv!ã rÙÊ9#3ûçÌtÙºÌã"{dd¼…Ì>ßÿáûÛçñyýÏß^Ñð%¥Õ“ó/½Þx+¢ç«À:C_j=ä ¦DÅÈÖë8ÍT\Ln Íæ¹°†DŽ%‘ÍÐL÷ʵûYÈSEkþý÷•,¨8=ñt³Ô‰¦EP& §!ÉIÆ
ÿ:ÚËítüF kû!®9:<ÚMÂÀŒOÅEàg€R&Ö¿_n›âTË1ê ¾ç·Ÿ[~òTýpD÷ni³Y3ÀÜ–ês¨½”‹‹Ôñõz–bÚzÍísÃú ëgša9ZlÈê_ÖmO‡ çH¦ªÇʬû%!#Ÿ£”ªÂ÷¾Ù¨ÙÈÕ•ëËÀå¾ $1 ¹—bT!PÅÚhº¡Îî^Ôˆ6ëáÐr‡Ý£=e[]t×w“ãŠóùzmæE DƒL%½ó\}°¡·¬ÿ
å„|;®–ÚRÑX +3 ŸÖrÿFíöJÞL–¿8ÁϘ/»«Ð,!DÇ…î<ÆiÊOµ SÙ”ñ£ÝT²Ç‘N#èxîj«»åuûoñ:Þ֧׹‹»ÄózFê’½Tõ œý +˜‰âüÝTRŠ‡ì¶NòØ]Æ_Ó”i¬ŽŸ_úú‘Å ‚¼K‚ΆÇSIÊe°µ{ˆ×Xsë(ÛÜT+ö®ë^º ++ •QͲƒâ„Þ˜Ò¸.É Ôï]Wpü½¯vëùëBåP•®ðDÐ8©ôNr°z¼‡ïæìñ6ù]“ó ˜Õ¥™ß‡ÄÂ9.æw™þÐ˜ÝºÓ +…%lÜOÍßc †ó‰é4Ü´Ê0K ñ•ªA[lØAuâÂØáÑÂ÷>DÙÇ+ø³û ôëófÔÈóÖ)ñÄIw‹ªè×J#4RH΋‘¯¤ÐÛCé_ﾈņkŒKº·mWfö/… <å"èq:”$±öñå”M¸уÜVý*Ž¼ù餱Î- ÎcH“í`ן,¬ùôO@ ™˜À<xc´á°2Š9L1.Î33µ±¹sWk¨g ç@B¯8 ßô+£@™Èv~¾”J©“öJ°ûZ€•0ÉDjëœÑ¾õ0õx9(Ç©Þ8×
}ñžûð» Ý<#à ۃ®ºX6GG†ßd±œÎ +lÅŸœ$f_dq_“ÉñøC–C'O§_œ„Í¢z™À7Í°5åAƒí` EûKࣃ„ >Ò„rÖ:«Í·ä—ˆ•Ö’"îJìK4åä NϲN^U©çuÃÌ¼ß !¿|gbTM‡H³™¢"
1WK‹pr)*Ó:ô}øù&X}¿³¼åð¡øúùDÊ’‰‰à†£/ÿ©“€óD-z°,¢L“4G{¨îwN +Ã磵E˜±Ÿºùxünôqb ßd˜[<ÇfÎ@ߤ»Pª p§vŠ,à ÈY·“›Úˆg”þ½#©Ø¦”üëÈ`…>—âI¼¤®;p»ï“‚ºúÈÞ˜Ôm}*Ð÷î7zžôCDuQÒé”c§„ Ë/οcÖ”N~?¾¨À¦Œâ~ Ò® QR__èeýrå +@¤õÃo_U¡;¤¢æªe?Z*½¿ÚOæËͦcZ¢6zÓ*î +€mK1”£»ãß:¹<f :µ¦V.sF»øÎN®õÎ îÅEQ‡gŒ‹uà,¥vz!ìuS,ñš#\¥€ª6KѯAÃIá)è˜SX1ïŒ~†‰<& ;Ã] zÜ)ZP= ëN¾Ðºg¼)Qµ°}¼>Õ˜z_# å *’Ðs,b½“o&‰ð]ÎÎì†Ò¬¦{˜± ãxÂZ©–\å .ÉÉ q™5í—]Í_ãÓ~w X~˜½UÖ"bg¬%Ì—ÊÉbÙ¶Õ¾VÂ3a¾$þ—ì!íL;ENLãÖ[µô(ÁzŠþÐÞÂ
:\¦oŽìÿÞÉðdþÌn¤j’Pïn‰“Ì{:}*PDvŸw*[ð@9‚ +Ô0a¸¦û[ßÅräÛ%Ó\qŸž]£÷Àëð|O-FêkÞ‹³€'‰Qö.ÊÂTqëÚĵ¦Îš)RžcÀ¾ôßØ Dã“V¶¢Å åž5yÔL ùR„wOƒù ͳ¬¯ãƲ¹ûx¥óuj2a™ dêMèaÁxö³]&e9õ};ªÄqÜm–íʳì $j´’V¢_yŸ¹6€W 3‚èíRõѹc§EsšN1}œÇ‹”Çžácž!\°1£,,ᄬ¨\XMÔ›ÖÁ€DÊŸ&ë«~9F=Þ'KJk® +ÀÝÏói<ÐÿiŒö? ͪ¾endstream +endobj +618 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 2 +/LastChar 151 +/Widths 1347 0 R +/BaseFont /VGVTRI+URWPalladioL-Ital +/FontDescriptor 616 0 R +>> endobj +616 0 obj << +/Ascent 722 +/CapHeight 693 +/Descent -261 +/FontName /VGVTRI+URWPalladioL-Ital +/ItalicAngle -9.5 +/StemV 78 +/XHeight 482 +/FontBBox [-170 -305 1010 941] +/Flags 4 +/CharSet (/fi/parenleft/parenright/comma/hyphen/period/one/two/three/four/five/six/seven/eight/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/W/X/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash) +/FontFile 617 0 R +>> endobj +1347 0 obj +[528 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 0 0 500 500 500 500 500 500 500 500 0 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 0 944 722 0 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ] +endobj +607 0 obj << +/Length1 862 +/Length2 1251 +/Length3 532 +/Length 1862 +/Filter /FlateDecode +>> +stream +xÚíUkTgnõJÀ+Å€€¸T +æ2M°hZ 䢘ÊLÈ@’I¢ TpE *TEJ+¥õ‚.R.+ +ž +rÓ(˜€`E.º¢î€zìÚŸ»¿öìÌŸyŸçùÞï™çýÎùœ xA$–„}Q™‚’A&àã ´¤ ™JpròÁ`H ²õf §'°”Q +*cßP;`LŽ›œq“Ÿ +¿2ç ¥ô]–£€$ˆ€%‹’À +憆¸¾žë,Ƀ™b³:¨oÕ³5ø¶ÆSÂN%S© .Äß7_üw6ûL&@…ˆ, + Ñ= +”˳gÿM-Bð‘Á° +º:PWjtauZEâgǯÿÅìis¥±Ë´!ì|b"ÜD?¼É!JQ:T¢?»WKŒÑY.ðÚo‰±ÉÈúrü˜åɳ™GËÃrwÓëÉADuJ¦fÞ ×•C m\Èâ¯õ¶Ìzìî¡oV¬ê_‘ÔlqXh`o=^7Õ×a¾Ø%pŸ‹ãRF× ÓÞ÷—Õ½÷Û–O*¼¼F0zí– ‡G”ûf®Ô‰¼Í#Ç¡É{¾h‡NçºiÕxÓ ßi-œ^ÈͪW=°ÏpLwzÔT®šÈL´Møýj¬)ñFÆpvÉÄW\3B½=ûRïumêe=%g÷†:{?»æ»nâgK›]4 EQûÜæœ<oÓ}/øç*0ý¥ÁtiYâ“r(¦ø\ýúñqß]X3LÌÞEþ¢úÀ–‡¥´æ ¬@˵7»|rž 1 h5ɤù+ÏNj΋÷Sˆ#î ×7”ÞÝ-}ÏÂæÛ¯6ñϲ¹ï “ìƾ=—bifŽšv†ÝÊ/Cžqæ–Ï— s^"?vj÷p +³g'Xu¥ ¼mÉÞ–ŸÈãdZD]L† ÔÝžU.
‹55Vçi´Ýö¦=úÜx+ƒ¦RˆšOædeóø›Â¾0IÚÖP˜Êçò ÝO* –¡‡V/K 5¦qö6=íu}, 2gžj/
K·]©†OÕz»O›²Ê-4pth~ËvØÉÍíâ#iyâøLJs|šÔ÷ÇØw‹F“~Lpé 5A¯nÌ›Hô·ÙW&~¤çÖxU—Ù;»<G©Ñ;Þ˜&µE?ïñŠ[DÛÖ·iöqI¹Ûㆠx&–ÜrÍ/óäd©Qì·Œö<§#f4&ÿŸ•ºqY“ ýc^68¯kùêõc šŸ. Ü¿úG#ÍEÙôí¹ÍˆÛãÕÁK^æ„<je[|óËÉ0㳸ÂéíÆ=®¦[{šð~Qê{é ë/ ‹[Xtñªö¢–ìKjmê¹zÔƒ®ÛygL©òò°²öŠ×J
Eœ|0W^Zzò#W-8cp¾WU_×Y3 Ñ' ÝÔU}ÌœÆD}G*¼Æ*KÙŸmü5‰®íc=ùe?åeJÇ“š&•]Y(»*ýñø1³¦—Ëy¹-ýÜ>+Í”« ›V=O¹±dz®ë±]½^4uâw•gã‚‘P]J‚§E`TÁåC‹?ÝhX÷B\ôpIBºvà(›˜² ü–aŽÁxÀ.–yK˯&× É<ñkÀÚ#úô´é ËŠú/ÕU¬
)ä45ÞaìY4Yÿ,ÅÙðMNÏq®}I÷óc• +endobj +608 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1348 0 R +/FirstChar 13 +/LastChar 110 +/Widths 1349 0 R +/BaseFont /VAUOWV+CMSY10 +/FontDescriptor 606 0 R +>> endobj +606 0 obj << +/Ascent 750 +/CapHeight 683 +/Descent -194 +/FontName /VAUOWV+CMSY10 +/ItalicAngle -14.035 +/StemV 85 +/XHeight 431 +/FontBBox [-29 -960 1116 775] +/Flags 4 +/CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash) +/FontFile 607 0 R +>> endobj +1349 0 obj +[1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ] +endobj +1348 0 obj << +/Type /Encoding +/Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef] +>> endobj +599 0 obj << +/Length1 1616 +/Length2 24746 +/Length3 532 +/Length 25639 +/Filter /FlateDecode +>> +stream +xÚ¬ºSek´&š•¶Í•¶mÛ¶mÛvf¥mÛf¥mVªÒ¶}kïÓ§OÇé~êÛ3bþßÀ7þ±VLRBeZA{#S1{;ZF:.€ª’º‚¡¡‰¥½ ’½!௘š”TØÉÔÐÅÒÞNÄÐÅ” nj1501999¡IÂöžN–æ. +0±tv°1ôüû/˜ƒ“å¿i¸:[Ú™ÿW4 +õÿ¾SÿµSø˽‹Š§ÃßÔþG)²ö&ÿóðŠ½À›–‘
@ËÄÁü÷Ê118Y˜}ÿÿbü¯³¬¡‹“¥@ûoÙ Œÿÿ?žÿ:éþ7Q;c{“¦EÙÅÐÎäï€ýOÁ?jcW'§¿¼þ{çÿýŸçGÝÔÔÃÔz}ÅÞ˜;Ä*=+Ã¥ #odJD{ Ÿd$Ô¡¬I¥¸0 Ö¾Ï?=âg•ÁG](]ó ×W‡çò™ÃçÕáX?º
y_ªéU®/1å¯B¤-².vêà z½2¸Œsõïë%™ P-6µÃÝ)E%½Òp¼™.f'ÈëgÊ +å< (&.ÕÃè25)hTbp§bâßVv*—èTï/o;eÚ0 &±º¥Œ¤8F OX5Éávדñ9Ä– ªA àÊü<xâË…×i†y£Ýë*ÐAlyŸU9J’ô(°ÐƒcÆœÝÛÞn e£U&¥»‡Û‡è›‡¶Ôœ¥1áÜå\³%Ö)ë]ŸüHÓO6QrB%¤(úkè>·Sog´ mY²mÄl? dEŠL0ç…ÿœæ¿Ô¸Å¤Í Ùl\Õ–lfñm³lvÑ+bžþTê¢Jd‚þâ•*®%ß^÷%Mzú,yGºð¢È¨Nï‰ð,-’ Ó`Êá® Ø'J˜Kn árËÏÅ%?ÙÜ\óÿâÞõý#„-îÌC½Jœ n)„¦Á‚…`ªXS“.ôR°ßµPË,Ñ?Ž™·w©&|!ŽîŠŒ|Õfœ9 p-¡BÝÕŸ—þBÐ9’ÐÇ1#ÄÙ€‹ —i &®¼Úß= Ň’—cú²LcDvØ·÷GüS
>*²)œ&ü9?·»b“Ä);âxˆðpÆò÷<q{¬œ
šNبkßÄ^ µNú:v–ˆóO[PÐfkpÛìÓä…&懦ÅnŠNZË,¯#j‹ìeؽ%
üî†A°ÜÍBÚ<´ iÌItxÍþSƒçŸˆ›ø¹C0¥ òym)¸ÍË•o¬¿|uM¦C¢˜F±uBmÆÇåIZÇëB¥ƒÝÑ=úë›GŠ×ûµ¶-ûÅÒÂoñ¨&N“N
d—âCMwvh¿2 vYòj¢ W*œÆX•_ +£õ¼ÓíøZ +ÅÓc A¢\k†Ø8+Ff +%VQ&4«à\ùœÝ¤á×/)ul3ù‹—I] +˜ã“×ôq¯Û»ÎU÷«V’5¯…ªì¿à!ôù âr¿Žò}( šâ*¥›K r`ܼÝWUi-ÁòCò=Jª”´z`Ë ™A9ˆRzí†RDÞå·Zhk‚•µå‘Lþ©±æUñè‘/—R©ZC‰oô¯·‘²o$i¡nôóÁ¡L °ê„{e>«AtãSZøx® +Xf’W9wðc +æl®Ù¥èÝ}£AIS ˜çèÕeCkCh Õ " :Êâ$nOn‰²î¬ü›T1†õPXÅÎÈ‚«Hͤ» "ä ‹?gìé8ék@Mdùi¿ÖšB\µôÁÍ•#з4Í÷–ç¹tÔ‚©±* ×£+!·_§ +¶Ãp¿I~!½æÀV(®Ž·SXF|3Áq‚åh½Ím~Û Xã3w™úN#
’ L>¯·åí +D$¹\¨ q ìk[; $å;£W>wFc)F%‚WF)ˆWJd½‚L›Me©F}qyY÷×¾+¼¸ç ³óVRhÉ”¶Úþ¥¸â¤Æs¬[¶ÈªCŠ"ÔÛÒº: -«J™$ +&ÿ%hr½ÚoçLá3ï³°4:®ò¨ç“ë°×6pvh‘«F€Å*±‰ƒTêœWÏÁ ¼ÕÆÆ#®’Š,§~Õ\ÀoØ5¸Øgk¼ÁÐ<7dYiÕʦ|¹ªROØò5z&< Hú½Ü”B(îwâšÕÃp”Õ†A§êžé¯hï…‰’ªZÛeÃÓ¦{äÛ«¢ù}Ë÷ r8±PȈ½WhPÁ îŒ ËŸ"=°:³zã> ÖP¼ þ-´mÆfX´ädÄòt´ ÊD©Ÿx‚Ìr†u¥‰çP;õ j ÓzužØ¼ô¦F
"YµŠ†'–$ Y5häâ<<ÄËaÚ![.)ýâfÙL¯s¡Føǘ …ÌÍ þ- KJþÎ~Þ(™Ø™ôi.xˆÚ’øÓcºTQ[ CN^|*TOû;¨ :ãEò–NÚ–.›$Çòþõéº=òR€ÙDg1´¡øk¥Œ-ûÑñÚ”c šc²» ˜Ç:Øз‰ôœp¸Â®²:±÷Î PâiÈÅ´Vý Û9*k c-J|ý#$ e öy6?ãgÙ—šNÝÌaÅó3Z×iÑF?$‡Kd4Š:?\ôp¥ðYvŽRp¾_Ñ#Õaä– !/ ‰é6ã˜7(LáöÏj¾ŒÍ†/Cz=ôõ7WxR„àQrGÈ(/èñ¼ßômãˆ9¶À{‹Âi’©± •f~õhi5ÄRX`²\ãYq ¥.ܦ|ÌFŒÅ6YÚ„ÊõiSXI?ùêT•
ú×~Įrl„Rü°±SÆñŸ3„@]½[ÏŽýõ~_Œ r*Œ~Ûp’°7™õÇ2-û±ˆT¬8Ug>^-š=´é5Ö_¯¡oU,Žr¦õWÙª¯1 Çû: Ã÷°ÝQÀ°‹klRW&Àüq-î¿\bú›!@ïÞP[þ!0¹ºQ°‚7hh`ª1 ½å4 èÉ _}~Ýz——7u~+ +3ï•r¤Ü×\¹û Hj±Z9ôÛšWò0R1öë<üëJÃBU²æ©6.Èj¯¥SB?ú%ig-š ô"
Ózõg- +»µmF È÷06úgûFíÊ%;'iòºó°0`Í0“s*aÙ¨6
xc AˆðÄW»Û_‡’è{õÖ¬þÔÐ…1‰’6j† +ñJñ¶LöP£4R'Ç¡rkuÌ [Xñ1H'°à‘ñ£Û¤Ÿ"‘ m¼LÐAÈ{~í ë£Q§³Î•‡\%"ÞÔn¿ƒKZÖÕxKiߣƒEÁÅ-\´!ˆ|’ w§©ÊB> +âœ]qO%¦Ÿ™¼^– +éæÉçz¸ùëS %¸ªB(\ɤP›<î‚jßuäF4gºË »©_}VÞoJ ¶Œ[†óOLÊaYë)¨vZÏÛR"ó†ôµ4¥%)eÈöüDÁ¥‚˜û ;Ïhúg(—óÏ>’Å“àýßYÝó±‹<¾l¨1y-i•éö`ãx3ú Ø_š±ÚúÖí÷‚ï…(F·01æ?_y|P.Êd<¹91†Î…9 ÓÜVô¡ms"jHÒ+fkµnäPBüdI 1†Ý—xiµÿ„ ík#vý$b{ÙVv)+W¦dŽò™Œ“Û‘VöJd•UþÞ€ôÓŠè7V !KC.Pw¶‘ÙðNF/åó´žœ0 ºøÖCýÑ4söûÒcÂâ©Bü9+ןxDå>÷Ü%÷LèÐäpï2…âÌ2Ka .ÉfÏš=Þmi'ªn#Ú7}@G™?õ + íY» 7üTç¶Ù®©´!È©»5ad&- 5ìÜ°
+@ô«³RbHïÚƾñäuò±›¿T¤;§ ÑjÜŸ]q¸Kïê¥]6ýT½µ‰ù¦P°u"Ì Ý*p¯œ]D ÜZHÆ@Ð^Ä/x"sRCšSÊxVéûd zJãâeG»ÍwQE£5·ÕZ…X,ö²IÒ;ö]¦M~ ˆÏž˜0sßgµk¥Š~@
ëó øœt]+ +J9¦êhÉ[Aºª¿é0C»òc²œ=µfÞš]E©I@˜üuŽomÏ z£ Í¥#¨Ûw+iu” 0Ðo÷ +v<Ò„O·Â¸‘óÓ¼”I ÿ´õ™6ŸÜ(Œ¡ˆ|lc`kÖ‰àøûÅ1õ”¾JK¾àÕ¶e8KœÛBTÿíü ”«>ÏüoD2‚‰Žtý¯üW
ßéZFTJ +ú=úCÓÜY MÑÕÇÓ#J$ø_Ò¶jRbqš©Ÿc¶
G2Aê£ü/-Öt³/?¶Mº½´¯’yÖØg½h +¯ìØEV‹¤uíw üÔ—ì{’ZÞ䢜çtÒU'àÃùº'à(>€µÏHUo-XY¾tCßNƒÿ4Éh³GoWøíntOï ¬°nû‚½—W´²éÝÌ[¤´*KQÝ•_ŠFãLX¥hš|=Ú« nµ;)Ú^Û×™¯ÏÖÙY ”ðæŒÌ ˜vK€„
BUfC›ŠA…>¢.¬¶Á_BÅ13Á¢ñ-=Ÿ?£ n¦€!ܰ°›&re€ Õð$åŒKúÔx`:—=T"Ðu¢öTL'ë;õ¦üÄsÂxë9"§¥PicRQ#‹;Ðœ|§°lèö„¨jÂÓSdÎqSdÒB¢´Ÿd Ƙ4I{r¹ëKºÿ($ÉɯcºVUÉj˜3>…2==LN§p\zNO¼cð“6nX ‰·nLLgŸòåÜÖLh•ÒþÅnÞÆèÙÂÈâªôŠ«½ +Ò\¨4›± “ÙHIB™4ÍÀ4ÄÍ\Üidfùæý„³Ù••çÆLYmýNYv ž«:ÿË Øg$e*#åÕa>zÑ™çüƒä*:Šêþ7yl‰@,‚~¢X~cþžúÌx}tÚ´¢ºîÉàÄÛŒcšž+Ê šÝoŠúÆßÉ®‹¢Äñl…ÀD 0N°E· ¼C´N¨,
–t3‡H±aÓpÒ¯a %é 3L„’¾— (¥¹¦H„»mÏM,§ðX© i
«›dý îÏãAugUd=-–
þ‘ýkÙŸÉù_ ‚ЋÜøæuÂ,ªëöW³b°/ô l£³'ÛJÒIœ(\c º¡ýkC!7¸Ëtä¡Ã+Š•~O÷]Ii ÖÎ ›éP?áSñÀì®sð~ÌÏý1¥âŒþVÿ~@à¨sÍÄô·ð³¤³ªˆkSGÄߧðY”X3GB„ üIj5ÓÎ2\J5ÍIÚáŸwÀ¥7ó>MÅÒð‹¼”%¤½÷Xu´tYð"wàK±>,Ö5:™Í
œ'ÓûÊ Éïš$šPéÅ™emÕaÎh7‚¶»<ö]Çc6Ô}Ñ
„yÛŒ×áF¶º…[`w$ù#¼FcÛ·âû²XG5wžâé[ Ǿ§Þ€ømõ §Q¼JfÐ2hÒPÙ+š%t q“àk Ó.Ói¥4ôÞ”³·P<»
Чã'*€¯îËþ””ìôzÚðÔ…ÿ$Äâ¿"lTœÜÝA‘ãê…älOaW”æi‘?û Иñ2Z‘6Ü°7…úZê|Ôü9—Í#ˆ‡YE
B s
þãÍ[ã)YVîUuä½”Åõ³Îº(Ð{D¾ÿe»1i™ëã1Öu®| ã\®@sW12ïz·mL½+O$;Œä¾mÉu…™ÏXF?y ]¼„a×7f(üÙþ×–ÛTÒ¢äÃùݺîÒ‰èhî`(\Äƾ´5–$ ð²ïOÖ*µóŸËÎñÆö0àE…guÉØ… +‰Ë2„Ò,Å>Ô@BCRÑ;ueAíßÑN06»Øa¶Uy Ì;N.£ýÜõ¤4«%ræ›Õª6£eŒÔ:³ WãQ2“b.[o Á!ñÀv è2¦ïü¸à|ƒ^TX§^Ã/¨ã*ÂÒ+pÙR.x¢d½tFšòo˜šÇÄ_°¿#Ö=£÷#ªÒ›»"ž<DAW…9s,1ËÃUÀ€>/×ïͬävUÅoÈÃê`WI3wï[õ<;,¹X¬š£}y¨^%± ¤õ©5µˆ]ôO®ej¯¯· a"›LáÜ]¿Ä8ÀnÕ¨dà©PÏ[œ¢Auï9]m´~sÀŒ Ëó °¬&¹¬Ú{Éóû +oBší=Ñ¢KÓ·\ôV×±õŒ!ªEö¯î÷Ì«ŽŸ¥ÇýEWÕ’±mB¹_Š$X ¢Jª‘$â¨YL¿¸¶’Æ‚'¯ä½,ê¦'ÈnÃáå¨X¸Y;x*J_gÀåÂíìd²p\b’&“—®p×îšêà¬ìî—?í9{•¦,žýߟh-ã£ÙâYutX +–Òê¸e$ö $®á- MÖFÅØ…ÝëöýJ|Kü„#?¥®¤ìÈ#‚!Óp'v%`qÊ!žÀy‹œnäÎçN—/+‹.Ì"¬ã@Ð ‰¢•ým·a•µ‰RÙD9oe É ¤› iHÉVb¿†Ï")Pê`ò]^€Æ¶ T®†˜¿†§†- §ÅÛÖÁ Oó³þŒåeFXƒ$ÊS¸Ÿ¯÷kŽŠòÍ™ fL¢˜šëʲF‘9‚‰_«õï+Ê‹\™¿¢úƒª¸QÏís‘Ê ²H§ µÈ=ÉŽ±ÿˆ `# + ”—¦e•>KDØ£8ë<^=\üH93Ñ2W‡¡aàÚÃÉø\þAݪˆøZä¨"ú<¦åO±gVVS´je먌(“ïÂÞ°¸6EPÀfßÁ×zÍ°Ÿ©/†¥eÝ鳨7µ‹&‹öŠôºG2agD±ˆÀ|6Àí 9s
ö¦€Ý1c`¼×멘îªÙHv-Ë3ðîß‹áü«ACrÔÇš¼^ =YãZ¨ÐzT]'¹Û‚M Ïì™ÓbÑÚØ»-Ó®1eZ.Ò+£¦ä5Ú×#í7h ¿Øþµ.'ÏŸMï°òR¢ÔÂÅ+oê·ûåþhMí_W6"u¦ + &V“‚…ÞWÑ0{‚!ýÓ 2üqô¨_š?Yob| _‡™ŠA«¼ƒKµËà<<ZõÛfeC¸–óc¬à¼/9Hoäcóµäþ3K¨ô•?[àXçOµhsë]§ Y*“ëƒ5<F2v€²¥¼|¬r{%ÂSì(‰%ºÙ_üy~.¥Êpì ÅæGår›ï–Å ñ:‹& /ì}*û¸P6CC)+XÒ´éüÞGî +k¯gÚ†ÃâI1J8žœ1÷‰òõN ˆßñó÷¦ùèbTÿñÑ#¥YÒ T§O¤¨ƒï2;º8Лȃ[@2 +”¤eû”/Æk„Øsã½”“ ëWÀØW-7‘ÙÌ“&Œ
ŠÙSÕçY'9üÈm™ó÷úŒI»~Ç9ýɾ!ì-\Œ%h“Z56ys&˜a]¼g"ô¬ ȆOúC™])[EýtBNÊDThÅYI±£²ÈȲ&d-ëd¸q°t!çëìÙ:TÞÖj®›o/\(7B–¬ÆöC ýN²Æº‘”.U-'‡:1íªËaŸ)ƒßÖ½ÞÂÞë^#šÕ
õƒKÖ1Ö1Ê5¾Ì§1v%áïz<¾6Í8eâÝëÁîÛA¿nºüzf½$É×Y…\þþÍÜ“O”?-,ʬ´<\ÅÇ/+«S“"\TÓÃiY+†Vz)üìZÂèNdM¿ã›–ó³›ÅG
ŒkC\?™^QÅA±DNI»„Ï3›moFªõØœ€Ï=ö[´ÕNÅàRu4x}ªs +¦}Õà`‹›µ/#’ Êì)ó(ôŸÁ—
´fŒg§‰ßhð–;ÛÌsøV2Ú ƒšÚ!T³^ä´²i÷ Ðá©uó@‡ e‘ëü“ý*=î<³ùs<¹¸~mIpHèRÕÙ>¾í¿o D÷"é†dÃåv©ùÑøŒ¿ ´Â§¸“ ÁO?%cÅùoÑÞK«›àc¾ƒLÀùKè:+y7H³àÉ×ÊuЪhCtd8ü;|£ðÐÐT/Ô2,uÉz˜}ôÚP8ºø~úàµL˜î¥1XÓ…çE'9ìQWKöu@a2ø +}zˆ‹Àœ ë D1ÝÆ54º +²ZW™jEá&+jJ”Nr·°ˆZNj“Ût³ÅDwû+gõ(ê¦ÎáߪYð]p‚'fNùä“#É™’UŠÉ }¯Û))âO]¨Üõ +·. ';A^…
?Aǵä(_F%XybS¶Öiî™y6 +¼ÁjõŒ8^–ScŽ…O¥–"};J¸„1 8—šP£íÝFÁ[²òéMÊqT,ø®}«ó³1YQÍ‹ã$ð'ˆ[_ÜÚ üÄÜ¥l˜VX)¯4’ÍҌÜ)%èyjµý0Oê¼-ª ĈȶwÕ:¢¢diËƇmZ·]„ûòB-½_ëd“8¡4Û=ѴúK(÷ãô×Ú±Žÿ!>:*ÒHˆÙÂWæŽ!B¸ýË! Aȱò‡âG ù¸8íÃqWA‚? +ø E«µÉØó Ê\ +jGžvCÂÚ,ÿ»â.éø*â QÖlþØóR™äæåU÷Ù ;[å]w”‘}{·X~=dðƒ½7¼—æËy©Ÿ†Lâ¦q4ÇÐûr4Sg$ØE…cø¢Å!q‘F8dS}gìY?èOÚÛ–¯W_ü'¼Î£A9nc?R¿p.?t3G¿ÝþBîÞ×prƒp´Ô¹ÓV«§í¯á|»¹5ÄQEû^Khóð{"²µ·‡ŸÎ²ý®0=ü½NX¤é}±·ÅZõÖRÒs,ûïÁ7ýC& ¨ž–×ÁX‚f.ë½1l ú”0âu!–Œì·ýÎSÁ 69¨…îl¹Z^îØÏhûiR±oæÊw•¼™"Çý„˜’Ј”.Ò¢; …xb“LôLiÇø}¤CÈú¶ÈFe‰ÞŸ¨ùŠ¡wG¸¢%à°Ù寃áÞËÛ¯†žxÅÉts9ýwI©Ã¶ +/h`p¦‚ùЃþ¾nA´JWŠ¯C;ÜyúûV¹¡zŽíx웋(ŸêªÞŸ2Iµ‰Vd“7%ÈL«X3u”‚Ô¡\•µñ\¨ÁkœÅÝõ×ÑëVñD`„<òú%#ŠÀC.-Ýw¿U©IAÍ\¿eXÕëʲ¹8¾q4׸¿\Éë»sø?®(P=2r±> ¾)—x÷…~Ü¥3dn©å\Û-=âÁ_Iø´ytTl§w`˜»q¯eIÁ4š“é‚°§¹ô[K¬¯dV´ÏW~†å¬Œ¹¶ø'Î_lûoú7³rÍÈ<¹*Î]?…÷ ù6° ·ßIË)òzâÇt‡o$pCt$Ôó_dŽVè@2]FwA ¤‹Ð®Û€¸‡}–ðKÖ·'û~$ ¥Ï•*€‘þ~… º
èax̢㒲¬
\ÏBó©œR]Æÿe´úx( øêådKi7ö…•Øà§l@.q]®É%vò~k5öwð +$ Uù‡:ƒ sŽßHQºš§p¯ìn©"¯‚Nux€yRÂL +" a¹Âz£t°p[ÅH¯cAq˜h½>þ… ûsö ¡i®¡k%lûÖ.›Wz¥"*Gb&øÆB<Aza¾ØXâ«‹\¬Ë#9ÜY »é†vÿò7]î½(\ÚŸô*2÷v +°ÞQd› vèµw89’9.„[>;häe¸ c\_ë‘Yf`¢ÆZCº$ò5ˆÕn! Ûɦ æÞ¤sx½®ÄrR=*À@:×9ï +Û»%êÓfþ +‚BàuÀT·n*ÏŒ ÜóÙRF”àêkRà?
™mD)ÙÊ$¾Ã”ô‡6õÆcíؔʊÊfú[አ+‘HòGNè½W¯¸;¡Máן!ÒPÆAÞò?‘é©ú@ãß}{¿B ß”ZŽŽ2ÐeXk®ÍÑ=&"Òp¯.$Yªûïññœ´é¢q{ónÂ# K÷¼Õß,SÊ×z¥vçSÅ`/r´ÔtUnί¥IàÓé´{y{õ‹¸%—ÃhIËÉ3”27—Ôë¤"YOK Ý~Lƒ&ºA7?¾ð."nzš+Ø´z'î,`J)D—ˆ*ª× OUym‚ `•–
W7Ð!p u6†Æè4âœêq÷9!¯³îÑ3T‘!?9šFÙºÿY %ìär9göó&ÇjÅ-jw„ ‰µ??˜‚U¶†?3Ýö·5dœ•àÕ).b[yÀë53àí¶cÄEw
yQ}NdIF,kéAŽ…Ù¶`'9¨ÊðôÀϲ…R‹úÚ£?èôî¬lКZ6~N³{þVš‰Ï[Úp³Æz»œJ` Ž¿9ÉT¢cšåZ Xø»z4×Zul=Ñ6»p né´¿–KN +‘IÜ11‡yÔÞ·k—J؉÷ …Êy~Úµá*'t†&.{^åÜùÉuö×ßW_wûeð{2?X%KûN ›ÏÈ‚œ={T; ‡d}5ËŽœ¼u o{µÓæ®mEi7hRïáÈyNo0P2ûI8Õí'Üàü5FÈ5rjuñµãÖm´‰Ý5‘
±Á#âÓ ¹~³»''Óm=^mÌ%°ÞJU#Í?çgE||ë÷£}Hré ƒÿàVŠD6åËÌq^CLwˆ|Gƒén‡ : 0ኽæïR _ÆV1†øQ/Ú à¯ˆ¨`QN¿T7ŒÔöi@ÍÌ®åθ
»MÔEì¾ Ì´®CÅ 8;mžTí£J2«X8K˜èºí¿û³1ĆQÈ}ñ ÄU
â…îäî'&5«{ƒpF^¸G +§ŠçÍ%Vš›)|CÓîÏ9vÉÓôpXRH.…]ÃÌ ò›øþTu{¾zÖ Ú9p†a«hÿ Ž©æµ¨óž½˜Q\5KñíÀعQòJØysé±–W?yj,S=¦¥¾jCÃYd…ÂNˆ£¶Y<oò‡Ÿ¨çÝ@Ð.F9-EO, û·#,Ó•5XsÉt µDXW¬,¨ +Л|:²$±pà¡Ô€ ÕN4”Öè}|O¨ÈîÜO«„ Òðf^MÌæs*Ü”>HzŠb^Pkè¾ $Ôs1¥\ÂQü[ê`Ƽ$˱ÞÒNr·äæJŸ¾óáv½_ ·»~xu 4“õ¼P&;±¤Ï=ÓÇAÒógÁÂ_ |0™›¾À:ÔqE9®uÜ Ïqr„.aaéeõßÁûì6Ī/ÝûàtvˆË +ªDÌ1ñÕ ò X¿äzcƒ>2ë4c"fî +tQ:ÔÄ|éòýÞ~¾Ÿ/:Øü U` ì(› ËwzæÖÃÚS3dú@xN%jFîjüÚcZÂè) 8\"}Gˆö—}×ì0!ñÃ/ñŠFÙqhÕL`è_ +†ÊµßhÂĺ3Þ#4RÀ© “ì×›Q&êI([êt +‡Û6Òú×ë_ ‰kYhJÛœN*A?7ƒƒ~åjØîZ€ás/ä MTÉ:¾ãÃÝò¦³NŒ²¹é+ <í|0N<ûDCÌ2@@Ð"‹Ržâ‚4g*%ZŸóĺk‹y™OÁÕ.ŒZâõ³Ø×7ö<üÎe¼‰å³À’Šp÷^ú…*˜ U‚§äfäQÔÏF +ùf ¶Bïô;‹y9ûWu FjÁ
ô…Õ2~pls%BUî-ÖŸ^ 锆߇‡Ø÷q‡×¹Óv*j9•¬ï®£"›ƒ~¼cR;ôÚ™ØÕà„°™}tkà>9 +=%?“Ž·ðV‰üì?´ë|ÜúHä/§ _«IæˆrCÒioìÓ€±•£ò¢€<'¤tuÌΖÌdÕ«eM~Æ4"žôüO= hTQà xT ^,6§EÈ'C’|“à—-ЗŸA4ˆ#Ì %ŽIù.e›Ò“ŽòYžÞd¶tvó]³ß Dóßãø®åtÉÁÚœ 1 qHo²#^ØšÀ&šÅÞÏÐç÷ZT,þ”Ç=… ä9ΩµWN0™ §¦DÚ¨®–®«„¥Ä¿pzú6+ZTÜ=µ÷™{牞Êü)Úð8é=±¾€ÍrUW˜AÊ/>¤¡J»®_³]ï£çj’Ý“E¯û¡
ƒ÷Ò÷òÚkž‡…æxÖ¨u8xŒRO7#0'k¸×É ¦Ù 3¸úó+Ô¤ÞLݤ‰LÄ +Çžž–ˆJç\þ,ûÀŽF×T|©xöA4ªàJe "7³(ý ü±^|›üfŸ×Ÿ†ÁÒþÊ$¯«éFòK0Y²Ö oÔ‰ÁÁúSƒ` ÍjTT¨C¨¾øÆä¹<·}1L¹œ7óˆÙÑEÚäHµ×gÞ\
] ¬<Wk;†ïXm +QÑf +ã9@/h0i‘ý;뀽…Î ßE§YÈFCÛíù¡Ô™Ëþäƒf¾Aö5[Œ–0 —Úñ¬søKlá Á䢣4 0f\ïª ]Ç‘¾”û’àY/q!œArÍ ò35K‡¯¾ïMئ½*KšNu°×OçvdúKÆRk¼NÌlÜÍegÁf<™˜×,O ú~’Ï@xm š„[àšÇ«—2£d!õÓÈ…¾„77z–Z¯×8¦çó3Ç:ÔíeS¬” ÷#xY&‹º—º=tkÙ”œ¼À.€Ugž\¤†zç8¢ÔçZ¼íZJ +ïGdÀvÇ@?/ÐÜF𤬨¹CêÔ÷úžD¨ZÆ ‹éµÌ7”» ºÙ扂Ȋê0É " Ñ ñEŠkhµW÷ oT¸t—‡÷Ú‡á¿ówÖSg6;Ò®Yf1 ²4ñûÆ®-Ñ]£œœøÁêË.bð=ZÁ?Ô*·h2¨÷@f +ÀË¡J šu©öaÚÍærsOÎIñ{É«ÓΚh.ŸÂ0Ù®p^ÏD Dz~ZÚ¬ÑÙ}á
HàSѯ‘G×µX t‹”úg*(7(ìÑ#pÊšAL”b71а••=ÉkæÎ +‰ÉðÏ[SQOmGéQO”ùóú*sê9L¢ßcçý7Á.°˜XóØ'ð»h”Ëj*¦DÊsª:èÒMu÷´© $qY°$h“ÍFøñÙFÔV’È 3~ö3¾½þe§!Ö°Ù±íGaùÀ +™¸8œîLéÅYŸÀ-é§àê… —+²’Ù7ge\!d%ÇçÙ
/ì|F››WÀ3͆qD¤ÈúGüʯäŠ%dRºÆ(·½· ¼Ð¦†¾…VšL>äÀº©–•ùh´GÉh ¯úr¯PGáÒªÚ(_aœSå‹a ‰·ê 0Ù|ý P_v$kø£Yù%ùœ~‚:\á‚‚É–~NÖCIÂAíÕ]˜¯¿n0» «'‚pu”¢é·|õõ /@ҸȊ +¥ ³mÈ*¤t Z®œf‘k™Qr‚ŸiµYéJ–“ríÃ;¶˜”æŽ×uqµ lŽ/Í£ëûñQò3ÆNQé[!›`SJ9†v/ú9ï1ѹ¶qã~‘—:‹^º¨˜Q¥žcsö²¹¶tÃò³™AÎmé9 + «ó/¶õ<øvçsK³~¨’mxÒ£€'´…ðîðRûPȆÏé‰=
¢6X7º +å‚3Ÿ»¶¥+FL{‘¥™É¸Ê{¦›d wE<Ûðöuª¡b~$.› o1 PYyàZ°„íãq»÷ê6›Kw¨Ð@Òøm!p–wB¢ÓxÙpܾâÏÆšuÖŒP9IL“Fˆ ü“VðW¡˜N¾«5Šoé +¹;~—ÿ409±‰z…:Ƀ˲Ïl'ˆÅÉO‡:⼤ßTÿŸg½0Ö‘ãC +‰)`Ül®Èå©` —«dÛeö‚÷PÅ=õ>©k¿Ç“ù1UâÔÏÎS9¾ 8¦¸ÉÏh(óÛÔA»SmÖIˆUH~bóŠ`®õ¥P>ÊÛD²D£ ¾æ¦“³ÂiϸlZE ¼ jJ2à‹£®£ž¼òÑÆ;JäüÈ»Iúâòã–øèÑz¸ ;4ýƒoŽÕz¿ÍnÑŒlœ v»fºü±±7†p•Efí¤t”ͤêNy(IF(¼Á_
¥Î +’p6°’{ çOt\AŠw2¢VúaMŸxJäÑÈ®BZ骿² rL?¯1 + G”=Ëò…#†Õ4ä ñK"´µð°“Þy¿Ä½¬ãpÜ-Ñ[É~JheæÉŽraaî%7UŸÔòŒ”1², û Wæ³Û/¨^ +$9mhoàpÝ0V™/ +Í Ô¼¦³ÂØ´VEíRÔ æ¹^
hÊ;2¾'ºîGÂ"òåå㊻¥ÉG‰Ò½’ïÛH £-êí'Ee›_·á •žŽk² ȼ\éÑ,úa+¾Ð¡};½#&Sÿ¦á*²ôhP³Ñ¯sn
·×7o¶EŠbÎÞsî\ô ·oÛê ` +ò‚ +â†tãÓˆ'—%CVÓIšb¤–§µë~ç&à!;°ë-GÂÞ YÞœÇê+ÄNä‚b|—AtFÄÅwÇóZ;žÌfíáLÖ#•«µ Zzêdí8žÁ Ê,`Pðª°àògqæó ýhí¾>¾ÆþPÐZ7“:®fìãèrÖΰ¦xÑ]Ôãa‘s~ç»+Vúšu\X`…À䌜÷ǧ”ÖÍÕÏ îõ€4+3wQt1û AYh¯‰/~òÙÉøM‡ô¦ øÈ_—³•œi0!šœäjª÷yÙl±‚r€ éED +è˜(Æ|(h „ÈA½®îÈGs%ÛA’Ã+© Ûb2ý—¼ŠÊÆ·Íší hÁó¹)[ǃ¥ Ôµ ︌2¾½¡'ÔÃ,N]¼tâÕå[²u&Ô˜?!&ôP{PÌóÀ´êì0Yͱ=·ºe ÖÁ¸‰‹ûyŽÆ»ZAKÕª}-¬þäs3C:3 ,»€ DŸÃ#‡ ÒÓ¼°Ÿ)þD°;·Zßj °’ êp_$S¢¸=\<8âg(Êî/vSÈÍTõŒ¥¤r ٠ߦ8N‹‡mpl;û|~kPæiÀ ä?¦
ÁDͦœ1ÜwÆ#EÏ’dï"ñ`S¤!²ÒœC:lCÌô~}WìÙP–3")Z&ýn2ôYp•Ä: Ï~¢rÓu}²6dÅMCO¹¹6+‡$€'@®Mm`Å-º6V^¹SWnwFbJgG¦h_ +¼Ÿ'Ïû¨H³·Âë ä!ªEüñžë£?ßFïíÉs+ØšˆO¢)þç½ð²Ç’×QúSòiãF& v ¬¨5ef˜ï2xœÀPÔk»ã±5ekÒ;Êx¿Ï•fa?E– õéè•yMhΣ ºr yì Váå09Âf ¹®ÑÁÈ?Lö²©«’â¾^爛0è8ðvr·áj;øë{Yèâr¡_›LÐÎ<ë‚6ã‰!týÕÍ㳌+MÆ’$,ËúåIòrJAÏR§9sÄŽH:{ÇRÿ¹•FÜ]Šß[ñB¾ù[^¢Wu¸ÛE ¤89„Õ'ùêâÒIŽyü†ê=º—ÌÒ £6æžê :´:žåGëZ{<ï!ÈLãóUýÁ¯öå¾8)yÁ´²'ÛNWÃð#bžÃ««óXU›þ|>KÞ°_Ñ£(Z¯ûÞYåx™O÷6tB™W³ÈÊZ#Ç ¥Ù.W@£7eÌá=j¶ÇÅ[t›~SØÀf[Þ ¿”8#E í´KlkäJIó°ünQ²&»ŸäbeɾdÅb«B˦àJ ³…PçȽ#ïExwö÷ W+ü(3 Ü3ß¾ÎâÐ"¶lTƤ%Âç5™“˜ÉÍÌ|¢Î—ùªPk$ ã4·‹r{$‹¬ä— è½0 ˜ã1–ò Èm_—ö\ùfɸ…ìÄäƒïSÚ‡»
'93!Åœ,ùÏkÅõ®“ù³§Z`Ì:v÷D)™éŸüJÔÙ³ …6<åY¢'°~S渊ØNÝ]öËPNGˆÔ”F]g$p€9K† ûÐ:ÉÊÜ®fÙ˜N£o/¿Ò§Ð+÷TìxÝgä—J.ì#^Id—§jè›ð{O†>ÈÝqYãºUj +Vèp ‡—-,9,©Áz*[5í¶V‰µ}¶ÔµNÛK` TRøðôÐå}¼Ëº,5®¼S<PÍôŠ£˜8éà2Sr‰ÉòUŸŠ Z_â•RÛc¥CyÌi¼åʵ cÞûCTò]¢6rÄO`3.²€’Íñ –ïË"hz
PKœÎ5³SÜ žb9N§’:j‘ŒOÆà5Å7¤i7ô¡¦h9i |žÞ£p¯/ÕësÍOs|“̇MÅD§á
Ô@^wöÀ3VÇŽG@EšCµ'´Yƒ®‰(e¢ÿ_;óØ ( +Yø—E[ŒOÞêžMn ŸV¬‹Â¦‡Dð‡X7ù7RbŸóöo‚57Mß• y +fkþŠP¼Œ°á ÀBŽ)3Nå
Häš{ ¶Ç¦e(dŽšã-´‹qÚ¾óƒÿ’ö%©Ë!Ut™îõEÀ·ÅÃe§á¨õOúÄĦKßd&oëdã¤Lo›ƒ×£Hd—MÞj +”ËÚ Íö+$hpýÛnü¼¯/Uâbõëú$× +§´Ë¶ðp^þÄ—EÖþBÚfbwþLWw:³Èrš"þ¦UHF³Š Ñ9¢˜”Íf¬£‚}Ÿj_5)¸palê +’!c«ý”ý¢F)0ÀðJXÜ|—Y«N¯ÛØ¡ O1:ï¢f2˜³ë¡»ž ï¦Ì+‘L,xÂ9¢Þ¸rQÒ'䘞ˆ˜lÏF~‚æ—Ã?a¾Ý0YZùCÀQ/Èk ã4G“ç+Ž´,´õÔ§‰ÎŠ[
+gñc¦ÕŽ™¡Ü3€ä ˜î¸î +Nïƒ_8B÷Œý±?·¡R¨[œå7Ø\ë!“Û¤QIÜ](äãZ9/!;aßîJ7(d§¹.·òŽíÙ"ÁãP[½ô¯t*ë·ZŸÏu2ÖX¿hrG¢éùÞ¿P¹÷$plñbì%4ªÝù£7-ÿ¬eØuLôùôfŸ šZÆw¤–H9»S?à5ùö\¸$$iÄh±Àßj ½}æøè—.3’L—íçv"X£ÇŒKfd”v¿ï[}™<‹âÍÁ,Ô:&—â„) Wßͦ¿¾öHâ¨o·±‰@ ꃼZe2Þí1›È÷2ȸA@/ ½Lj¡=Ø-æ©.ò&ŒÔ‘þObw
æØ CJ\q¦û6_¼AÅèØJæÖ´ö˜Øë2ÊB÷
©zhÛúXQ½îò# ETÄÝ*lÊ6×ÖOéþéetX%í$TÉÊȃËrrÙË«³Raµ'p¤›€®Þ½Ðü B:ËbF“•¢õ”«Ú0dieš†¡¬Í|iÄYõÿ6ü dòžsu #EËên³ø…>°‡&¾%TÅÄêâúÔ>¡ )TÀ8ì2‹Rà?ì)œñÎJ“F7J
]ÚkúDG‰œ·^ßÂÑ$”mË8?äò›U–ãêw8”dR׎º™þ×)Uªžàa* Ç%n' +5”û´¦LÀu¬cA‹æ¤(ž ¯Ïú Ó/YNRZÕcù˽Ð)€¾¢_M\¼íöú£˜: l#¶Q_DE¶¶ü’yÓ
ðL©NlKõß·h„#£3įÎ/Þ>€ºL&?Ê6æÂc +sìm<ßò“ûöüàÏû@n6“$ZÿbáÌóå•h +ßÄCù 6#11ß7ÎQbÜc󨮎ê*„QÖżÿ ° H<Z®º„O|í6LDôÏÀ€w¢Íð ô¹é…éýL‚øU0? Å ºŸ4òCæ¦Ð\
øÍ ê¬EoDÁú‘ß{hÊä¾bÈ“*yb¢€·ÒËÓi_ R½ÀåSZ Vé~ð£%ú’¯d‚t–…<xTÕ¬¸!ˆ‡(Z V¥2ŒÞ|Ò××&ÜÈSÃHX»x.ÌÔY‹°kDH=£ òivR‰ö‡OÙŒ¸É“:Õè& Á#K¶kð0¬Ï¯èCYý +–|Ú–¨ZjVሠ¡~ü;È»¬«ójoœ ¸Ö’@·Î§,1ؾ~hW2Ѻ¦“sËRs IÛiv ‰XCt”€™Wg$Œe0‘.Öƒg†-‰>HÒ¬jÉ4!™¢'±ßõãÈ2Jt°™ñ/£ºÌQ>Yý¤ª•IŽá’,ÊV;á._—7€yØ«UËbG
dŽcÖ^]Œð +' Œä××6nÕ÷_¨ïo=›öÊ`Êp˜—#aèôhëܺÂqᒟ槆71|uå,'ÿ P
w\=X•ËÎWB«¸¸ñ|_<8Œ¥ùè×᪗é”|À¶ šÀ8Ýø²:yº„>¥‚x߉¸[Ð} °8}Ì‘™÷‘¡K³Ô –ða\“…¬¼ëDŠ±ýi9®±eËš€¬üKýÄ…ÿ ’"€ØSJqÎT.ŸêŠ—BRÝ„ðú“W¢@Ú(| í!lÝ4Ð:°ŠŸ-TËWSÞX“Bo‹ëÇ£’¬\U‰ +lŸUÄÙ!1îõJ k&eüù'Ègw¹Còd¯ "ýú{['^Ì3Y»G Ñ{K¾|ˆ‹-ï?1âɳZöQ™±šjA!ÏqÎp¦D9Ï°1‰æ—ßÏñšyªJ߇Àè€ü?±2àÙ°«³´~ w¨ ‹Æ¢ ˜˜‘°vN*·nø‚(Y/¿åã^Uûºö¶+FDû±_HÿOŸ˜ìw] \˜Ó—1é6+Û“†CE]Ïï›l¦Zh8{BÂjP1æöÐÑÕ2ÌS9Y–Ïð-Æ^èØi<<Dgø‚sÆôÅ«fðŽ Ý.YŒC›I@Í/ ‹.¾kÝA•1›Ä4%ù +0ôCV»(hãÍߨ£Ø‘ôÍL÷ø¤”zs ·/Ê·wâ Žr²\„1íNkó³«ãI¢úb‚°í˧‰xªå1!Rxižÿ§þþ‹T66»”yBØ,[™f +øm(m +=ÿPA8¢R–Ž&}«(òý†Ú¯:¡W0Ì˽xÝÄPSUrôs{Ûžfk‹üYyü±z¢ŠÒn” ÍÛá’šúeäZ€¥L +VwWØàÏ<ø7ýç»oG‡^pM‡yFÙæ^m<`ué$om2Û¥õ<¦>¬ÞÀÏl$Þ‚ˆgY\î·e]ø‡·‰í¤LH¨V_àó-AhRah —JéÂ2ÍX\L/ê [ºÚ1qNd„Ì@µÏÛ÷ + ¨ë cR÷aƒ>½x™&¥\—Kº>VG—Gá·oT&Íe'\¥«Ð"9 +÷¿ÏTÊRáÕä´ã—ámñ[©“Ö¢ÈÕoÜTÔr³I,¨ìÚâƒèr“DÒk×.iOGEÃŒïpì} dö¤™È}-wÆNMÛýV«*oðË]|VN×ÉÄÐdIÍ]n[ìJ!&°žc,ÂÙ„~G3^>Ðb&b÷6›$¤qUUø[S
K^“€“8 U³æ1xâºòq³ÛÆïw
…:×=€%¦¥¶äÄF· +;*¬{Çšª(ÛQ„J54p0PÉ©Ámp®ïÅünmà,)XÓOÏs é£Ù™«Ô ËÒŒ_È5Pðö_AnygÞP“%ðYYú>r~|vÇÞéÆv ý
ù4p¥v +Ò0Ãø NðE»L`À÷ % ìë±ðQËš/À{ú.-ävÓoo@W éÒ¯ñ2wCÍÈí$_±NÁ³æq˜FÔfTiu׳Ï5uò¶û¾¼l¼«õ‰à-Xˆ&½²æ'ù€ L©¬ÿÃÏBeZYIgŽïÝ;š!< $B…ýíÁXI±<ƒ”@hš³¬÷DP.·æBúþ €dö"¢žHÀ½¦©e|B ܇K É£û'c~{…±Kí!FfBýÊ>5—ÅË@Ge!¯{Óô^aÐÏë ñR@Í‹N„¤ú£…Q@â`c?èá»ä¦Ý»ÁŒ#Ì/cáôPä²´µêÍÞ=¡±Ÿ/Wgžƒö“
Ã]íµ¹š[ÊŸ 0t¶wpí,øß:œ Œ!*}_›Ï¨œ=ËCiN@“Fk(2‰Æ!¿Ðì´V•Á£Ü¿7š@×Ímãå@Ð$5ÚÜ´V+«ÐqqãÞ fÖˤׄð²:ħirmhѲP&#ãê`Ä/Û¶<Še´Zm bÉÒbÖ^ë€8ø 2¸Ê- æ½èž~¦ »¦ ¤¥ÕeY"é"¿èßÔÕB*Šÿëæ"#¼1’/EzÎH,6M¼¼„•êÏĦ¯àÈí_[‰z ‹‹ì…A؈å~×\ñâ´¹êÃu;ÖN/CÜ~ê,NÌ“÷üÙ¿‚NÙÇûhü³Ù1ê¹VK +#7k9+~FÑØ™¤wI¡Ý5?xIõMœb»o~—9ûn`Bâñ«ƒ›ù=—ì¨Þâ¡Ó=:R®Üæ±³§Ïýë;Ü
Þ°ë2©p¡ÔWì (˜=ÝYr„9òç$ž:®ãBZ :óæ²È¾HwE>…T²;ëÐÑš?Eg:Ç/BóÃ"gwC šíYŠ+•9¨Ñ(©öþ‹)ÍTVƒ±Ù¹/žãÇŠp0þ
8RÌ×ó€€Y÷Žˆ6øÑþÆÈ]“aVÅ;6
̃.ÊÏË7N +×C&©ü7 ÙÖì€ÓåÅ;¨Ý.ô©qF…0W¬tÛ€¸œ&Æ,0þ¯ÆÝ x }B¹âáÃÍÃlr²ÁÿCPZ_>Y>÷ñu%ëÓTÁÊè@6%ë»î(_þOÒ[})ì׌#*¶XgËñ{u•8×€.´7Z˜gJ‚Hz
Õ +½»ôúaDz—\n T£î©Ãc¢@ºÍšèU#í´j,*'YimщAØ*–WÀ°;šQôÜø A¼ê.ŸcmˆD9Ò>#É ôÅÿdUÚ¾ÞRÓU=þ”äê1ËPžÿRÇýÉžÀÂŒÇ7 ÉçKpÁ&‹ž¿ØßA4›DP§¬ã²4äôCðQ?è≠+i7Žk¯¢¦Vúìë1=:—1nÁƒd‰ ÄÇbŠê€ñ-þÞ2–R–,* ؼB²:¦È½ WŠãŠ’Ïæ8ªóŽ[MTÄmëA¸Ûr Š +®?ìÑÈ:Ì>n.¦„ Ú…†AWy1ÔÑ3mÕ]}íËd¯‰Ïá¼!yÂú/1½º²6È ¾ž»(…è5ÅßÞ-S©-פlÝHÄÒÙ$øªèÿõ\ú²ÍÚBašÔC SQ¬?{÷Õn‚Å ©"¦R꟢âLJÿYz–œÁã5¡4dÁ/* Þ÷ÊJïYÁ³ož–yh\Y< ¼&ÊoKqÐfÜ Úüà xÙµµÓÝO…+åb|ìý޷☸ :$eÂ]ä‹[}"{µËq:V¬yšèBA ¨äì¨Ú‚þÚVN F¼ÃÚW¨$Æý· qÝ?j¥W ж1mPe6SôóJÛõ˜Šy°·KZeë*X.º’Àm›¬*/—"÷Ë\ŸŒdõ}˜Æ LºŠ@/å>n®ÚÐÒHT‹ƒÌŽÆAÊõx$ôA.Äž@'¨ç‡š, +T!}³Ý Îäýð†â £/=Åÿcvz#þ#k”ˆ£ÉÄ㻑„ì¿aÝ f…¼…$â”3|t(Ž¾4hléŒØ×ÿw®ˆ[Žë;ÕØ¿©í?O¶ÿ¼3–a}+Æj¹3Fm˜¸"ÝM £lçòþ¤VÊ I‡ §iÊßà‡‡ãDù¤‹¬…9þû.ƈú›£’à@¤=KTxçyO
nZ [Ž /Bý®g\ÝÅi‰ KÖÒMýœÆ}jÿ+ë±5d7í:oæc¨‰€!póúŸDͽ†/Gªæ‰·ŽTï 0î#E/ÃrÉM~+ À.…*ó'©oŒžã˜qÑàöB¹ÇÉm£ÅéúÝò‚9hnì˜ÕM~£Y:À¬ª|å_SÑ÷E¤÷Jåƒè@¸¤&_÷ä¾iº /×E>UR'UàÍm˜óµ¦•k`°¡«Íù¤@); sžŸC¦²áB?§°[RIx ¯‹‰"5ÌZ÷Æß •3
tm›Ð² ýÀ«B«Ïc”õŸj'Áþqƒt„® +pS>FŽÇ_è|/ÉQ꣰–—þù"t5@Óºá÷Qу;vä=íÚ[|r9>t4™ynÓry>lä<þ“ýÖˆ•ÑÓpeBïaÂ)&ÓôF(ÜlŽª<Ö ÆÑÇÚ‹çÊ6B¹ ìÎÑd¹p†¯UÝwŠø ¦šŠœ}J%æN.á Ÿ·-Yg¦I&ÞÅoÂÂÝáòŒÖÝ ’ëüîÅ%ÙºR¹å‡fǼ¶øáSŸ¦RNëê·P¹ Žý§ RVª,ukªZž5ð°dã
ê/z’#ѱ‰· V„ÆáÛ5åcSŸaŸ®ÔŽ½YŒg<^ƒßL‘àŒ>î âô?8}˜fý£Ö,<B"j·ÞþÓd¥Äi¬S7™ÔS*ÍpeK5Pàfâ õõxîxÇwe5¼±Ô;Ì&áwïY+wc +Úܾƒ•˜½j^ÇO³?DkÅ Õ(„)¾ áãO Ú¾À³—g´àÚÓ¿cŒª(ú}øjJ;ó‚à,*Ìhz{Ž…˜•K¸+;¨(®hn¸‡1„•êP]Mõ,Nýåq,sn Ú€©÷hçõÛEõ™™‘´Æ÷k²êMé`÷j¶È;¥\²\¯]6öÀ©PÁ•YÞ@DÕãáV +¬|°½ûjãœÙwÝœd^fÈž€©9F<ö$¥½WïCåì<¦fg)½<ËÖ¶ølÝôÆ5Ÿº'æ¶âgà;ºŸ[SM
+ý€i¬óJÁ@èaÀâøÌœMjYÜuòQþe³?†9]ÑðK…Õ\ì4« ƒŸëà‹½KŽöíÍ9YäÕí½Tí„L¡oů ‘ÃAQÅÃ[Wo¤,C5m”`~É@ëè.4[®ö‡ÛAÉðFŒ}Ñúò¤Îkç~ÜØëiµ@š1klî{–ñ;‹ ~.|xàyÁÏ·A|ËA þêòÅJ©‰dV¡³öî7“`g‡ÚÛ>}$ú릷;Úã5ÒÌZQø$k»o^ËòøC@„Çlª +L€-²¥ø»¼Jîýý +¡YÆS4{Ú0…b3ð?°äVf‹±Ò‚"©†¾£:iHß^Áa1`IÊRŠOÊGë½qPÌŽ3†aµæÁ¶ìêÒZ ( ¾QûÈ´µ*½TÌ~4Wl?tnt49$ºÚÉ-zs^"ΉTŽ ¿ÚLi‹¨'}ãN~)™ØËžIS–+×XC” œï€tsai9£–Óv4êø&O¶ê¾ùš\CVæ ˜ƒÉZLÞRÈÇHýI½…àV8’ãÚ«#w}Ýá¸û"--xõôLd:ÞÂ9cœBŒÂÙ*ï#»Ã¡áÕô„u ‰¨Ù³)ŸáB¤É® …uÏÎÛoU†LÁÄÙWsÞ×£ö>ÅÉÚéH\"ü…ô›šu0a& †
¸V•Úð¥;T§’›î:¾Ð×'—LÕ=¸‡ Bí;`51&®séUÐ œ`¤‘ øŽºT¸‹¥{ +Ð]ŸXêy‘ ß²oÓ€$ð ;ñ^¯ $bМǒƒeR¨õJQ°~ð’½¢h•ƒö jtÁð’£ Aš–ÝHFþŒßæ¦>ù~~ÛŽÂÒ“]Ž3 Îk¥@\-`y-Œì|Šò +8¨™€¢íuÉu(
{¤”ðßÁá*¬Ï‡pr^!Þ¢ ë0SQPVÆ;”M°(ÎE0’A æÛ£Ÿq E©¸›sFÍ5Ñ¥·¬XÌÖX;q¡{{ïHäP'Iðm å¨u葅ʲz~Ì|™Á¦¤Ê×춻rŠŸ2µÕГ(ÚÆDÕ Š·Ž¾Lb` Ån\a#ð-7ÊaÐ@ß™HÙ¶-dØä.`séBÈ‹Å(Óâ‚4æ/gËÏÂ1‹´ˆ¶êC- +endobj +600 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 2 +/LastChar 151 +/Widths 1350 0 R +/BaseFont /ZSDOCT+URWPalladioL-Roma +/FontDescriptor 598 0 R +>> endobj +598 0 obj << +/Ascent 715 +/CapHeight 680 +/Descent -282 +/FontName /ZSDOCT+URWPalladioL-Roma +/ItalicAngle 0 +/StemV 84 +/XHeight 469 +/FontBBox [-166 -283 1021 943] +/Flags 4 +/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash) +/FontFile 599 0 R +>> endobj +1350 0 obj +[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 0 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ] +endobj +596 0 obj << +/Length1 1614 +/Length2 24485 +/Length3 532 +/Length 25368 +/Filter /FlateDecode +>> +stream +xÚ¬zceß³eÙ¶ë–m£Ë¶mÛ¶mWuÙ¶mÛ6»Œ®.×ôïÿ4ñf>ͼ'âìÌÜ+WæʽãÞˆCF¤ L'hbod*foçBÇDÏÈ
PURW0´±14±´—¡²·1ü5³Á‘ ;™ºXÚÛ‰º˜rÔMM +7µ3u2´(¸ÙXd,MíœM© +ð|I¨ +‘wÈ»8hN‚ôÊà3/Õc¼o—eöÀ´ØÕN¦•ôJ? ðg»Xœ nÿP¸ ‘>; ø§7Æ£w#5¡Ôýº$O>ÿóL1<16:Òw>pŒK“MÆãO à˜‹Ë¯¥Z)ZÝL~Ó‘mÂ{ôÔ*’»RÆ¢)ï0=ã½Ég —\"nsYâ‚{s’ ?ËçžiE«vY«Ôè€9¡ÇΗ©5{ý‰÷r=Fa‘ŠÚòBLÖÔ—J|‚í uÿáq™ßx&™å2‹r&G-H.‹Û"]pYÝÝÝÜ + "+0TjêkÉ™”“Œ†yF +3o¡a³ ìR€Á ¥äËG—$5]Ÿk&”ÈÔ›îª7[ãúÞÛÕ3Üî2R×HŽƒvž>kMt] ËwE*–3¼m–ô»°˜(×5 ƒ> ìÛ:¸øJ¼ü;xÏÙúãÌôÆë2àÑÞJìîKéÑTXŠ
Ñv…—Ç P¤úJzöJèXëÈ0¨Ê@-œéÇ=$!áFŽÚdÉr
¸Ò*û3JE›1* -Yé +5=Wx²à¶$_?äÑåŒ6i7ei¸pÄ9ÎA÷ H»æ(»Ñ4@ïêŠRaï†cû •cœ¦Ã™¸ß÷Rž¾Ï¬º/säæ¤Ux\Wx!’™²– +ûˆÝ{Y„Í! \®©E.M.û¬BÛ)°÷d)”(Ü}LxÜž s1Ôú~ã^ZˆUø‹t¦íÝ]TV!ò³þ"«ˆêVØ¥ÅBŸ‰òc yGOiEåŸáÉ[1*‡¸8E[¹ähÕï9¸Z˜3q¥MÕ2^¾dŠ¼Da—ÌLŒû\ﶓ×G
hàºõ¦‚Úr¤ïåXØx·à외[]tWÚ*¢å#îÑfÙ +<ËnJ;ØW9EÛÛW0Òˆ¨š¡ý=OésmàìPr‚ž!at5nd‰÷GJ—‰ŽsÍï:¨›+|}]›2Bjr¹“Þ14Á©
¾qêE®l=ÎÙqXñEpõÐëLïgß* R-h^è¶ynªÖö«$¿1mcqm›àÍÌGm` …ð×K𗎲©«t»e‰åû—´´, ‰#7Êc1^Ë XSú33<þÔ‚Q*¤ž´@·‹´ñi 2ÄíkÔȸ70ƒ@9}¥áejÎÐ +d„Ü)-l ÕZv±uãV Ò‘ÈU¤‡éœÙù¶›náBFöR`i# VGö{Cà +µ<ćI‰¡ÿ&)õduä.lõÚ…¾UF¯*뛦‡7æÛ–8*²I°m~¾9ÀP‹U¡ÐIûVó(B–)l;߸´JŸÒðQ]ìF¨ñÏ1Jò+î;©³5à"^Er5äg¶Ð ò¦.‹í5ÄéÄùm
¿Ž+[ñCJuM2Þ‰@¥q‘~+á Ûå(c¶öäÝ÷°œX³ þŽ8¾cçz° RŠžØàW+@U<G £»íã4k¨t‰ÜÕÏUcÌ ƒ v™DÄkËGÙ’¤ÈÏC—ÝRÀÈcí¬–žÃMuk
T»1ê¯c6n陌¡@3;måâò±ã3Î?jÛ— +ûy›–C¬g›ë¾lñÀ¹>` q¸2'Ô÷éöu3GLiÖÌP‹!Œ ²ý}Æ>$íég“œáœ·íç‚ÖU½½˜.ˆU-”Y2„bIi—Iª@Vóàï¢ø=ú/÷!ÁÈϹ5ä`¨xÏb¨ðrŽeA¸ìö˜:0µ.m¦¸.#3
Ù\ˆct”àŒ´Ñl- U™ésÿÏÕYÝ…žƒPòÝ×uóÍŸÓð,Š M{ˆêBCœ¾vb¸ÔTCR§dÚc¸eëq61»y«Ä'ù +\®¨c?šœö©?Q®ÉóeŒCÝ»ñ§ š˜PE˜©•Øõ!™»ïë¿x/ëí-¤Kñ1(LùË\1ñyBµ³õ¢§X‰¶ Îç°w¸)Šë–·ö H!û!|½Ž(§‚ ÿ&W;©2 +çüø±Pu¯Žq÷¹<¦^RvÂà ÀGuOܶBžÃD@ ˆ•ŒVÇ8 ¿öýG^ÅÐ…ÂÔÜ’‚×4bãÝ#¼c£NðÀK%ÝíÖˆÓúÛÙ’<@´ç ªÜßp–oè°B/::â±Ý.û›QW3´ÐK¨Sû–Abˆ‘¾IìxˆV©]ºü +.o¥¢è›xÛŽ=m§<°·‡Ñ"a¿YDUrçÓ8å<Ñ綉¯àçËgX´½xD‘ WÕ^¤ú]ÏbݸDÆ~œiÐÙŒ9BWØðÅ +ÀcYûÞ´Nƒ%„›#5ÆT½” ÷
µ“)¶;ч*þý³mÃ{ÀÓš¿†xÙ:~rƒ‚æ¢p¡ÊOGÊ|‡{Â]D‡R—xdHi?¯e8ß#u0ë «²ÒAR¢×ã“ŠomE°“Ž˜¹Ö1W¼V6ºÜEÍ8X“ÂA÷M™*=´Î„ÒzÓôž½žCÂ
©Á ýÖ v§”åfk &¡îKYŽè \ý¼üÎ-{7±¤mí‚0o ….†)Ž‘TûáYª{è•ïÉ«ö»± +!ä/woD3“*·â—þzöq¼7VwJ +áèñ!r±Otž˜¹f{«› (‡*Qs#òèRMc}çè–ßþ î©vâl¿Ëñ{¸Q7(P#,L¿Omƒqäµ<§5:Q™ op`[õ9†rïõNy’ ÃTñEs(ê”#„&ü¦»pÜlUÛ/æž@ûT n|«ywrõ¿-Yî€ÈôU`%vÑÊ½Ñ ƒ OÞû®JxàuÕL¾ñ’Ã}änwJ×á L=ƒãMnižgT2älÕ§9¿ÜžYÄ'H£Öþ…öL=òlÆ4×…F”ÖÜ+gruǦÒ3&T +ŒÓ2l8¨ ¦…þJoË¥Ò§c½}„B +þ£ÁuâÖW¨ÌÜ|ò h0®&Ÿ#ñ
Éúp覻Q ¢Áîjg”Þþ€Òƒ +¹Œ'µ@O§þKlÐí÷¡‰ŠÆŸ@,Û—š·%¡°„`鸘\,˜3›}y§O’¢Av(˜igísø?/Æ¢ÉÇ1w«rû
ñ îäÐnfÁ‚ê;+êÙáNïõƒÓé2‡l §Áœúî„]î"¹àᛇ?ÉPl¾^·f˜SÊËq²æøÐuÑR™lkOVöÿ= išA1ØêþìÄ~Iȼ¼÷Ï(ÄXkÂç?[¡ƒ 4"Ô <ºeYA/,vÈ•±%sK +į´^ÑæJ4«KsGØèx8¤õH¯H {s‚Ï+³ûuŠwœ‹ä ”ã¶EÊŒ˜©øzV᫃‚³]ÃÎ+6%ô,ñ%ËZ"3vò;îÇšmçÊi-å:L~NY|Je™ç›¯¢
x*.º¾<Èzíòiw^ª(xw6ôÁu¥v8£½/DÕýˆ*Túøˆô´å˜ÜÍ-‰úøL…µ0[0îßÓƒíÅ·³nÜÁ.yÉ8vJv d;~ë½cæ,²3ŒÙŶçŸ]
ÊÞD x‘¸¯ˆpt¶n3õy(ƒ[øô¼}!µ}IDM /@ã¾#Á‹1éósùÉ©õZ ˜F©b ÓÄ$ ²>th mpÇÖ´i
QgdË÷¯„â–œý”'÷t‰jP +¨a§ ÎßÿñóÅ,ÿÓÄ‹‡îRmÍAšMžbã ÷Dý0ɤA TédEü~܆¾Ë@¦KØj v¸ÉâU—xêÚ¢ÆhÉã\a<zµcé$§¥%¶Í¶pƒ¹&å}UfÍ`4ýÎÇ—Íþ–âløÑç %|·‹ùþ¾Z9}ÞEJS8M‚›¡W…U8¿ŒË$w¿ ¥Þ¬¬—ÞŸ9†êOw<Bì%ü®8~9):)AoÞ¸7ªü ä«:jð²óð:±£Ù„xJIñ‰Ë¨X«`±eú~Ž‡÷ax^? +!¨£ë¨…]–Õ•zXYáêàõ%\yÌ캶7Eiç0ˆY#@å¸÷}½Œd [¯)pQÓNøœhp‹]Ï£héFÕà5‰_¡l}ì„3\JÍŒ£“|V(TœàJÈ`/öç} ¨³ƒú"-ŠÞÕH+áK!EUé_Œ{GÀÙð¥*®Ž±ä‘ôªýh¼WpbO½¯àXÒ´²öªºÕY¶)G¼—…V(n|rm¬6éC¢9q#˃r8|;Ô^Vü¡løà +Y + ?ž®Ëm´¢˜^ÝkB°gmpŸÇhAÁ›ã+’½ ¦´ùCºìÛ*
¶‘ÊÌèmiÔYHjÈêo‘©ma¥î¨ÆŸ´ºÁtPäšP¥i¢‰Ã Gö] Û,[wdbÕ8ì`Hj•¬F(!2"L<ý蔸ÙÌ vØä_C8Z¢=|„Àh[œ_sb N~•–F‰Èå/ ‚œ69v98 ÛúIÀ[µ!w3¢ï‰=R‡x*’ÁÃ~ú!ñT™N
c•Öd)ƒ—®²Å³`¤@À6«Ù
â··Úþ óÿU±3«Š”ì ûe“ öà ;ˆûtán‡úÝqرØ9î]OÖăkp§OŠºçhÚqèìùœ*é4!QÅ]leo
P¯°
û(ŠpžOH;Àpn}XÈ&ùhzb}>-o1‚לä<OàÀ¦
@¬½*Ý·V†òh +F&bÊ_ë8$Þx£§Ë©Ã¤EpPKyuVTe͸H$ët+áÈC0ù“9©!I[ô6[ñãœöŽD)K²su;f–JîEu—û!šâ’ÿC4áÉ 69-úý£*ÁÅ-æu½!Œ±–‘©jM0™é'¨C¨Uä[,6ÒCé›@c=ÌÒ¾æpû³5meX†p>¥Qò{qAb0hºAxô¬eš–G¡ž« ÷·=³^þ•Ø;¶)îtŸ~FjÒÃ÷°&….V’‘bP5Çzj;êü;¼N–åW' ̓3Mçzª~®¤?ú%öRRl{3 !¸ýGT˜òýªêbј?ÄOO‡ö?é‘ä4~#À LÝš7æ´n¢™hfì÷$¡Tk2_+šçä[{p¿¥¦Ñ§t±¸s;Eº·øeÙ'ÉsH° ]á#epÝÚB[NÖ©Ìì9ôŠ~+CK¹’´5vôÏ”¿§Åû$‚rq|xØÃñz˜¥-`)®þÙšî(‚–ÂPªã4·Áq…e•Š©™.\Æ +·ò4«4é5Tò÷¢uv¶GÜL܈%Z
š tÏÆY²éw*žw6 Ÿ+¿ m ;ÆèfûºlA“] +Oc òÖ†›k<²8ÞCà8 +? +©çœ.Ñ1FЋd4èõŸDú½åÜüÒª»x+˜ôL½›’jËeÆYîÎ)}hïÌ)Ô…9Õ1$5zü6Åhæ¨dlxMË‘¥]ŽÿF„k§±œ¬Óš¥E]T‹æu¹ÓyEì±ûÜT¨&š(H‰Z—¢ö³Ž½%ÒánôâÜë#ê…“ jš-¢Í-ÿ1¶ˆ†£iµÝéËõ¬õXbßÄÂxò6Q‡kWPNÇ<0z%ª$A‹ \Âœð²j÷À®HÕ©”Ó"¡°~¾üós¿›éùÀ_íÝ 2mµ9ÐQ€’TB†@tÁTõ£;ËEßWEÌDÌŒguÅ]gÊf)"PÆÖâ1¿í^‰šVÝæI×ÐK‹qùÍÐX ŒÊY€²Âú1Ž» vp 9t#ûÎvCkÏToòÏĦ.ÚÒ Åp¥Øð*ÞÅAšàal.‹Òj¨BNš®)s\¬AØ(-¾Â‚`}¢þ•¿¹t€ƒ'ÚÞ ÇØç¦Á ¥‹i†Ö«nµðý“kf—P.Ye8ÚF‚Hôóž‚^AÅô“͉a'Ô0Ñú||{†aÑS OKn§
a·¯dŸ‘æjlšTŸxCbyŒÔí£ÝñÔMÊuÇiYðr‚ÐurÚëx ªnø˜n©œ0 ’Ýø$^´' J#æ›<BR3o°Ð‚¶.×Ò¾²8tEiÄ™h¢x]{*—áª-fÓ´‚.$žÂÅà>Q[ÝèøyE˱éëˆî¯Gj(Ûïh>4±ï3vÇ]«×3…1Ox/n±êψ´Ph|
\k±Z/BÛØ;n~ å á*`Ñ,n·¬§C ßÓ5‚ó ÑÜßÃû‘aèTq«ý’„,é±®²ð%¨¸¦¸H™˜þ_8²ºlH,ÏÉP?2N 'Ë¢Cs32Œµ]•Ôtf… p”-Ϩ,ù ï“Û³É +×ÝÀýr2`cÑ•:ï_ï6ësˆBª +c[/ì¶}1?ƒ8»ãe §Tº¬lÊ£ÇÉr´Ð–†)ˆ?~%@{$û뤓Ñ_•LrH›¨XòÅz£²á‹¼££N5R?Pâ¦&+û•VÕ¯5t×PF¢×= Œ'SÙÖÆš•âˆ7”Di´ÔÍÌÐø×u¬÷“„Á§ïj¾¨Œ*Æ'mÓåÍF×™9j>"þ ªƒÎZ—©®›k²‚ŠÁ¨ùéCÌÂ\ìżÁ5ÉëòöƒlLÆ£Ú€víE • (Š_‡EW¹ÞOèIBai°…@Ôóþ11šÏ[;„ +mø-³²a£7 ™ˆÑ4yª¦”
Š.éw- áÏA&7–æ˜hæØ-syÊýem5ÖÔ¸ÙR—¹Õð™ $¥£–1u*Z&‰%6Ù0å! Ù$‡"˜«¸&%‡ÒæÖzMUôG+40\ëGBÝÍßYi”¿¯Ã„Ä€¶MõtÞé1ûi +˜¥^nè ”íêç•âÎ,ÅŽÓ²:$!¨5]š¼ úuØÍÿò´¢·8“å‹ W"°ˆý¡VN +Z„1Û÷
ÿêséGe<hˆ-r° -n ®õTÂg
“„ÖŸÜ9ëZšÀl«zÜ•k²¬• 2¥‡…à§+3m¶X&Œ5Hãe,*Vw¢® _d÷¼øjdnÅ”Ífr eƒîL¸nüfI‚[xÓåƒ÷T% Í*pîj¦xKÙ•P¶d¤”¾Ò–f +Ã,7p“o#ØxpÀÔÄàZ×LÎÌæ(4= Úö]’p×-¦’×s0‰!±§²
;)‰²†Ó½zKP°,v“)˜¼6=.½3Œ¥NN4uwÁçkŒÔi?ßÛ‡½ |#ÝIgÓ>³¾’!!\¡»NfM;–ù€y¾u/‰m_L‚{Hà éš41,³ø·YŠ†ÈEh+þ¼¡ÿ1ÿÁc¤Kw‰æ@áðB>sÑX»ÒVücdåªïÄ‹5Ëb7½ÆR¥çEŽ[/Ò†Ôü‘Î +)<=U|xxtp9Wlz7;B#Jk•ï*$¥:˛ɚ§rSWí»ü¾‚6Ƀ`"ëPÑÙ8f’cDÍ3UO°úOZ5i”ö
›¸¯Z¹³uzÏýåk ÒªŸÆû‰Ô8è AiµåD¬Ê¯ÌÌ +¹J)°•§Ù´0 ×)NÇv*‡
B×ýD:)‡‘>}†rB¯csÏïq\þ%2Òûà<óÐYZ +Doµ~‘áNÞÍžb…ü÷ æ»!µ«u`º3æ¼ºç •E ¹ùÐÇð”‚çR¾m¹mì?£•• +Ÿ‚„¨Õ¯êF ‡Ü–Ђ +z®Ìx"q¬\?™Lüú)#¸§˜y
^d1]
ÀGó¥KÝØL·);68Ƨ!i›Jb“<šžôO!™¹n-º’l$ø‚æiÚ Ö†/ +ÉØ!úzZûE ¹¡Ü˜V]‡`ü— ½H€'cÝ›Å.æö– b:ßü3Ù
¤#sÀL¥ü&(ÉÂËsõÉX›èœ2?hv†¿óÌïÀR‰¦Ý‡uZËpdÛO6-ÿ(¬ :Im¨àXsièë³Ñ=Û:«OÇEû±êï)ådÚå_n5~G¾¨íÆØ"6M= ‡”Bä|àaá•$t&0c®ŽN,–zQ Ü!ÙBþ†Ó -)˜¢½ëò{^¸ƒÞQ3@TÞù™4ïU½G7© æÀ7òyÎ%]öH|½éx\|Ýso§k5k„«º§8çQ]g®êWø·]`h §Í§ÂUŒ 5¾yoÆ‘Ä ‘ +¢š~µ9•v7N€¨Þ„J‡ØÜwº€µ´íµ·S*ñ¦×“ç–«,yóîö†ã‡>κüXÎ! M ]ÜAÃÒ (V % ?9s6÷%: +ÜÃhë¹8±Ã2Çœ»Ädñ†’¸ÆbäØ\Ô&PèaåÜS~žE¤ºÃ•P³e}ŒC’37@Ðì=Cù¦9Ü°hcW7£v)P½¹3ùx%ì=Q
M–ýHÕøÄ žª ™Iú+|W"ÁÚÑöq¿–‰c#}~8ÄldTÔ›#ì‚zŸŠË b8ƒ½ÌàÚ/V}zÑ Eê2eâ ƒÂIyP™!Âp@÷CxKŒK³óì>5A 3…Ê‘–r0صàŵ€?Ž=µ~‰l~lE½ ÚÝ Ä>=Æš”,S ð–lö-ok8‡ªâ7} +æb¶+Mƒ $(-TbaÄnÜÏ€³î¸‡ë7›KæÓËŽê¼`ËØ”!êQ Ê—`µ{y±>Ñ:ésHçz¸$-©žY¬|ÄýÁP/[0«'ý–~õ™î!;Þžù +Åñf!*BJpc3w”Ò¥õ½ +_¥êû Rô9>Î1t%¿Y¯ÉIÍ efæ%ÕÇtìÁS=·Û;éÇË»â Ófé¢òðÒ?Ç^|cgGKgËhçÞÓüñæ³ø[ <£ªFö:&Ë¿H28*§ª ƒe*ÙY ƒ”p>Ÿå‚žq$®!W¤²É IÒᆘÍìôµ2'h Õü›eÌ‚¯©ÑðúÀ†\¯E>æ$ü¿Ápn NÌðªÌyÝ„¤Ã ÈÄp©É?·~ºÇiÚŽÐYçÝzC£ ‚un`×HK`ÀiájÿP~Á«ÕáR*Uk(ñÞjóe~?r/]S7 éÆRúí;|@“ +ðÊÂ
C@ +]Ç]½|ˆmë‹0µZ~Vy¾ +‡.Wƒ”½‘ð®¯c[æ±`¸}Õp{Ù§EÞ…lž=E9Yðuh`‚ø-s™Ê‡¡Eæú䊬ϛ1 +|Éûw°©ØâjrÉHÒ,É‹Æ,CbE¶—»Þ^èFêÛ9¹çnx,9c¤œãÖxrí“Í$åÈ£˜Ð^òK~_“â¨ö «48 ++ÇRaçÉç²7[BÞºé¥4\faZ€T
¨ÏŒg"”¦¡9¨™_Ûü Cµµ’)µëËÏ
‡8Ÿ]ÛŒ±î}èÀ,??õbÒfÞÑ5MË$_ÿözÞ?=¬ +
F]|N—éUÍQÌVá°ÊEšŸk´`ô—Y±fD
T‹¾g뉓Äw„Óg"‡ÓZ3<Ýãýøð£ÈZžp Í M>3 ίðåñ—2ºÔ7¨ažb8»×éŒ5!‰Ñ~þš‚ ¾dm>Ú¡³^óZ¾7±YijûvV +Ö²¯LL³fúêW‘¬ñExm íˆ/˜Ö39¢N1ÒŠyógõ4R–(,wV:Ív¡³)·…âÃÚx‰y¡þ3éT–V²`mÁ¦oA¼,×Qf*Å +†ìÓg¤…žVVÔMˆ"óC>”-²™é=$uÖI€å°•p„Â
Ô䪀]ƒy€ +áSý qÓS¿ª†R.“=©Àô®¸ å)léj“%ÕÐ}PˆJ®D‘é=œ¼™–Ïßõ‰¼ØÇ´:4]‡ÔÇ ž¤=ðøsÃuú³ä0A*›Â«mõß¿5Ä%#6ä@¾* æCàK}‡õdƒÖô_?±íÒÑaÑçpZöñj¤F{ªUpþ¶«EAHJÉûµGCåF=f +wÔ84<õòN!…OÑÑ +Ü*¢èp^ö}ÿLl QÛÊyÞò0æ[¢-C »=šK\ËÏ]E4ÈÐùëx´¾O^ƒÅZR=á¡Â iüÆnnÆL´—tžú[!ÖŽ ôbkÌ zøCt0p
n€òA–Ý +ÉÚëTÓ:ó%½ó»êó×o~EGvQw—a“Çu!àð|" È®]åû2Å[_ “Eœ(Û$¤ú±KÊ'lÞ‚ l¾R‡è|n8²D®|a/EÃÌ62ØatŒ„RàU`©ÌÚIËÅ«|¨8[d J¸– 3Ò–SÖåä9òsÛétiô6jÅÍ©uÂd\þö|ƒ±¡]Ê7`WªŒÉ?¹´RÜð¤ukaØŸSñƒZÂì뛋ÂðÌ‹Wõ?ÕxZJKu`Ò£{žÉ‡?z:RÎ܃u™ÞrZï°æWð\¦ ÐÝB¯Ü$± +•m›;ÆÖ‚N‘šI‰Ì>0åœ\×ÔÁrÁ–~¿ß¦Wp —|@(’ý$&hdž–mGë¿L‹a1 Dx,}ŠÊq—›ƒEr²S¤ÌÂ*—;
ÒžÏpòbÜ‚7§"suÊ–XŽ¢jÅVvdJ9e°ùZØü¢·±›¡6 Fj’uoß@žÕÂÏRØA£šÏè7±R³ÜŸC¿«=¬z«R(–&HÍéE×`l¹Õé<˧2&žù?Ñ j›]#Èvÿ£ïo¨ðk£â„ÕˆH@ü‹õëE 5XVº[੨1?\ýbûìS£Ao!b1/ѳ§‰J<<×*½´—Ô [,'{11ÅÓät—«‹É«˜Ù ½U,ÓF•€û?çIIïºÒÂëGS#Íç‚FÄg ñf¬"Gh€ãÄ.OÙ[‰]W‡BáSdSÔVÙþ´¥àÍü‚íLjÚ</p´žlÅ +"ˆ§§³±ªn†QÆöš»æuðÕ¥L(¥âŠv0Bo f¢Ü{¸ïÛÖˆ,`,3Ìýá”H¶ÛçÅ×í,°Ÿ\ýýæf‰_[äÙAL·É<ê}<òZYšŽ¯×ÎQ6§¨Ñ<¨ð¼Æ5¸¸@7:ë =zÎ0É
/¢¡§ZGVv9 ÏÞ9ô%çŽüû΋tå1áy ¨œ½¡¸d)稬ª2Nš vï“ÞÆk oö¢@~¶Ï©žäö»cµÞð(’/gQ MšÉcùüZÞ‡pªÀÖugâ2±tcÀ‚ûc âåwÁÀ‚û"”ñ3džQ0eƒ¸®#8¶W¾‚.¡tøš‰f@¤¶HðÀz+›4í¤?Õ_ù` +W;«Ä‚üUh&ÕŠÒ¥HS nFi@YüáŠFr¹ûjØ©ô‚üîŒL0æÂú]ˆ<‚V!}–K/iú â uXoJ–{N4YcAC†ÿÛ€/i}hXxQ_²·v S|PIpL‹OÎÄÿ×éÉÂNâÎþ§%ò¢®#q=‹ß˜‘ëÞÊXì¸o^t 7eˆ×WTæ4Sö0XÏÖYò€}6Ü›Z²ÈÄ]}rƒÌ:±l:# bkäÝ– aÌý·€®Ï:$œäDDöÌǃêŽO +³š}±ômCa¨œs¥”—žÀÔ|%«¯bå„ÊÁ®U‰P¤ÑU£3ÊšØ=çäÁá½ ¦½Ü j Ë” “0ÂÀ²Ú/ÕH«’º}Ÿ½ 'ÒôÃûψW–˜k† ô@k«Fì¨,çl÷Œû[o½¯åÏ HQÒ‰…< v:Qñ7~to‹ô îÍñˆ”µÏŠaT'cΜֹE8«™É&Ö+¯«exÞÓIþ#êÀK„N¨à;=/mÒ,ŽÞ5êgné*š^D‡S "‰±pÍq>Ým…’º>à ìöû×ÇãJ@zæxÕÕFW8^ +.@ ü,ñ“`aMJ!λŠ6N‡ú:žØ7y|‘Rä, ,²àMgBˆ·»¦8o¹®(QF
™³nZˆpZª„;¶ƒ¤Ää.«³:‹}ïþí¸<$ÈñÄÙ“† öú¬vdž“IF#ûeyùéëBCⲶtÊgìvve] Š|(Ü©½ÞŽÖ2Ç +"IúvœÝ~ÙuÊ)k˜ˆB±©R…Vd›}‚Á à,‰$™ØmŸF3S)pŸœOigRD['ù<пi[Ïe 2rÃ2;í¢Ð
ŸUATþV]¤·êœUÃþe½ø¹7ã “àìxáO¹¦€`¼Æ!³†…˜I®‘fþ²¸<Üzm7—‡£©ŠT›ä% €È¯•“º»®bÔq᎕ÂÙxú§Åd%]òR¾ˆNa†PåÛ‘Ô›§ÅË·o#=ç’™¦™›ý&à¼)g‘^%›Ï¥ ‘¹m8®à†aiå==çƒÀ¶ rAao¼¶5–‚ñbP¥C‹ð¿Ú7‡õJ@Ùƶ Û¶m³cÛöŽmu:¶mÛîØêØæù'÷ îì|§ `M«Ö „í±-!‹°!Š£ñFll«šuÿ¶³àEl°è^÷ìQú)æ<3¶ÄeóçUU$…»j×~a»XL^äMΊþùýê㉃j [‡‡·CÄ*Ä⮈àÒh‚»¦QË;u|ºUw">,œ¤âÔ;û2Ùöí„gè‚s+‘뻹ˆ5'
ò5lÞ¢ +|dà3 E¹Æ:[qáÚ™£ò|Q²îî +¦A½! V™Ñ«ô¸õ!UÖ‘»¿ûZì´àž÷¼ˆ_Éx ºËEµz™ãŸæ`ߎµ1BT5¢S.t´ÕãGéÓ ª›Jfƒ@áƒüZ~9:מÊF&–es×A·„^_Òj:Š54e°ñ2ZÅ[»É8 +ïZgUñ YÄÙšf8Âôd¿ÜÕÌ°ŠkÄÇ‘Pöd¼ùCSÖèJEAPÖ6ÿÝĸî$˜ç¥Ç§¤F§Íä0'tÀ¸í•kØ0-öÈ*¯X&ÜÞÎe0ª"Óž`1Ò‘ÿZJPé‰|ϪâŽëH¸Äo¯"0‘y‡Äúyú#gcqê‡ót}_/ ^ÈdkwÜÙíúòÜ×›ã“3ųʶe/oJ„ yÍ,½ä!…‘NV§7S£dò=á`ëNŠ°›½7›.5ö_4cå6Ä}|3mÏ
‚¡há9é4Î…c ÄæeG(½¯üª§!Dî§Â‰ë%mëÒI¿lbÿr?¤áoÛTZô=Éé–‡™Ã ¦…ñL22–ÏÔW‚b²’BžÕ”1Ó¾=ne AŸ˜ç¾cqaZ *^"MïpØ +f‰ª^±Ü‹ é¼E..ƒ§úW÷ #^ߥ3áÖøfF,þœ{L$ÆLÜ#b +%Ue +ÖÇÿ$»R‚0 °*kpC ›5D $*|º™¼g®yÓà\'\óK[3;pÎH·û¬Bêš<\)Á\K¨mù*ªýùÂýÌââr¹é'É‹ªí³=Fûš°«'d<šgîcŠé'U
¾³ò)2.š9V×Ú›õgö#Ë£b@KÎåUÉ¢*@!ï Xw·)2Íö«+¬CYq4¿1ww¾\ò.—Ôd]?Ù'œ¥”c8 +†n| »Aº§D f2 =]SÞºž2])ø.¡st£%²pΉ“Wz6kJgýòÇ“ô‡a³ö—‰ù®9y3jž ð:¯·®sa³*|Ë—~Þ²A'±j"‚a<tÝÜ¿cžB[ŸË´}!ÃqÛ.tÞ¯ÕŒ£ã¶ƒ3 +ƒË[ÓôÚ¯^dþþÂ()<е€â¬‰fL^:Q+ +*ç+Ë7t±;¶Ý¢
*%:‘Õ]=âï›Ëu'–¸bȦ•@ø¶$®ä“Ns5>7;mjo'õ£NL)H?”ÌsŒÈÔ$aËê×tPf\D:. 3Üí ]0ŒEFöáGÌåëd\W”%mÔÀàWíQÎ1‚Ôé^ȃÂgì/}™ïTJ@f¢”³ìr' +Ÿ–YBAí¿†ÒŒê§äkÖÁ[„Xé„5ÔOBÌåçŒ;ç0NGGw¶;è‹q +~êŸch]8-ož¨`¤÷3oi> ýß" C¸ð*$4üÊVÊÇà-L>?´<²èl7“xxÞŠâƒsÌ™ú sŠÒµÅG +‹I: "0²sŠ|¯ÕÁí›góij§6 W]˜d
Ý£,P•9Q¦%· Þ$,æv'){Ù¨«wÆ +š +éɃSaåò5¨îŠ‘NK÷É“äQgÀeÁŠã*C†QÊú;±W¨+Ì(=ð¶ðr ¶}!Y ÏÍê»pD™Vµp¦ÔÃHã/°²\k‹÷ï-7•g;먴R‡:g\ ;ìÇiw^îmÖºÔ£…&ú§uâ@’åàº\s›eðV +ÕÊz]¹§0Ë0Ôo{„ù9fJY?ó*î ^”ƒ ðé )U_‚)(ƒ+ |õ÷±íàõ§¼Õæ÷ãæG T jO×~ªØ:_†Üª63+‹êËí [ºšŽjJ½põŽÚìt +®Çï u;¢¸a +X§äÊÎ L‚|]BuKÚ ãªX›ŠŠji·ý ÜÉL5ÕvÜ4±bY(G¹Á©{»QR3œ”äï³IgÒü»IlštêÉÛ|ÃÓD ¬k{[Åi6Þˆâ àô@ðww=ã›{Qúã¿TêFióLmò¤llÃ?æáúnÝöþÆžçètÒn¢³¯?> +ukóñð^$r…ùÛ0¬˜¡dâ,ö§éi¶h9PϹçÏX+#œá-1k `þ73´>ÕÏiÕ€â9rµÖîÍu1‡[ +.òvŒÆ›ãWa°rÕ œÜ”`Ÿ}ö¿¯ÂýÛwq¹ÙïÖ ”‚·0®„i‘%Áüwþ!W¤Ìëe²Ó +¿£JÄäôÀÈ~ ïbþCñ÷a¼™V £;Ò9Dáö$hGSú‰</Ñ¥ÿ‘)Ƶèl["ŸV± N 5Ò«m‡®ÆH©)§âÀŠÐû ÏIÐK¸ÖÕ«\U…ïÁ#ÅXa!=*ˆª]!ÁîÞYÃÂídï1šÅ|âe9}âF+$r $SêxÜ”d2Ä“qChŸMH•ÛaÄN¨¹kl˜’?r´š•mnr"CÀÂ8Ô@æõ%<"ɾ@#Û™ÀÓÞâ™ –ÚÈöÀ0ítEž”ïû´€šÚ¡MÜ™:ãZÕBL•wÛ{1+(Úéï³´æ8ÿïÕaÐÓ#ËãŽÑOE‚šy ¯ý”lî:¬¿_À×þË=“ { E‰¶hvî~s2Ѭo¢Æ7u ñdØJü7¶ài˜ñÑ »[ïtQÅ ™ÅèøŒË;pÕKôÂãÃì³Ùì§{´3Óàr^ìI¹Úw°Úç)k%P>]À¼#A97±§ãÈ*Á¡atìm}¶—†mK•8ù6T«Ç}þÖåãÜxò`žüyþÕ\ÈqïN51FA1Â'Œ‘uôÐÅ42î²8ݕ沊° Fô„«Ô¬àCøb&åûlÅ +.ô.!¯ ùŒl}‹²-ꦚ!Î(®dìQl’ç0(oih7»"âØS ~M¹û<w]óÓË»Tá!±Ú¢$‘6¢þ‚hx}}åPyOÖ”ñÄ. ¯ºHƒƒ>¶%úÇõ+°jÐMᶵ=$,ƒ‰½=öPSÆO>ßʳqa—ïñˆëo"èäËÇt>U¦©Cði‘‚1åÄÀU±l¾Ø ÉB½Wiõã(¼šQí ‹Ù».¬@Üÿ ÄñŽš‰49c̤HD–…P=ºÝXt>-š-”ã¸4•öv‰_1E‡1;K-ÏŽØõÆ©É-4iž æ5¿Ó³ƒæ‡ÈÌÞ\Ô†ë1tD‹ÈÄtŽËd6_EófNñŸZ +…¯oÏà’X³`G
ÊŸMjâV Q̼ó{?#ü{¨ +ÿ†%ôAn÷«Et_I^}Ü< &ì°ÄªäcY:/‹Èš
7Ôöy vcªð, +´Âpmê_oS´±KR*\ÍeãzÜ bfú0óz30s–ÙXsø1ðniȹ‡"/]vºrÊO ‚0Ð4.²'‚çàž³ÖVŠ¢2ð m+ø«Ö°ÎhP_ P^ÉòâRý;Ð<Pyâ6°™ba]a
~”ÿ¬˜òr¸2–æj âÌi@ç‹Ùb’“¿ ý«M²ìÖ@o“ð)4âéØIM.Ñá}ó´Oqu#Ú <ko²öžü °ƒ“2N%Ûk¥Žw¾_ÃÓ|·,xr»¼uÁ=…–/SVÊGã¬l¹`³–½ä{íi
¼X\n®^>Ä“œ jÒ Ë&Oæng•Ûlý0k ôÂ7¢ mWÌçO5RŒ0 +ŠÇ½Íè÷å/‘:Ìé5b"=žOæýÕ0Z꛳Ùø ¹'sä3âçDç&EÇ +‘ƒ úS¼×¨,î$‚Ñ¢±Í97Å Öàb+𶡸 5f‰ôÍÄE áÄŠ\u’
Ϲs? +¸ÑàXÎRP*;Výt”ÄùYh.H ‘¦P‡mºx¬KÆ2¥¶^’f²åå¨t¤Ç´gˆîPsÐ;íÆžÿ|>w…Äv»Úhwò®â€n ÷¯ü×@(áÆzø³Æ)±GÈû
Ðú¹'»ÐÛºäz÷ +ªCð’󬧌¤piÅ2{Oe«pFañp¨“òK¯Áf¤wÍÍF¯×p˜û$ð«—þ£R>,ÈÃð 2*ÍpÃÛ@Hd/¿«–e† ‘[Ã~“®ä“Ô‹Ëq˜øeˆ ÛvŒëkmÆ{iâñø*@À˜BAY¸9“X±Än©StÞSÖL( J[/Ît S> üÆ3Ý[מ¢ÿ}×yáõ +êä;ã¶,¤
R††§t«É–¯Îo$–Nžù˜ªÏÍê;~6owAõÁf=c ³½ŒÎF[Å„æù–¢
k¦ƒùœrÏ%ǨTá…äé ~BÖ|®âËGbÏîå
Ȳ Æà|RMì^ï6QÌHè6 jR jôäßÄËèT[\ûâ‰RµÃÂ/H]\qfˆN¼fc*)¥Ö`õâÌ<ò&$´†»€ËVÑ’oþ¤qP¥`•i«ìÅ“ /‚®iø=ÃØ…®¤ ØH’‘·LŸwžðˆ VßÉÛ¤Xù¹ ‡¸N‰UÈF)ŸùÍ/'!xx2¼yT.o |³ìŽò©ÏÍ#$£A:Â>§%÷ˆºjôyáÄÅ ïaÿa$îÉ·FrQòÖü›¹Ó+üy»¡B•oV”`¦Úv +&®[öà"¥ƒÊ r0—®£½ O +‘pGÌœ'¡véÏ jËN‘D "jÀ=D Æ/¬?õKjNêps÷y Eg 𸠛âæÑÅÀé¸ eZÊÌÓÉj¸-•0Ýàµ%‚aÄ€%’'ðX
ŒÞy˜ ž9˳Õ-AŠ^¢&‡†¡Äú¢|;“õ’ð[Õƒ¼“x¦Ñëc-£V^ùéïÎ$W‚ +cd(¨[÷[qJDü5›UÁï¦ùúª“|i‹DÞø£– ¶8ÐÄÎ9_µàé4dað@˜Ÿ
P´¼jp-sð}Æ÷FþP³‹3 ó#¢•Cø°¯‹ÀÀ« £“TK|å÷lfËZ¬h'B‘@á4u®°8ó]0tƒˆ‚Ÿ·Èr»‹•Å!¦¿Ñ TŽºéør:4xé"&ÅN Œ/S;8gw¿…×Û¦‰*™ÎûTáž “axe4ܧ •>³î@E ƒÉhª…Ê(ˆ·êÃÖ&L}n³‘ƒÉ1rǺj,ƒ©}j¯Ø`í}¦|ÙQì¼¼ ó.òE)KïÝ’|³I4.Î 3qÉ-™ÑŽa‰~Ó»š—8Ãd®HÎù¢záá~oÍ•ƒtfž +®RÁ1æ"+Ob´½ÞnšŸF±¡é’Þù4g?nhO)Õ"AD·â™¥ïŸÜõ ׶auE‰ø–ßl· +ØNB†@–·üa`laø¯"kÝ =“¿'pr +3 c]MŽ<Z!ÖYЙÖÄÊq̼RüÄ“xìqñm>*9Œz±â{¥ò˜r»¨A®€ÎVÝÁã¤þ칧ǘ¡O–•½¬€K™òLÞ“N¿b ª:"eä%‰zÖ¾˜+°¢ v¯
–=üµ{nváû¸iÉ ³5@“¥¼ ŽÀQEG}Ò="ÎÊg2¹k}rgÁÎaïÄbF2§«:ôq‘l5eúY[Ûh[Pz +Õ"W›‚HóoHëg AÐÐYqo!a{In&Ýq7õµÊ´…B„ì©™-‡–¸ ²“ÑÉ@ùïå¿ûïz‡^Âö[ÏŠëN¥
Ê
‰/\Œ«6 Å:ê×c·•©àÀ®Dº¶6?i&Ç]ÊÕ#¼Ð‚Æ›d¡&~ 1 ¬çúàˆÚa;ÙzðBì•9|ÄyôÔùõ䢕)²röTÇÈ]ÓuÅ…CäW®iCê««(LjS——VL¬' @벎3ŽPœ2s JƒWŸ’÷/-pxÇåjØ !Ã1WÕ3ûg¯èêÂø;øßïv!Çs8mÝ{¦b
µÏTfkŽžý¥]ÂÕþÚ¼þ ä@’èQ§üKþDЃU³øøäܯ
Éí£sfàb8äª*neð¿¾=à8XçRâÛ5‰æAD>D?¯[6ènºMeÒÊЪ“Ž\Ì¡Œ@\$ì1‰ìÒ%$¸˜¿Ó‚j)Û±œžhÄßF% ²&â}–ž9 ÷»¸nqôM‘棆dŽà5<ƒ(»°äHd´ +ÿm“'èZÿm+‰pÁB"ÊÚO‹a££‘Úàÿa¥ÅCîp7¨Ûw_¬QOuü"’8ÏΓX£ìì?³F£, »«VH¤nÈ8ò»‡Ö
œ»Œ¯WhHâÍQ6ååõ0bÞwþOä ÀG•tÙAz‚ÿr½S{–§ÝrðÃF5'va¿ ƪb…T› »¬ñº´=:I£V‹åc¢pf€ÅFw”™þ¡±šç©‰Øô:î» :·€·^Ϩ„¯¶q zº
QVàD~Í‘6‰ +Æ94£ë
Fsf‡U…ÞpÃxò¯*N.sžuÒ7#0 ÷Óc‚ HÕ˜ –âYph9ÅUG— Þ¿¯çÖëY:/¾=¶'·2€ùµG³<~ª:™HJë¸p”£0L;µ/$ +ŠÝØfxö7w÷AꎎL¤³íXUòW³.’¼ª’;ÓÓ¡E"Så]FÞÉÊÏ"iòmþò¯Ñ7„ò—Ú+ÝظqŸKÓ™û˜Žz„Œ¼{R?5ùÁ.’ª–).ÄYðñ¡“ÿ’‡èa£öî3Mä¬8;
O'ÂÒÃ{(:õ„ +2 _LØÅ£™>÷R¤½¼ +NÜßúú +Lœ›Ê%…LeÌ¿+1Œ- •*ŒÂ0G70ýo2ˆ…"³ôd°Ç\g¶i7±ÝâsqLÆ7!õòîÏ¢{ßr%tCáòA@òÊý»ÑÕ*k„ï:qÉê“2²)]dÀÒ‚¸ê‚ƒL/j”ª®äQéâ a“ H'‘±èñä^¹®˜%ö/ïŽö»Gž¤ò÷»F¬Píù'€.wÉ¢‰ç’‘H=¨>9ŸhxÓ~TÑMÖìÜ‘œ\nÁ¼)¬2ÂÆP¶R7wõ/qiÉ#·gD^&Ñ6JD»‡ùþþµ˜‹VÕz<ƒªÕ! +6_mŠq'2~‹Ò=aFŠ†þÐœ²?Ç ¯Z¡._|;l[×OX˜àJÁ+QGýiÜZÉP &Yyf2—<²è•rŒG Ü75·ïá3òŽÃ#z‡FF⨾ãúF4þN¸ü5àcíÚ6P·¡“e ä è‡Ék¢œu_KŸ¥°L‹*·éñ0MH¼CrœT>Ü㇟x FÿàRÂB_!äµi¨N Ù%$hâ]tÞ ‰¢èÛîûs¶¼ª=nù<ü¨òÁËY©ÞØîƒQKñ™ÆýgF==ˆ3š öùs Cì¶G’Ð!YŠ
WaðŠ +·Yà¾]ˆh‘!{â#iŽ»¤"”¯ùù4bwËZ¨X à2&£‘.¿l=b, ¢,Ùl<aâr7à')¬Í‹RQÜ.)ö2—.‘ч¥r×uü)RÖ\-Cà" +¨{0öÊðeh饑@s£²çäV>ÔúAœ¦Gôì©5W 0!ÒãBîV\Êå6ÔÔëߥåíýŽá;RÐ$øžv(Ó@ÃIC M«Çv¹Ì_§/# È +ÙÌÑ‚§ õ±Á¿2å 6ôw’ä{0ëó¬+/6A3C¿X ¬Ÿ? +¥0©j T™¶„qÚ]¡ÁÂ'DY¸
ö.g¬Âñ¨û ;AJÒ´á¿ÔÍ[ßÇHûaA@Ôñ ?ÍJµAì»tI•%[Ø$ Òð³"ɾ s™ÿ?÷€ÿ +endobj +597 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 1336 0 R +/FirstChar 2 +/LastChar 151 +/Widths 1351 0 R +/BaseFont /NEGMHA+URWPalladioL-Bold +/FontDescriptor 595 0 R +>> endobj +595 0 obj << +/Ascent 708 +/CapHeight 672 +/Descent -266 +/FontName /NEGMHA+URWPalladioL-Bold +/ItalicAngle 0 +/StemV 123 +/XHeight 471 +/FontBBox [-152 -301 1000 935] +/Flags 4 +/CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash) +/FontFile 596 0 R +>> endobj +1351 0 obj +[611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 0 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ] +endobj +601 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [590 0 R 603 0 R 610 0 R 629 0 R 646 0 R 657 0 R] +>> endobj +672 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [664 0 R 674 0 R 679 0 R 687 0 R 698 0 R 706 0 R] +>> endobj +717 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [713 0 R 720 0 R 727 0 R 739 0 R 748 0 R 753 0 R] +>> endobj +764 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [757 0 R 766 0 R 776 0 R 787 0 R 794 0 R 803 0 R] +>> endobj +813 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [807 0 R 815 0 R 819 0 R 829 0 R 835 0 R 843 0 R] +>> endobj +861 0 obj << +/Type /Pages +/Count 6 +/Parent 1352 0 R +/Kids [853 0 R 863 0 R 877 0 R 884 0 R 888 0 R 894 0 R] +>> endobj +907 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [900 0 R 909 0 R 916 0 R 920 0 R 925 0 R 931 0 R] +>> endobj +947 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [938 0 R 953 0 R 957 0 R 967 0 R 974 0 R 982 0 R] +>> endobj +992 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [986 0 R 994 0 R 1001 0 R 1006 0 R 1013 0 R 1021 0 R] +>> endobj +1035 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [1029 0 R 1037 0 R 1046 0 R 1051 0 R 1055 0 R 1063 0 R] +>> endobj +1084 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [1075 0 R 1086 0 R 1102 0 R 1114 0 R 1120 0 R 1127 0 R] +>> endobj +1149 0 obj << +/Type /Pages +/Count 6 +/Parent 1353 0 R +/Kids [1138 0 R 1151 0 R 1158 0 R 1164 0 R 1168 0 R 1176 0 R] +>> endobj +1196 0 obj << +/Type /Pages +/Count 6 +/Parent 1354 0 R +/Kids [1186 0 R 1198 0 R 1202 0 R 1209 0 R 1221 0 R 1276 0 R] +>> endobj +1335 0 obj << +/Type /Pages +/Count 1 +/Parent 1354 0 R +/Kids [1327 0 R] +>> endobj +1352 0 obj << +/Type /Pages +/Count 36 +/Parent 1355 0 R +/Kids [601 0 R 672 0 R 717 0 R 764 0 R 813 0 R 861 0 R] +>> endobj +1353 0 obj << +/Type /Pages +/Count 36 +/Parent 1355 0 R +/Kids [907 0 R 947 0 R 992 0 R 1035 0 R 1084 0 R 1149 0 R] +>> endobj +1354 0 obj << +/Type /Pages +/Count 7 +/Parent 1355 0 R +/Kids [1196 0 R 1335 0 R] +>> endobj +1355 0 obj << +/Type /Pages +/Count 79 +/Kids [1352 0 R 1353 0 R 1354 0 R] +>> endobj +1356 0 obj << +/Type /Outlines +/First 7 0 R +/Last 555 0 R +/Count 9 +>> endobj +587 0 obj << +/Title 588 0 R +/A 585 0 R +/Parent 575 0 R +/Prev 583 0 R +>> endobj +583 0 obj << +/Title 584 0 R +/A 581 0 R +/Parent 575 0 R +/Prev 579 0 R +/Next 587 0 R +>> endobj +579 0 obj << +/Title 580 0 R +/A 577 0 R +/Parent 575 0 R +/Next 583 0 R +>> endobj +575 0 obj << +/Title 576 0 R +/A 573 0 R +/Parent 555 0 R +/Prev 567 0 R +/First 579 0 R +/Last 587 0 R +/Count -3 +>> endobj +571 0 obj << +/Title 572 0 R +/A 569 0 R +/Parent 567 0 R +>> endobj +567 0 obj << +/Title 568 0 R +/A 565 0 R +/Parent 555 0 R +/Prev 559 0 R +/Next 575 0 R +/First 571 0 R +/Last 571 0 R +/Count -1 +>> endobj +563 0 obj << +/Title 564 0 R +/A 561 0 R +/Parent 559 0 R +>> endobj +559 0 obj << +/Title 560 0 R +/A 557 0 R +/Parent 555 0 R +/Next 567 0 R +/First 563 0 R +/Last 563 0 R +/Count -1 +>> endobj +555 0 obj << +/Title 556 0 R +/A 553 0 R +/Parent 1356 0 R +/Prev 535 0 R +/First 559 0 R +/Last 575 0 R +/Count -3 +>> endobj +551 0 obj << +/Title 552 0 R +/A 549 0 R +/Parent 535 0 R +/Prev 547 0 R +>> endobj +547 0 obj << +/Title 548 0 R +/A 545 0 R +/Parent 535 0 R +/Prev 539 0 R +/Next 551 0 R +>> endobj +543 0 obj << +/Title 544 0 R +/A 541 0 R +/Parent 539 0 R +>> endobj +539 0 obj << +/Title 540 0 R +/A 537 0 R +/Parent 535 0 R +/Next 547 0 R +/First 543 0 R +/Last 543 0 R +/Count -1 +>> endobj +535 0 obj << +/Title 536 0 R +/A 533 0 R +/Parent 1356 0 R +/Prev 511 0 R +/Next 555 0 R +/First 539 0 R +/Last 551 0 R +/Count -3 +>> endobj +531 0 obj << +/Title 532 0 R +/A 529 0 R +/Parent 511 0 R +/Prev 519 0 R +>> endobj +527 0 obj << +/Title 528 0 R +/A 525 0 R +/Parent 519 0 R +/Prev 523 0 R +>> endobj +523 0 obj << +/Title 524 0 R +/A 521 0 R +/Parent 519 0 R +/Next 527 0 R +>> endobj +519 0 obj << +/Title 520 0 R +/A 517 0 R +/Parent 511 0 R +/Prev 515 0 R +/Next 531 0 R +/First 523 0 R +/Last 527 0 R +/Count -2 +>> endobj +515 0 obj << +/Title 516 0 R +/A 513 0 R +/Parent 511 0 R +/Next 519 0 R +>> endobj +511 0 obj << +/Title 512 0 R +/A 509 0 R +/Parent 1356 0 R +/Prev 239 0 R +/Next 535 0 R +/First 515 0 R +/Last 531 0 R +/Count -3 +>> endobj +507 0 obj << +/Title 508 0 R +/A 505 0 R +/Parent 463 0 R +/Prev 491 0 R +>> endobj +503 0 obj << +/Title 504 0 R +/A 501 0 R +/Parent 491 0 R +/Prev 499 0 R +>> endobj +499 0 obj << +/Title 500 0 R +/A 497 0 R +/Parent 491 0 R +/Prev 495 0 R +/Next 503 0 R +>> endobj +495 0 obj << +/Title 496 0 R +/A 493 0 R +/Parent 491 0 R +/Next 499 0 R +>> endobj +491 0 obj << +/Title 492 0 R +/A 489 0 R +/Parent 463 0 R +/Prev 487 0 R +/Next 507 0 R +/First 495 0 R +/Last 503 0 R +/Count -3 +>> endobj +487 0 obj << +/Title 488 0 R +/A 485 0 R +/Parent 463 0 R +/Prev 483 0 R +/Next 491 0 R +>> endobj +483 0 obj << +/Title 484 0 R +/A 481 0 R +/Parent 463 0 R +/Prev 479 0 R +/Next 487 0 R +>> endobj +479 0 obj << +/Title 480 0 R +/A 477 0 R +/Parent 463 0 R +/Prev 467 0 R +/Next 483 0 R +>> endobj +475 0 obj << +/Title 476 0 R +/A 473 0 R +/Parent 467 0 R +/Prev 471 0 R +>> endobj +471 0 obj << +/Title 472 0 R +/A 469 0 R +/Parent 467 0 R +/Next 475 0 R +>> endobj +467 0 obj << +/Title 468 0 R +/A 465 0 R +/Parent 463 0 R +/Next 479 0 R +/First 471 0 R +/Last 475 0 R +/Count -2 +>> endobj +463 0 obj << +/Title 464 0 R +/A 461 0 R +/Parent 239 0 R +/Prev 271 0 R +/First 467 0 R +/Last 507 0 R +/Count -6 +>> endobj +459 0 obj << +/Title 460 0 R +/A 457 0 R +/Parent 443 0 R +/Prev 455 0 R +>> endobj +455 0 obj << +/Title 456 0 R +/A 453 0 R +/Parent 443 0 R +/Prev 451 0 R +/Next 459 0 R +>> endobj +451 0 obj << +/Title 452 0 R +/A 449 0 R +/Parent 443 0 R +/Prev 447 0 R +/Next 455 0 R +>> endobj +447 0 obj << +/Title 448 0 R +/A 445 0 R +/Parent 443 0 R +/Next 451 0 R +>> endobj +443 0 obj << +/Title 444 0 R +/A 441 0 R +/Parent 271 0 R +/Prev 439 0 R +/First 447 0 R +/Last 459 0 R +/Count -4 +>> endobj +439 0 obj << +/Title 440 0 R +/A 437 0 R +/Parent 271 0 R +/Prev 435 0 R +/Next 443 0 R +>> endobj +435 0 obj << +/Title 436 0 R +/A 433 0 R +/Parent 271 0 R +/Prev 431 0 R +/Next 439 0 R +>> endobj +431 0 obj << +/Title 432 0 R +/A 429 0 R +/Parent 271 0 R +/Prev 427 0 R +/Next 435 0 R +>> endobj +427 0 obj << +/Title 428 0 R +/A 425 0 R +/Parent 271 0 R +/Prev 423 0 R +/Next 431 0 R +>> endobj +423 0 obj << +/Title 424 0 R +/A 421 0 R +/Parent 271 0 R +/Prev 419 0 R +/Next 427 0 R +>> endobj +419 0 obj << +/Title 420 0 R +/A 417 0 R +/Parent 271 0 R +/Prev 415 0 R +/Next 423 0 R +>> endobj +415 0 obj << +/Title 416 0 R +/A 413 0 R +/Parent 271 0 R +/Prev 343 0 R +/Next 419 0 R +>> endobj +411 0 obj << +/Title 412 0 R +/A 409 0 R +/Parent 343 0 R +/Prev 407 0 R +>> endobj +407 0 obj << +/Title 408 0 R +/A 405 0 R +/Parent 343 0 R +/Prev 403 0 R +/Next 411 0 R +>> endobj +403 0 obj << +/Title 404 0 R +/A 401 0 R +/Parent 343 0 R +/Prev 399 0 R +/Next 407 0 R +>> endobj +399 0 obj << +/Title 400 0 R +/A 397 0 R +/Parent 343 0 R +/Prev 395 0 R +/Next 403 0 R +>> endobj +395 0 obj << +/Title 396 0 R +/A 393 0 R +/Parent 343 0 R +/Prev 391 0 R +/Next 399 0 R +>> endobj +391 0 obj << +/Title 392 0 R +/A 389 0 R +/Parent 343 0 R +/Prev 387 0 R +/Next 395 0 R +>> endobj +387 0 obj << +/Title 388 0 R +/A 385 0 R +/Parent 343 0 R +/Prev 383 0 R +/Next 391 0 R +>> endobj +383 0 obj << +/Title 384 0 R +/A 381 0 R +/Parent 343 0 R +/Prev 379 0 R +/Next 387 0 R +>> endobj +379 0 obj << +/Title 380 0 R +/A 377 0 R +/Parent 343 0 R +/Prev 375 0 R +/Next 383 0 R +>> endobj +375 0 obj << +/Title 376 0 R +/A 373 0 R +/Parent 343 0 R +/Prev 371 0 R +/Next 379 0 R +>> endobj +371 0 obj << +/Title 372 0 R +/A 369 0 R +/Parent 343 0 R +/Prev 367 0 R +/Next 375 0 R +>> endobj +367 0 obj << +/Title 368 0 R +/A 365 0 R +/Parent 343 0 R +/Prev 363 0 R +/Next 371 0 R +>> endobj +363 0 obj << +/Title 364 0 R +/A 361 0 R +/Parent 343 0 R +/Prev 359 0 R +/Next 367 0 R +>> endobj +359 0 obj << +/Title 360 0 R +/A 357 0 R +/Parent 343 0 R +/Prev 355 0 R +/Next 363 0 R +>> endobj +355 0 obj << +/Title 356 0 R +/A 353 0 R +/Parent 343 0 R +/Prev 351 0 R +/Next 359 0 R +>> endobj +351 0 obj << +/Title 352 0 R +/A 349 0 R +/Parent 343 0 R +/Prev 347 0 R +/Next 355 0 R +>> endobj +347 0 obj << +/Title 348 0 R +/A 345 0 R +/Parent 343 0 R +/Next 351 0 R +>> endobj +343 0 obj << +/Title 344 0 R +/A 341 0 R +/Parent 271 0 R +/Prev 339 0 R +/Next 415 0 R +/First 347 0 R +/Last 411 0 R +/Count -17 +>> endobj +339 0 obj << +/Title 340 0 R +/A 337 0 R +/Parent 271 0 R +/Prev 335 0 R +/Next 343 0 R +>> endobj +335 0 obj << +/Title 336 0 R +/A 333 0 R +/Parent 271 0 R +/Prev 331 0 R +/Next 339 0 R +>> endobj +331 0 obj << +/Title 332 0 R +/A 329 0 R +/Parent 271 0 R +/Prev 327 0 R +/Next 335 0 R +>> endobj +327 0 obj << +/Title 328 0 R +/A 325 0 R +/Parent 271 0 R +/Prev 323 0 R +/Next 331 0 R +>> endobj +323 0 obj << +/Title 324 0 R +/A 321 0 R +/Parent 271 0 R +/Prev 311 0 R +/Next 327 0 R +>> endobj +319 0 obj << +/Title 320 0 R +/A 317 0 R +/Parent 311 0 R +/Prev 315 0 R +>> endobj +315 0 obj << +/Title 316 0 R +/A 313 0 R +/Parent 311 0 R +/Next 319 0 R +>> endobj +311 0 obj << +/Title 312 0 R +/A 309 0 R +/Parent 271 0 R +/Prev 307 0 R +/Next 323 0 R +/First 315 0 R +/Last 319 0 R +/Count -2 +>> endobj +307 0 obj << +/Title 308 0 R +/A 305 0 R +/Parent 271 0 R +/Prev 303 0 R +/Next 311 0 R +>> endobj +303 0 obj << +/Title 304 0 R +/A 301 0 R +/Parent 271 0 R +/Prev 299 0 R +/Next 307 0 R +>> endobj +299 0 obj << +/Title 300 0 R +/A 297 0 R +/Parent 271 0 R +/Prev 295 0 R +/Next 303 0 R +>> endobj +295 0 obj << +/Title 296 0 R +/A 293 0 R +/Parent 271 0 R +/Prev 291 0 R +/Next 299 0 R +>> endobj +291 0 obj << +/Title 292 0 R +/A 289 0 R +/Parent 271 0 R +/Prev 287 0 R +/Next 295 0 R +>> endobj +287 0 obj << +/Title 288 0 R +/A 285 0 R +/Parent 271 0 R +/Prev 283 0 R +/Next 291 0 R +>> endobj +283 0 obj << +/Title 284 0 R +/A 281 0 R +/Parent 271 0 R +/Prev 279 0 R +/Next 287 0 R +>> endobj +279 0 obj << +/Title 280 0 R +/A 277 0 R +/Parent 271 0 R +/Prev 275 0 R +/Next 283 0 R +>> endobj +275 0 obj << +/Title 276 0 R +/A 273 0 R +/Parent 271 0 R +/Next 279 0 R +>> endobj +271 0 obj << +/Title 272 0 R +/A 269 0 R +/Parent 239 0 R +/Prev 243 0 R +/Next 463 0 R +/First 275 0 R +/Last 443 0 R +/Count -24 +>> endobj +267 0 obj << +/Title 268 0 R +/A 265 0 R +/Parent 259 0 R +/Prev 263 0 R +>> endobj +263 0 obj << +/Title 264 0 R +/A 261 0 R +/Parent 259 0 R +/Next 267 0 R +>> endobj +259 0 obj << +/Title 260 0 R +/A 257 0 R +/Parent 243 0 R +/Prev 247 0 R +/First 263 0 R +/Last 267 0 R +/Count -2 +>> endobj +255 0 obj << +/Title 256 0 R +/A 253 0 R +/Parent 247 0 R +/Prev 251 0 R +>> endobj +251 0 obj << +/Title 252 0 R +/A 249 0 R +/Parent 247 0 R +/Next 255 0 R +>> endobj +247 0 obj << +/Title 248 0 R +/A 245 0 R +/Parent 243 0 R +/Next 259 0 R +/First 251 0 R +/Last 255 0 R +/Count -2 +>> endobj +243 0 obj << +/Title 244 0 R +/A 241 0 R +/Parent 239 0 R +/Next 271 0 R +/First 247 0 R +/Last 259 0 R +/Count -2 +>> endobj +239 0 obj << +/Title 240 0 R +/A 237 0 R +/Parent 1356 0 R +/Prev 227 0 R +/Next 511 0 R +/First 243 0 R +/Last 463 0 R +/Count -3 +>> endobj +235 0 obj << +/Title 236 0 R +/A 233 0 R +/Parent 227 0 R +/Prev 231 0 R +>> endobj +231 0 obj << +/Title 232 0 R +/A 229 0 R +/Parent 227 0 R +/Next 235 0 R +>> endobj +227 0 obj << +/Title 228 0 R +/A 225 0 R +/Parent 1356 0 R +/Prev 131 0 R +/Next 239 0 R +/First 231 0 R +/Last 235 0 R +/Count -2 +>> endobj +223 0 obj << +/Title 224 0 R +/A 221 0 R +/Parent 215 0 R +/Prev 219 0 R +>> endobj +219 0 obj << +/Title 220 0 R +/A 217 0 R +/Parent 215 0 R +/Next 223 0 R +>> endobj +215 0 obj << +/Title 216 0 R +/A 213 0 R +/Parent 131 0 R +/Prev 199 0 R +/First 219 0 R +/Last 223 0 R +/Count -2 +>> endobj +211 0 obj << +/Title 212 0 R +/A 209 0 R +/Parent 199 0 R +/Prev 207 0 R +>> endobj +207 0 obj << +/Title 208 0 R +/A 205 0 R +/Parent 199 0 R +/Prev 203 0 R +/Next 211 0 R +>> endobj +203 0 obj << +/Title 204 0 R +/A 201 0 R +/Parent 199 0 R +/Next 207 0 R +>> endobj +199 0 obj << +/Title 200 0 R +/A 197 0 R +/Parent 131 0 R +/Prev 195 0 R +/Next 215 0 R +/First 203 0 R +/Last 211 0 R +/Count -3 +>> endobj +195 0 obj << +/Title 196 0 R +/A 193 0 R +/Parent 131 0 R +/Prev 191 0 R +/Next 199 0 R +>> endobj +191 0 obj << +/Title 192 0 R +/A 189 0 R +/Parent 131 0 R +/Prev 155 0 R +/Next 195 0 R +>> endobj +187 0 obj << +/Title 188 0 R +/A 185 0 R +/Parent 155 0 R +/Prev 183 0 R +>> endobj +183 0 obj << +/Title 184 0 R +/A 181 0 R +/Parent 155 0 R +/Prev 179 0 R +/Next 187 0 R +>> endobj +179 0 obj << +/Title 180 0 R +/A 177 0 R +/Parent 155 0 R +/Prev 175 0 R +/Next 183 0 R +>> endobj +175 0 obj << +/Title 176 0 R +/A 173 0 R +/Parent 155 0 R +/Prev 171 0 R +/Next 179 0 R +>> endobj +171 0 obj << +/Title 172 0 R +/A 169 0 R +/Parent 155 0 R +/Prev 159 0 R +/Next 175 0 R +>> endobj +167 0 obj << +/Title 168 0 R +/A 165 0 R +/Parent 159 0 R +/Prev 163 0 R +>> endobj +163 0 obj << +/Title 164 0 R +/A 161 0 R +/Parent 159 0 R +/Next 167 0 R +>> endobj +159 0 obj << +/Title 160 0 R +/A 157 0 R +/Parent 155 0 R +/Next 171 0 R +/First 163 0 R +/Last 167 0 R +/Count -2 +>> endobj +155 0 obj << +/Title 156 0 R +/A 153 0 R +/Parent 131 0 R +/Prev 151 0 R +/Next 191 0 R +/First 159 0 R +/Last 187 0 R +/Count -6 +>> endobj +151 0 obj << +/Title 152 0 R +/A 149 0 R +/Parent 131 0 R +/Prev 147 0 R +/Next 155 0 R +>> endobj +147 0 obj << +/Title 148 0 R +/A 145 0 R +/Parent 131 0 R +/Prev 139 0 R +/Next 151 0 R +>> endobj +143 0 obj << +/Title 144 0 R +/A 141 0 R +/Parent 139 0 R +>> endobj +139 0 obj << +/Title 140 0 R +/A 137 0 R +/Parent 131 0 R +/Prev 135 0 R +/Next 147 0 R +/First 143 0 R +/Last 143 0 R +/Count -1 +>> endobj +135 0 obj << +/Title 136 0 R +/A 133 0 R +/Parent 131 0 R +/Next 139 0 R +>> endobj +131 0 obj << +/Title 132 0 R +/A 129 0 R +/Parent 1356 0 R +/Prev 91 0 R +/Next 227 0 R +/First 135 0 R +/Last 215 0 R +/Count -9 +>> endobj +127 0 obj << +/Title 128 0 R +/A 125 0 R +/Parent 111 0 R +/Prev 115 0 R +>> endobj +123 0 obj << +/Title 124 0 R +/A 121 0 R +/Parent 115 0 R +/Prev 119 0 R +>> endobj +119 0 obj << +/Title 120 0 R +/A 117 0 R +/Parent 115 0 R +/Next 123 0 R +>> endobj +115 0 obj << +/Title 116 0 R +/A 113 0 R +/Parent 111 0 R +/Next 127 0 R +/First 119 0 R +/Last 123 0 R +/Count -2 +>> endobj +111 0 obj << +/Title 112 0 R +/A 109 0 R +/Parent 91 0 R +/Prev 107 0 R +/First 115 0 R +/Last 127 0 R +/Count -2 +>> endobj +107 0 obj << +/Title 108 0 R +/A 105 0 R +/Parent 91 0 R +/Prev 95 0 R +/Next 111 0 R +>> endobj +103 0 obj << +/Title 104 0 R +/A 101 0 R +/Parent 95 0 R +/Prev 99 0 R +>> endobj +99 0 obj << +/Title 100 0 R +/A 97 0 R +/Parent 95 0 R +/Next 103 0 R +>> endobj +95 0 obj << +/Title 96 0 R +/A 93 0 R +/Parent 91 0 R +/Next 107 0 R +/First 99 0 R +/Last 103 0 R +/Count -2 +>> endobj +91 0 obj << +/Title 92 0 R +/A 89 0 R +/Parent 1356 0 R +/Prev 67 0 R +/Next 131 0 R +/First 95 0 R +/Last 111 0 R +/Count -3 +>> endobj +87 0 obj << +/Title 88 0 R +/A 85 0 R +/Parent 67 0 R +/Prev 83 0 R +>> endobj +83 0 obj << +/Title 84 0 R +/A 81 0 R +/Parent 67 0 R +/Prev 79 0 R +/Next 87 0 R +>> endobj +79 0 obj << +/Title 80 0 R +/A 77 0 R +/Parent 67 0 R +/Prev 75 0 R +/Next 83 0 R +>> endobj +75 0 obj << +/Title 76 0 R +/A 73 0 R +/Parent 67 0 R +/Prev 71 0 R +/Next 79 0 R +>> endobj +71 0 obj << +/Title 72 0 R +/A 69 0 R +/Parent 67 0 R +/Next 75 0 R +>> endobj +67 0 obj << +/Title 68 0 R +/A 65 0 R +/Parent 1356 0 R +/Prev 7 0 R +/Next 91 0 R +/First 71 0 R +/Last 87 0 R +/Count -5 +>> endobj +63 0 obj << +/Title 64 0 R +/A 61 0 R +/Parent 23 0 R +/Prev 55 0 R +>> endobj +59 0 obj << +/Title 60 0 R +/A 57 0 R +/Parent 55 0 R +>> endobj +55 0 obj << +/Title 56 0 R +/A 53 0 R +/Parent 23 0 R +/Prev 39 0 R +/Next 63 0 R +/First 59 0 R +/Last 59 0 R +/Count -1 +>> endobj +51 0 obj << +/Title 52 0 R +/A 49 0 R +/Parent 39 0 R +/Prev 47 0 R +>> endobj +47 0 obj << +/Title 48 0 R +/A 45 0 R +/Parent 39 0 R +/Prev 43 0 R +/Next 51 0 R +>> endobj +43 0 obj << +/Title 44 0 R +/A 41 0 R +/Parent 39 0 R +/Next 47 0 R +>> endobj +39 0 obj << +/Title 40 0 R +/A 37 0 R +/Parent 23 0 R +/Prev 35 0 R +/Next 55 0 R +/First 43 0 R +/Last 51 0 R +/Count -3 +>> endobj +35 0 obj << +/Title 36 0 R +/A 33 0 R +/Parent 23 0 R +/Prev 31 0 R +/Next 39 0 R +>> endobj +31 0 obj << +/Title 32 0 R +/A 29 0 R +/Parent 23 0 R +/Prev 27 0 R +/Next 35 0 R +>> endobj +27 0 obj << +/Title 28 0 R +/A 25 0 R +/Parent 23 0 R +/Next 31 0 R +>> endobj +23 0 obj << +/Title 24 0 R +/A 21 0 R +/Parent 7 0 R +/Prev 19 0 R +/First 27 0 R +/Last 63 0 R +/Count -6 +>> endobj +19 0 obj << +/Title 20 0 R +/A 17 0 R +/Parent 7 0 R +/Prev 15 0 R +/Next 23 0 R +>> endobj +15 0 obj << +/Title 16 0 R +/A 13 0 R +/Parent 7 0 R +/Prev 11 0 R +/Next 19 0 R +>> endobj +11 0 obj << +/Title 12 0 R +/A 9 0 R +/Parent 7 0 R +/Next 15 0 R +>> endobj +7 0 obj << +/Title 8 0 R +/A 5 0 R +/Parent 1356 0 R +/Next 67 0 R +/First 11 0 R +/Last 23 0 R +/Count -4 +>> endobj +1357 0 obj << +/Names [(Access_Control_Lists) 1172 0 R (Bv9ARM.ch01) 613 0 R (Bv9ARM.ch02) 667 0 R (Bv9ARM.ch03) 682 0 R (Bv9ARM.ch04) 730 0 R (Bv9ARM.ch05) 810 0 R (Bv9ARM.ch06) 822 0 R (Bv9ARM.ch07) 1171 0 R (Bv9ARM.ch08) 1189 0 R (Bv9ARM.ch09) 1205 0 R (Configuration_File_Grammar) 849 0 R (DNSSEC) 782 0 R (Doc-Start) 594 0 R (Setting_TTLs) 1141 0 R (access_control) 963 0 R (acl) 857 0 R (address_match_lists) 827 0 R (admin_tools) 704 0 R (appendix.A) 554 0 R (bibliography) 1217 0 R (boolean_options) 736 0 R (builtin) 1025 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 226 0 R (chapter.6) 238 0 R (chapter.7) 510 0 R (chapter.8) 534 0 R (cite.RFC1034) 1233 0 R (cite.RFC1035) 1235 0 R (cite.RFC1101) 1290 0 R (cite.RFC1123) 1292 0 R (cite.RFC1183) 1270 0 R (cite.RFC1464) 1310 0 R (cite.RFC1535) 1262 0 R (cite.RFC1536) 1264 0 R (cite.RFC1537) 1300 0 R (cite.RFC1591) 1294 0 R (cite.RFC1706) 1272 0 R (cite.RFC1712) 1324 0 R (cite.RFC1713) 1312 0 R (cite.RFC1794) 1314 0 R (cite.RFC1876) 1274 0 R (cite.RFC1886) 1254 0 R (cite.RFC1912) 1302 0 R (cite.RFC1982) 1266 0 R (cite.RFC1995) 1240 0 R (cite.RFC1996) 1242 0 R (cite.RFC2010) 1304 0 R (cite.RFC2052) 1280 0 R (cite.RFC2065) 1256 0 R (cite.RFC2136) 1244 0 R (cite.RFC2137) 1258 0 R (cite.RFC2163) 1282 0 R (cite.RFC2168) 1284 0 R (cite.RFC2181) 1246 0 R (cite.RFC2219) 1306 0 R (cite.RFC2230) 1286 0 R (cite.RFC2240) 1316 0 R (cite.RFC2308) 1248 0 R (cite.RFC2317) 1296 0 R (cite.RFC2345) 1318 0 R (cite.RFC2352) 1320 0 R (cite.RFC2845) 1250 0 R (cite.RFC974) 1237 0 R (cite.id2492354) 1333 0 R (configuration_file_elements) 823 0 R (controls_statement_definition_and_usage) 718 0 R (diagnostic_tools) 655 0 R (dynamic_update) 734 0 R (dynamic_update_policies) 774 0 R (dynamic_update_security) 972 0 R (historical_dns_information) 1212 0 R (id2465864) 614 0 R (id2466744) 615 0 R (id2466798) 619 0 R (id2466807) 620 0 R (id2467648) 690 0 R (id2467665) 691 0 R (id2468484) 635 0 R (id2468627) 637 0 R (id2468647) 638 0 R (id2468664) 999 0 R (id2468955) 639 0 R (id2469040) 642 0 R (id2469114) 649 0 R (id2469205) 652 0 R (id2469226) 653 0 R (id2469245) 654 0 R (id2469274) 660 0 R (id2469306) 661 0 R (id2469332) 662 0 R (id2469364) 668 0 R (id2469388) 669 0 R (id2469399) 670 0 R (id2469481) 671 0 R (id2469490) 677 0 R (id2469521) 684 0 R (id2469537) 685 0 R (id2470116) 694 0 R (id2470121) 695 0 R (id2471306) 723 0 R (id2471318) 724 0 R (id2471731) 745 0 R (id2472292) 761 0 R (id2472308) 762 0 R (id2472342) 763 0 R (id2472358) 769 0 R (id2472366) 770 0 R (id2472406) 771 0 R (id2472458) 772 0 R (id2472502) 779 0 R (id2472516) 780 0 R (id2472633) 781 0 R (id2472699) 790 0 R (id2472766) 791 0 R (id2472909) 792 0 R (id2472933) 797 0 R (id2472992) 799 0 R (id2473012) 800 0 R (id2473180) 811 0 R (id2473387) 824 0 R (id2474020) 832 0 R (id2474046) 833 0 R (id2474140) 838 0 R (id2474155) 839 0 R (id2474184) 840 0 R (id2474329) 850 0 R (id2474694) 856 0 R (id2474736) 858 0 R (id2474862) 860 0 R (id2475131) 868 0 R (id2475146) 869 0 R (id2475169) 870 0 R (id2475190) 871 0 R (id2475261) 880 0 R (id2475456) 881 0 R (id2475508) 882 0 R (id2476201) 897 0 R (id2476729) 903 0 R (id2476870) 904 0 R (id2476933) 912 0 R (id2476977) 913 0 R (id2476992) 914 0 R (id2478674) 934 0 R (id2479741) 960 0 R (id2479792) 962 0 R (id2479971) 971 0 R (id2480128) 977 0 R (id2480722) 989 0 R (id2480738) 990 0 R (id2480976) 997 0 R (id2483475) 1017 0 R (id2483930) 1032 0 R (id2484556) 1042 0 R (id2484673) 1043 0 R (id2484741) 1049 0 R (id2485414) 1058 0 R (id2485420) 1059 0 R (id2485425) 1060 0 R (id2485658) 1066 0 R (id2485689) 1067 0 R (id2486790) 1105 0 R (id2486949) 1107 0 R (id2486967) 1108 0 R (id2486988) 1111 0 R (id2487128) 1117 0 R (id2487779) 1123 0 R (id2487888) 1125 0 R (id2487909) 1130 0 R (id2488198) 1132 0 R (id2488313) 1134 0 R (id2488331) 1135 0 R (id2488705) 1142 0 R (id2488878) 1144 0 R (id2488892) 1145 0 R (id2488984) 1147 0 R (id2489003) 1148 0 R (id2489059) 1154 0 R (id2489122) 1155 0 R (id2489153) 1156 0 R (id2489213) 1161 0 R (id2489545) 1182 0 R (id2489621) 1183 0 R (id2489678) 1184 0 R (id2489885) 1190 0 R (id2489891) 1191 0 R (id2489902) 1192 0 R (id2489920) 1193 0 R (id2490050) 1206 0 R (id2490055) 1207 0 R (id2490243) 1213 0 R (id2490554) 1215 0 R (id2490899) 1229 0 R (id2490901) 1231 0 R (id2490909) 1236 0 R (id2491001) 1232 0 R (id2491025) 1234 0 R (id2491062) 1245 0 R (id2491088) 1247 0 R (id2491113) 1239 0 R (id2491138) 1241 0 R (id2491161) 1243 0 R (id2491217) 1249 0 R (id2491277) 1252 0 R (id2491292) 1253 0 R (id2491331) 1255 0 R (id2491370) 1257 0 R (id2491398) 1260 0 R (id2491406) 1261 0 R (id2491432) 1263 0 R (id2491499) 1265 0 R (id2491536) 1268 0 R (id2491541) 1269 0 R (id2491598) 1271 0 R (id2491636) 1283 0 R (id2491671) 1273 0 R (id2491725) 1279 0 R (id2491765) 1281 0 R (id2491792) 1285 0 R (id2491818) 1288 0 R (id2491826) 1289 0 R (id2491851) 1291 0 R (id2491875) 1293 0 R (id2491896) 1295 0 R (id2491943) 1298 0 R (id2491950) 1299 0 R (id2491976) 1301 0 R (id2492003) 1303 0 R (id2492039) 1305 0 R (id2492078) 1308 0 R (id2492099) 1309 0 R (id2492121) 1311 0 R (id2492146) 1313 0 R (id2492170) 1315 0 R (id2492193) 1317 0 R (id2492238) 1319 0 R (id2492263) 1322 0 R (id2492269) 1323 0 R (id2492342) 1330 0 R (id2492352) 1332 0 R (id2492354) 1334 0 R (incremental_zone_transfers) 742 0 R (internet_drafts) 1325 0 R (ipv6addresses) 801 0 R (journal) 735 0 R (lwresd) 812 0 R (notify) 731 0 R (options) 923 0 R (page.1) 593 0 R (page.10) 689 0 R (page.11) 700 0 R (page.12) 708 0 R (page.13) 715 0 R (page.14) 722 0 R (page.15) 729 0 R (page.16) 741 0 R (page.17) 750 0 R (page.18) 755 0 R (page.19) 759 0 R (page.2) 605 0 R (page.20) 768 0 R (page.21) 778 0 R (page.22) 789 0 R (page.23) 796 0 R (page.24) 805 0 R (page.25) 809 0 R (page.26) 817 0 R (page.27) 821 0 R (page.28) 831 0 R (page.29) 837 0 R (page.3) 612 0 R (page.30) 845 0 R (page.31) 855 0 R (page.32) 865 0 R (page.33) 879 0 R (page.34) 886 0 R (page.35) 890 0 R (page.36) 896 0 R (page.37) 902 0 R (page.38) 911 0 R (page.39) 918 0 R (page.4) 631 0 R (page.40) 922 0 R (page.41) 927 0 R (page.42) 933 0 R (page.43) 940 0 R (page.44) 955 0 R (page.45) 959 0 R (page.46) 969 0 R (page.47) 976 0 R (page.48) 984 0 R (page.49) 988 0 R (page.5) 648 0 R (page.50) 996 0 R (page.51) 1003 0 R (page.52) 1008 0 R (page.53) 1015 0 R (page.54) 1023 0 R (page.55) 1031 0 R (page.56) 1039 0 R (page.57) 1048 0 R (page.58) 1053 0 R (page.59) 1057 0 R (page.6) 659 0 R (page.60) 1065 0 R (page.61) 1077 0 R (page.62) 1088 0 R (page.63) 1104 0 R (page.64) 1116 0 R (page.65) 1122 0 R (page.66) 1129 0 R (page.67) 1140 0 R (page.68) 1153 0 R (page.69) 1160 0 R (page.7) 666 0 R (page.70) 1166 0 R (page.71) 1170 0 R (page.72) 1178 0 R (page.73) 1188 0 R (page.74) 1200 0 R (page.75) 1204 0 R (page.76) 1211 0 R (page.77) 1224 0 R (page.78) 1278 0 R (page.79) 1329 0 R (page.8) 676 0 R (page.9) 681 0 R (proposed_standards) 746 0 R (rfcs) 644 0 R (rndc) 875 0 R (rrset_ordering) 696 0 R (sample_configuration) 683 0 R (section*.1) 1228 0 R (section*.10) 1321 0 R (section*.11) 1331 0 R (section*.2) 1230 0 R (section*.3) 1238 0 R (section*.4) 1251 0 R (section*.5) 1259 0 R (section*.6) 1267 0 R (section*.7) 1287 0 R (section*.8) 1297 0 R (section*.9) 1307 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) 154 0 R (section.4.6) 190 0 R (section.4.7) 194 0 R (section.4.8) 198 0 R (section.4.9) 214 0 R (section.5.1) 230 0 R (section.5.2) 234 0 R (section.6.1) 242 0 R (section.6.2) 270 0 R (section.6.3) 462 0 R (section.7.1) 514 0 R (section.7.2) 518 0 R (section.7.3) 530 0 R (section.8.1) 538 0 R (section.8.2) 546 0 R (section.8.3) 550 0 R (section.A.1) 558 0 R (section.A.2) 566 0 R (section.A.3) 574 0 R (server_statement_definition_and_usage) 951 0 R (server_statement_grammar) 1034 0 R (statsfile) 929 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.5.1) 158 0 R (subsection.4.5.2) 170 0 R (subsection.4.5.3) 174 0 R (subsection.4.5.4) 178 0 R (subsection.4.5.5) 182 0 R (subsection.4.5.6) 186 0 R (subsection.4.8.1) 202 0 R (subsection.4.8.2) 206 0 R (subsection.4.8.3) 210 0 R (subsection.4.9.1) 218 0 R (subsection.4.9.2) 222 0 R (subsection.6.1.1) 246 0 R (subsection.6.1.2) 258 0 R (subsection.6.2.1) 274 0 R (subsection.6.2.10) 310 0 R (subsection.6.2.11) 322 0 R (subsection.6.2.12) 326 0 R (subsection.6.2.13) 330 0 R (subsection.6.2.14) 334 0 R (subsection.6.2.15) 338 0 R (subsection.6.2.16) 342 0 R (subsection.6.2.17) 414 0 R (subsection.6.2.18) 418 0 R (subsection.6.2.19) 422 0 R (subsection.6.2.2) 278 0 R (subsection.6.2.20) 426 0 R (subsection.6.2.21) 430 0 R (subsection.6.2.22) 434 0 R (subsection.6.2.23) 438 0 R (subsection.6.2.24) 442 0 R (subsection.6.2.3) 282 0 R (subsection.6.2.4) 286 0 R (subsection.6.2.5) 290 0 R (subsection.6.2.6) 294 0 R (subsection.6.2.7) 298 0 R (subsection.6.2.8) 302 0 R (subsection.6.2.9) 306 0 R (subsection.6.3.1) 466 0 R (subsection.6.3.2) 478 0 R (subsection.6.3.3) 482 0 R (subsection.6.3.4) 486 0 R (subsection.6.3.5) 490 0 R (subsection.6.3.6) 506 0 R (subsection.7.2.1) 522 0 R (subsection.7.2.2) 526 0 R (subsection.8.1.1) 542 0 R (subsection.A.1.1) 562 0 R (subsection.A.2.1) 570 0 R (subsection.A.3.1) 578 0 R (subsection.A.3.2) 582 0 R (subsection.A.3.3) 586 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) 162 0 R (subsubsection.4.5.1.2) 166 0 R (subsubsection.6.1.1.1) 250 0 R (subsubsection.6.1.1.2) 254 0 R (subsubsection.6.1.2.1) 262 0 R (subsubsection.6.1.2.2) 266 0 R (subsubsection.6.2.10.1) 314 0 R (subsubsection.6.2.10.2) 318 0 R (subsubsection.6.2.16.1) 346 0 R (subsubsection.6.2.16.10) 382 0 R (subsubsection.6.2.16.11) 386 0 R (subsubsection.6.2.16.12) 390 0 R (subsubsection.6.2.16.13) 394 0 R (subsubsection.6.2.16.14) 398 0 R (subsubsection.6.2.16.15) 402 0 R (subsubsection.6.2.16.16) 406 0 R (subsubsection.6.2.16.17) 410 0 R (subsubsection.6.2.16.2) 350 0 R (subsubsection.6.2.16.3) 354 0 R (subsubsection.6.2.16.4) 358 0 R (subsubsection.6.2.16.5) 362 0 R (subsubsection.6.2.16.6) 366 0 R (subsubsection.6.2.16.7) 370 0 R (subsubsection.6.2.16.8) 374 0 R (subsubsection.6.2.16.9) 378 0 R (subsubsection.6.2.24.1) 446 0 R (subsubsection.6.2.24.2) 450 0 R (subsubsection.6.2.24.3) 454 0 R (subsubsection.6.2.24.4) 458 0 R (subsubsection.6.3.1.1) 470 0 R (subsubsection.6.3.1.2) 474 0 R (subsubsection.6.3.5.1) 494 0 R (subsubsection.6.3.5.2) 498 0 R (subsubsection.6.3.5.3) 502 0 R (table.1.1) 621 0 R (table.1.2) 636 0 R (table.3.1) 692 0 R (table.3.2) 725 0 R (table.6.1) 825 0 R (table.6.10) 1112 0 R (table.6.11) 1118 0 R (table.6.12) 1124 0 R (table.6.13) 1131 0 R (table.6.14) 1133 0 R (table.6.15) 1136 0 R (table.6.16) 1143 0 R (table.6.17) 1146 0 R (table.6.18) 1162 0 R (table.6.2) 851 0 R (table.6.3) 859 0 R (table.6.4) 898 0 R (table.6.5) 935 0 R (table.6.6) 1018 0 R (table.6.7) 1033 0 R (table.6.8) 1061 0 R (table.6.9) 1106 0 R (table.A.1) 1214 0 R (table.A.2) 1216 0 R (the_category_phrase) 892 0 R (the_sortlist_statement) 1009 0 R (topology) 1004 0 R (tsig) 760 0 R (tuning) 1019 0 R (types_of_resource_records_and_when_to_use_them) 643 0 R (view_statement_grammar) 1027 0 R (zone_statement_grammar) 965 0 R (zone_transfers) 737 0 R] +/Limits [(Access_Control_Lists) (zone_transfers)] +>> endobj +1358 0 obj << +/Kids [1357 0 R] +>> endobj +1359 0 obj << +/Dests 1358 0 R +>> endobj +1360 0 obj << +/Type /Catalog +/Pages 1355 0 R +/Outlines 1356 0 R +/Names 1359 0 R +/PageMode /UseOutlines +/OpenAction 589 0 R +>> endobj +1361 0 obj << +/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords() +/CreationDate (D:20051104123603+11'00') +/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4) +>> endobj +xref +0 1362 +0000000001 65535 f +0000000002 00000 f +0000000003 00000 f +0000000004 00000 f +0000000000 00000 f +0000000009 00000 n +0000018859 00000 n +0000483529 00000 n +0000000054 00000 n +0000000086 00000 n +0000018983 00000 n +0000483457 00000 n +0000000133 00000 n +0000000173 00000 n +0000019108 00000 n +0000483371 00000 n +0000000221 00000 n +0000000273 00000 n +0000019233 00000 n +0000483285 00000 n +0000000321 00000 n +0000000377 00000 n +0000023668 00000 n +0000483175 00000 n +0000000425 00000 n +0000000478 00000 n +0000023792 00000 n +0000483101 00000 n +0000000531 00000 n +0000000572 00000 n +0000023917 00000 n +0000483014 00000 n +0000000625 00000 n +0000000674 00000 n +0000024042 00000 n +0000482927 00000 n +0000000727 00000 n +0000000757 00000 n +0000028190 00000 n +0000482803 00000 n +0000000810 00000 n +0000000861 00000 n +0000028315 00000 n +0000482729 00000 n +0000000919 00000 n +0000000964 00000 n +0000028440 00000 n +0000482642 00000 n +0000001022 00000 n +0000001062 00000 n +0000028565 00000 n +0000482568 00000 n +0000001120 00000 n +0000001162 00000 n +0000031474 00000 n +0000482444 00000 n +0000001215 00000 n +0000001260 00000 n +0000031599 00000 n +0000482383 00000 n +0000001318 00000 n +0000001355 00000 n +0000031724 00000 n +0000482309 00000 n +0000001408 00000 n +0000001463 00000 n +0000034112 00000 n +0000482184 00000 n +0000001509 00000 n +0000001556 00000 n +0000034237 00000 n +0000482110 00000 n +0000001604 00000 n +0000001648 00000 n +0000034362 00000 n +0000482023 00000 n +0000001696 00000 n +0000001735 00000 n +0000034485 00000 n +0000481936 00000 n +0000001783 00000 n +0000001825 00000 n +0000034609 00000 n +0000481849 00000 n +0000001873 00000 n +0000001936 00000 n +0000035645 00000 n +0000481775 00000 n +0000001984 00000 n +0000002034 00000 n +0000037323 00000 n +0000481647 00000 n +0000002080 00000 n +0000002126 00000 n +0000037447 00000 n +0000481534 00000 n +0000002174 00000 n +0000002218 00000 n +0000037572 00000 n +0000481458 00000 n +0000002271 00000 n +0000002323 00000 n +0000037697 00000 n +0000481381 00000 n +0000002377 00000 n +0000002436 00000 n +0000040313 00000 n +0000481290 00000 n +0000002485 00000 n +0000002523 00000 n +0000040564 00000 n +0000481173 00000 n +0000002572 00000 n +0000002618 00000 n +0000040690 00000 n +0000481055 00000 n +0000002672 00000 n +0000002739 00000 n +0000043869 00000 n +0000480976 00000 n +0000002798 00000 n +0000002842 00000 n +0000043995 00000 n +0000480897 00000 n +0000002901 00000 n +0000002949 00000 n +0000053818 00000 n +0000480818 00000 n +0000003003 00000 n +0000003036 00000 n +0000057084 00000 n +0000480686 00000 n +0000003083 00000 n +0000003126 00000 n +0000057210 00000 n +0000480607 00000 n +0000003175 00000 n +0000003205 00000 n +0000057336 00000 n +0000480475 00000 n +0000003254 00000 n +0000003292 00000 n +0000057461 00000 n +0000480410 00000 n +0000003346 00000 n +0000003388 00000 n +0000061908 00000 n +0000480317 00000 n +0000003437 00000 n +0000003496 00000 n +0000062034 00000 n +0000480224 00000 n +0000003545 00000 n +0000003578 00000 n +0000068735 00000 n +0000480092 00000 n +0000003627 00000 n +0000003655 00000 n +0000068861 00000 n +0000479974 00000 n +0000003709 00000 n +0000003778 00000 n +0000068987 00000 n +0000479895 00000 n +0000003837 00000 n +0000003885 00000 n +0000069113 00000 n +0000479816 00000 n +0000003944 00000 n +0000003989 00000 n +0000072115 00000 n +0000479723 00000 n +0000004043 00000 n +0000004111 00000 n +0000072241 00000 n +0000479630 00000 n +0000004165 00000 n +0000004235 00000 n +0000072367 00000 n +0000479537 00000 n +0000004289 00000 n +0000004352 00000 n +0000072493 00000 n +0000479444 00000 n +0000004406 00000 n +0000004461 00000 n +0000076214 00000 n +0000479365 00000 n +0000004515 00000 n +0000004547 00000 n +0000076340 00000 n +0000479272 00000 n +0000004596 00000 n +0000004624 00000 n +0000076465 00000 n +0000479179 00000 n +0000004673 00000 n +0000004705 00000 n +0000076591 00000 n +0000479047 00000 n +0000004754 00000 n +0000004784 00000 n +0000080038 00000 n +0000478968 00000 n +0000004838 00000 n +0000004879 00000 n +0000080163 00000 n +0000478875 00000 n +0000004933 00000 n +0000004975 00000 n +0000080289 00000 n +0000478796 00000 n +0000005029 00000 n +0000005074 00000 n +0000082997 00000 n +0000478678 00000 n +0000005123 00000 n +0000005169 00000 n +0000083123 00000 n +0000478599 00000 n +0000005223 00000 n +0000005283 00000 n +0000083249 00000 n +0000478520 00000 n +0000005337 00000 n +0000005406 00000 n +0000086059 00000 n +0000478387 00000 n +0000005453 00000 n +0000005506 00000 n +0000086185 00000 n +0000478308 00000 n +0000005555 00000 n +0000005611 00000 n +0000086311 00000 n +0000478229 00000 n +0000005660 00000 n +0000005709 00000 n +0000090413 00000 n +0000478096 00000 n +0000005756 00000 n +0000005808 00000 n +0000090539 00000 n +0000477978 00000 n +0000005857 00000 n +0000005908 00000 n +0000094681 00000 n +0000477860 00000 n +0000005962 00000 n +0000006007 00000 n +0000094806 00000 n +0000477781 00000 n +0000006066 00000 n +0000006100 00000 n +0000094931 00000 n +0000477702 00000 n +0000006159 00000 n +0000006207 00000 n +0000098209 00000 n +0000477584 00000 n +0000006261 00000 n +0000006301 00000 n +0000098335 00000 n +0000477505 00000 n +0000006360 00000 n +0000006394 00000 n +0000098461 00000 n +0000477426 00000 n +0000006453 00000 n +0000006501 00000 n +0000102189 00000 n +0000477293 00000 n +0000006550 00000 n +0000006600 00000 n +0000105995 00000 n +0000477214 00000 n +0000006654 00000 n +0000006701 00000 n +0000106121 00000 n +0000477121 00000 n +0000006755 00000 n +0000006815 00000 n +0000106371 00000 n +0000477028 00000 n +0000006869 00000 n +0000006921 00000 n +0000106497 00000 n +0000476935 00000 n +0000006975 00000 n +0000007040 00000 n +0000111147 00000 n +0000476842 00000 n +0000007094 00000 n +0000007145 00000 n +0000111273 00000 n +0000476749 00000 n +0000007199 00000 n +0000007263 00000 n +0000111399 00000 n +0000476656 00000 n +0000007317 00000 n +0000007364 00000 n +0000111525 00000 n +0000476563 00000 n +0000007418 00000 n +0000007478 00000 n +0000114467 00000 n +0000476470 00000 n +0000007532 00000 n +0000007583 00000 n +0000114593 00000 n +0000476338 00000 n +0000007638 00000 n +0000007703 00000 n +0000114719 00000 n +0000476259 00000 n +0000007763 00000 n +0000007810 00000 n +0000125127 00000 n +0000476180 00000 n +0000007870 00000 n +0000007918 00000 n +0000128845 00000 n +0000476087 00000 n +0000007973 00000 n +0000008023 00000 n +0000128971 00000 n +0000475994 00000 n +0000008078 00000 n +0000008141 00000 n +0000130711 00000 n +0000475901 00000 n +0000008196 00000 n +0000008248 00000 n +0000130837 00000 n +0000475808 00000 n +0000008303 00000 n +0000008368 00000 n +0000130963 00000 n +0000475715 00000 n +0000008423 00000 n +0000008475 00000 n +0000136313 00000 n +0000475582 00000 n +0000008530 00000 n +0000008595 00000 n +0000140379 00000 n +0000475503 00000 n +0000008655 00000 n +0000008699 00000 n +0000159492 00000 n +0000475410 00000 n +0000008759 00000 n +0000008798 00000 n +0000159618 00000 n +0000475317 00000 n +0000008858 00000 n +0000008905 00000 n +0000159743 00000 n +0000475224 00000 n +0000008965 00000 n +0000009008 00000 n +0000163657 00000 n +0000475131 00000 n +0000009068 00000 n +0000009107 00000 n +0000166745 00000 n +0000475038 00000 n +0000009167 00000 n +0000009209 00000 n +0000166871 00000 n +0000474945 00000 n +0000009269 00000 n +0000009312 00000 n +0000174775 00000 n +0000474852 00000 n +0000009372 00000 n +0000009419 00000 n +0000174899 00000 n +0000474759 00000 n +0000009479 00000 n +0000009540 00000 n +0000178845 00000 n +0000474666 00000 n +0000009601 00000 n +0000009653 00000 n +0000178971 00000 n +0000474573 00000 n +0000009714 00000 n +0000009767 00000 n +0000181984 00000 n +0000474480 00000 n +0000009828 00000 n +0000009866 00000 n +0000185943 00000 n +0000474387 00000 n +0000009927 00000 n +0000009979 00000 n +0000189321 00000 n +0000474294 00000 n +0000010040 00000 n +0000010084 00000 n +0000189579 00000 n +0000474201 00000 n +0000010145 00000 n +0000010181 00000 n +0000194073 00000 n +0000474108 00000 n +0000010242 00000 n +0000010305 00000 n +0000197229 00000 n +0000474029 00000 n +0000010366 00000 n +0000010415 00000 n +0000197486 00000 n +0000473936 00000 n +0000010470 00000 n +0000010521 00000 n +0000197615 00000 n +0000473843 00000 n +0000010576 00000 n +0000010640 00000 n +0000202325 00000 n +0000473750 00000 n +0000010695 00000 n +0000010752 00000 n +0000202454 00000 n +0000473657 00000 n +0000010807 00000 n +0000010877 00000 n +0000206017 00000 n +0000473564 00000 n +0000010932 00000 n +0000010981 00000 n +0000206146 00000 n +0000473471 00000 n +0000011036 00000 n +0000011098 00000 n +0000207911 00000 n +0000473378 00000 n +0000011153 00000 n +0000011202 00000 n +0000211360 00000 n +0000473260 00000 n +0000011257 00000 n +0000011319 00000 n +0000211489 00000 n +0000473181 00000 n +0000011379 00000 n +0000011418 00000 n +0000216452 00000 n +0000473088 00000 n +0000011478 00000 n +0000011512 00000 n +0000216581 00000 n +0000472995 00000 n +0000011572 00000 n +0000011613 00000 n +0000226764 00000 n +0000472916 00000 n +0000011673 00000 n +0000011725 00000 n +0000230938 00000 n +0000472798 00000 n +0000011774 00000 n +0000011807 00000 n +0000231067 00000 n +0000472680 00000 n +0000011861 00000 n +0000011933 00000 n +0000231195 00000 n +0000472601 00000 n +0000011992 00000 n +0000012036 00000 n +0000238969 00000 n +0000472522 00000 n +0000012095 00000 n +0000012148 00000 n +0000242553 00000 n +0000472429 00000 n +0000012202 00000 n +0000012252 00000 n +0000245916 00000 n +0000472336 00000 n +0000012306 00000 n +0000012344 00000 n +0000246174 00000 n +0000472243 00000 n +0000012398 00000 n +0000012447 00000 n +0000246432 00000 n +0000472111 00000 n +0000012501 00000 n +0000012553 00000 n +0000246561 00000 n +0000472032 00000 n +0000012612 00000 n +0000012664 00000 n +0000249442 00000 n +0000471939 00000 n +0000012723 00000 n +0000012776 00000 n +0000249571 00000 n +0000471860 00000 n +0000012835 00000 n +0000012884 00000 n +0000249700 00000 n +0000471781 00000 n +0000012938 00000 n +0000013018 00000 n +0000255562 00000 n +0000471648 00000 n +0000013065 00000 n +0000013117 00000 n +0000255691 00000 n +0000471569 00000 n +0000013166 00000 n +0000013210 00000 n +0000259402 00000 n +0000471437 00000 n +0000013259 00000 n +0000013321 00000 n +0000259531 00000 n +0000471358 00000 n +0000013375 00000 n +0000013423 00000 n +0000259660 00000 n +0000471279 00000 n +0000013477 00000 n +0000013528 00000 n +0000259789 00000 n +0000471200 00000 n +0000013577 00000 n +0000013624 00000 n +0000262719 00000 n +0000471067 00000 n +0000013671 00000 n +0000013708 00000 n +0000262848 00000 n +0000470949 00000 n +0000013757 00000 n +0000013796 00000 n +0000262977 00000 n +0000470884 00000 n +0000013850 00000 n +0000013928 00000 n +0000263106 00000 n +0000470791 00000 n +0000013977 00000 n +0000014044 00000 n +0000263235 00000 n +0000470712 00000 n +0000014093 00000 n +0000014138 00000 n +0000266737 00000 n +0000470593 00000 n +0000014186 00000 n +0000014218 00000 n +0000266866 00000 n +0000470475 00000 n +0000014267 00000 n +0000014306 00000 n +0000266995 00000 n +0000470410 00000 n +0000014360 00000 n +0000014421 00000 n +0000271002 00000 n +0000470278 00000 n +0000014470 00000 n +0000014527 00000 n +0000271131 00000 n +0000470213 00000 n +0000014581 00000 n +0000014630 00000 n +0000271519 00000 n +0000470095 00000 n +0000014679 00000 n +0000014741 00000 n +0000271648 00000 n +0000470016 00000 n +0000014795 00000 n +0000014850 00000 n +0000284749 00000 n +0000469923 00000 n +0000014904 00000 n +0000014945 00000 n +0000285811 00000 n +0000469844 00000 n +0000014999 00000 n +0000015051 00000 n +0000015405 00000 n +0000015653 00000 n +0000015104 00000 n +0000015527 00000 n +0000015590 00000 n +0000466703 00000 n +0000441039 00000 n +0000466529 00000 n +0000439990 00000 n +0000414055 00000 n +0000439816 00000 n +0000467708 00000 n +0000016305 00000 n +0000016120 00000 n +0000015738 00000 n +0000016242 00000 n +0000413370 00000 n +0000411224 00000 n +0000413206 00000 n +0000019484 00000 n +0000018674 00000 n +0000016390 00000 n +0000018796 00000 n +0000018920 00000 n +0000019045 00000 n +0000019170 00000 n +0000410370 00000 n +0000390012 00000 n +0000410196 00000 n +0000019295 00000 n +0000019358 00000 n +0000019421 00000 n +0000389071 00000 n +0000369672 00000 n +0000388898 00000 n +0000368945 00000 n +0000352561 00000 n +0000368772 00000 n +0000024167 00000 n +0000022985 00000 n +0000019608 00000 n +0000023479 00000 n +0000352026 00000 n +0000335109 00000 n +0000351842 00000 n +0000023542 00000 n +0000023605 00000 n +0000023729 00000 n +0000023854 00000 n +0000023979 00000 n +0000023135 00000 n +0000023328 00000 n +0000024104 00000 n +0000231131 00000 n +0000271712 00000 n +0000028690 00000 n +0000027655 00000 n +0000024291 00000 n +0000028127 00000 n +0000028252 00000 n +0000027805 00000 n +0000027967 00000 n +0000028377 00000 n +0000028502 00000 n +0000028627 00000 n +0000043932 00000 n +0000031848 00000 n +0000031289 00000 n +0000028814 00000 n +0000031411 00000 n +0000031536 00000 n +0000031661 00000 n +0000031785 00000 n +0000034734 00000 n +0000033927 00000 n +0000031959 00000 n +0000034049 00000 n +0000034174 00000 n +0000034299 00000 n +0000034424 00000 n +0000034546 00000 n +0000034671 00000 n +0000467826 00000 n +0000035770 00000 n +0000035460 00000 n +0000034819 00000 n +0000035582 00000 n +0000035707 00000 n +0000037823 00000 n +0000037138 00000 n +0000035868 00000 n +0000037260 00000 n +0000037385 00000 n +0000037509 00000 n +0000037634 00000 n +0000037760 00000 n +0000040816 00000 n +0000039949 00000 n +0000037921 00000 n +0000040250 00000 n +0000040376 00000 n +0000040439 00000 n +0000040501 00000 n +0000040091 00000 n +0000040627 00000 n +0000040753 00000 n +0000189385 00000 n +0000044121 00000 n +0000043684 00000 n +0000040927 00000 n +0000043806 00000 n +0000334582 00000 n +0000325273 00000 n +0000334405 00000 n +0000044058 00000 n +0000047626 00000 n +0000047441 00000 n +0000044245 00000 n +0000047563 00000 n +0000324830 00000 n +0000318031 00000 n +0000324653 00000 n +0000051895 00000 n +0000051505 00000 n +0000047789 00000 n +0000051832 00000 n +0000051647 00000 n +0000467944 00000 n +0000106560 00000 n +0000054068 00000 n +0000053633 00000 n +0000052032 00000 n +0000053755 00000 n +0000053881 00000 n +0000053942 00000 n +0000054005 00000 n +0000057587 00000 n +0000056549 00000 n +0000054192 00000 n +0000057021 00000 n +0000057147 00000 n +0000057273 00000 n +0000056699 00000 n +0000056860 00000 n +0000057398 00000 n +0000057524 00000 n +0000140442 00000 n +0000166934 00000 n +0000062160 00000 n +0000061369 00000 n +0000057685 00000 n +0000061845 00000 n +0000061971 00000 n +0000061519 00000 n +0000061684 00000 n +0000062097 00000 n +0000276260 00000 n +0000064989 00000 n +0000064617 00000 n +0000062310 00000 n +0000064926 00000 n +0000064759 00000 n +0000066145 00000 n +0000065960 00000 n +0000065113 00000 n +0000066082 00000 n +0000069239 00000 n +0000068550 00000 n +0000066243 00000 n +0000068672 00000 n +0000068798 00000 n +0000068924 00000 n +0000069050 00000 n +0000069176 00000 n +0000468062 00000 n +0000072619 00000 n +0000071742 00000 n +0000069376 00000 n +0000072052 00000 n +0000072178 00000 n +0000072304 00000 n +0000072430 00000 n +0000072556 00000 n +0000071884 00000 n +0000226828 00000 n +0000076716 00000 n +0000076029 00000 n +0000072756 00000 n +0000076151 00000 n +0000076277 00000 n +0000076403 00000 n +0000076528 00000 n +0000076653 00000 n +0000317678 00000 n +0000315683 00000 n +0000317515 00000 n +0000080413 00000 n +0000079853 00000 n +0000076853 00000 n +0000079975 00000 n +0000080100 00000 n +0000080226 00000 n +0000080350 00000 n +0000083375 00000 n +0000082633 00000 n +0000080537 00000 n +0000082934 00000 n +0000083060 00000 n +0000082775 00000 n +0000083186 00000 n +0000083312 00000 n +0000271195 00000 n +0000083833 00000 n +0000083648 00000 n +0000083499 00000 n +0000083770 00000 n +0000086437 00000 n +0000085874 00000 n +0000083874 00000 n +0000085996 00000 n +0000086122 00000 n +0000086248 00000 n +0000086374 00000 n +0000468180 00000 n +0000086869 00000 n +0000086684 00000 n +0000086535 00000 n +0000086806 00000 n +0000090790 00000 n +0000090042 00000 n +0000086910 00000 n +0000090350 00000 n +0000090476 00000 n +0000090601 00000 n +0000090664 00000 n +0000090727 00000 n +0000090184 00000 n +0000094744 00000 n +0000095057 00000 n +0000094496 00000 n +0000090888 00000 n +0000094618 00000 n +0000094868 00000 n +0000094994 00000 n +0000098587 00000 n +0000098024 00000 n +0000095194 00000 n +0000098146 00000 n +0000098272 00000 n +0000098398 00000 n +0000098524 00000 n +0000101201 00000 n +0000102440 00000 n +0000101079 00000 n +0000098698 00000 n +0000102126 00000 n +0000314870 00000 n +0000306196 00000 n +0000314698 00000 n +0000102252 00000 n +0000102315 00000 n +0000102378 00000 n +0000106623 00000 n +0000105810 00000 n +0000102592 00000 n +0000105932 00000 n +0000106058 00000 n +0000106182 00000 n +0000106245 00000 n +0000106308 00000 n +0000106434 00000 n +0000468298 00000 n +0000111651 00000 n +0000110085 00000 n +0000106734 00000 n +0000111084 00000 n +0000110259 00000 n +0000110409 00000 n +0000111210 00000 n +0000111336 00000 n +0000111462 00000 n +0000111588 00000 n +0000110567 00000 n +0000110718 00000 n +0000110902 00000 n +0000286325 00000 n +0000114845 00000 n +0000114282 00000 n +0000111788 00000 n +0000114404 00000 n +0000114530 00000 n +0000114656 00000 n +0000114782 00000 n +0000119363 00000 n +0000119178 00000 n +0000114982 00000 n +0000119300 00000 n +0000122390 00000 n +0000122020 00000 n +0000119474 00000 n +0000122327 00000 n +0000122162 00000 n +0000125190 00000 n +0000125379 00000 n +0000124942 00000 n +0000122501 00000 n +0000125064 00000 n +0000125253 00000 n +0000125316 00000 n +0000129097 00000 n +0000128329 00000 n +0000125490 00000 n +0000128782 00000 n +0000128908 00000 n +0000129034 00000 n +0000128479 00000 n +0000128630 00000 n +0000468416 00000 n +0000131089 00000 n +0000130526 00000 n +0000129208 00000 n +0000130648 00000 n +0000130774 00000 n +0000130900 00000 n +0000131026 00000 n +0000132625 00000 n +0000132440 00000 n +0000131200 00000 n +0000132562 00000 n +0000136439 00000 n +0000136128 00000 n +0000132723 00000 n +0000136250 00000 n +0000136376 00000 n +0000140505 00000 n +0000140019 00000 n +0000136563 00000 n +0000140316 00000 n +0000140161 00000 n +0000197293 00000 n +0000144437 00000 n +0000144127 00000 n +0000140629 00000 n +0000144249 00000 n +0000144312 00000 n +0000144374 00000 n +0000148409 00000 n +0000151142 00000 n +0000148227 00000 n +0000144561 00000 n +0000151079 00000 n +0000150045 00000 n +0000150198 00000 n +0000150354 00000 n +0000150538 00000 n +0000150711 00000 n +0000150895 00000 n +0000468534 00000 n +0000149877 00000 n +0000149934 00000 n +0000150023 00000 n +0000197679 00000 n +0000155337 00000 n +0000155152 00000 n +0000151320 00000 n +0000155274 00000 n +0000159869 00000 n +0000158946 00000 n +0000155461 00000 n +0000159429 00000 n +0000159555 00000 n +0000159096 00000 n +0000159681 00000 n +0000159806 00000 n +0000159264 00000 n +0000207975 00000 n +0000163782 00000 n +0000163282 00000 n +0000159980 00000 n +0000163594 00000 n +0000163424 00000 n +0000163720 00000 n +0000259852 00000 n +0000166997 00000 n +0000166560 00000 n +0000163906 00000 n +0000166682 00000 n +0000166808 00000 n +0000305670 00000 n +0000297780 00000 n +0000305497 00000 n +0000170997 00000 n +0000170812 00000 n +0000167162 00000 n +0000170934 00000 n +0000175025 00000 n +0000174397 00000 n +0000171108 00000 n +0000174712 00000 n +0000174836 00000 n +0000174962 00000 n +0000174539 00000 n +0000468652 00000 n +0000179097 00000 n +0000178486 00000 n +0000175190 00000 n +0000178782 00000 n +0000178908 00000 n +0000178628 00000 n +0000179034 00000 n +0000182112 00000 n +0000181794 00000 n +0000179208 00000 n +0000181919 00000 n +0000182047 00000 n +0000186072 00000 n +0000185406 00000 n +0000182278 00000 n +0000185878 00000 n +0000186007 00000 n +0000185561 00000 n +0000185723 00000 n +0000189708 00000 n +0000188941 00000 n +0000186184 00000 n +0000189256 00000 n +0000189087 00000 n +0000189449 00000 n +0000189514 00000 n +0000189643 00000 n +0000194202 00000 n +0000193524 00000 n +0000189874 00000 n +0000194008 00000 n +0000193679 00000 n +0000194137 00000 n +0000193841 00000 n +0000206081 00000 n +0000197742 00000 n +0000197038 00000 n +0000194368 00000 n +0000197164 00000 n +0000197357 00000 n +0000197421 00000 n +0000197550 00000 n +0000468774 00000 n +0000202583 00000 n +0000201630 00000 n +0000197854 00000 n +0000202260 00000 n +0000201795 00000 n +0000201945 00000 n +0000202389 00000 n +0000202518 00000 n +0000202107 00000 n +0000206275 00000 n +0000205826 00000 n +0000202695 00000 n +0000205952 00000 n +0000206210 00000 n +0000208039 00000 n +0000207720 00000 n +0000206387 00000 n +0000207846 00000 n +0000211746 00000 n +0000211169 00000 n +0000208151 00000 n +0000211295 00000 n +0000211424 00000 n +0000211553 00000 n +0000211618 00000 n +0000211683 00000 n +0000216710 00000 n +0000215208 00000 n +0000211858 00000 n +0000216387 00000 n +0000216516 00000 n +0000216645 00000 n +0000215400 00000 n +0000215562 00000 n +0000215724 00000 n +0000215886 00000 n +0000216057 00000 n +0000216227 00000 n +0000221529 00000 n +0000220300 00000 n +0000216822 00000 n +0000221464 00000 n +0000220492 00000 n +0000220655 00000 n +0000220817 00000 n +0000220979 00000 n +0000221139 00000 n +0000221301 00000 n +0000468899 00000 n +0000226892 00000 n +0000224533 00000 n +0000221654 00000 n +0000226699 00000 n +0000224779 00000 n +0000224932 00000 n +0000225094 00000 n +0000225256 00000 n +0000225418 00000 n +0000225580 00000 n +0000225742 00000 n +0000225904 00000 n +0000226066 00000 n +0000226220 00000 n +0000226381 00000 n +0000226536 00000 n +0000231452 00000 n +0000230255 00000 n +0000227017 00000 n +0000230743 00000 n +0000230808 00000 n +0000230873 00000 n +0000231002 00000 n +0000231259 00000 n +0000230411 00000 n +0000230581 00000 n +0000231324 00000 n +0000231388 00000 n +0000235060 00000 n +0000234739 00000 n +0000231577 00000 n +0000234865 00000 n +0000234930 00000 n +0000234995 00000 n +0000239098 00000 n +0000238648 00000 n +0000235159 00000 n +0000238774 00000 n +0000238839 00000 n +0000238904 00000 n +0000239033 00000 n +0000242812 00000 n +0000242102 00000 n +0000239223 00000 n +0000242228 00000 n +0000242293 00000 n +0000242358 00000 n +0000242423 00000 n +0000242488 00000 n +0000242617 00000 n +0000242682 00000 n +0000242747 00000 n +0000246688 00000 n +0000245725 00000 n +0000242937 00000 n +0000245851 00000 n +0000245980 00000 n +0000246045 00000 n +0000246110 00000 n +0000246238 00000 n +0000246302 00000 n +0000246367 00000 n +0000246496 00000 n +0000246624 00000 n +0000469024 00000 n +0000249829 00000 n +0000249251 00000 n +0000246880 00000 n +0000249377 00000 n +0000249506 00000 n +0000249635 00000 n +0000249764 00000 n +0000252798 00000 n +0000252477 00000 n +0000250021 00000 n +0000252603 00000 n +0000252668 00000 n +0000252733 00000 n +0000253251 00000 n +0000253060 00000 n +0000252910 00000 n +0000253186 00000 n +0000255820 00000 n +0000254911 00000 n +0000253293 00000 n +0000255497 00000 n +0000255626 00000 n +0000255755 00000 n +0000255067 00000 n +0000255282 00000 n +0000259916 00000 n +0000259211 00000 n +0000255945 00000 n +0000259337 00000 n +0000297459 00000 n +0000288246 00000 n +0000297273 00000 n +0000259466 00000 n +0000259595 00000 n +0000259724 00000 n +0000263363 00000 n +0000262137 00000 n +0000260081 00000 n +0000262654 00000 n +0000262783 00000 n +0000262912 00000 n +0000263041 00000 n +0000263170 00000 n +0000263299 00000 n +0000262293 00000 n +0000262465 00000 n +0000469149 00000 n +0000263816 00000 n +0000263625 00000 n +0000263475 00000 n +0000263751 00000 n +0000267124 00000 n +0000266546 00000 n +0000263858 00000 n +0000266672 00000 n +0000266801 00000 n +0000266930 00000 n +0000267059 00000 n +0000271776 00000 n +0000270426 00000 n +0000267210 00000 n +0000270937 00000 n +0000271066 00000 n +0000271259 00000 n +0000271324 00000 n +0000271389 00000 n +0000271454 00000 n +0000271583 00000 n +0000270582 00000 n +0000270760 00000 n +0000278658 00000 n +0000274598 00000 n +0000271927 00000 n +0000274772 00000 n +0000275480 00000 n +0000274950 00000 n +0000275128 00000 n +0000275304 00000 n +0000275545 00000 n +0000275610 00000 n +0000275675 00000 n +0000275740 00000 n +0000275805 00000 n +0000275870 00000 n +0000275935 00000 n +0000276000 00000 n +0000276065 00000 n +0000276130 00000 n +0000276195 00000 n +0000276324 00000 n +0000276389 00000 n +0000276454 00000 n +0000276519 00000 n +0000276584 00000 n +0000276648 00000 n +0000276713 00000 n +0000276777 00000 n +0000276842 00000 n +0000276907 00000 n +0000276972 00000 n +0000277037 00000 n +0000277101 00000 n +0000277166 00000 n +0000277231 00000 n +0000277296 00000 n +0000277361 00000 n +0000277426 00000 n +0000277491 00000 n +0000277555 00000 n +0000277620 00000 n +0000277685 00000 n +0000277750 00000 n +0000277815 00000 n +0000277880 00000 n +0000277945 00000 n +0000278010 00000 n +0000278075 00000 n +0000278140 00000 n +0000278205 00000 n +0000278270 00000 n +0000278335 00000 n +0000278400 00000 n +0000278465 00000 n +0000278530 00000 n +0000278594 00000 n +0000284877 00000 n +0000281570 00000 n +0000278809 00000 n +0000281696 00000 n +0000281761 00000 n +0000281826 00000 n +0000281891 00000 n +0000281956 00000 n +0000282021 00000 n +0000282085 00000 n +0000282150 00000 n +0000282215 00000 n +0000282280 00000 n +0000282345 00000 n +0000282410 00000 n +0000282475 00000 n +0000282540 00000 n +0000282605 00000 n +0000282670 00000 n +0000282735 00000 n +0000282800 00000 n +0000282865 00000 n +0000282930 00000 n +0000282995 00000 n +0000283060 00000 n +0000283125 00000 n +0000283190 00000 n +0000283254 00000 n +0000283319 00000 n +0000283384 00000 n +0000283449 00000 n +0000283514 00000 n +0000283579 00000 n +0000283644 00000 n +0000283709 00000 n +0000283774 00000 n +0000283839 00000 n +0000283904 00000 n +0000283969 00000 n +0000284034 00000 n +0000284099 00000 n +0000284164 00000 n +0000284229 00000 n +0000284294 00000 n +0000284359 00000 n +0000284424 00000 n +0000284489 00000 n +0000284554 00000 n +0000284619 00000 n +0000284684 00000 n +0000284813 00000 n +0000286200 00000 n +0000285620 00000 n +0000284989 00000 n +0000285746 00000 n +0000285875 00000 n +0000285940 00000 n +0000286005 00000 n +0000286070 00000 n +0000286135 00000 n +0000469274 00000 n +0000286357 00000 n +0000297701 00000 n +0000305945 00000 n +0000315264 00000 n +0000317923 00000 n +0000317892 00000 n +0000325072 00000 n +0000334868 00000 n +0000352366 00000 n +0000369353 00000 n +0000389635 00000 n +0000410774 00000 n +0000413857 00000 n +0000413627 00000 n +0000440544 00000 n +0000467222 00000 n +0000469354 00000 n +0000469474 00000 n +0000469597 00000 n +0000469686 00000 n +0000469768 00000 n +0000483639 00000 n +0000495601 00000 n +0000495642 00000 n +0000495682 00000 n +0000495816 00000 n +trailer +<< +/Size 1362 +/Root 1360 0 R +/Info 1361 0 R +/ID [<398C74303A70323E9600C964366A931D> <398C74303A70323E9600C964366A931D>] +>> +startxref +496080 +%%EOF diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt new file mode 100644 index 000000000000..fa41e7635e2f --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories +Expires: February 2006 August 2005 + + + + Domain Name System (DNS) IANA Considerations + ------ ---- ------ ----- ---- -------------- + <draft-ietf-dnsext-2929bis-01.txt> + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this draft is unlimited. It is intended to become + the new BCP 42 obsoleting RFC 2929. Comments should be sent to the + DNS Working Group mailing list <namedroppers@ops.ietf.org>. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + Internet Assigned Number Authority (IANA) parameter assignment + considerations are given for the allocation of Domain Name System + (DNS) classes, RR types, operation codes, error codes, RR header + bits, and AFSDB subtypes. + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DNS Query/Response Headers..............................3 + 2.1 One Spare Bit?.........................................4 + 2.2 Opcode Assignment......................................4 + 2.3 RCODE Assignment.......................................5 + 3. DNS Resource Records....................................6 + 3.1 RR TYPE IANA Considerations............................7 + 3.1.1 DNS TYPE Allocation Policy...........................8 + 3.1.2 Special Note on the OPT RR...........................9 + 3.1.3 The AFSDB RR Subtype Field...........................9 + 3.2 RR CLASS IANA Considerations...........................9 + 3.3 RR NAME Considerations................................11 + 4. Security Considerations................................11 + + Appendix: Changes from RFC 2929...........................12 + + Copyright and Disclaimer..................................13 + Normative References......................................13 + Informative References....................................14 + + Authors Addresses.........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +1. Introduction + + The Domain Name System (DNS) provides replicated distributed secure + hierarchical databases which hierarchically store "resource records" + (RRs) under domain names. DNS data is structured into CLASSes and + zones which can be independently maintained. See [RFC 1034, 1035, + 2136, 2181, 4033] familiarity with which is assumed. + + This document provides, either directly or by reference, general IANA + parameter assignment considerations applying across DNS query and + response headers and all RRs. There may be additional IANA + considerations that apply to only a particular RR type or + query/response opcode. See the specific RFC defining that RR type or + query/response opcode for such considerations if they have been + defined, except for AFSDB RR considerations [RFC 1183] which are + included herein. This RFC obsoletes [RFC 2929]. + + IANA currently maintains a web page of DNS parameters. See + <http://www.iana.org/numbers.htm>. + + "IETF Standards Action", "IETF Consensus", "Specification Required", + and "Private Use" are as defined in [RFC 2434]. + + + +2. DNS Query/Response Headers + + The header for DNS queries and responses contains field/bits in the + following diagram taken from [RFC 2136, 2929]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The ID field identifies the query and is echoed in the response so + they can be matched. + + The QR bit indicates whether the header is for a query or a response. + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful + only in queries or only in responses, depending on the bit. However, + many DNS implementations copy the query header as the initial value + of the response header without clearing bits. Thus any attempt to + use a "query" bit with a different meaning in a response or to define + a query meaning for a "response" bit is dangerous given existing + implementation. Such meanings may only be assigned by an IETF + Standards Action. + + The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), + authority count (NSCOUNT), and additional information count (ARCOUNT) + express the number of records in each section for all opcodes except + Update. These fields have the same structure and data type for + Update but are instead the counts for the zone (ZOCOUNT), + prerequisite (PRCOUNT), update (UPCOUNT), and additional information + (ARCOUNT) sections. + + + +2.1 One Spare Bit? + + There have been ancient DNS implementations for which the Z bit being + on in a query meant that only a response from the primary server for + a zone is acceptable. It is believed that current DNS + implementations ignore this bit. + + Assigning a meaning to the Z bit requires an IETF Standards Action. + + + +2.2 Opcode Assignment + + Currently DNS OpCodes are assigned as follows: + + OpCode Name Reference + + 0 Query [RFC 1035] + 1 IQuery (Inverse Query, Obsolete) [RFC 3425] + 2 Status [RFC 1035] + 3 available for assignment + 4 Notify [RFC 1996] + 5 Update [RFC 2136] + 6-15 available for assignment + + New OpCode assignments require an IETF Standards Action as modified + by [RFC 4020]. + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +2.3 RCODE Assignment + + It would appear from the DNS header above that only four bits of + RCODE, or response/error code are available. However, RCODEs can + appear not only at the top level of a DNS response but also inside + OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. + The OPT RR provides an eight bit extension resulting in a 12 bit + RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. + + Error codes appearing in the DNS header and in these three RR types + all refer to the same error code space with the single exception of + error code 16 which has a different meaning in the OPT RR from its + meaning in other contexts. See table below. + + RCODE Name Description Reference + Decimal + Hexadecimal + 0 NoError No Error [RFC 1035] + 1 FormErr Format Error [RFC 1035] + 2 ServFail Server Failure [RFC 1035] + 3 NXDomain Non-Existent Domain [RFC 1035] + 4 NotImp Not Implemented [RFC 1035] + 5 Refused Query Refused [RFC 1035] + 6 YXDomain Name Exists when it should not [RFC 2136] + 7 YXRRSet RR Set Exists when it should not [RFC 2136] + 8 NXRRSet RR Set that should exist does not [RFC 2136] + 9 NotAuth Server Not Authoritative for zone [RFC 2136] + 10 NotZone Name not contained in zone [RFC 2136] + 11 - 15 Available for assignment + 16 BADVERS Bad OPT Version [RFC 2671] + 16 BADSIG TSIG Signature Failure [RFC 2845] + 17 BADKEY Key not recognized [RFC 2845] + 18 BADTIME Signature out of time window [RFC 2845] + 19 BADMODE Bad TKEY Mode [RPC 2930] + 20 BADNAME Duplicate key name [RPF 2930] + 21 BADALG Algorithm not supported [RPF 2930] + + 22 - 3,840 + 0x0016 - 0x0F00 Available for assignment + + 3,841 - 4,095 + 0x0F01 - 0x0FFF Private Use + + 4,096 - 65,534 + 0x1000 - 0xFFFE Available for assignment + + 65,535 + 0xFFFF Reserved, can only be allocated by an IETF + Standards Action. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Since it is important that RCODEs be understood for interoperability, + assignment of new RCODE listed above as "available for assignment" + requires an IETF Consensus. + + + +3. DNS Resource Records + + All RRs have the same top level format shown in the figure below + taken from [RFC 1035]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + NAME is an owner name, i.e., the name of the node to which this + resource record pertains. NAMEs are specific to a CLASS as described + in section 3.2. NAMEs consist of an ordered sequence of one or more + labels each of which has a label type [RFC 1035, 2671]. + + TYPE is a two octet unsigned integer containing one of the RR TYPE + codes. See section 3.1. + + CLASS is a two octet unsigned integer containing one of the RR CLASS + codes. See section 3.2. + + TTL is a four octet (32 bit) bit unsigned integer that specifies the + number of seconds that the resource record may be cached before the + source of the information should again be consulted. Zero is + interpreted to mean that the RR can only be used for the transaction + in progress. + + RDLENGTH is an unsigned 16 bit integer that specifies the length in + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + octets of the RDATA field. + + RDATA is a variable length string of octets that constitutes the + resource. The format of this information varies according to the TYPE + and in some cases the CLASS of the resource record. + + + +3.1 RR TYPE IANA Considerations + + There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, + and MetaTYPEs. + + Data TYPEs are the primary means of storing data. QTYPES can only be + used in queries. Meta-TYPEs designate transient data associated with + an particular DNS message and in some cases can also be used in + queries. Thus far, data TYPEs have been assigned from 1 upwards plus + the block from 100 through 103 while Q and Meta Types have been + assigned from 255 downwards except for the OPT Meta-RR which is + assigned TYPE 41. There have been DNS implementations which made + caching decisions based on the top bit of the bottom byte of the RR + TYPE. + + There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG + [RFC 2845], and TKEY [RFC 2930]. + + There are currently five QTYPEs assigned: * (all), MAILA, MAILB, + AXFR, and IXFR. + + Considerations for the allocation of new RR TYPEs are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC + 2535] and in other circumstances and must never be allocated + for ordinary use. + + 1 - 127 + 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data + TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + 128 - 255 + 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and + Meta TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + 256 - 32,767 + 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS + TYPE Allocation Policy as specified in section 3.1.1. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. + + 65,280 - 65534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + + +3.1.1 DNS TYPE Allocation Policy + + Parameter values specified above as assigned based on DNS TYPE + Allocation Policy. That is, Expert Review with the additional + requirement that the review be based on a complete template as + specified below which has been posted for three weeks to the + namedroppers@ops.ietf.org mailing list. + + Partial or draft templates may be posted with the intend of + soliciting feedback. + + + DNS RR TYPE PARAMETER ALLOCATION TEMPLATE + + Date: + + Name and email of originator: + + Pointer to internet-draft or other document giving a detailed + description of the protocol use of the new RR Type: + + What need is the new RR TYPE intended to fix? + + What existing RR TYPE(s) come closest to filling that need and why are + they unsatisfactory? + + Does the proposed RR TYPR require special handling within the DNS + different from an Unknown RR TYPE? + + Comments: + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.1.2 Special Note on the OPT RR + + The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its + primary purpose is to extend the effective field size of various DNS + fields including RCODE, label type, OpCode, flag bits, and RDATA + size. In particular, for resolvers and servers that recognize it, it + extends the RCODE field from 4 to 12 bits. + + + +3.1.3 The AFSDB RR Subtype Field + + The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same + RDATA field structure as the MX RR but the 16 bit unsigned integer + field at the beginning of the RDATA is interpreted as a subtype as + follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Allocation requires IETF Standards Action. + + 1 + 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. + + 2 + 0x0002 - DCE/NCA root cell directory node [RFC 1183]. + + 3 - 65,279 + 0x0003 - 0xFEFF - Allocation by IETF Consensus. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, allocation requires IETF Standards Action. + + + +3.2 RR CLASS IANA Considerations + + DNS CLASSes have been little used but constitute another dimension of + the DNS distributed database. In particular, there is no necessary + relationship between the name space or root servers for one CLASS and + those for another CLASS. The same name can have completely different + meanings in different CLASSes; however, the label types are the same + and the null label is usable only as root in every CLASS. However, + as global networking and DNS have evolved, the IN, or Internet, CLASS + has dominated DNS use. + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + There are two subcategories of DNS CLASSes: normal data containing + classes and QCLASSes that are only meaningful in queries or updates. + + The current CLASS assignments and considerations for future + assignments are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Reserved, assignment requires an IETF Standards Action. + + 1 + 0x0001 - Internet (IN). + + 2 + 0x0002 - Available for assignment by IETF Consensus as a data CLASS. + + 3 + 0x0003 - Chaos (CH) [Moon 1981]. + + 4 + 0x0004 - Hesiod (HS) [Dyer 1987]. + + 5 - 127 + 0x0005 - 0x007F - available for assignment by IETF Consensus for data + CLASSes only. + + 128 - 253 + 0x0080 - 0x00FD - available for assignment by IETF Consensus for + QCLASSes only. + + 254 + 0x00FE - QCLASS None [RFC 2136]. + + 255 + 0x00FF - QCLASS Any [RFC 1035]. + + 256 - 32,767 + 0x0100 - 0x7FFF - Assigned by IETF Consensus. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Assigned based on Specification Required as defined + in [RFC 2434]. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.3 RR NAME Considerations + + DNS NAMEs are sequences of labels [RFC 1035]. The last label in each + NAME is "ROOT" which is the zero length label. By definition, the + null or ROOT label can not be used for any other NAME purpose. + + At the present time, there are two categories of label types, data + labels and compression labels. Compression labels are pointers to + data labels elsewhere within an RR or DNS message and are intended to + shorten the wire encoding of NAMEs. The two existing data label + types are sometimes referred to as Text and Binary. Text labels can, + in fact, include any octet value including zero value octets but most + current uses involve only [US-ASCII]. For retrieval, Text labels are + defined to treat ASCII upper and lower case letter codes as matching + [insensitive]. Binary labels are bit sequences [RFC 2673]. The + Binary label type is Experimental [RFC 3363]. + + IANA considerations for label types are given in [RFC 2671]. + + NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon + 1981] CLASSes are essentially for local use. The IN or Internet + CLASS is thus the only DNS CLASS in global use on the Internet at + this time. + + A somewhat out-of-date description of name allocation in the IN Class + is given in [RFC 1591]. Some information on reserved top level + domain names is in BCP 32 [RFC 2606]. + + + +4. Security Considerations + + This document addresses IANA considerations in the allocation of + general DNS parameters, not security. See [RFC 4033, 4034, 4035] for + secure DNS considerations. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Appendix: Changes from RFC 2929 + + RFC Editor: This Appendix should be deleted for publication. + + Changes from RFC 2929 to this draft: + + 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE + Allocation Policy" and add the specification of that policy. Change + some remaining "IETF Standards Action" allocation requirements to say + "as modified by [RFC 4020]". + + 2. Updated various RFC references. + + 3. Mentioned that the Binary label type is now Experimental and + IQuery is Obsolete. + + 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be + IETF Standards Action required. + + 5. Add an IANA allocation policy for the AFSDB RR Subtype field. + + 6. Addition of reference to case insensitive draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + +D. Eastlake 3rd [Page 13] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", September 2000. + + [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November + 2002. + + [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of + Standards Track Code Points", BCP 100, RFC 4020, February 2005. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + + +Informative References + + [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, + + [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts + Institute of Technology Artificial Intelligence Laboratory, June + 1981. + + [RFC 1591] - Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", RFC 2606, June 1999. + + [insensitive] - Eastlake, D., "Domain Name System (DNS) Case + + +D. Eastlake 3rd [Page 14] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, + work in progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 15] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Authors Addresses + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + email: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires February 2006. + + Its file name is draft-ietf-dnsext-2929bis-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 16] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt new file mode 100644 index 000000000000..2cd972473d0c --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt @@ -0,0 +1,562 @@ + + + + +DNSEXT M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: August 13, 2005 T. Lemon + A. Gustafsson + Nominum, Inc. + February 9, 2005 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + <draft-ietf-dnsext-dhcid-rr-09.txt> + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + It is possible for multiple DHCP clients to attempt to update the + same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or + the clients themselves perform the DNS updates, conflicts can arise. + To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] + + + +Stapp, et al. Expires August 13, 2005 [Page 1] + +Internet-Draft The DHCID RR February 2005 + + + proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients to which they refer. + This memo defines a distinct RR type for this purpose for use by DHCP + clients and servers, the "DHCID" RR. + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4 + 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4 + 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4 + 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 + 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires August 13, 2005 [Page 2] + +Internet-Draft The DHCID RR February 2005 + + +1. Terminology + + 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 [2]. + +2. Introduction + + A set of procedures to allow DHCP [7] clients and servers to + automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed + in "Resolution of DNS Name Conflicts" [1]. + + Conflicts can arise if multiple DHCP clients wish to use the same DNS + name. To resolve such conflicts, "Resolution of DNS Name Conflicts" + [1] proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients using them. In the + interest of clarity, it is preferable for this DHCP information to + use a distinct RR type. This memo defines a distinct RR for this + purpose for use by DHCP clients or servers, the "DHCID" RR. + + In order to avoid exposing potentially sensitive identifying + information, the data stored is the result of a one-way MD5 [5] hash + computation. The hash includes information from the DHCP client's + REQUEST message as well as the domain name itself, so that the data + stored in the DHCID RR will be dependent on both the client + identification used in the DHCP protocol interaction and the domain + name. This means that the DHCID RDATA will vary if a single client + is associated over time with more than one name. This makes it + difficult to 'track' a client as it is associated with various domain + names. + + The MD5 hash algorithm has been shown to be weaker than the SHA-1 + algorithm; it could therefore be argued that SHA-1 is a better + choice. However, SHA-1 is significantly slower than MD5. A + successful attack of MD5's weakness does not reveal the original data + that was used to generate the signature, but rather provides a new + set of input data that will produce the same signature. Because we + are using the MD5 hash to conceal the original data, the fact that an + attacker could produce a different plaintext resulting in the same + MD5 output is not significant concern. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The + DHCID RR is only defined in the IN class. DHCID RRs cause no + additional section processing. The DHCID RR is not a singleton type. + + + + + +Stapp, et al. Expires August 13, 2005 [Page 3] + +Internet-Draft The DHCID RR February 2005 + + +3.1 DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its interpretation + by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. DHCP + clients or servers use the DHCID RR to associate a DHCP client's + identity with a DNS name, so that multiple DHCP clients and servers + may deterministically perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record RDATA + consists of a 16-bit identifier type, in network byte order, followed + by one or more bytes representing the actual identifier: + + < 16 bits > DHCP identifier used + < n bytes > MD5 digest + + +3.2 DHCID Presentation Format + + In DNS master files, the RDATA is represented as a single block in + base 64 encoding identical to that used for representing binary data + in RFC 2535 [8]. The data may be divided up into any number of white + space separated substrings, down to single base 64 digits, which are + concatenated to form the complete RDATA. These substrings can span + lines using the standard parentheses. + +3.3 The DHCID RR Type Codes + + The DHCID RR Type Code specifies what data from the DHCP client's + request was used as input into the hash function. The type codes are + defined in a registry maintained by IANA, as specified in Section 7. + The initial list of assigned values for the type code is: + + 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. + 0x0001 = The data portion from a DHCPv4 client's Client Identifier + option [9]. + 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 + client's Client Identifier option [10] or the DUID field from a + DHCPv4 client's Client Identifier option [12]). + + 0x0003 - 0xfffe = Available to be assigned by IANA. + + 0xffff = RESERVED + +3.4 Computation of the RDATA + + The DHCID RDATA is formed by concatenating the two type bytes with + + + +Stapp, et al. Expires August 13, 2005 [Page 4] + +Internet-Draft The DHCID RR February 2005 + + + some variable-length identifying data. + + < type > < data > + + The RDATA for all type codes other than 0xffff, which is reserved for + future expansion, is formed by concatenating the two type bytes and a + 16-byte MD5 hash value. The input to the hash function is defined to + be: + + data = MD5(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC 2535 [8], section 8.1. The type code and the + identifier are related as specified in Section 3.3: the type code + describes the source of the identifier. + + When the updater is using the client's link-layer address as the + identifier, the first two bytes of the DHCID RDATA MUST be zero. To + generate the rest of the resource record, the updater computes a + one-way hash using the MD5 algorithm across a buffer containing the + client's network hardware type, link-layer address, and the FQDN + data. Specifically, the first byte of the buffer contains the + network hardware type as it appeared in the DHCP 'htype' field of the + client's DHCPREQUEST message. All of the significant bytes of the + chaddr field in the client's DHCPREQUEST message follow, in the same + order in which the bytes appear in the DHCPREQUEST message. The + number of significant bytes in the 'chaddr' field is specified in the + 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified + above, follows. + + When the updater is using the DHCPv4 Client Identifier option sent by + the client in its DHCPREQUEST message, the first two bytes of the + DHCID RR MUST be 0x0001, in network byte order. The rest of the + DHCID RR MUST contain the results of computing an MD5 hash across the + payload of the option, followed by the FQDN. The payload of the + option consists of the bytes of the option following the option code + and length. + + When the updater is using the DHCPv6 DUID sent by the client in its + REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, + in network byte order. The rest of the DHCID RR MUST contain the + results of computing an MD5 hash across the payload of the option, + followed by the FQDN. The payload of the option consists of the + bytes of the option following the option code and length. + +3.5 Examples + + + + + +Stapp, et al. Expires August 13, 2005 [Page 5] + +Internet-Draft The DHCID RR February 2005 + + +3.5.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.example.com" uses the client's link-layer address to identify + the client. The DHCID RDATA is composed by setting the two type + bytes to zero, and performing an MD5 hash computation across a buffer + containing the Ethernet MAC type byte, 0x01, the six bytes of MAC + address, and the domain name (represented as specified in + Section 3.4). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + + +3.5.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client which + included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c + in its DHCP request. The server updates the name "chi.example.com" + on the client's behalf, and uses the DHCP client identifier option + data as input in forming a DHCID RR. The DHCID RDATA is formed by + setting the two type bytes to the value 0x0001, and performing an MD5 + hash computation across a buffer containing the seven bytes from the + client-id option and the FQDN (represented as specified in + Section 3.4). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 + + +4. Use of the DHCID RR + + This RR MUST NOT be used for any purpose other than that detailed in + "Resolution of DNS Name Conflicts" [1]. Although this RR contains + data that is opaque to DNS servers, the data must be consistent + across all entities that update and interpret this record. + Therefore, new data formats may only be defined through actions of + the DHC Working Group, as a result of revising [1]. + +5. Updater Behavior + + The data in the DHCID RR allows updaters to determine whether more + than one DHCP client desires to use a particular FQDN. This allows + site administrators to establish policy about DNS updates. The DHCID + RR does not establish any policy itself. + + Updaters use data from a DHCP client's request and the domain name + + + +Stapp, et al. Expires August 13, 2005 [Page 6] + +Internet-Draft The DHCID RR February 2005 + + + that the client desires to use to compute a client identity hash, and + then compare that hash to the data in any DHCID RRs on the name that + they wish to associate with the client's IP address. If an updater + discovers DHCID RRs whose RDATA does not match the client identity + that they have computed, the updater SHOULD conclude that a different + client is currently associated with the name in question. The + updater SHOULD then proceed according to the site's administrative + policy. That policy might dictate that a different name be selected, + or it might permit the updater to continue. + +6. Security Considerations + + The DHCID record as such does not introduce any new security problems + into the DNS. In order to avoid exposing private information about + DHCP clients to public scrutiny, a one-way hash is used to obscure + all client information. In order to make it difficult to 'track' a + client by examining the names associated with a particular hash + value, the FQDN is included in the hash computation. Thus, the RDATA + is dependent on both the DHCP client identification data and on each + FQDN associated with the client. + + Administrators should be wary of permitting unsecured DNS updates to + zones which are exposed to the global Internet. Both DHCP clients + and servers SHOULD use some form of update authentication (e.g., TSIG + [11]) when performing DNS updates. + +7. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + + This specification defines a new number-space for the 16-bit type + codes associated with the DHCID RR. IANA is requested to establish a + registry of the values for this number-space. + + Three initial values are assigned in Section 3.3, and the value + 0xFFFF is reserved for future use. New DHCID RR type codes are + tentatively assigned after the specification for the associated type + code, published as an Internet Draft, has received expert review by a + designated expert. The final assignment of DHCID RR type codes is + through Standards Action, as defined in RFC 2434 [6]. + +8. Acknowledgements + + Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and + Ralph Droms for their review and suggestions. + + + + + +Stapp, et al. Expires August 13, 2005 [Page 7] + +Internet-Draft The DHCID RR February 2005 + + +9. References + +9.1 Normative References + + [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among + DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +9.2 Informative References + + [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [8] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers + for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. + + + + + + + + +Stapp, et al. Expires August 13, 2005 [Page 8] + +Internet-Draft The DHCID RR February 2005 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.1535 + Email: mjs@cisco.com + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + Email: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + Email: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires August 13, 2005 [Page 9] + +Internet-Draft The DHCID RR February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Stapp, et al. Expires August 13, 2005 [Page 10] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt new file mode 100644 index 000000000000..438e8008a4c7 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt @@ -0,0 +1,1397 @@ +DNS Extensions Working Group G. Sisson +Internet-Draft B. Laurie +Expires: January 11, 2006 Nominet + July 10, 2005 + + + Derivation of DNS Name Predecessor and Successor + draft-ietf-dnsext-dns-name-p-s-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 January 11, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes two methods for deriving the canonically- + ordered predecessor and successor of a DNS name. These methods may + be used for dynamic NSEC resource record synthesis, enabling + security-aware name servers to provide authenticated denial of + existence without disclosing other owner names in a DNSSEC-secured + zone. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 1] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 + 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4 + 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4 + 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6 + 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6 + 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7 + 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7 + 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 + 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8 + 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8 + 5.4.2. Use of Modified Method With Zones Containing + SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Examples of Immediate Predecessors Using Absolute + Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Examples of Immediate Successors Using Absolute Method . . 13 + 6.3. Examples of Predecessors Using Modified Method . . . . . . 19 + 6.4. Examples of Successors Using Modified Method . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 + A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22 + A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23 + A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . . . 25 + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 2] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +1. Introduction + + One of the proposals for avoiding the exposure of zone information + during the deployment DNSSEC is dynamic NSEC resource record (RR) + synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- + trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the + generation of NSEC RRs that just span the query name for non-existent + owner names. In order to do this, the DNS names which would occur + just prior to and just following a given query name must be + calculated in real time, as maintaining a list of all possible owner + names that might occur in a zone would be impracticable. + + Section 6.1 of [RFC4034] defines canonical DNS name order. This + document does not amend or modify this definition. However, the + derivation of immediate predecessor and successor, while trivial, is + non-obvious. Accordingly, several methods are described here as an + aid to implementors and a reference to other interested parties. + + This document describes two methods: + + 1. An ``absolute method'', which returns the immediate predecessor + or successor of a domain name such that no valid DNS name could + exist between that DNS name and the predecessor or successor. + + 2. A ``modified method'', which returns a predecessor and successor + which are more economical in size and computation. This method + is restricted to use with zones consisting only of single-label + owner names where a maximum-length owner name would not result in + a DNS name exceeding the maximum DNS name length. This is, + however, the type of zone for which the technique of online- + signing is most likely to be used. + + +2. Notational Conventions + + The following notational conventions are used in this document for + economy of expression: + + N: An unspecified DNS name. + + P(N): Immediate predecessor to N (absolute method). + + S(N): Immediate successor to N (absolute method). + + P'(N): Predecessor to N (modified method). + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 3] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + S'(N): Successor to N (modified method). + + +3. Absolute Method + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +3.1. Derivation of DNS Name Predecessor + + To derive P(N): + + 1. If N is the same as the owner name of the zone apex, prepend N + repeatedly with labels of the maximum length possible consisting + of octets of the maximum sort value (e.g. 0xff) until N is the + maximum length possible; otherwise continue to the next step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet and continue with step 5. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values that correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. Continue to the next step. + + 5. Prepend N repeatedly with labels of as long a length as possible + consisting of octets of the maximum sort value until N is the + maximum length possible. + +3.2. Derivation of DNS Name Successor + + To derive S(N): + + 1. If N is two or more octets shorter than the maximum DNS name + length, prepend N with a label containing a single octet of the + minimum sort value (e.g. 0x00); otherwise continue to the next + step. + + 2. If N is one or more octets shorter than the maximum DNS name + length and the least significant (left-most) label is one or more + octets shorter than the maximum label length, append an octet of + + + +Sisson & Laurie Expires January 11, 2006 [Page 4] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values that + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + 4. Remove the least significant (left-most) label. If N is now the + same as the owner name of the zone apex, do nothing. (This will + occur only if N is the maximum possible name in canonical DNS + name order, and thus has wrapped to the owner name of zone apex.) + Otherwise repeat starting at step 2. + + +4. Modified Method + + This method is for use with zones consisting only of single-label + owner names where an owner name consisting of label of maximum length + would not result in a DNS name which exceeded the maximum DNS name + length. This method is computationally simpler and returns values + which are more economical in size than the absolute method. It + differs from the absolute method detailed above in the following + ways: + + 1. Step 1 of the derivation P(N) has been omitted as the existence + of the owner name of the zone apex never requires denial. + + 2. A new step 1 has been introduced which removes unnecessary + labels. + + 3. Step 4 of the derivation P(N) has been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission generally results in a significant + reduction of the length of derived predecessors. + + 4. Step 1 of the derivation S(N) had been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission results in a tiny reduction of the + length of derived successors, and maintains consistency with the + modification of step 4 of the derivation P(N) described above. + + 5. Steps 2 and 4 of the derivation S(N) have been modified to + eliminate checks for maximum DNS name length, as it is an + assumption of this method that no DNS name in the zone can exceed + the maximum DNS name length. + + + +Sisson & Laurie Expires January 11, 2006 [Page 5] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +4.1. Derivation of DNS Name Predecessor + + To derive P'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1; otherwise continue to next + step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values which correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. + +4.2. Derivation of DNS Name Successor + + To derive S'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1. Continue to next step. + + 2. If the least significant (left-most) label of N is one or more + octets shorter than the maximum label length, append an octet of + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values which + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + + +Sisson & Laurie Expires January 11, 2006 [Page 6] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 4. Remove the least significant (left-most) label. (This will occur + only if the least significant label is the maximum label length + and consists entirely of octets of the maximum sort value, and + thus has wrapped to the owner name of the zone apex.) + + +5. Notes + +5.1. Case Considerations + + Section 3.5 of [RFC1034] specifies that "while upper and lower case + letters are allowed in [DNS] names, no significance is attached to + the case". Additionally, Section 6.1 of [RFC4034] states that when + determining canonical DNS name order, "uppercase US-ASCII letters are + treated as if they were lowercase US-ASCII letters". Consequently, + values corresponding to US-ASCII uppercase letters must be skipped + when decrementing and incrementing octets in the derivations + described in Section 3.1 and Section 3.2. + + The following pseudo-code is illustrative: + + Decrement the value of an octet: + + if (octet == '[') // '[' is just after uppercase 'Z' + octet = '@'; // '@' is just prior to uppercase 'A' + else + octet--; + + Increment the value of an octet: + + if (octet == '@') // '@' is just prior to uppercase 'A' + octet = '['; // '[' is just after uppercase 'Z' + else + octet++; + +5.2. Choice of Range + + [RFC2181] makes the clarification that "any binary string whatever + can be used as the label of any resource record". Consequently the + minimum sort value may be set as 0x00 and the maximum sort value as + 0xff, and the range of possible values will be any DNS name which + contains octets of any value other than those corresponding to + uppercase US-ASCII letters. + + However, if all owner names in a zone are in the letter-digit-hyphen, + or LDH, format specified in [RFC1034], it may be desirable to + restrict the range of possible values to DNS names containing only + LDH values. This has the effect of: + + + +Sisson & Laurie Expires January 11, 2006 [Page 7] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 1. making the output of tools such as `dig' and `nslookup' less + subject to confusion; + + 2. minimising the impact that NSEC RRs containing DNS names with + non-LDH values (or non-printable values) might have on faulty DNS + resolver implementations; and + + 3. preventing the possibility of results which are wildcard DNS + names (see Section 5.3). + + This may be accomplished by using a minimum sort value of 0x1f (US- + ASCII character `-') and a maximum sort value of 0x7a (US-ASCII + character lowercase `z'), and then skipping non-LDH, non-lowercase + values when incrementing or decrementing octets. + +5.3. Wild Card Considerations + + Neither derivation avoids the possibility that the result may be a + DNS name containing a wildcard label, i.e. a label containing a + single octet with the value 0x2a (US-ASCII character `*'). With + additional tests, wildcard DNS names may be explicitly avoided; + alternatively, if the range of octet values can be restricted to + those corresponding to letter-digit-hyphen, or LDH, characters (see + Section 5.2), such DNS names will not occur. + + Note that it is improbable that a result which is a wildcard DNS name + will occur unintentionally; even if one does occur either as the + owner name of, or in the RDATA of an NSEC RR, it is treated as a + literal DNS name with no special meaning. + +5.4. Possible Modifications + +5.4.1. Restriction of Effective Maximum DNS Name Length + + [RFC1034] specifies that "the total number of octets that represent a + [DNS] name (i.e., the sum of all label octets and label lengths) is + limited to 255", including the null (zero-length) label which + represents the root. For the purpose of deriving predecessors and + successors during NSEC RR synthesis, the maximum DNS name length may + be effectively restricted to the length of the longest DNS name in + the zone. This will minimise the size of responses containing + synthesised NSEC RRs but, especially in the case of the modified + method, may result in some additional computational complexity. + + Note that this modification will have the effect of revealing + information about the longest name in the zone. Moreover, when the + contents of the zone changes, e.g. during dynamic updates and zone + transfers, care must be taken to ensure that the effective maximum + + + +Sisson & Laurie Expires January 11, 2006 [Page 8] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + DNS name length agrees with the new contents. + +5.4.2. Use of Modified Method With Zones Containing SRV RRs + + Normally the modified method cannot be used in zones that contain + SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple + labels. However the use of SRV RRs can be accommodated by various + techniques. There are at least four possible ways to do this: + + 1. Use conventional NSEC RRs for the region of the zone that + contains first-level labels beginning with the underscore (`_') + character. For the purposes of generating these NSEC RRs, the + existence of (possibly fictional) ownernames `9{63}' and `a' + could be assumed, providing a lower and upper bound for this + region. Then all queries where the QNAME doesn't exist but + contains a first-level label beginning with an underscore could + be handled using the normal DNSSEC protocol. + + This approach would make it possible to enumerate all DNS names + in the zone containing a first-level label beginning with + underscore, including all SRV RRs, but this may be of less a + concern to the zone administrator than incurring the overhead of + the absolute method or of the following variants of the modified + method. + + 2. The absolute method could be used for synthesising NSEC RRs for + all queries where the QNAME contains a leading underscore. + However this re-introduces the susceptibility of the absolute + method to denial of service activity, as an attacker could send + queries for an effectively inexhaustible supply of domain names + beginning with a leading underscore. + + 3. A variant of the modified method could be used for synthesising + NSEC RRs for all queries where the QNAME contains a leading + underscore. This variant would assume that all predecessors and + successors to queries where the QNAME contains a leading + underscore may consist of two lablels rather than only one. This + introduces a little additional complexity without incurring the + full increase in response size and computational complexity as + the absolute method. + + 4. Finally, a variant the modified method which assumes that all + owner names in the zone consist of one or two labels could be + used. However this negates much of the reduction in response + size of the modified method and may be nearly as computationally + complex as the absolute method. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 9] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +6. Examples + + In the following examples: + + the owner name of the zone apex is "example.com."; + + the range of octet values is 0x00 - 0xff excluding values + corresponding to uppercase US-ASCII letters; and + + non-printable octet values are expressed as three-digit decimal + numbers preceded by a backslash (as specified in Section 5.1 of + [RFC1035]). + +6.1. Examples of Immediate Predecessors Using Absolute Method + + Example of typical case: + + P(foo.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fon\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 10] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label of DNS name + consists of a single octet of the minimum sort value: + + P(\000.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P(foo\000.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.foo.example.com. + + or, in alternate notation: + + \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 11] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains an octet which must be decremented by + skipping values corresponding to US-ASCII uppercase letters: + + P(fo\[.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fo\@\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 12] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + +6.2. Examples of Immediate Successors Using Absolute Method + + Example of typical case: + + S(foo.example.com.) = \000.foo.example.com. + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 13] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is one octet short of the maximum DNS name + length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + .ooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooo.ooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooo.ooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{47}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \000.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + fo{47}\000.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 14] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + o.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{48}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + p.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{47}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 15] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the least + significant (left-most) label has the maximum sort value: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + \255{49}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooop.oooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooo.oooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooooooooo. + example.com. + + or, in alternate notation: + + o{62}p.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 16] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the eight + least significant (right-most) octets of the least significant (left- + most) label have the maximum sort value: + + N = foooooooooooooooooooooooooooooooooooooooo\255 + \255\255\255\255\255\255\255.ooooooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooo.ooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooo.ooooooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooop.oooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + ooooooooo.oooooooooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooo.oooooooooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{39}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 17] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and contains an + octet which must be incremented by skipping values corresponding to + US-ASCII uppercase letters: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + \@.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\@.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \[.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\[.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 18] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name has the maximum possible sort order in the + zone, and consequently wraps to the owner name of the zone apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + + S(N) = example.com. + +6.3. Examples of Predecessors Using Modified Method + + Example of typical case: + + P'(foo.example.com.) = + + fon\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + fon\255{60}.example.com. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 19] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains more labels than DNS names in the + zone: + + P'(bar.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P'(foo\000.example.com.) = foo.example.com. + + Example where least significant (left-most) label has the minimum + sort value: + + P'(\000.example.com.) = example.com. + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P'(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + +6.4. Examples of Successors Using Modified Method + + Example of typical case: + + S'(foo.example.com.) = foo\000.example.com. + + Example where DNS name contains more labels than DNS names in the + zone: + + S'(bar.foo.example.com.) = foo\000.example.com. + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 20] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label has the maximum + sort value, and consequently wraps to the owner name of the zone + apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + + S'(N) = example.com. + + +7. Security Considerations + + The derivation of some predecessors/successors requires the testing + of more conditions than others. Consequently the effectiveness of a + denial-of-service attack may be enhanced by sending queries that + require more conditions to be tested. The modified method involves + the testing of fewer conditions than the absolute method and + consequently is somewhat less susceptible to this exposure. + + +8. IANA Considerations + + This document has no IANA actions. + + Note to RFC Editor: This section is included to make it clear during + pre-publication review that this document has no IANA actions. It + may therefore be removed should it be published as an RFC. + + +9. Acknowledgments + + The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and + Niall O'Reilly for their review and input. + + +10. References + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 21] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +10.1 Normative References + + [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. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + +10.2 Informative References + + [I-D.ietf-dnsext-dnssec-online-signing] + Ihren, J. and S. Weiler, "Minimally Covering NSEC Records + and DNSSEC On-line Signing", + draft-ietf-dnsext-dnssec-online-signing-00 (work in + progress), May 2005. + + [I-D.ietf-dnsext-dnssec-trans] + Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC + Transition Mechanisms", + draft-ietf-dnsext-dnssec-trans-02 (work in progress), + February 2005. + + +Appendix A. Change History + +A.1. Changes from sisson-02 to ietf-00 + + o Added notes on use of SRV RRs with modified method. + + o Changed reference from weiler-dnssec-online-signing to ietf- + dnsext-dnssec-online-signing. + + o Changed reference from ietf-dnsext-dnssec-records to RFC 4034. + + o Miscellaneous minor changes to text. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 22] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +A.2. Changes from sisson-01 to sisson-02 + + o Added modified version of derivation (with supporting examples). + + o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). + + o Added clarification to derivations about when processing stops. + + o Miscellaneous minor changes to text. + +A.3. Changes from sisson-00 to sisson-01 + + o Split step 3 of derivation of DNS name predecessor into two + distinct steps for clarity. + + o Added clarifying text and examples related to the requirement to + avoid uppercase characters when decrementing or incrementing + octets. + + o Added optimisation using restriction of effective maximum DNS name + length. + + o Changed examples to use decimal rather than octal notation as per + [RFC1035]. + + o Corrected DNS name length of some examples. + + o Added reference to weiler-dnssec-online-signing. + + o Miscellaneous minor changes to text. + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 23] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Authors' Addresses + + Geoffrey Sisson + Nominet + Sandford Gate + Sandy Lane West + Oxford + OX4 6LB + GB + + Phone: +44 1865 332339 + Email: geoff@nominet.org.uk + + + Ben Laurie + Nominet + 17 Perryn Road + London + W3 7LR + GB + + Phone: +44 20 8735 0686 + Email: ben@algroup.co.uk + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 24] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 25] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt new file mode 100644 index 000000000000..3a800f98880d --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt @@ -0,0 +1,616 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) May 23, 2005 +Expires: November 24, 2005 + + + Clarifications and Implementation Notes for DNSSECbis + draft-ietf-dnsext-dnssec-bis-updates-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 November 24, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is a collection of minor technical clarifications to + the DNSSECbis document set. It is meant to serve as a resource to + implementors as well as an interim repository of possible DNSSECbis + errata. + + + + + + + +Weiler Expires November 24, 2005 [Page 1] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Proposed additions in future versions + + An index sorted by the section of DNSSECbis being clarified. + + A list of proposed protocol changes being made in other documents, + such as NSEC3 and Epsilon. This document would not make those + changes, merely provide an index into the documents that are making + changes. + +Changes between -00 and -01 + + Document significantly restructured. + + Added section on QTYPE=ANY. + +Changes between personal submission and first WG draft + + Added Section 2.1 based on namedroppers discussions from March 9-10, + 2005. + + Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2. + + Added the DNSSECbis RFC numbers. + + Figured out the confusion in Section 4.1. + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 2] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 + 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 + 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4 + 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5 + 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5 + 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 + 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 + 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 + 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6 + 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 + 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7 + 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7 + 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 11 + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 3] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +1. Introduction and Terminology + + This document lists some minor clarifications and corrections to + DNSSECbis, as described in [1], [2], and [3]. + + It is intended to serve as a resource for implementors and as a + repository of items that need to be addressed when advancing the + DNSSECbis documents from Proposed Standard to Draft Standard. + + In this version (-01 of the WG document), feedback is particularly + solicited on the structure of the document and whether the text in + the recently added sections is correct and sufficient. + + Proposed substantive additions to this document should be sent to the + namedroppers mailing list as well as to the editor of this document. + The editor would greatly prefer text suitable for direct inclusion in + this document. + +1.1 Structure of this Document + + The clarifications to DNSSECbis are sorted according to the editor's + impression of their importance, starting with ones which could, if + ignored, lead to security and stability problems and progressing down + to clarifications that are likely to have little operational impact. + Mere typos and awkward phrasings are not addressed unless they could + lead to misinterpretation of the DNSSECbis documents. + +1.2 Terminology + + 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 [4]. + +2. Significant Concerns + + This section provides clarifications that, if overlooked, could lead + to security issues or major interoperability problems. + +2.1 Clarifications on Non-Existence Proofs + + RFC4035 Section 5.4 slightly underspecifies the algorithm for + checking non-existence proofs. In particular, the algorithm there + might incorrectly allow the NSEC from the parent side of a zone cut + to prove the non-existence of either other RRs at that name in the + child zone or other names in the child zone. It might also allow a + NSEC at the same name as a DNAME to prove the non-existence of names + beneath that DNAME. + + + + +Weiler Expires November 24, 2005 [Page 4] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + A parent-side delegation NSEC (one with the NS bit set, but no SOA + bit set, and with a singer field that's shorter than the owner name) + must not be used to assume non-existence of any RRs below that zone + cut (both RRs at that ownername and at ownernames with more leading + labels, no matter their content). Similarly, an NSEC with the DNAME + bit set must not be used to assume the non-existence of any + descendant of that NSEC's owner name. + +2.2 Empty Non-Terminal Proofs + + To be written, based on Roy Arends' May 11th message to namedroppers. + +2.3 Validating Responses to an ANY Query + + RFC4035 does not address now to validate responses when QTYPE=*. As + described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* + may include a subset of the RRsets at a given name -- it is not + necessary to include all RRsets at the QNAME in the response. + + When validating a response to QTYPE=*, validate all received RRsets + that match QNAME and QCLASS. If any of those RRsets fail validation, + treat the answer as Bogus. If there are no RRsets matching QNAME and + QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as + clarified in this document). To be clear, a validator must not + insist on receiving all records at the QNAME in response to QTYPE=*. + +3. Interoperability Concerns + +3.1 Unknown DS Message Digest Algorithms + + Section 5.2 of RFC4035 includes rules for how to handle delegations + to zones that are signed with entirely unsupported algorithms, as + indicated by the algorithms shown in those zone's DS RRsets. It does + not explicitly address how to handle DS records that use unsupported + message digest algorithms. In brief, DS records using unknown or + unsupported message digest algorithms MUST be treated the same way as + DS records referring to DNSKEY RRs of unknown or unsupported + algorithms. + + The existing text says: + + If the validator does not support any of the algorithms listed + in an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + + + +Weiler Expires November 24, 2005 [Page 5] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + To paraphrase the above, when determining the security status of a + zone, a validator discards (for this purpose only) any DS records + listing unknown or unsupported algorithms. If none are left, the + zone is treated as if it were unsigned. + + Modified to consider DS message digest algorithms, a validator also + discards any DS records using unknown or unsupported message digest + algorithms. + +3.2 Private Algorithms + + As discussed above, section 5.2 of RFC4035 requires that validators + make decisions about the security status of zones based on the public + key algorithms shown in the DS records for those zones. In the case + of private algorithms, as described in RFC4034 Appendix A.1.1, the + eight-bit algorithm field in the DS RR is not conclusive about what + algorithm(s) is actually in use. + + If no private algorithms appear in the DS set or if any supported + algorithm appears in the DS set, no special processing will be + needed. In the remaining cases, the security status of the zone + depends on whether or not the resolver supports any of the private + algorithms in use (provided that these DS records use supported hash + functions, as discussed in Section 3.1). In these cases, the + resolver MUST retrieve the corresponding DNSKEY for each private + algorithm DS record and examine the public key field to determine the + algorithm in use. The security-aware resolver MUST ensure that the + hash of the DNSKEY RR's owner name and RDATA matches the digest in + the DS RR. If they do not match, and no other DS establishes that + the zone is secure, the referral should be considered BAD data, as + discussed in RFC4035. + + This clarification facilitates the broader use of private algorithms, + as suggested by [5]. + +3.3 Caution About Local Policy and Multiple RRSIGs + + When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3 + suggests that "the local resolver security policy determines whether + the resolver also has to test these RRSIG RRs and how to resolve + conflicts if these RRSIG RRs lead to differing results." In most + cases, a resolver would be well advised to accept any valid RRSIG as + sufficient. If the first RRSIG tested fails validation, a resolver + would be well advised to try others, giving a successful validation + result if any can be validated and giving a failure only if all + RRSIGs fail validation. + + If a resolver adopts a more restrictive policy, there's a danger that + + + +Weiler Expires November 24, 2005 [Page 6] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + properly-signed data might unnecessarily fail validation, perhaps + because of cache timing issues. Furthermore, certain zone management + techniques, like the Double Signature Zone-signing Key Rollover + method described in section 4.2.1.2 of [6] might not work reliably. + +3.4 Key Tag Calculation + + RFC4034 Appendix B.1 incorrectly defines the Key Tag field + calculation for algorithm 1. It correctly says that the Key Tag is + the most significant 16 of the least significant 24 bits of the + public key modulus. However, RFC4034 then goes on to incorrectly say + that this is 4th to last and 3rd to last octets of the public key + modulus. It is, in fact, the 3rd to last and 2nd to last octets. + +4. Minor Corrections and Clarifications + +4.1 Finding Zone Cuts + + Appendix C.8 of RFC4035 discusses sending DS queries to the servers + for a parent zone. To do that, a resolver may first need to apply + special rules to discover what those servers are. + + As explained in Section 3.1.4.1 of RFC4035, security-aware name + servers need to apply special processing rules to handle the DS RR, + and in some situations the resolver may also need to apply special + rules to locate the name servers for the parent zone if the resolver + does not already have the parent's NS RRset. Section 4.2 of RFC4035 + specifies a mechanism for doing that. + +4.2 Clarifications on DNSKEY Usage + + Questions of the form "can I use a different DNSKEY for signing the + X" have occasionally arisen. + + The short answer is "yes, absolutely". You can even use a different + DNSKEY for each RRset in a zone, subject only to practical limits on + the size of the DNSKEY RRset. However, be aware that there is no way + to tell resolvers what a particularly DNSKEY is supposed to be used + for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to + authenticate any RRset in the zone. For example, if a weaker or less + trusted DNSKEY is being used to authenticate NSEC RRsets or all + dynamically updated records, that same DNSKEY can also be used to + sign any other RRsets from the zone. + + Furthermore, note that the SEP bit setting has no effect on how a + DNSKEY may be used -- the validation process is specifically + prohibited from using that bit by RFC4034 section 2.1.2. It possible + to use a DNSKEY without the SEP bit set as the sole secure entry + + + +Weiler Expires November 24, 2005 [Page 7] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + point to the zone, yet use a DNSKEY with the SEP bit set to sign all + RRsets in the zone (other than the DNSKEY RRset). It's also possible + to use a single DNSKEY, with or without the SEP bit set, to sign the + entire zone, including the DNSKEY RRset itself. + +4.3 Errors in Examples + + The text in RFC4035 Section C.1 refers to the examples in B.1 as + "x.w.example.com" while B.1 uses "x.w.example". This is painfully + obvious in the second paragraph where it states that the RRSIG labels + field value of 3 indicates that the answer was not the result of + wildcard expansion. This is true for "x.w.example" but not for + "x.w.example.com", which of course has a label count of 4 + (antithetically, a label count of 3 would imply the answer was the + result of a wildcard expansion). + + The first paragraph of RFC4035 Section C.6 also has a minor error: + the reference to "a.z.w.w.example" should instead be "a.z.w.example", + as in the previous line. + +5. IANA Considerations + + This document specifies no IANA Actions. + +6. Security Considerations + + This document does not make fundamental changes to the DNSSEC + protocol, as it was generally understood when DNSSECbis was + published. It does, however, address some ambiguities and omissions + in those documents that, if not recognized and addressed in + implementations, could lead to security failures. In particular, the + validation algorithm clarifications in Section 2 are critical for + preserving the security properties DNSSEC offers. Furthermore, + failure to address some of the interoperability concerns in Section 3 + could limit the ability to later change or expand DNSSEC, including + by adding new algorithms. + +7. References + +7.1 Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Weiler Expires November 24, 2005 [Page 8] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +7.2 Informative References + + [5] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), + December 2004. + + [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-04 (work in + progress), May 2005. + + +Author's Address + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + +Appendix A. Acknowledgments + + The editor is extremely grateful to those who, in addition to finding + errors and omissions in the DNSSECbis document set, have provided + text suitable for inclusion in this document. + + The lack of specificity about handling private algorithms, as + described in Section 3.2, and the lack of specificity in handling ANY + queries, as described in Section 2.3, were discovered by David + Blacka. + + The error in algorithm 1 key tag calculation, as described in + Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake + contributed text for Section 3.4. + + The bug relating to delegation NSEC RR's in Section 2.1 was found by + Roy Badami. Roy Arends found the related problem with DNAME. + + The errors in the RFC4035 examples were found by Roy Arends, who also + contributed text for Section 4.3 of this document. + + + +Weiler Expires November 24, 2005 [Page 9] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + The editor would like to thank Olafur Gudmundsson and Scott Rose for + their substantive comments on the text of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 10] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler Expires November 24, 2005 [Page 11] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt new file mode 100644 index 000000000000..ee03583a1306 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt @@ -0,0 +1,784 @@ + + + +DNSEXT D. Blacka +Internet-Draft Verisign, Inc. +Expires: January 19, 2006 July 18, 2005 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 January 19, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the long history of the development of the DNS security extensions + [1] (DNSSEC), a number of alternate methodologies and modifications + have been proposed and rejected for practical, rather than strictly + technical, reasons. There is a desire to be able to experiment with + these alternate methods in the public DNS. This document describes a + methodology for deploying alternate, non-backwards-compatible, DNSSEC + methodologies in an experimental fashion without disrupting the + deployment of standard DNSSEC. + + + + +Blacka Expires January 19, 2006 [Page 1] + +Internet-Draft DNSSEC Experiments July 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 + 10.2 Informative References . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 2] + +Internet-Draft DNSSEC Experiments July 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [4]) and the DNS security extensions ([1], [2], and [3]. + + 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 [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 3] + +Internet-Draft DNSSEC Experiments July 2005 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC, and to try + these changes on real zones in the public DNS. This creates a + problem when the change to DNSSEC would make all or part of the zone + using those changes appear bogus (bad) or otherwise broken to + existing DNSSEC-aware resolvers. + + This document describes a standard methodology for setting up public + DNSSEC experiments. This methodology addresses the issue of co- + existence with standard DNSSEC and DNS by using unknown algorithm + identifiers to hide the experimental DNSSEC protocol modifications + from standard DNSSEC-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 4] + +Internet-Draft DNSSEC Experiments July 2005 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and server that do implement the DNSSEC + standard. + + Non-Backwards-Compatible: describes experiments that would cause a + standard DNSSEC-aware resolver to (incorrectly) determine that all + or part of a zone is bogus, or to otherwise not interoperable with + standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly could be used + if desired. + + Note that, in essence, this metholodolgy would also be used to + introduce a new DNSSEC algorithm, independently from any DNSSEC + experimental protocol change. + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 5] + +Internet-Draft DNSSEC Experiments July 2005 + + +4. Method + + The core of the methodology is the use of strictly "unknown" + algorithms to sign the experimental zone, and more importantly, + having only unknown algorithm DS records for the delegation to the + zone at the parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithms. From [3], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is unlikely that a validator would not implement the behavior, or, + more to the point, it will not violate this behavior in an unsafe way + (see below (Section 6).) + + Because we are talking about experiments, it is RECOMMENDED that + private algorithm numbers be used (see [2], appendix A.1.1. Note + that secure handling of private algorithms requires special handing + by the validator logic. See [6] for futher details.) Normally, + instead of actually inventing new signing algorithms, the recommended + path is to create alternate algorithm identifiers that are aliases + for the existing, known algorithms. While, strictly speaking, it is + only necessary to create an alternate identifier for the mandatory + algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be + aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec- + experiment-a.example.com". However, any unique identifier will + + + +Blacka Expires January 19, 2006 [Page 6] + +Internet-Draft DNSSEC Experiments July 2005 + + + suffice. + + Using this method, resolvers (or, more specificially, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of DNSSEC-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiments algorithm identifiers and + experimental semantics), and servers and resolvers that are unware of + the experiment. + + This method also precludes any zone from being both in an experiment + and in a classic DNSSEC island of security. That is, a zone is + either in an experiment and only experimentally validatable, or it + isn't. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 7] + +Internet-Draft DNSSEC Experiments July 2005 + + +5. Defining an Experiment + + The DNSSEC experiment must define the particular set of (previously + unknown) algorithms that identify the experiment, and define what + each unknown algorithm identifier means. Typically, unless the + experiment is actually experimenting with a new DNSSEC algorithm, + this will be a mapping of private algorithm identifiers to existing, + known algorithms. + + Normally the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + may choose non-private algorithm numbers, although this would require + an IANA allocation (see below (Section 9).) + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and provide + the mapping of "3.dnssec-experiment-a.example.com" is an alias of + DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is + an alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST then only recognize the experiment's semantics when + present in a zone signed by one or more of these private algorithms. + + In general, however, resolvers involved in the experiment are + expected to understand both standard DNSSEC and the defined + experimental DNSSEC protocol, although this isn't required. + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 8] + +Internet-Draft DNSSEC Experiments July 2005 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at the not validatable response and + conclude that the response is bogus, either due to local policy + or implementation details. This is not expected to be the common + case, however. + + 2. In general, it will not be possible for DNSSEC-aware resolvers + not aware of the experiment to build a chain of trust through an + experimental zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 9] + +Internet-Draft DNSSEC Experiments July 2005 + + +7. Transitions + + If an experiment is successful, there may be a desire to move the + experiment to a standards-track extension. One way to do so would be + to move from private algorithm numbers to IANA allocated algorithm + numbers, with otherwise the same meaning. This would still leave a + divide between resolvers that understood the extension versus + resolvers that did not. It would, in essence, create an additional + version of DNSSEC. + + An alternate technique might be to do a typecode rollover, thus + actually creating a definitive new version of DNSSEC. There may be + other transition techniques available, as well. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 10] + +Internet-Draft DNSSEC Experiments July 2005 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 11] + +Internet-Draft DNSSEC Experiments July 2005 + + +9. IANA Considerations + + IANA may need to allocate new DNSSEC algorithm numbers if that + transition approach is taken, or the experiment decides to use + allocated numbers to begin with. No IANA action is required to + deploy an experiment using private algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 12] + +Internet-Draft DNSSEC Experiments July 2005 + + +10. References + +10.1 Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +10.2 Informative References + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Weiler, S., "Clarifications and Implementation Notes for + DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in + progress), March 2005. + + +Author's Address + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + +Blacka Expires January 19, 2006 [Page 13] + +Internet-Draft DNSSEC Experiments July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Blacka Expires January 19, 2006 [Page 14] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt new file mode 100644 index 000000000000..f7abddc43e4a --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt @@ -0,0 +1,560 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) J. Ihren +Expires: November 13, 2005 Autonomica AB + May 12, 2005 + + + Minimally Covering NSEC Records and DNSSEC On-line Signing + draft-ietf-dnsext-dnssec-online-signing-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 November 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes how to construct DNSSEC NSEC resource records + that cover a smaller range of names than called for by RFC4034. By + generating and signing these records on demand, authoritative name + servers can effectively stop the disclosure of zone contents + otherwise made possible by walking the chain of NSEC records in a + signed zone. + + + + +Weiler & Ihren Expires November 13, 2005 [Page 1] + +Internet-Draft NSEC Epsilon May 2005 + + +Changes from weiler-01 to ietf-00 + + Inserted RFC numbers for 4033, 4034, and 4035. + + Specified contents of bitmap field in synthesized NSEC RR's, pointing + out that this relaxes a constraint in 4035. Added 4035 to the + Updates header. + +Changes from weiler-00 to weiler-01 + + Clarified that this updates RFC4034 by relaxing requirements on the + next name field. + + Added examples covering wildcard names. + + In the 'better functions' section, reiterated that perfect functions + aren't needed. + + Added a reference to RFC 2119. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 2] + +Internet-Draft NSEC Epsilon May 2005 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4 + 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4 + 3. Better Increment & Decrement Functions . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 + 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 3] + +Internet-Draft NSEC Epsilon May 2005 + + +1. Introduction and Terminology + + With DNSSEC [1], an NSEC record lists the next instantiated name in + its zone, proving that no names exist in the "span" between the + NSEC's owner name and the name in the "next name" field. In this + document, an NSEC record is said to "cover" the names between its + owner name and next name. + + Through repeated queries that return NSEC records, it is possible to + retrieve all of the names in the zone, a process commonly called + "walking" the zone. Some zone owners have policies forbidding zone + transfers by arbitrary clients; this side-effect of the NSEC + architecture subverts those policies. + + This document presents a way to prevent zone walking by constructing + NSEC records that cover fewer names. These records can make zone + walking take approximately as many queries as simply asking for all + possible names in a zone, making zone walking impractical. Some of + these records must be created and signed on demand, which requires + on-line private keys. Anyone contemplating use of this technique is + strongly encouraged to review the discussion of the risks of on-line + signing in Section 5. + + The technique presented here may be useful to a zone owner that wants + to use DNSSEC, is concerned about exposure of its zone contents via + zone walking, and is willing to bear the costs of on-line signing. + + 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 [4]. + +2. Minimally Covering NSEC Records + + This mechanism involves changes to NSEC records for instantiated + names, which can still be generated and signed in advance, as well as + the on-demand generation and signing of new NSEC records whenever a + name must be proven not to exist. + + In the 'next name' field of instantiated names' NSEC records, rather + than list the next instantiated name in the zone, list any name that + falls lexically after the NSEC's owner name and before the next + instantiated name in the zone, according to the ordering function in + RFC4034 [2] section 6.2. This relaxes the requirement in section + 4.1.1 of RFC4034 that the 'next name' field contains the next owner + name in the zone. This change is expected to be fully compatible + with all existing DNSSEC validators. These NSEC records are returned + whenever proving something specifically about the owner name (e.g. + that no resource records of a given type appear at that name). + + + +Weiler & Ihren Expires November 13, 2005 [Page 4] + +Internet-Draft NSEC Epsilon May 2005 + + + Whenever an NSEC record is needed to prove the non-existence of a + name, a new NSEC record is dynamically produced and signed. The new + NSEC record has an owner name lexically before the QNAME but + lexically following any existing name and a 'next name' lexically + following the QNAME but before any existing name. + + The generated NSEC record's type bitmap SHOULD have the RRSIG and + NSEC bits set and SHOULD NOT have any other bits set. This relaxes + the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at + names that did not exist before the zone wsa signed. + + The functions to generate the lexically following and proceeding + names need not be perfect nor consistent, but the generated NSEC + records must not cover any existing names. Furthermore, this + technique works best when the generated NSEC records cover as few + names as possible. + + An NSEC record denying the existence of a wildcard may be generated + in the same way. Since the NSEC record covering a non-existent + wildcard is likely to be used in response to many queries, + authoritative name servers using the techniques described here may + want to pregenerate or cache that record and its corresponding RRSIG. + + For example, a query for an A record at the non-instantiated name + example.com might produce the following two NSEC records, the first + denying the existence of the name example.com and the second denying + the existence of a wildcard: + + exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) + + ).com 3600 IN NSEC +.com ( RRSIG NSEC ) + + Before answering a query with these records, an authoritative server + must test for the existence of names between these endpoints. If the + generated NSEC would cover existing names (e.g. exampldd.com or + *bizarre.example.com), a better increment or decrement function may + be used or the covered name closest to the QNAME could be used as the + NSEC owner name or next name, as appropriate. If an existing name is + used as the NSEC owner name, that name's real NSEC record MUST be + returned. Using the same example, assuming an exampldd.com + delegation exists, this record might be returned from the parent: + + exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) + + Like every authoritative record in the zone, each generated NSEC + record MUST have corresponding RRSIGs generated using each algorithm + (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as + described in RFC4035 [3] section 2.2. To minimize the number of + + + +Weiler & Ihren Expires November 13, 2005 [Page 5] + +Internet-Draft NSEC Epsilon May 2005 + + + signatures that must be generated, a zone may wish to limit the + number of algorithms in its DNSKEY RRset. + +3. Better Increment & Decrement Functions + + Section 6.2 of RFC4034 defines a strict ordering of DNS names. + Working backwards from that definition, it should be possible to + define increment and decrement functions that generate the + immediately following and preceding names, respectively. This + document does not define such functions. Instead, this section + presents functions that come reasonably close to the perfect ones. + As described above, an authoritative server should still ensure than + no generated NSEC covers any existing name. + + To increment a name, add a leading label with a single null (zero- + value) octet. + + To decrement a name, decrement the last character of the leftmost + label, then fill that label to a length of 63 octets with octets of + value 255. To decrement a null (zero-value) octet, remove the octet + -- if an empty label is left, remove the label. Defining this + function numerically: fill the left-most label to its maximum length + with zeros (numeric, not ASCII zeros) and subtract one. + + In response to a query for the non-existent name foo.example.com, + these functions produce NSEC records of: + + fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) + + )\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) + + The first of these NSEC RRs proves that no exact match for + foo.example.com exists, and the second proves that there is no + wildcard in example.com. + + Both of these functions are imperfect: they don't take into account + constraints on number of labels in a name nor total length of a name. + As noted in the previous section, though, this technique does not + depend on the use of perfect increment or decrement functions: it is + sufficient to test whether any instantiated names fall into the span + + + +Weiler & Ihren Expires November 13, 2005 [Page 6] + +Internet-Draft NSEC Epsilon May 2005 + + + covered by the generated NSEC and, if so, substitute those + instantiated owner names for the NSEC owner name or next name, as + appropriate. + +4. IANA Considerations + + Per RFC4041, IANA should think carefully about the protection of + their immortal souls. + +5. Security Considerations + + This approach requires on-demand generation of RRSIG records. This + creates several new vulnerabilities. + + First, on-demand signing requires that a zone's authoritative servers + have access to its private keys. Storing private keys on well-known + internet-accessible servers may make them more vulnerable to + unintended disclosure. + + Second, since generation of public key signatures tends to be + computationally demanding, the requirement for on-demand signing + makes authoritative servers vulnerable to a denial of service attack. + + Lastly, if the increment and decrement functions are predictable, on- + demand signing may enable a chosen-plaintext attack on a zone's + private keys. Zones using this approach should attempt to use + cryptographic algorithms that are resistant to chosen-plaintext + attacks. It's worth noting that while DNSSEC has a "mandatory to + implement" algorithm, that is a requirement on resolvers and + validators -- there is no requirement that a zone be signed with any + given algorithm. + + The success of using minimally covering NSEC record to prevent zone + walking depends greatly on the quality of the increment and decrement + functions chosen. An increment function that chooses a name + obviously derived from the next instantiated name may be easily + reverse engineered, destroying the value of this technique. An + increment function that always returns a name close to the next + instantiated name is likewise a poor choice. Good choices of + increment and decrement functions are the ones that produce the + immediately following and preceding names, respectively, though zone + administrators may wish to use less perfect functions that return + more human-friendly names than the functions described in Section 3 + above. + + Another obvious but misguided concern is the danger from synthesized + NSEC records being replayed. It's possible for an attacker to replay + an old but still validly signed NSEC record after a new name has been + + + +Weiler & Ihren Expires November 13, 2005 [Page 7] + +Internet-Draft NSEC Epsilon May 2005 + + + added in the span covered by that NSEC, incorrectly proving that + there is no record at that name. This danger exists with DNSSEC as + defined in [-bis]. The techniques described here actually decrease + the danger, since the span covered by any NSEC record is smaller than + before. Choosing better increment and decrement functions will + further reduce this danger. + +6. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + Email: johani@autonomica.se + +Appendix A. Acknowledgments + + Many individuals contributed to this design. They include, in + addition to the authors of this document, Olaf Kolkman, Ed Lewis, + + + +Weiler & Ihren Expires November 13, 2005 [Page 8] + +Internet-Draft NSEC Epsilon May 2005 + + + Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, + Jakob Schlyter, Bill Manning, and Joao Damas. + + The key innovation of this document, namely that perfect increment + and decrement functions are not necessary, arose during a discussion + among the above-listed people at the RIPE49 meeting in September + 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 9] + +Internet-Draft NSEC Epsilon May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler & Ihren Expires November 13, 2005 [Page 10] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt new file mode 100644 index 000000000000..17e28e8286e2 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt @@ -0,0 +1,896 @@ + + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: January 19, 2006 M. Kosters + D. Blacka + Verisign, Inc. + July 18, 2005 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-07 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 January 19, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC + 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are + cryptographically secured. Maintaining this cryptography is not + practical or necessary. This document describes an experimental + "Opt-In" model that allows administrators to omit this cryptography + and manage the cost of adopting DNSSEC with large zones. + + + +Arends, et al. Expires January 19, 2006 [Page 1] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5 + 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5 + 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6 + 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6 + 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7 + 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7 + 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8 + 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 11.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 2] + +Internet-Draft DNSSEC Opt-In July 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([3], [4], and [5], referred to in this + document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 + [10]) is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + unsigned name: refers to a DNS name that does not (at least) have a + NSEC record. + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this 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 [7]. + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NSEC record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes an experimental method of eliminating the + + + +Arends, et al. Expires January 19, 2006 [Page 3] + +Internet-Draft DNSSEC Opt-In July 2005 + + + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [6]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with only one or more of these private algorithms. This + requires the signing tools and servers to support private algorithms, + as well as Opt-In. + + Resolvers wishing to validate Opt-In zones MUST only do so when the + zone is only signed using one or more of these private algorithms. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + +4. Protocol Additions + + In DNSSEC, delegation NS RRsets are not signed, but are instead + accompanied by a NSEC RRset of the same name and (possibly) a DS + record. The security status of the subzone is determined by the + presence or absence of the DS RRset, cryptographically proven by the + NSEC record. Opt-In expands this definition by allowing insecure + delegations to exist within an otherwise signed zone without the + corresponding NSEC record at the delegation's owner name. These + insecure delegations are proven insecure by using a covering NSEC + record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC standard DNSSEC + NSEC records and Opt-In NSEC records. This is accomplished by + "tagging" the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + + + +Arends, et al. Expires January 19, 2006 [Page 4] + +Internet-Draft DNSSEC Opt-In July 2005 + + + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map and the signed NSEC record does assert + the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and standard DNSSEC NSEC records. If a NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or not- + specified) NSEC bit in the type bit map of the NSEC record. + o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in + the type bit map of the NSEC record. + + and, + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. Servers also SHOULD reject AXFR or IXFR + + + +Arends, et al. Expires January 19, 2006 [Page 5] + +Internet-Draft DNSSEC Opt-In July 2005 + + + responses that violate this restriction. + +4.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In standard DNSSEC, NSEC records already must be returned along with + the insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to search for the covering NSEC RRset. + +4.1.3 Wildcards and Opt-In + + Standard DNSSEC describes the practice of returning NSEC records to + prove the non-existence of an applicable wildcard in non-existent + name responses. This NSEC record can be described as a "negative + wildcard proof". The use of Opt-In NSEC records changes the + necessity for this practice. For non-existent name responses when + the query name (qname) is covered by an Opt-In tagged NSEC record, + servers MAY choose to omit the wildcard proof record, and clients + MUST NOT treat the absence of this NSEC record as a validation error. + + The intent of the standard DNSSEC negative wildcard proof requirement + is to prevent malicious users from undetectably removing valid + wildcard responses. In order for this cryptographic proof to work, + the resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" + NSEC record. + 2. No applicable wildcard exists. This is done by returning a NSEC + record proving that the wildcard does not exist (this is the + negative wildcard proof). + + However, if the NSEC record covering the exact qname is an Opt-In + NSEC record, the resolver will not be able to prove the first part of + this equation, as the qname might exist as an insecure delegation. + Thus, since the total proof cannot be completed, the negative + wildcard proof NSEC record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NSEC record does not change the + practice of returning a NSEC along with a wildcard expansion. Even + + + +Arends, et al. Expires January 19, 2006 [Page 6] + +Internet-Draft DNSSEC Opt-In July 2005 + + + though the Opt-In NSEC will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +4.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. Servers SHOULD return responses + to update requests with RCODE=REFUSED. + +4.2 Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NSEC + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NSEC record's span + that are not NS records or corresponding glue records. + +4.2.2 Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NSEC records to + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In standard DNSSEC, the security status is proven by the existence + or absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + + + +Arends, et al. Expires January 19, 2006 [Page 7] + +Internet-Draft DNSSEC Opt-In July 2005 + + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the referred-to subzone is signed + or unsigned. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NSEC record, the resolver MUST NOT require proof (in the form + of a NSEC record) that a wildcard did not exist. + +4.2.3 NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from standard DNSSEC in that the covering NSEC + will not have the same owner name as the delegation. Some + implementations may have to use new methods for finding these NSEC + records. + +4.2.4 Use of the AD bit + + The AD bit, as defined by [2] and [5], MUST NOT be set when: + + o sending a Name Error (RCODE=3) response where the covering NSEC is + tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., TLDs) can avoid the substantial overhead of + + + +Arends, et al. Expires January 19, 2006 [Page 8] + +Internet-Draft DNSSEC Opt-In July 2005 + + + modifying and resigning the affected NSEC records. + +6. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( + SOA NS RRSIG DNSKEY ) + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., "FIRST- + SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- + SECURE.EXAMPLE A") will result in a standard DNSSEC response. + + A query for a nonexistent RRset will result in a response that + differs from standard DNSSEC by: the NSEC record will be tagged as + Opt-In, there may be no NSEC record proving the non-existence of a + + + +Arends, et al. Expires January 19, 2006 [Page 9] + +Internet-Draft DNSSEC Opt-In July 2005 + + + matching wildcard record, and the AD bit will not be set. + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- + SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure + delegations in the range they define. (NOT-SECURE.EXAMPLE. and + UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is + part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + removed from the zone without modifying and resigning the prior NSEC + record. Delegations with names that fall between NOT-SECURE- + 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without + resigning any NSEC records. + +7. Transition Issues + + Opt-In is not backwards compatible with standard DNSSEC and is + considered experimental. Standard DNSSEC compliant implementations + would not recognize Opt-In tagged NSEC records as different from + + + +Arends, et al. Expires January 19, 2006 [Page 10] + +Internet-Draft DNSSEC Opt-In July 2005 + + + standard NSEC records. Because of this, standard DNSSEC + implementations, if they were to validate Opt-In style responses, + would reject all Opt-In insecure delegations within a zone as + invalid. However, by only signing with private algorithms, standard + DNSSEC implementations will treat Opt-In responses as unsigned. + + It should be noted that all elements in the resolution path between + (and including) the validator and the authoritative name server must + be aware of the Opt-In experiment and implement the Opt-In semantics + for successful validation to be possible. In particular, this + includes any caching middleboxes between the validator and + authoritative name server. + +8. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilities are described in more detail in [12] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 11] + +Internet-Draft DNSSEC Opt-In July 2005 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + +9. IANA Considerations + + None. + +10. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + +11. References + + + + +Arends, et al. Expires January 19, 2006 [Page 12] + +Internet-Draft DNSSEC Opt-In July 2005 + + +11.1 Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [6] Blacka, D., "DNSSEC Experiments", + draft-ietf-dnsext-dnssec-experiments-01 (work in progress), + July 2005. + +11.2 Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 13] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + Email: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + URI: http://www.verisignlabs.com + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + + + +Arends, et al. Expires January 19, 2006 [Page 14] + +Internet-Draft DNSSEC Opt-In July 2005 + + + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. + R_A is a response generated from V_A, following RFC 2535bis. + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as + described below. + A query is DNSSEC-aware if it either has the DO bit [11] turned + on, or is for a DNSSEC-specific record type. + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + 5. Return R_C. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 15] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 19, 2006 [Page 16] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 000000000000..dd8cbf0682e0 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: August 25, 2005 P. Koch + DENIC eG + J. Schlyter + NIC-SE + February 21, 2005 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-02.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document collects and summarizes different proposals for + alternative and additional strategies for authenticated denial in DNS + responses, evaluates these proposals and gives a recommendation for a + + + +Arends, et al. Expires August 25, 2005 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + way forward. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 + 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 + 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 + 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 + 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 + 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 + 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 + 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 + 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 + 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 + 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 + 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 + 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +1. Introduction + + This report shall document the process of dealing with the NSEC + walking problem late in the Last Call for + [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, + I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion + that took place in the DNSEXT WG during the first half of June 2004 + as well as some additional ideas that came up subsequently. + + This is an edited excerpt of the chairs' mail to the WG: + The working group consents on not including NSEC-alt in the + DNSSEC-bis documents. The working group considers to take up + "prevention of zone enumeration" as a work item. + There may be multiple mechanisms to allow for co-existence with + DNSSEC-bis. The chairs allow the working group a little over a + week (up to June 12, 2004) to come to consensus on a possible + modification to the document to enable gentle rollover. If that + consensus cannot be reached the DNSSEC-bis documents will go out + as-is. + + To ease the process of getting consensus, a summary of the proposed + solutions and analysis of the pros and cons were written during the + weekend. + + This summary includes: + + An inventory of the proposed mechanisms to make a transition to + future work on authenticated denial of existence. + List the known Pros and Cons, possibly provide new arguments, and + possible security considerations of these mechanisms. + Provide a recommendation on a way forward that is least disruptive + to the DNSSEC-bis specifications as they stand and keep an open + path to other methods for authenticated denial of existence. + + The descriptions of the proposals in this document are coarse and do + not cover every detail necessary for implementation. In any case, + documentation and further study is needed before implementaion and/or + deployment, including those which seem to be solely operational in + nature. + +2. Transition Mechanisms + + In the light of recent discussions and past proposals, we have found + several ways to allow for transition to future expansion of + authenticated denial. We tried to illuminate the paths and pitfalls + in these ways forward. Some proposals lead to a versioning of + DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other + proposals are 'clean' but may cause delay, while again others may be + + + +Arends, et al. Expires August 25, 2005 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + plain hacks. + + Some paths do not introduce versioning, and might require the current + DNSSEC-bis documents to be fully updated to allow for extensions to + authenticated denial mechanisms. Other paths introduce versioning + and do not (or minimally) require DNSSEC-bis documents to be updated, + allowing DNSSEC-bis to be deployed, while future versions can be + drafted independent from or partially depending on DNSSEC-bis. + +2.1 Mechanisms With Need of Updating DNSSEC-bis + + Mechanisms in this category demand updates to the DNSSEC-bis document + set. + +2.1.1 Dynamic NSEC Synthesis + + This proposal assumes that NSEC RRs and the authenticating RRSIG will + be generated dynamically to just cover the (non existent) query name. + The owner name is (the) one preceding the name queried for, the Next + Owner Name Field has the value of the Query Name Field + 1 (first + successor in canonical ordering). A separate key (the normal ZSK or + a separate ZSK per authoritative server) would be used for RRSIGs on + NSEC RRs. This is a defense against enumeration, though it has the + presumption of online signing. + +2.1.1.1 Coexistence and Migration + + There is no change in interpretation other then that the next owner + name might or might not exist. + +2.1.1.2 Limitations + + This introduces an unbalanced cost between query and response + generation due to dynamic generation of signatures. + +2.1.1.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents might need to be updated to indicate + that the next owner name might not be an existing name in the zone. + This is not a real change to the spec since implementers have been + warned not to synthesize with previously cached NSEC records. A + specific bit to identify the dynamic signature generating key might + be useful as well, to prevent it from being used to fake positive + data. + +2.1.1.4 Cons + + Unbalanced cost is a ground for DDoS. Though this protects against + + + +Arends, et al. Expires August 25, 2005 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + enumeration, it is not really a path for versioning. + +2.1.1.5 Pros + + Hardly any amendments to DNSSEC-bis. + +2.1.2 Add Versioning/Subtyping to Current NSEC + + This proposal introduces versioning for the NSEC RR type (a.k.a. + subtyping) by adding a (one octet) version field to the NSEC RDATA. + Version number 0 is assigned to the current (DNSSEC-bis) meaning, + making this an 'Must Be Zero' (MBZ) for the to be published docset. + +2.1.2.1 Coexistence and Migration + + Since the versioning is done inside the NSEC RR, different versions + may coexist. However, depending on future methods, that may or may + not be useful inside a single zone. Resolvers cannot ask for + specific NSEC versions but may be able to indicate version support by + means of a to be defined EDNS option bit. + +2.1.2.2 Limitations + + There are no technical limitations, though it will cause delay to + allow testing of the (currently unknown) new NSEC interpretation. + + Since the versioning and signaling is done inside the NSEC RR, future + methods will likely be restricted to a single RR type authenticated + denial (as opposed to e.g. NSEC-alt, which currently proposes three + RR types). + +2.1.2.3 Amendments to DNSSEC-bis + + Full Update of the current DNSSEC-bis documents to provide for new + fields in NSEC, while specifying behavior in case of unknown field + values. + +2.1.2.4 Cons + + Though this is a clean and clear path without versioning DNSSEC, it + takes some time to design, gain consensus, update the current + dnssec-bis document, test and implement a new authenticated denial + record. + +2.1.2.5 Pros + + Does not introduce an iteration to DNSSEC while providing a clear and + clean migration strategy. + + + +Arends, et al. Expires August 25, 2005 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.3 Type Bit Map NSEC Indicator + + Bits in the type-bit-map are reused or allocated to signify the + interpretation of NSEC. + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + the RDATA or introduce an alternative denial mechanism, invoked by + the specific type-bit-map-bits. + +2.1.3.1 Coexistence and migration + + Old and new NSEC meaning could coexist, depending how the signaling + would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR + types are available as well as those covering meta/query types or + types to be specifically allocated. + +2.1.3.2 Limitations + + This mechanism uses an NSEC field that was not designed for that + purpose. Similar methods were discussed during the Opt-In discussion + and the Silly-State discussion. + +2.1.3.3 Amendments to DNSSEC-bis + + The specific type-bit-map-bits must be allocated and they need to be + specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) + interpretation. Also, behaviour of the resolver and validator must + be documented in case unknown values are encountered for the MBZ + field. Currently the protocol document specifies that the validator + MUST ignore the setting of the NSEC and the RRSIG bits, while other + bits are only used for the specific purpose of the type-bit-map field + +2.1.3.4 Cons + + The type-bit-map was not designed for this purpose. It is a + straightforward hack. Text in protocol section 5.4 was put in + specially to defend against this usage. + +2.1.3.5 Pros + + No change needed to the on-the-wire protocol as specified in the + current docset. + +2.1.4 New Apex Type + + This introduces a new Apex type (parallel to the zone's SOA) + indicating the DNSSEC version (or authenticated denial) used in or + + + +Arends, et al. Expires August 25, 2005 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + for this zone. + +2.1.4.1 Coexistence and Migration + + Depending on the design of this new RR type multiple denial + mechanisms may coexist in a zone. Old validators will not understand + and thus ignore the new type, so interpretation of the new NSEC + scheme may fail, negative responses may appear 'bogus'. + +2.1.4.2 Limitations + + A record of this kind is likely to carry additional + feature/versioning indications unrelated to the current question of + authenticated denial. + +2.1.4.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the absence of this type indicates dnssec-bis, and that the (mere) + presence of this type indicated unknown versions. + +2.1.4.4 Cons + + The only other 'zone' or 'apex' record is the SOA record. Though + this proposal is not new, it is yet unknown how it might fulfill + authenticated denial extensions. This new RR type would only provide + for a generalized signaling mechanism, not the new authenticated + denial scheme. Since it is likely to be general in nature, due to + this generality consensus is not to be reached soon. + +2.1.4.5 Pros + + This approach would allow for a lot of other per zone information to + be transported or signaled to both (slave) servers and resolvers. + +2.1.5 NSEC White Lies + + This proposal disables one part of NSEC (the pointer part) by means + of a special target (root, apex, owner, ...), leaving intact only the + ability to authenticate denial of existence of RR sets, not denial of + existence of domain names (NXDOMAIN). It may be necessary to have + one working NSEC to prove the absence of a wildcard. + +2.1.5.1 Coexistence and Migration + + The NSEC target can be specified per RR, so standard NSEC and 'white + lie' NSEC can coexist in a zone. There is no need for migration + because no versioning is introduced or intended. + + + +Arends, et al. Expires August 25, 2005 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.5.2 Limitations + + This proposal breaks the protocol and is applicable to certain types + of zones only (no wildcard, no deep names, delegation only). Most of + the burden is put on the resolver side and operational consequences + are yet to be studied. + +2.1.5.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the NXDOMAIN responses may be insecure. + +2.1.5.4 Cons + + Strictly speaking this breaks the protocol and doesn't fully fulfill + the requirements for authenticated denial of existence. Security + implications need to be carefully documented: search path problems + (forged denial of existence may lead to wrong expansion of non-FQDNs + [RFC1535]) and replay attacks to deny existence of records. + +2.1.5.5 Pros + + Hardly any amendments to DNSSEC-bis. Operational "trick" that is + available anyway. + +2.1.6 NSEC Optional via DNSSKEY Flag + + A new DNSKEY may be defined to declare NSEC optional per zone. + +2.1.6.1 Coexistence and Migration + + Current resolvers/validators will not understand the Flag bit and + will have to treat negative responses as bogus. Otherwise, no + migration path is needed since NSEC is simply turned off. + +2.1.6.2 Limitations + + NSEC can only be made completely optional at the cost of being unable + to prove unsecure delegations (absence of a DS RR [RFC3658]). A next + to this approach would just disable authenticated denial for + non-existence of nodes. + +2.1.6.3 Amendments to DNSSEC-bis + + New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to + be specified in the light of absence of authenticated denial. + + + + + +Arends, et al. Expires August 25, 2005 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.6.4 Cons + + Doesn't fully meet requirements. Operational consequences to be + studied. + +2.1.6.5 Pros + + Official version of the "trick" presented in (8). Operational + problems can be addressed during future work on validators. + +2.1.7 New Answer Pseudo RR Type + + A new pseudo RR type may be defined that will be dynamically created + (and signed) by the responding authoritative server. The RR in the + response will cover the QNAME, QCLASS and QTYPE and will authenticate + both denial of existence of name (NXDOMAIN) or RRset. + +2.1.7.1 Coexistence and Migration + + Current resolvers/validators will not understand the pseudo RR and + will thus not be able to process negative responses so testified. A + signaling or solicitation method would have to be specified. + +2.1.7.2 Limitations + + This method can only be used with online keys and online signing + capacity. + +2.1.7.3 Amendments to DNSSEC-bis + + Signaling method needs to be defined. + +2.1.7.4 Cons + + Keys have to be held and processed online with all security + implications. An additional flag for those keys identifying them as + online or negative answer only keys should be considered. + +2.1.7.5 Pros + + Expands DNSSEC authentication to the RCODE. + +2.1.8 SIG(0) Based Authenticated Denial + + +2.1.8.1 Coexistence and Migration + + + + + +Arends, et al. Expires August 25, 2005 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.8.2 Limitations + + +2.1.8.3 Amendments to DNSSEC-bis + + +2.1.8.4 Cons + + +2.1.8.5 Pros + + +2.2 Mechanisms Without Need of Updating DNSSEC-bis + +2.2.1 Partial Type-code and Signal Rollover + + Carefully crafted type code/signal rollover to define a new + authenticated denial space that extends/replaces DNSSEC-bis + authenticated denial space. This particular path is illuminated by + Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> + posted to <namedroppers@ops.ietf.org> 2004-06-02. + +2.2.1.1 Coexistence and Migration + + To protect the current resolver for future versions, a new DNSSEC-OK + bit must be allocated to make clear it does or does not understand + the future version. Also, a new DS type needs to be allocated to + allow differentiation between a current signed delegation and a + 'future' signed delegation. Also, current NSEC needs to be rolled + into a new authenticated denial type. + +2.2.1.2 Limitations + + None. + +2.2.1.3 Amendments to DNSSEC-bis + + None. + +2.2.1.4 Cons + + It is cumbersome to carefully craft an TCR that 'just fits'. The + DNSSEC-bis protocol has many 'borderline' cases that needs special + consideration. It might be easier to do a full TCR, since a few of + the types and signals need upgrading anyway. + + + + + + +Arends, et al. Expires August 25, 2005 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.2.1.5 Pros + + Graceful adoption of future versions of NSEC, while there are no + amendments to DNSSEC-bis. + +2.2.2 A Complete Type-code and Signal Rollover + + A new DNSSEC space is defined which can exist independent of current + DNSSEC-bis space. + + This proposal assumes that all current DNSSEC type-codes + (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any + future versions of DNSSEC. Any future version of DNSSEC has its own + types to allow for keys, signatures, authenticated denial, etcetera. + +2.2.2.1 Coexistence and Migration + + Both spaces can co-exist. They can be made completely orthogonal. + +2.2.2.2 Limitations + + None. + +2.2.2.3 Amendments to DNSSEC-bis + + None. + +2.2.2.4 Cons + + With this path we abandon the current DNSSEC-bis. Though it is easy + to role specific well-known and well-tested parts into the re-write, + once deployment has started this path is very expensive for + implementers, registries, registrars and registrants as well as + resolvers/users. A TCR is not to be expected to occur frequently, so + while a next generation authenticated denial may be enabled by a TCR, + it is likely that that TCR will only be agreed upon if it serves a + whole basket of changes or additions. A quick introduction of + NSEC-ng should not be expected from this path. + +2.2.2.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. It is + always there as last resort. + +2.2.3 Unknown Algorithm in RRSIG + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + + + +Arends, et al. Expires August 25, 2005 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + the RDATA or introduce an alternative denial mechanism, invoked by + the specific unknown signing algorithm. The different interpretation + would be signaled by use of different signature algorithms in the + RRSIG records covering the NSEC RRs. + + When an entire zone is signed with a single unknown algorithm, it + will cause implementations that follow current dnssec-bis documents + to treat individual RRsets as unsigned. + +2.2.3.1 Coexistence and migration + + Old and new NSEC RDATA interpretation or known and unknown Signatures + can NOT coexist in a zone since signatures cover complete (NSEC) + RRSets. + +2.2.3.2 Limitations + + Validating resolvers agnostic of new interpretation will treat the + NSEC RRset as "not signed". This affects wildcard and non-existence + proof, as well as proof for (un)secured delegations. Also, all + positive signatures (RRSIGs on RRSets other than DS, NSEC) appear + insecure/bogus to an old validator. + + The algorithm version space is split for each future version of + DNSSEC. Violation of the 'modular components' concept. We use the + 'validator' to protect the 'resolver' from unknown interpretations. + +2.2.3.3 Amendments to DNSSEC-bis + + None. + +2.2.3.4 Cons + + The algorithm field was not designed for this purpose. This is a + straightforward hack. + +2.2.3.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. + +3. Recommendation + + The authors recommend that the working group commits to and starts + work on a partial TCR, allowing graceful transition towards a future + version of NSEC. Meanwhile, to accomodate the need for an + immediately, temporary, solution against zone-traversal, we recommend + On-Demand NSEC synthesis. + + + + +Arends, et al. Expires August 25, 2005 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + This approach does not require any mandatory changes to DNSSEC-bis, + does not violate the protocol and fulfills the requirements. As a + side effect, it moves the cost of implementation and deployment to + the users (zone owners) of this mechanism. + +4. Acknowledgements + + The authors would like to thank Sam Weiler and Mark Andrews for their + input and constructive comments. + +5. References + +5.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Massey, D., Larson, M. and S. + Rose, "DNS Security Introduction and Requirements", + Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., "Protocol Modifications for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, + October 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., "Resource Records for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-records-11, + October 2004. + + [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. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + +5.2 Informative References + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, October + 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + + + +Arends, et al. Expires August 25, 2005 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + RFC 2535, March 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + Enschede 7523 XC + The Netherlands + + Phone: +31 53 4850485 + Email: roy.arends@telin.nl + + + Peter Koch + DENIC eG + Wiesenh"uttenplatz 26 + Frankfurt 60329 + Germany + + Phone: +49 69 27235 0 + Email: pk@DENIC.DE + + + Jakob Schlyter + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + Email: jakob@nic.se + URI: http://www.nic.se/ + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 14] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 25, 2005 [Page 15] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt new file mode 100644 index 000000000000..2cdcdb16c920 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT ECC Keys in the DNS +Expires: January 2006 July 2005 + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + <draft-ietf-dnsext-ecc-key-07.txt> + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list <namedroppers@ops.ietf.org>. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve Data in Resource Records.................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 + + Informational References..................................15 + Normative Refrences.......................................15 + + Author's Addresses........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 4033, 4034, + 4035]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. + + 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]. + + + +2. Elliptic Curve Data in Resource Records + + Elliptic curve public keys are stored in the DNS within the RDATA + portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the + structure shown below. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, representations are + defined for every type of finite field, and every type of elliptic + curve. The reader should be aware that there is a unique finite + field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of an RR and MUST be + ignored when processing an RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of + degree D is X^D (which is not irreducible). The next is X^D+1, which + is sometimes irreducible, followed by X^D-1, which isn't. Assuming + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Elliptic Curve SIG Resource Records + + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + shown below. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) + + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + + S = ( K^(-1) * (hash + X*R) ) mod Q. + + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + + If S > Q/2, set S = Q - S. + + The pair (R,S) is the signature. + + Another party verifies the signature as follows: + + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + + hash = SHA-1 ( data ) + + Sinv = S^(-1) mod Q. + + U1 = (hash * Sinv) mod Q. + + U2 = (R * Sinv) mod Q. + + (U1 * G + U2 * Y) is computed on the elliptic curve. + + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + + The signature is valid if V = R. + + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. + + + + 6. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + + + + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Copyright and Disclaimer + + Copyright (C) The Internet Society 2005. This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June + 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security Extensions", RFC + 4034, March 2005. + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + Email: rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + Expiration and File Name + + This draft expires in January 2006. + + Its file name is draft-ietf-dnsext-ecc-key-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt new file mode 100644 index 000000000000..1c4c3f635e37 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt @@ -0,0 +1,754 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Updates RFC 1034, 1035 Motorola Laboratories +Expires January 2006 July 2005 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + <draft-ietf-dnsext-insensitive-06.txt> + + Donald E. Eastlake 3rd + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification updates RFCs 1034 and 1035. + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Copyright Notice...........................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 3. Name Lookup, Label Types, and CLASS.....................4 + 3.1 Original DNS Label Types...............................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 3.3 CLASS Case Insensitivity Considerations................5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 5. Internationalized Domain Names..........................7 + 6. Security Considerations.................................8 + + Copyright and Disclaimer...................................9 + Normative References.......................................9 + Informative References....................................10 + + Changes Between Draft Version.............................11 + -02 to -03 Changes........................................11 + -03 to -04 Changes........................................11 + -04 to -05 Changes........................................11 + -05 to -06 Changes........................................12 + + Author's Address..........................................13 + Expiration and File Name..................................13 + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] that are treated in a + case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. This clarification updates RFCs 1034 + and 1035 [STD 13]. + + 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]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + However, the individual octets of which DNS names consist are not + limited to valid ASCII character codes. They are 8-bit bytes and all + values are allowed. Many applications, however, interpret them as + ASCII characters. + + + +2.1 Escaping Unusual DNS Label Octets + + In Master Files [STD 13] and other human readable and writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range of 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One typographic convention for octets that do not correspond to an + ASCII printing graphic is to use a back-slash followed by the value + of the octet as an unsigned integer represented by exactly three + decimal digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself which can be + expressed as \092 or \\ and the special label separator period (".") + which can be expressed as and \046 or \. respectively. It is + advisable to avoid using a backslash to quote an immediately + following non-printing ASCII character code to avoid implementation + difficulties. + + A back-slash followed by only one or two decimal digits is undefined. + A back-slash followed by four decimal digits produces two octets, the + first octet having the value of the first three digits considered as + a decimal number and the second octet being the character code for + the fourth decimal digit. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 5-octet label where the second + octet has all bits zero, the third is a backslash, and the fourth + octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + + + +3. Name Lookup, Label Types, and CLASS + + The original DNS design decision was made that comparisons on name + lookup for DNS queries should be case insensitive [STD 13]. That is + to say, a lookup string octet with a value in the inclusive range of + 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical + value and also match the corresponding value in the inclusive range + 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet + with a lower case ASCII letter value MUST similarly match the + identical value and also match the corresponding value in the upper + case ASCII letter range. + + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type. The terms originally referred to the + two font trays for storing, in partitioned areas, the different + physical type elements. Before movable type, the nearest equivalent + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + terms were "majuscule" and "minuscule".) + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in [iso-8859-1] or [iso-8859-2]. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts, where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +3.1 Original DNS Label Types + + DNS labels in wire-encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 octets, and indirect (or + compression) labels which consist of an offset pointer to a name + location elsewhere in the wire encoding on a DNS message. (The ASCII + label of length zero is reserved for use as the name of the root node + of the name tree.) ASCII labels follow the ASCII case conventions + described herein and, as stated above, can actually contain arbitrary + byte values. Indirect labels are, in effect, replaced by the name to + which they point which is then treated with the case insensitivity + rules in this document. + + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far is the BINARY type [RFC + 2673] which is now Experimental [RFC 3363].) + + The ASCII case insensitivity conventions only apply to ASCII labels, + that is to say, label type 0x0, whether appearing directly or invoked + by indirect labels. + + + +3.3 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + The handling of DNS label case is not CLASS dependent. With the + original design of DNS, it was intended that a recursive DNS resolver + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + + be able to handle new CLASSes that were unknown at the time of its + implementation. This requires uniform handling of label case + insensitivity. Should it become desireable, for example, to allocate + a CLASS with "case sensitive ASCII labels" for example, it would be + necessary to allocate a new label type for these labels. + + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD 13] says + case MUST be preserved on output, and preserved when convenient on + input. However, this means less than it would appear since the + preservation of case on output is NOT required when output is + optimized by the use of indirect labels, as explained below. + + + +4.1 DNS Output Case Preservation + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshaled by taking the label on the node whose name is + to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations, thus "preserving" case. However, to + optimize output, indirect labels may be used to point to names + elsewhere in the DNS answer. In determining whether the name to be + pointed to, for example the QNAME, is the "same" as the remainder of + the name being optimized, the case insensitive comparison specified + above is done. Thus such optimization may easily destroy the output + preservation of case. This type of optimization is commonly called + "name compression". + + + +4.2 DNS Input Case Preservation + + Originally, DNS data came from an ASCII Master File as defined in + [STD 13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC 1995] have been added as a source of DNS data [RFC + 2136, 3007]. When a node in the DNS name tree is created by any of + such inputs, no case conversion is done. Thus the case of ASCII + labels is preserved if they are for nodes being created. However, + when a name label is input for a node that already exist in DNS data + being held, the situation is more complex. Implementations are free + to retain the case first loaded for such a label or allow new input + to override the old case or even maintain separate copies preserving + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + + the input case. + + For example, if data with owner name "foo.bar.example" is loaded and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", might or might + not be changed to "BAR" in the DNS stored data or the actual input + case could be preserved. Thus later retrieval of data stored under + "xyz.bar.example" in this case can return all data with + "xyz.BAR.example" or all data with "xyz.bar.example" or even, when + more than one RR is being returned, a mixture of these two cases. + This last case is unlikely because optimization of answer length + through indirect labels tends to cause only copy of the name tail + ("bar.example" or "BAR.example") to be used for all returned RRs. + Note that none of this has any effect on the number of completeness + of the RR set returned, only on the case of the names in the RR set + returned. + + The same considerations apply when inputting multiple data records + with owner names differing only in case. For example, if an "A" + record is the first resourced record stored under owner name + "xyz.BAR.example" and then a second "A" record is stored under + "XYZ.BAR.example", the second MAY be stored with the first (lower + case initial label) name or the second MAY override the first so that + only an upper case initial label is retained or both capitalizations + MAY be kept in the DNS stored data. In any case, a retrieval with + either capitalization will retrieve all RRs with either + capitalization. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredictable output capitalization. + + + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC 3490, 3454, 3491, and + 3492]. It makes most of [UNICODE] available through a separate + application level transformation from internationalized domain name + to DNS domain name and from DNS domain name to internationalized + domain name. Any case insensitivity that internationalized domain + names and labels have varies depending on the script and is handled + entirely as part of the transformation described in [RFC 3454] and + [RFC 3491] which should be seen for further details. This is not a + part of the DNS as standardized in STD 13. + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some data base + or file system. Or it could be interpreted as binary data by some + integrity or authentication code system. These problems can usually + be handled by using a standardized or "canonical" form of the DNS + ASCII type labels, that is, always mapping the ASCII letter value + octets in ASCII labels to some specific pre-chosen case, either upper + case or lower case. An example of a canonical form for domain names + (and also a canonical ordering for them) appears in Section 6 of [RFC + 4034]. See also [RFC 3597]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. + + [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Informative References + + [ISO 8859-1] - International Standards Organization, Standard for + Character Encodings, Latin-1. + + [ISO 8859-2] - International Standards Organization, Standard for + Character Encodings, Latin-2. + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of + Foo", 1 April 2001. + + [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + <http://www.unicode.org/unicode/standard/standard.html>. + + + + + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Changes Between Draft Version + + RFC Editor: The following summaries of changes between draft versions + are to be removed before publication. + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + 2. Change to indicate that later input of a label for an existing DNS + name tree node may or may not be normalized to the earlier input or + override it or both may be preserved. + + 3. Numerous minor wording changes. + + + +-03 to -04 Changes + + The following changes were made between draft versions -03 and -04: + + 1. Change to conform to the new IPR, Copyright, etc., notice + requirements. + + 2. Change in some section headers for clarity. + + 3. Drop section on wildcards. + + 4. Add emphasis on loss of case preservation due to name compression. + + 5. Add references to RFCs 1995 and 3092. + + + +-04 to -05 Changes + + The following changes were made between draft versions -04 and -05: + + 1. More clearly state that this draft updates RFCs 1034, 1035 [STD + 13]. + + 2. Add informative references to ISO 8859-1 and ISO 8859-2. + + 3. Fix hyphenation and capitalization nits. + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS Case Insensitivity + + +-05 to -06 Changes + + The following changes were made between draft version -05 and -06. + + 1. Add notation to the RFC Editor that the draft version change + summaries are to be removed before RFC publication. + + 2. Additional text explaining why labe case insensitivity is CLASS + independent. + + 3. Changes and additional text clarifying that the fact that + inconsistent case in data loaded into DNS may result in + unpredicatable or inconsistent case in DNS storage but has no effect + on the completeness of RR sets retrieved. + + 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to + be to [RFC 4034]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires January 2006. + + Its file name is draft-ietf-dnsext-insensitive-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 13] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt new file mode 100644 index 000000000000..160afc356a07 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt @@ -0,0 +1,334 @@ +DNS Extensions Working Group J. Schlyter +Internet-Draft May 19, 2005 +Expires: November 20, 2005 + + + RFC 3597 Interoperability Report + draft-ietf-dnsext-interop3597-02.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 November 20, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 1] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3 + 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3 + 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4 + 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4 + 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 + A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 + Intellectual Property and Copyright Statements . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 2] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +1. Introduction + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. The test was + performed during June and July 2004 by request of the IETF DNS + Extensions Working Group. + +2. Implementations + + The following is a list, in alphabetic order, of implementations + tested for compliance with RFC 3597: + + DNSJava 1.6.4 + ISC BIND 8.4.5 + ISC BIND 9.3.0 + NSD 2.1.1 + Net::DNS 0.47 patchlevel 1 + Nominum ANS 2.2.1.0.d + + These implementations covers the following functions (number of + implementations tested for each function in paranthesis): + + Authoritative Name Servers (4) + Full Recursive Resolver (2) + Stub Resolver (4) + DNSSEC Zone Signers (2) + + All listed implementations are genetically different. + +3. Tests + + The following tests was been performed to validate compliance with + RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression") + and 5 ("Text Representation"). + +3.1 Authoritative Primary Name Server + + The test zone data (Appendix A) was loaded into the name server + implementation and the server was queried for the loaded information. + +3.2 Authoritative Secondary Name Server + + The test zone data (Appendix A) was transferred using AXFR from + another name server implementation and the server was queried for the + transferred information. + + + + + + +Schlyter Expires November 20, 2005 [Page 3] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +3.3 Full Recursive Resolver + + A recursive resolver was queried for resource records from a domain + with the test zone data (Appendix A). + +3.4 Stub Resolver + + A stub resolver was used to query resource records from a domain with + the test zone data (Appendix A). + +3.5 DNSSEC Signer + + A DNSSEC signer was used to sign a zone with test zone data + (Appendix A). + +4. Problems found + + Two implementations had problems with text presentation of zero + length RDATA. + + One implementation had problems with text presentation of RR type + code and classes >= 4096. + + Bug reports were filed for problems found. + +5. Summary + + Unknown type codes works in the tested authoritative servers, + recursive resolvers and stub clients. + + No changes are needed to advance RFC 3597 to draft standard. + +6. Normative References + + [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + +Author's Address + + Jakob Schlyter + + Email: jakob@rfc.se + + + + + + + + +Schlyter Expires November 20, 2005 [Page 4] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Appendix A. Test zone data + + ; A-record encoded as TYPE1 + a TYPE1 \# 4 7f000001 + a TYPE1 192.0.2.1 + a A \# 4 7f000002 + + ; draft-ietf-secsh-dns-05.txt + sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e + + ; bogus test record (from RFC 3597) + type731 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + + ; zero length RDATA (from RFC 3597) + type62347 TYPE62347 \# 0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 5] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Schlyter Expires November 20, 2005 [Page 6] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt new file mode 100644 index 000000000000..5de6e85ecf65 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt @@ -0,0 +1,1740 @@ + + + + + + +DNSEXT Working Group Bernard Aboba +INTERNET-DRAFT Dave Thaler +Category: Standards Track Levon Esibov +<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation +29 August 2005 + + Linklocal Multicast Name Resolution (LLMNR) + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 March 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society 2005. + +Abstract + + The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable + name resolution in scenarios in which conventional DNS name + resolution is not possible. LLMNR supports all current and future + DNS formats, types and classes, while operating on a separate port + from DNS, and with a distinct resolver cache. Since LLMNR only + operates on the local link, it cannot be considered a substitute for + DNS. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name Resolution Using LLMNR ........................... 4 + 2.1 LLMNR Packet Format ............................. 6 + 2.2 Sender Behavior ................................. 9 + 2.3 Responder Behavior .............................. 10 + 2.4 Unicast Queries and Responses ................... 12 + 2.5 Off-link Detection .............................. 13 + 2.6 Responder Responsibilities ...................... 13 + 2.7 Retransmission and Jitter ....................... 14 + 2.8 DNS TTL ......................................... 15 + 2.9 Use of the Authority and Additional Sections .... 15 +3. Usage model ........................................... 16 + 3.1 LLMNR Configuration ............................. 17 +4. Conflict Resolution ................................... 18 + 4.1 Uniqueness Verification ......................... 19 + 4.2 Conflict Detection and Defense .................. 20 + 4.3 Considerations for Multiple Interfaces .......... 21 + 4.4 API issues ...................................... 22 +5. Security Considerations ............................... 22 + 5.1 Denial of Service ............................... 23 + 5.2 Spoofing ...............,........................ 23 + 5.3 Authentication .................................. 24 + 5.4 Cache and Port Separation ....................... 25 +6. IANA considerations ................................... 25 +7. Constants ............................................. 25 +8. References ............................................ 25 + 8.1 Normative References ............................ 25 + 8.2 Informative References .......................... 26 +Acknowledgments .............................................. 27 +Authors' Addresses ........................................... 28 +Intellectual Property Statement .............................. 28 +Disclaimer of Validity ....................................... 29 +Copyright Statement .......................................... 29 + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +1. Introduction + + This document discusses Link Local Multicast Name Resolution (LLMNR), + which is based on the DNS packet format and supports all current and + future DNS formats, types and classes. LLMNR operates on a separate + port from the Domain Name System (DNS), with a distinct resolver + cache. + + The goal of LLMNR is to enable name resolution in scenarios in which + conventional DNS name resolution is not possible. Usage scenarios + (discussed in more detail in Section 3.1) include situations in which + hosts are not configured with the address of a DNS server; where the + DNS server is unavailable or unreachable; where there is no DNS + server authoritative for the name of a host, or where the + authoritative DNS server does not have the desired RRs, as described + in Section 2. + + Since LLMNR only operates on the local link, it cannot be considered + a substitute for DNS. Link-scope multicast addresses are used to + prevent propagation of LLMNR traffic across routers, potentially + flooding the network. LLMNR queries can also be sent to a unicast + address, as described in Section 2.4. + + Propagation of LLMNR packets on the local link is considered + sufficient to enable name resolution in small networks. In such + networks, if a network has a gateway, then typically the network is + able to provide DNS server configuration. Configuration issues are + discussed in Section 3.1. + + In the future, it may be desirable to consider use of multicast name + resolution with multicast scopes beyond the link-scope. This could + occur if LLMNR deployment is successful, the need arises for + multicast name resolution beyond the link-scope, or multicast routing + becomes ubiquitous. For example, expanded support for multicast name + resolution might be required for mobile ad-hoc networks. + + Once we have experience in LLMNR deployment in terms of + administrative issues, usability and impact on the network, it will + be possible to reevaluate which multicast scopes are appropriate for + use with multicast name resolution. IPv4 administratively scoped + multicast usage is specified in "Administratively Scoped IP + Multicast" [RFC2365]. + + Service discovery in general, as well as discovery of DNS servers + using LLMNR in particular, is outside of the scope of this document, + as is name resolution over non-multicast capable media. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +1.1. Requirements + + In this document, several words are used to signify the requirements + of the specification. 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 + [RFC2119]. + +1.2. Terminology + + This document assumes familiarity with DNS terminology defined in + [RFC1035]. Other terminology used in this document includes: + +Positively Resolved + Responses with RCODE set to zero are referred to in this document + as "positively resolved". + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + +Reachable + An LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address received on that link. + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + +Sender + A host that sends an LLMNR query. + +UNIQUE + There are some scenarios when multiple responders may respond to + the same query. There are other scenarios when only one responder + may respond to a query. Names for which only a single responder is + anticipated are referred to as UNIQUE. Name uniqueness is + configured on the responder, and therefore uniqueness verification + is the responder's responsibility. + +2. Name Resolution Using LLMNR + + LLMNR is a peer-to-peer name resolution protocol that is not intended + as a replacement for DNS. LLMNR queries are sent to and received on + port 5355. The IPv4 link-scope multicast address a given responder + listens to, and to which a sender sends queries, is 224.0.0.252. The + IPv6 link-scope multicast address a given responder listens to, and + + + +Aboba, Thaler & Esibov Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + to which a sender sends all queries, is FF02:0:0:0:0:0:1:3. + + Typically a host is configured as both an LLMNR sender and a + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender, if only to verify the uniqueness of names as described in + Section 4. This document does not specify how names are chosen or + configured. This may occur via any mechanism, including DHCPv4 + [RFC2131] or DHCPv6 [RFC3315]. + + LLMNR usage MAY be configured manually or automatically on a per + interface basis. By default, LLMNR responders SHOULD be enabled on + all interfaces, at all times. Enabling LLMNR for use in situations + where a DNS server has been configured will result in a change in + default behavior without a simultaneous update to configuration + information. Where this is considered undesirable, LLMNR SHOULD NOT + be enabled by default, so that hosts will neither listen on the link- + scope multicast address, nor will they send queries to that address. + + By default, LLMNR queries MAY be sent only when one of the following + conditions are met: + + [1] No manual or automatic DNS configuration has been performed. + If DNS server address(es) have been configured, then LLMNR + SHOULD NOT be used as the primary name resolution mechanism, + although it MAY be used as a secondary name resolution + mechanism. A dual stack host SHOULD attempt to reach DNS + servers overall protocols on which DNS server address(es) are + configured, prior to sending LLMNR queries. For dual stack + hosts configured with DNS server address(es) for one protocol + but not another, this inplies that DNS queries SHOULD be sent + over the protocol configured with a DNS server, prior to + sending LLMNR queries. + + [2] All attempts to resolve the name via DNS on all interfaces + have failed after exhausting the searchlist. This can occur + because DNS servers did not respond, or because they + responded to DNS queries with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. Where a + single resolver call generates DNS queries for A and AAAA RRs, + an implementation MAY choose not to send LLMNR queries if any + of the DNS queries is successful. An LLMNR query SHOULD only + be sent for the originally requested name; a searchlist + is not used to form additional LLMNR queries. + + While these conditions are necessary for sending an LLMNR query, they + are not sufficient. While an LLMNR sender MAY send a query for any + name, it also MAY impose additional conditions on sending LLMNR + + + +Aboba, Thaler & Esibov Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + queries. For example, a sender configured with a DNS server MAY send + LLMNR queries only for unqualified names and for fully qualified + domain names within configured zones. + + A typical sequence of events for LLMNR usage is as follows: + + [a] DNS servers are not configured or attempts to resolve the + name via DNS have failed, after exhausting the searchlist. + Also, the name to be queried satisfies the restrictions + imposed by the implementation. + + [b] An LLMNR sender sends an LLMNR query to the link-scope + multicast address(es), unless a unicast query is indicated, + as specified in Section 2.4. + + [c] A responder responds to this query only if it is authoritative + for the domain name in the query. A responder responds to a + multicast query by sending a unicast UDP response to the sender. + Unicast queries are responded to as indicated in Section 2.4. + + [d] Upon reception of the response, the sender processes it. + + The sections that follow provide further details on sender and + responder behavior. + +2.1. LLMNR Packet Format + + LLMNR is based on the DNS packet format defined in [RFC1035] Section + 4 for both queries and responses. LLMNR implementations SHOULD send + UDP queries and responses only as large as are known to be + permissible without causing fragmentation. When in doubt a maximum + packet size of 512 octets SHOULD be used. LLMNR implementations MUST + accept UDP queries and responses as large as the smaller of the link + MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 + octets for the header, VLAN tag and CRC). + +2.1.1. LLMNR Header Format + + LLMNR queries and responses utilize the DNS header format defined in + [RFC1035] with exceptions noted below: + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. For advice on generation of pseudo-random values, please + consult [RFC1750]. + +QR Query/Response. A one bit field, which if set indicates that the + message is an LLMNR response; if clear then the message is an LLMNR + query. + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + +C Conflict. When set within a request, the 'C'onflict bit indicates + that a sender has received multiple LLMNR responses to this query. + In an LLMNR response, if the name is considered UNIQUE, then the + 'C' bit is clear, otherwise it is set. LLMNR senders do not + retransmit queries with the 'C' bit set. Responders MUST NOT + respond to LLMNR queries with the 'C' bit set, but may start the + uniqueness verification process, as described in Section 4.2. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set in an LLMNR response, + then the sender SHOULD discard the response and resend the LLMNR + query over TCP using the unicast address of the responder as the + destination address. See [RFC2181] and Section 2.4 of this + specification for further discussion of the TC bit. + +T Tentative. The 'T'entative bit is set in a response if the + responder is authoritative for the name, but has not yet verified + the uniqueness of the name. A responder MUST ignore the 'T' bit in + a query, if set. A response with the 'T' bit set is silently + discarded by the sender, except if it is a uniqueness query, in + which case a conflict has been detected and a responder MUST + resolve the conflict as described in Section 4.1. + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the sender MUST set RCODE to zero; + the responder ignores the RCODE and assumes it to be zero. The + response to a multicast LLMNR query MUST have RCODE set to zero. A + sender MUST silently discard an LLMNR response with a non-zero + RCODE sent in response to a multicast query. + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferable to not + sending a response, since it enables errors to be diagnosed. + Errors include those defined in [RFC2845], such as BADSIG(16), + BADKEY(17) and BADTIME(18). + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + + + +Aboba, Thaler & Esibov Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + discard LLMNR queries with ANCOUNT not equal to zero. + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. LLMNR + responders MUST silently discard LLMNR queries with NSCOUNT not + equal to zero. + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + +2.2. Sender Behavior + + A sender MAY send an LLMNR query for any legal resource record type + (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. + As described in Section 2.4, a sender MAY also send a unicast query. + + The sender MUST anticipate receiving no replies to some LLMNR + queries, in the event that no responders are available within the + link-scope. If no response is received, a resolver treats it as a + response that the name does not exist (RCODE=3 is returned). A + sender can handle duplicate responses by discarding responses with a + source IP address and ID field that duplicate a response already + received. + + When multiple valid LLMNR responses are received with the 'C' bit + set, they SHOULD be concatenated and treated in the same manner that + multiple RRs received from the same DNS server would be. However, + responses with the 'C' bit set SHOULD NOT be concatenated with + responses with the 'C' bit clear; instead, only the responses with + the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are + received along with error response(s), then the error responses are + + + +Aboba, Thaler & Esibov Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + silently discarded. + + If error responses are received from both DNS and LLMNR, then the + lowest RCODE value should be returned. For example, if either DNS or + LLMNR receives a response with RCODE=0, then this should returned to + the caller. + + Since the responder may order the RRs in the response so as to + indicate preference, the sender SHOULD preserve ordering in the + response to the querying application. + +2.3. Responder Behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address, responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a + responder has another RR in addition to the SOA RR; the SOA RR MUST + NOT be the only RR that a responder has. However, in general whether + RRs are manually or automatically created is an implementation + decision. + + For example, a host configured to have computer name "host1" and to + be a member of the "example.com" domain, and with IPv4 address + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.2.0.192.in-addr.arpa. IN PTR host1. + IN PTR host1.example.com. + + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. + ip6.arpa IN PTR host1. (line split for formatting reasons) + IN PTR host1.example.com. + + An LLMNR responder might be further manually configured with the name + of a local mail server with an MX RR included in the "host1." and + "host1.example.com." records. + + In responding to queries: + + + + + +Aboba, Thaler & Esibov Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +[a] Responders MUST listen on UDP port 5355 on the link-scope multicast + address(es) defined in Section 2, and on UDP and TCP port 5355 on + the unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses MUST always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[g] If a responder is authoritative for a name, it MUST respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. + + As an example, a host configured to respond to LLMNR queries for the + name "foo.example.com." is authoritative for the name + "foo.example.com.". On receiving an LLMNR query for an A RR with the + name "foo.example.com." the host authoritatively responds with A + RR(s) that contain IP address(es) in the RDATA of the resource + record. If the responder has a AAAA RR, but no A RR, and an A RR + query is received, the responder would respond with RCODE=0 and an + empty answer section. + + In conventional DNS terminology a DNS server authoritative for a zone + is authoritative for all the domain names under the zone apex except + for the branches delegated into separate zones. Contrary to + conventional DNS terminology, an LLMNR responder is authoritative + only for the zone apex. + + + +Aboba, Thaler & Esibov Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + For example the host "foo.example.com." is not authoritative for the + name "child.foo.example.com." unless the host is configured with + multiple names, including "foo.example.com." and + "child.foo.example.com.". As a result, "foo.example.com." cannot + reply to an LLMNR query for "child.foo.example.com." with RCODE=3 + (authoritative name error). The purpose of limiting the name + authority scope of a responder is to prevent complications that could + be caused by coexistence of two or more hosts with the names + representing child and parent (or grandparent) nodes in the DNS tree, + for example, "foo.example.com." and "child.foo.example.com.". + + Without the restriction on authority an LLMNR query for an A resource + record for the name "child.foo.example.com." would result in two + authoritative responses: RCODE=3 (authoritative name error) received + from "foo.example.com.", and a requested A record - from + "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled + hosts could perform a dynamic update of the parent (or grandparent) + zone with a delegation to a child zone; for example a host + "child.foo.example.com." could send a dynamic update for the NS and + glue A record to "foo.example.com.". However, this approach + significantly complicates implementation of LLMNR and would not be + acceptable for lightweight hosts. + +2.4. Unicast Queries and Responses + + Unicast queries SHOULD be sent when: + + [a] A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + [b] The sender queries for a PTR RR of a fully formed IP address + within the "in-addr.arpa" or "ip6.arpa" zones. + + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same TCP connection as the query. Senders MUST + support sending TCP queries, and responders MUST support listening + for TCP queries. If the sender of a TCP query receives a response to + that query not using TCP, the response MUST be silently discarded. + + Unicast UDP queries MUST be silently discarded. + + If TCP connection setup cannot be completed in order to send a + unicast TCP query, this is treated as a response that no records of + the specified type and class exist for the specified name (it is + treated the same as a response with RCODE=0 and an empty answer + section). + + + + + +Aboba, Thaler & Esibov Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +2.5. "Off link" Detection + + A sender MUST select a source address for LLMNR queries that is + assigned on the interface on which the query is sent. The + destination address of an LLMNR query MUST be a link-scope multicast + address or a unicast address. + + A responder MUST select a source address for responses that is + assigned on the interface on which the query was received. The + destination address of an LLMNR response MUST be a unicast address. + + On receiving an LLMNR query, the responder MUST check whether it was + sent to a LLMNR multicast addresses defined in Section 2. If it was + sent to another multicast address, then the query MUST be silently + discarded. + + Section 2.4 discusses use of TCP for LLMNR queries and responses. In + composing an LLMNR query using TCP, the sender MUST set the Hop Limit + field in the IPv6 header and the TTL field in the IPv4 header of the + response to one (1). The responder SHOULD set the TTL or Hop Limit + settings on the TCP listen socket to one (1) so that SYN-ACK packets + will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This + prevents an incoming connection from off-link since the sender will + not receive a SYN-ACK from the responder. + + For UDP queries and responses, the Hop Limit field in the IPv6 header + and the TTL field in the IPV4 header MAY be set to any value. + However, it is RECOMMENDED that the value 255 be used for + compatibility with Apple Bonjour [Bonjour]. + + Implementation note: + + In the sockets API for IPv4 [POSIX], the IP_TTL and + IP_MULTICAST_TTL socket options are used to set the TTL of + outgoing unicast and multicast packets. The IP_RECVTTL socket + option is available on some platforms to retrieve the IPv4 TTL of + received packets with recvmsg(). [RFC2292] specifies similar + options for setting and retrieving the IPv6 Hop Limit. + +2.6. Responder Responsibilities + + It is the responsibility of the responder to ensure that RRs returned + in LLMNR responses MUST only include values that are valid on the + local interface, such as IPv4 or IPv6 addresses valid on the local + link or names defended using the mechanism described in Section 4. + IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local + addresses are defined in [RFC2373]. In particular: + + + + +Aboba, Thaler & Esibov Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + [a] If a link-scope IPv6 address is returned in a AAAA RR, + that address MUST be valid on the local link over which + LLMNR is used. + + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + +2.7. Retransmission and Jitter + + An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine + when to retransmit an LLMNR query. An LLMNR sender SHOULD either + estimate the LLMNR_TIMEOUT for each interface, or set a reasonably + high initial timeout. Suggested constants are described in Section + 7. + + If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, + then a sender SHOULD repeat the transmission of the query in order to + assure that it was received by a host capable of responding to it, + while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR + query SHOULD NOT be sent more than three times. + + Where LLMNR queries are sent using TCP, retransmission is handled by + the transport layer. Queries with the 'C' bit set MUST be sent using + multicast UDP and MUST NOT be retransmitted. + + An LLMNR sender cannot know in advance if a query sent using + multicast will receive no response, one response, or more than one + response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response + has been received, or if it is necessary to collect all potential + responses, such as if a uniqueness verification query is being made. + Otherwise an LLMNR sender SHOULD consider a multicast query answered + after the first response is received, if that response has the 'C' + bit clear. + + + +Aboba, Thaler & Esibov Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + However, if the first response has the 'C' bit set, then the sender + SHOULD wait for LLMNR_TIMEOUT in order to collect all possible + responses. When multiple valid answers are received, they may first + be concatenated, and then treated in the same manner that multiple + RRs received from the same DNS server would. A unicast query sender + considers the query answered after the first response is received, so + that it only waits for LLMNR_TIMEOUT if no response has been + received. + + Since it is possible for a response with the 'C' bit clear to be + followed by a response with the 'C' bit set, an LLMNR sender SHOULD + be prepared to process additional responses for the purposes of + conflict detection and LLMNR_TIMEOUT estimation, even after it has + considered a query answered. + + In order to avoid synchronization, the transmission of each LLMNR + query and response SHOULD delayed by a time randomly selected from + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + responders responding with names which they have previously + determined to be UNIQUE (see Section 4 for details). + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + + Due to the TTL minimalization necessary when caching an RRset, all + TTLs in an RRset MUST be set to the same value. + +2.9. Use of the Authority and Additional Sections + + Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a + concept of delegation. In LLMNR, the NS resource record type may be + stored and queried for like any other type, but it has no special + delegation semantics as it does in the DNS. Responders MAY have NS + records associated with the names for which they are authoritative, + but they SHOULD NOT include these NS records in the authority + sections of responses. + + Responders SHOULD insert an SOA record into the authority section of + a negative response, to facilitate negative caching as specified in + [RFC2308]. The TTL of this record is set from the minimum of the + MINIMUM field of the SOA record and the TTL of the SOA itself, and + indicates how long a resolver may cache the negative answer. The + owner name of the SOA record (MNAME) MUST be set to the query name. + The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored + + + +Aboba, Thaler & Esibov Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + by senders. Negative responses without SOA records SHOULD NOT be + cached. + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. + + Senders MUST NOT cache RRs from the authority or additional section + of a response as answers, though they may be used for other purposes + such as negative caching. + +3. Usage Model + + Since LLMNR is a secondary name resolution mechanism, its usage is in + part determined by the behavior of DNS implementations. This + document does not specify any changes to DNS resolver behavior, such + as searchlist processing or retransmission/failover policy. However, + robust DNS resolver implementations are more likely to avoid + unnecessary LLMNR queries. + + As noted in [DNSPerf], even when DNS servers are configured, a + significant fraction of DNS queries do not receive a response, or + result in negative responses due to missing inverse mappings or NS + records that point to nonexistent or inappropriate hosts. This has + the potential to result in a large number of unnecessary LLMNR + queries. + + [RFC1536] describes common DNS implementation errors and fixes. If + the proposed fixes are implemented, unnecessary LLMNR queries will be + reduced substantially, and so implementation of [RFC1536] is + recommended. + + For example, [RFC1536] Section 1 describes issues with retransmission + and recommends implementation of a retransmission policy based on + round trip estimates, with exponential backoff. [RFC1536] Section 4 + describes issues with failover, and recommends that resolvers try + another server when they don't receive a response to a query. These + policies are likely to avoid unnecessary LLMNR queries. + + [RFC1536] Section 3 describes zero answer bugs, which if addressed + + + +Aboba, Thaler & Esibov Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + will also reduce unnecessary LLMNR queries. + + [RFC1536] Section 6 describes name error bugs and recommended + searchlist processing that will reduce unnecessary RCODE=3 + (authoritative name) errors, thereby also reducing unnecessary LLMNR + queries. + +3.1. LLMNR Configuration + + Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is + possible for a dual stack host to be configured with the address of a + DNS server over IPv4, while remaining unconfigured with a DNS server + suitable for use over IPv6. + + In these situations, a dual stack host will send AAAA queries to the + configured DNS server over IPv4. However, an IPv6-only host + unconfigured with a DNS server suitable for use over IPv6 will be + unable to resolve names using DNS. Automatic IPv6 DNS configuration + mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely + deployed, and not all DNS servers support IPv6. Therefore lack of + IPv6 DNS configuration may be a common problem in the short term, and + LLMNR may prove useful in enabling link-local name resolution over + IPv6. + + Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local + IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no + DNS server is authoritative for the names of local hosts, or the + authoritative DNS server(s) do not support dynamic update, then LLMNR + enables linklocal name resolution over IPv4. + + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + + + +Aboba, Thaler & Esibov Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + configure LLMNR on an interface. The LLMNR Enable Option, described + in [LLMNREnable], can be used to explicitly enable or disable use of + LLMNR on an interface. The LLMNR Enable Option does not determine + whether or in which order DNS itself is used for name resolution. + The order in which various name resolution mechanisms should be used + can be specified using the Name Service Search Option (NSSO) for DHCP + [RFC2937], using the LLMNR Enable Option code carried in the NSSO + data. + + It is possible that DNS configuration mechanisms will go in and out + of service. In these circumstances, it is possible for hosts within + an administrative domain to be inconsistent in their DNS + configuration. + + For example, where DHCP is used for configuring DNS servers, one or + more DHCP servers can fail. As a result, hosts configured prior to + the outage will be configured with a DNS server, while hosts + configured after the outage will not. Alternatively, it is possible + for the DNS configuration mechanism to continue functioning while + configured DNS servers fail. + + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict Resolution + + By default, a responder SHOULD be configured to behave as though its + name is UNIQUE on each interface on which LLMNR is enabled. However, + it is also possible to configure multiple responders to be + authoritative for the same name. For example, multiple responders + MAY respond to a query for an A or AAAA type record for a cluster + name (assigned to multiple hosts in the cluster). + + To detect duplicate use of a name, an administrator can use a name + resolution utility which employs LLMNR and lists both responses and + responders. This would allow an administrator to diagnose behavior + and potentially to intervene and reconfigure LLMNR responders who + should not be configured to respond to the same name. + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +4.1. Uniqueness Verification + + Prior to sending an LLMNR response with the 'T' bit clear, a + responder configured with a UNIQUE name MUST verify that there is no + other host within the scope of LLMNR query propagation that is + authoritative for the same name on that interface. + + Once a responder has verified that its name is UNIQUE, if it receives + an LLMNR query for that name, with the 'C' bit clear, it MUST + respond, with the 'T' bit clear. Prior to verifying that its name is + UNIQUE, a responder MUST set the 'T' bit in responses. + + Uniqueness verification is carried out when the host: + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive + during sleep) + - is configured to respond to LLMNR queries on an interface + enabled for transmission and reception of IP traffic + - is configured to respond to LLMNR queries using additional + UNIQUE resource records + - verifies the acquisition of a new IP address and configuration + on an interface + + To verify uniqueness, a responder MUST send an LLMNR query with the + 'C' bit clear, over all protocols on which it responds to LLMNR + queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify + uniqueness of a name by sending a query for the name with type='ANY'. + + If no response is received, the sender retransmits the query, as + specified in Section 2.7. If a response is received, the sender MUST + check if the source address matches the address of any of its + interfaces; if so, then the response is not considered a conflict, + since it originates from the sender. To avoid triggering conflict + detection, a responder that detects that it is connected to the same + link on multiple interfaces SHOULD set the 'C' bit in responses. + + If a response is received with the 'T' bit clear, the responder MUST + NOT use the name in response to LLMNR queries received over any + protocol (IPv4 or IPv6). If a response is received with the 'T' bit + set, the responder MUST check if the source IP address in the + response, interpreted as an unsigned integer, is less than the source + IP address in the query. If so, the responder MUST NOT use the name + in response to LLMNR queries received over any protocol (IPv4 or + IPv6). For the purpose of uniqueness verification, the contents of + the answer section in a response is irrelevant. + + Periodically carrying out uniqueness verification in an attempt to + + + +Aboba, Thaler & Esibov Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. LLMNR responders SHOULD NOT + periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + In order to enable ongoing detection of name conflicts, when an LLMNR + sender receives multiple LLMNR responses to a query, it MUST check if + the 'C' bit is clear in any of the responses. If so, the sender + SHOULD send another query for the same name, type and class, this + time with the 'C' bit set, with the potentially conflicting resource + records included in the additional section. + + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict before acting on it. A + responder receiving a query with the 'C' bit set MUST NOT respond. + + If the query is for a UNIQUE name, then the responder MUST send its + own query for the same name, type and class, with the 'C' bit clear. + If a response is received, the sender MUST check if the source + address matches the address of any of its interfaces; if so, then the + response is not considered a conflict, since it originates from the + sender. To avoid triggering conflict detection, a responder that + detects that it is connected to the same link on multiple interfaces + SHOULD set the 'C' bit in responses. + + An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD + log them. Upon detecting a conflict, an LLMNR responder MUST + immediately stop using the conflicting name in response to LLMNR + queries received over any supported protocol, if the source IP + address in the response, interpreted as an unsigned integer, is less + than the source IP address in the uniqueness verification query. + + After stopping the use of a name, the responder MAY elect to + configure a new name. However, since name reconfiguration may be + disruptive, this is not required, and a responder may have been + configured to respond to multiple names so that alternative names may + already be available. A host that has stopped the use of a name may + attempt uniqueness verification again after the expiration of the TTL + of the conflicting response. + + + +Aboba, Thaler & Esibov Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +4.3. Considerations for Multiple Interfaces + + A multi-homed host may elect to configure LLMNR on only one of its + active interfaces. In many situations this will be adequate. + However, should a host need to configure LLMNR on more than one of + its active interfaces, there are some additional precautions it MUST + take. Implementers who are not planning to support LLMNR on multiple + interfaces simultaneously may skip this section. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + + A multi-homed host checks the uniqueness of UNIQUE records as + described in Section 4. The situation is illustrated in figure 1. + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + + In this situation, the multi-homed myhost will probe for, and defend, + its host name on both interfaces. A conflict will be detected on one + interface, but not the other. The multi-homed myhost will not be + able to respond with a host RR for "myhost" on the interface on the + right (see Figure 1). The multi-homed host may, however, be + configured to use the "myhost" name on the interface on the left. + + Since names are only unique per-link, hosts on different links could + be using the same name. If an LLMNR client sends requests over + multiple interfaces, and receives replies from more than one, the + result returned to the client is defined by the implementation. The + situation is illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + + If host myhost is configured to use LLMNR on both interfaces, it will + send LLMNR queries on both interfaces. When host myhost sends a + query for the host RR for name "A" it will receive a response from + hosts on both interfaces. + + Host myhost cannot distinguish between the situation shown in Figure + + + +Aboba, Thaler & Esibov Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + 2, and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + + This illustrates that the proposed name conflict resolution mechanism + does not support detection or resolution of conflicts between hosts + on different links. This problem can also occur with DNS when a + multi-homed host is connected to two different networks with + separated name spaces. It is not the intent of this document to + address the issue of uniqueness of names within DNS. + +4.4. API Issues + + [RFC2553] provides an API which can partially solve the name + ambiguity problem for applications written to use this API, since the + sockaddr_in6 structure exposes the scope within which each scoped + address exists, and this structure can be used for both IPv4 (using + v4-mapped IPv6 addresses) and IPv6 addresses. + + Following the example in Figure 2, an application on 'myhost' issues + the request getaddrinfo("A", ...) with ai_family=AF_INET6 and + ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both + interfaces and the resolver library will return a list containing + multiple addrinfo structures, each with an associated sockaddr_in6 + structure. This list will thus contain the IPv4 and IPv6 addresses + of both hosts responding to the name 'A'. Link-local addresses will + have a sin6_scope_id value that disambiguates which interface is used + to reach the address. Of course, to the application, Figures 2 and 3 + are still indistinguishable, but this API allows the application to + communicate successfully with any address in the list. + +5. Security Considerations + + LLMNR is a peer-to-peer name resolution protocol designed for use on + the local link. While LLMNR limits the vulnerability of responders + to off-link senders, it is possible for an off-link responder to + reach a sender. + + In scenarios such as public "hotspots" attackers can be present on + the same link. These threats are most serious in wireless networks + such as 802.11, since attackers on a wired network will require + physical access to the network, while wireless attackers may mount + + + +Aboba, Thaler & Esibov Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + attacks from a distance. Link-layer security such as [IEEE-802.11i] + can be of assistance against these threats if it is available. + + This section details security measures available to mitigate threats + from on and off-link attackers. + +5.1. Denial of Service + + Attackers may take advantage of LLMNR conflict detection by + allocating the same name, denying service to other LLMNR responders + and possibly allowing an attacker to receive packets destined for + other hosts. By logging conflicts, LLMNR responders can provide + forensic evidence of these attacks. + + An attacker may spoof LLMNR queries from a victim's address in order + to mount a denial of service attack. Responders setting the IPv6 Hop + Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP + response may be able to reach the victim across the Internet. + + While LLMNR responders only respond to queries for which they are + authoritative and LLMNR does not provide wildcard query support, an + LLMNR response may be larger than the query, and an attacker can + generate multiple responses to a query for a name used by multiple + responders. A sender may protect itself against unsolicited + responses by silently discarding them as rapidly as possible. + +5.2. Spoofing + + LLMNR is designed to prevent reception of queries sent by an off-link + attacker. LLMNR requires that responders receiving UDP queries check + that they are sent to a link-scope multicast address. However, it is + possible that some routers may not properly implement link-scope + multicast, or that link-scope multicast addresses may leak into the + multicast routing system. To prevent successful setup of TCP + connections by an off-link sender, responders receiving a TCP SYN + reply with a TCP SYN-ACK with TTL set to one (1). + + While it is difficult for an off-link attacker to send an LLMNR query + to a responder, it is possible for an off-link attacker to spoof a + response to a query (such as an A or AAAA query for a popular + Internet host), and by using a TTL or Hop Limit field larger than one + (1), for the forged response to reach the LLMNR sender. Since the + forged response will only be accepted if it contains a matching ID + field, choosing a pseudo-random ID field within queries provides some + protection against off-link responders. + + Since LLMNR queries can be sent when DNS server(s) do not respond, an + attacker can execute a denial of service attack on the DNS server(s) + + + +Aboba, Thaler & Esibov Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + and then poison the LLMNR cache by responding to an LLMNR query with + incorrect information. As noted in "Threat Analysis of the Domain + Name System (DNS)" [RFC3833] these threats also exist with DNS, since + DNS response spoofing tools are available that can allow an attacker + to respond to a query more quickly than a distant DNS server. + However, while switched networks or link layer security may make it + difficult for an on-link attacker to snoop unicast DNS queries, + multicast LLMNR queries are propagated to all hosts on the link, + making it possible for an on-link attacker to spoof LLMNR responses + without having to guess the value of the ID field in the query. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing + a response in a timely way is not difficult, since a legitimate + response will never be received. + + Limiting the situations in which LLMNR queries are sent, as described + in Section 2, is the best protection against these attacks. If LLMNR + is given higher priority than DNS among the enabled name resolution + mechanisms, a denial of service attack on the DNS server would not be + necessary in order to poison the LLMNR cache, since LLMNR queries + would be sent even when the DNS server is available. In addition, + the LLMNR cache, once poisoned, would take precedence over the DNS + cache, eliminating the benefits of cache separation. As a result, + LLMNR is only used as a name resolution mechanism of last resort. + +5.3. Authentication + + LLMNR is a peer-to-peer name resolution protocol, and as a result, + it is often deployed in situations where no trust model can be + assumed. This makes it difficult to apply existing DNS security + mechanisms to LLMNR. + + LLMNR does not support "delegated trust" (CD or AD bits). As a + result, unless LLMNR senders are DNSSEC aware, it is not feasible to + use DNSSEC [RFC4033] with LLMNR. + + If authentication is desired, and a pre-arranged security + configuration is possible, then the following security mechanisms may + be used: + +[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) + [RFC2931] security mechanisms. "DNS Name Service based on Secure + Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes + the use of TSIG to secure LLMNR responses, based on group keys. + + + + +Aboba, Thaler & Esibov Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +[b] IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast + queries. In a small network without a certificate authority, this + can be most easily accomplished through configuration of a group + pre-shared key for trusted hosts. + + Where these mechanisms cannot be supported, responses to LLMNR + queries may be unauthenticated. + +5.4. Cache and Port Separation + + In order to prevent responses to LLMNR queries from polluting the DNS + cache, LLMNR implementations MUST use a distinct, isolated cache for + LLMNR on each interface. The use of separate caches is most + effective when LLMNR is used as a name resolution mechanism of last + resort, since this minimizes the opportunities for poisoning the + LLMNR cache, and decreases reliance on it. + + LLMNR operates on a separate port from DNS, reducing the likelihood + that a DNS server will unintentionally respond to an LLMNR query. + +6. IANA Considerations + + This specification creates one new name space: the reserved bits in + the LLMNR header. These are allocated by IETF Consensus, in + accordance with BCP 26 [RFC2434]. + + LLMNR requires allocation of port 5355 for both TCP and UDP. + + LLMNR requires allocation of link-scope multicast IPv4 address + 224.0.0.252, as well as link-scope multicast IPv6 address + FF02:0:0:0:0:0:1:3. + +7. Constants + + The following timing constants are used in this protocol; they are + not intended to be user configurable. + + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (if set statically on all interfaces) + 100 ms (IEEE 802 media, including IEEE 802.11) + +8. References + +8.1. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + + + +Aboba, Thaler & Esibov Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + +8.2. Informative References + +[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft + (work in progress), draft-cheshire-dnsext-multicastdns-05.txt, + June 2005. + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + +[IEEE-802.11i] + Institute of Electrical and Electronics Engineers, "Supplement + to Standard for Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless LAN Medium Access Control (MAC) and Physical Layer + (PHY) Specifications: Specification for Enhanced Security", + IEEE 802.11i, July 2004. + + + +Aboba, Thaler & Esibov Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[LLMNRSec] + Jeong, J., Park, J. and H. Kim, "DNS Name Service based on + Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT + 2004, Phoenix Park, Korea, February 9-11, 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirement", RFC 4033, March + 2005. + + + + +Aboba, Thaler & Esibov Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under + DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge + their contribution to the current specification. Constructive input + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + +Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Levon Esibov + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: levone@microsoft.com + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + +Aboba, Thaler & Esibov Standards Track [Page 28] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +Open Issues + + Open issues with this specification are tracked on the following web + site: + + http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 29] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt new file mode 100644 index 000000000000..cc3c276b99a7 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt @@ -0,0 +1,2072 @@ + + + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: December 3, 2005 Nominet + R. Arends + Telematica Instituut + june 2005 + + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 December 3, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be + used to provide authenticated denial of existence of DNS ownernames + and types; however, it permits any user to traverse a zone and obtain + a listing of all ownernames. + + A complete zone file can be used either directly as a source of + + + +Laurie, et al. Expires December 3, 2005 [Page 1] + +Internet-Draft nsec3 june 2005 + + + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries (particularly in Europe) may be under strict legal + obligations to protect. Many registries therefore prohibit copying + of their zone file; however the use of NSEC RRs renders policies + unenforceable. + + This document proposes a scheme which obscures original ownernames + while permitting authenticated denial of existence of non-existent + names. Non-authoritative delegation point NS RR types may be + excluded. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 + 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 + 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7 + 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 + 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8 + 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9 + 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9 + 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10 + 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10 + 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11 + 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11 + 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 + 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12 + 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13 + 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14 + 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14 + 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14 + 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18 + + + +Laurie, et al. Expires December 3, 2005 [Page 2] + +Internet-Draft nsec3 june 2005 + + + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23 + B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28 + B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30 + B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . . 37 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 3] + +Internet-Draft nsec3 june 2005 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduced the NSEC Resource + Record (RR) for authenticated denial of existence. This document + introduces a new RR as an alternative to NSEC that provides measures + against zone traversal and allows for gradual expansion of + delegation-centric zones. + +1.1 Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + A second problem was the requirement that the existence of all record + types in a zone - including delegation point NS record types - must + be accounted for, despite the fact that delegation point NS RRsets + are not authoritative and not signed. This requirement has a side- + effect that the overhead of delegation-centric signed zones is not + related to the increase in security of subzones. This requirement + does not allow delegation-centric zones size to grow in relation to + the growth of signed subzones. + + In the past, solutions have been proposed as a measure against these + side effects but at the time were regarded as secondary over the need + to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) + a graceful transition path to future enhancements is introduced, + while current DNSSEC deployment can continue. This document presents + the NSEC3 Resource Record which mitigates these issues with the NSEC + RR. + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + +1.2 Reserved Words + + 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]. + +1.3 Terminology + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + + + +Laurie, et al. Expires December 3, 2005 [Page 4] + +Internet-Draft nsec3 june 2005 + + + over the original (unmodified) ownername, this result is referred to + as "hashed ownername". + + "Canonical ordering of the zone" means the order in which hashed + ownernames are arranged according to their numerical value, treating + the leftmost (lowest numbered) byte as the most significant byte. + +2. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record lists RR types present at the NSEC3 RR's + original ownername. It includes the next hashed ownername in the + canonical ordering of the zone. The complete set of NSEC3 RRs in a + zone indicates which RRsets exist for the original ownername of the + RRset and form a chain of hashed ownernames in the zone. This + information is used to provide authenticated denial of existence for + DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation + point NS RRsets can optionally be excluded. To provide protection + against zone traversal, the ownernames used in the NSEC3 RR are + cryptographic hashes of the original ownername prepended to the name + of the zone. The NSEC3 RR indicates which hash function is used to + construct the hash, which salt is used, and how many iterations of + the hash function are performed over the original ownername. + + The ownername for the NSEC3 RR is the base32 encoding of the hashed + ownername. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +2.1 NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 RR is as shown below: + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 5] + +Internet-Draft nsec3 june 2005 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|Hash Function| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Authoritative Only Flag Field + + The Authoritative Only Flag field indicates whether the Type Bit Maps + include delegation point NS record types. + + If the flag is set to 1, the NS RR type bit for a delegation point + ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR + type bit MUST be ignored during processing of the NSEC3 RR. The NS + RR type bit has no meaning in this context (it is not authoritative), + hence the NSEC3 does not contest the existence of a NS RRset for this + ownername. When a delegation is not secured, there exist no DS RR + type nor any other authoritative types for this delegation, hence the + unsecured delegation has no NSEC3 record associated. Please see the + Special Consideration section for implications for unsigned + delegations. + + If the flag is set to 0, the NS RR type bit for a delegation point + ownername MUST be set if the NSEC3 covers a delegation, even though + the NS RR itself is not authoritative. This implies that all + delegations, signed or unsigned, have an NSEC3 record associated. + This behaviour is identical to NSEC behaviour. + +2.1.2 The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + This document defines Value 1 for SHA-1 and Value 127 for + experimental. All other values are reserved. + + On reception, a resolver MUST discard an NSEC3 RR with an unknown + hash function value. + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 6] + +Internet-Draft nsec3 june 2005 + + +2.1.3 The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. + +2.1.4 The Salt Length Field + + The salt length field defines the length of the salt in octets. + +2.1.5 The Salt Field + + The Salt field is not present when the Salt Length Field has a value + of 0. + + The Salt field is prepended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. + + The salt is also prepended during iterations of the hash function. + + Note that although it is theoretically possible to cover the entire + possible ownername space with different salt values, it is + computationally infeasible to do so, and so there MUST be at least + one salt which is the same for all NSEC3 records. This means that no + matter what name is asked for in a query, it is guaranteed to be + possible to find a covering NSEC3 record. Note that this does not + preclude the use of two different salts at the same time - indeed + this may well occur naturally, due to rolling the salt value + periodically. + + The salt value SHOULD be changed from time to time - this is to + prevent the use of a precomputed dictionary to reduce the cost of + enumeration. + +2.1.6 The Next Hashed Ownername Field + + The Next Hashed Ownername field contains the hash of the ownername of + the next RR in the canonical ordering of the hashed ownernames of the + zone. The value of the Next Hashed Ownername Field in the last NSEC3 + record in the zone is the same as the ownername of the first NSEC3 RR + in the zone in canonical order. + + Hashed ownernames of RRsets not authoritative for the given zone + (such as glue records) MUST NOT be listed in the Next Hashed + Ownername unless at least one authoritative RRset exists at the same + ownername. + + + + +Laurie, et al. Expires December 3, 2005 [Page 7] + +Internet-Draft nsec3 june 2005 + + + Note that the Next Hashed Ownername field is not encoded, unlike the + NSEC3 RR's ownername. It is the unmodified binary hash value. + +2.1.7 The list of Type Bit Map(s) Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's ownername. + + The Type bits for the NSEC3 RR and RRSIG RR MUST be set during + generation, and MUST be ignored during processing. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + The RR type 2 (NS) is authoritative at the apex of a zone and is not + authoritative at delegation points. If the Authoritative Only Flag + is set to 1, the delegation point NS RR type MUST NOT be included in + the type bit maps. If the Authoritative Only Flag is set to 0, the + NS RR type at a delegation point MUST be included in the type bit + maps. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 + [RFC2929] (section 3.1) or within the range reserved for assignment + only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not + + + +Laurie, et al. Expires December 3, 2005 [Page 8] + +Internet-Draft nsec3 june 2005 + + + appear in zone data. If encountered, they must be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpreted as zero octets. + +2.2 The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Authoritative Only Field is represented as an unsigned decimal + integer. The value are either 0 or 1. + + The Hash field is presented as the name of the hash or as an unsigned + decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + The Salt Field is represented as 00 when the Salt Length field has + value 0. + + The Next Hashed Ownername field is represented as a sequence of case- + insensitive base32 digits. Whitespace is allowed within the + sequence. + + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [RFC3597] (section 5) MUST be + used. + +3. Creating Additional NSEC3 RRs for Empty Non Terminals + + In order to prove the non-existence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an Empty Non Terminal. + + Additional NSEC3 RRs are synthesized which cover every existing + intermediate label level. Additional NSEC3 RRs are identical in + format to NSEC3 RRs that cover existing RRs in the zone. The + difference is that the type-bit-maps only indicate the existence of + + + +Laurie, et al. Expires December 3, 2005 [Page 9] + +Internet-Draft nsec3 june 2005 + + + an NSEC3 RR type and an RRSIG RR type. + +4. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + +5. Including NSEC3 RRs in a Zone + + Each owner name in the zone which has authoritative data or a secured + delegation point NS RRset MUST have an NSEC3 resource record. + + An unsecured delegation point NS RRset MAY have an NSEC3 resource + record. This is different from NSEC records where an unsecured + delegation point NS RRset MUST have an NSEC record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 RR type itself and its + corresponding RRSIG RR type. + + The bitmap for the NSEC3 RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + The following steps describe the proper construction of NSEC3 + + + +Laurie, et al. Expires December 3, 2005 [Page 10] + +Internet-Draft nsec3 june 2005 + + + records. + 1. For each unique original owner name in the zone, add an NSEC3 + RRset. This includes NSEC3 RRsets for unsigned delegation point + NS RRsets, unless the policy is to have Authoritative Only NSEC3 + RRsets. The ownername of the NSEC3 RR is the hashed equivalent + of the original owner name, prepended to the zone name. + 2. For each RRset at the original owner, set the corresponding bit + in the type bit map. + 3. If the difference in number of labels between the apex and the + original ownername is greater then 1, additional NSEC3s need to + be added for every empty non-terminal between the apex and the + original ownername. + 4. Sort the set of NSEC3 RRs. + 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next + Hashed Ownername of the last NSEC3 in the zone contains the value + of the hashed ownername of the first NSEC3 in the zone. + 6. If the policy is to have authoritative only, set the + Authoritative Only bit in those NSEC3 RRs that cover unsecured + delegation points. + +6. Special Considerations + + The following paragraphs clarify specific behaviour explain special + considerations for implementations. + +6.1 Delegation Points + + This proposal introduces the Authoritative Only Flag which indicates + whether non authoritative delegation point NS records are included in + the type bit Maps. As discussed in paragraph 2.1.1, a flag value of + 0 indicates that the interpretation of the type bit maps is identical + to NSEC records. + + The following subsections describe behaviour when the flag value is + 1. + +6.1.1 Unsigned Delegations + + Delegation point NS records are not authoritative. They are + authoritative in the delegated zone. No other data exists at the + ownername of an unsigned delegation point. + + Since no authoritative data exist at this ownername, it is excluded + from the NSEC3 chain. This is an optimization, since it relieves the + zone of including an NSEC3 record and its associated signature for + this name. + + An NSEC3 that denies existence of ownernames between X and X' with + + + +Laurie, et al. Expires December 3, 2005 [Page 11] + +Internet-Draft nsec3 june 2005 + + + the Authoritative Only Flag set to 1 can not be used to prove the + presence or the absence of delegation point NS records for unsigned + delegations in the interval (X, X'). The Authoritative Only Flag + effectively states No Contest on the presence of delegation point NS + resource records. + + Since proof is absent, there exists a new attack vector. Unsigned + delegation point NS records can be deleted during a man in the middle + attack, effectively denying existence of the delegation. This is a + form of Denial of Service, where the victim has no information it is + under attack, since all signatures are valid and the fabricated + response form is a known type of response. + + The only possible mitigation is to either not use this method, hence + proving existence or absence of unsigned delegations, or to sign all + delegations, regardless of whether the delegated zone is signed or + not. + + A second attack vector exists in that an adversary is able to + successfully fabricate an (unsigned) response claiming a nonexistent + delegation exists. + + The only possible mitigation is to mandate the signing of all + delegations. + +6.2 Proving Nonexistence + + If a wildcard resource record appears in a zone, its asterisk label + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 4035 + [RFC4035] describes the impact of wildcards on authenticated denial + of existence. + + In order to prove there exist no RRs for a domain, as well as no + source of synthesis, an RR must be shown for the closest encloser, + and non-existence must be shown for all closer labels and for the + wildcard at the closest encloser. + + This can be done as follows. If the QNAME in the query is + omega.alfa.beta.example, and the closest encloser is beta.example + (the nearest ancestor to omega.alfa.beta.example), then the server + should return an NSEC3 that demonstrates the nonexistence of + alfa.beta.example, an NSEC3 that demonstrates the nonexistence of + *.beta.example, and an NSEC3 that demonstrates the existence of + beta.example. This takes between one and three NSEC3 records, since + a single record can, by chance, prove more than one of these facts. + + When a verifier checks this response, then the existence of + + + +Laurie, et al. Expires December 3, 2005 [Page 12] + +Internet-Draft nsec3 june 2005 + + + beta.example together with the non-existence of alfa.beta.example + proves that the closest encloser is indeed beta.example. The non- + existence of *.beta.example shows that there is no wildcard at the + closest encloser, and so no source of synthesis for + omega.alfa.beta.example. These two facts are sufficient to satisfy + the resolver that the QNAME cannot be resolved. + + In practice, since the NSEC3 owner and next names are hashed, if the + server responds with an NSEC3 for beta.example, the resolver will + have to try successively longer names, starting with example, moving + to beta.example, alfa.beta.example, and so on, until one of them + hashes to a value that matches the interval (but not the ownername + nor next owner name) of one of the returned NSEC3s (this name will be + alfa.beta.example). Once it has done this, it knows the closest + encloser (i.e. beta.example), and can then easily check the other two + required proofs. + + Note that it is not possible for one of the shorter names tried by + the resolver to be denied by one of the returned NSEC3s, since, by + definition, all these names exist and so cannot appear within the + range covered by an NSEC3. Note, however, that the first name that + the resolver tries MUST be the apex of the zone, since names above + the apex could be denied by one of the returned NSEC3s. + +6.3 Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of the dictionary doubles. The NSEC3 RR can use a + maximum of 2040 bits of salt, multiplying the cost by 2^2040. + + There MUST be a complete set of NSEC3s for the zone using the same + salt value. The salt value for each NSEC3 RR MUST be equal for a + single version of the zone. + + The salt SHOULD be changed every time the zone is resigned to prevent + precomputation using a single salt. + +6.4 Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^(n/2) for a hash of length n + bits (i.e. 2^80 for SHA-1). Though this probability is extremely + low, the following paragraphs deal with avoiding collisions and + assessing possible damage in the event of an attack using hash + collisions. + + + + +Laurie, et al. Expires December 3, 2005 [Page 13] + +Internet-Draft nsec3 june 2005 + + +6.4.1 Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occurring, an alternative salt + SHOULD be chosen and all hash values SHOULD be regenerated. + + If hash values are not regenerated on collision, the NSEC3 RR MUST + list all authoritative RR types that exist for both owners, to avoid + a replay attack, spoofing an existing type as non-existent. + +6.4.2 Second Preimage Requirement Analysis + + A cryptographic hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + preimage X' <> X such that hash(X) = hash(X'). The work factor for + finding a second preimage is of the order of 2^160 for SHA-1. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the non- + existent name, or to fail the initial query. Note that the adversary + can't mount this attack on an existing name but only on a name that + the adversary can't choose and does not yet exist. + +6.4.3 Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage resistance is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. Considering that hash values are + presented in base32, which represents 5 bits per label character, + truncation must be done on a 5 bit boundary. This would be unwise, + since the work factor to produce collisions would then approximate + the size of the zone. + + + + +Laurie, et al. Expires December 3, 2005 [Page 14] + +Internet-Draft nsec3 june 2005 + + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. Of + course, the size of the corresponding RRSIG RR is not reduced, so + truncation is of limited benefit. + + Truncation could be signalled simply by reducing the length of the + first label in the ownername. Note that there would have to be a + corresponding reduction in the length of the Next Hashed Ownername + field. + +7. Performance Considerations + + Iterated hashes will obviously impose a performance penalty on both + authoritative servers and resolvers. Therefore, the number of + iterations should be carefully chosen. In particular it should be + noted that a high value for iterations gives an attacker a very good + denial of service attack, since the attacker need not bother to + verify the results of their queries, and hence has no performance + penalty of his own. + + On the other hand, nameservers with low query rates and limited + bandwidth are already subject to a bandwidth based denial of service + attack, since responses are typically an order of magnitude larger + than queries, and hence these servers may choose a high value of + iterations in order to increase the difficulty of offline attempts to + enumerate their namespace without significantly increasing their + vulnerability to denial of service attacks. + +8. IANA Considerations + + IANA has to create a new registry for NSEC3 Hash Functions. The + range for this registry is 0-127. Value 0 is the identity function. + Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value + 127 is marked as Experimental. + +9. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than traversing the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names, though this would obviously be more detectable. + + + +Laurie, et al. Expires December 3, 2005 [Page 15] + +Internet-Draft nsec3 june 2005 + + + The expense of this off-line attack can be chosen by setting the + number of iterations in the NSEC3 RR. + + High-value domains are also susceptible to a precalculated dictionary + attack - that is, a list of hashes for all likely names is computed + once, then NSEC3 is scanned periodically and compared against the + precomputed hashes. This attack is prevented by changing the salt on + a regular basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the non-existence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + +10. References + +10.1 Normative References + + [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. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + + +Laurie, et al. Expires December 3, 2005 [Page 16] + +Internet-Draft nsec3 june 2005 + + + [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. + +10.2 Informative References + + [I-D.ietf-dnsext-trustupdate-threshold] + Ihren, J., "An In-Band Rollover Mechanism and an Out-Of- + Band Priming Method for DNSSEC Trust Anchors.", + draft-ietf-dnsext-trustupdate-threshold-00 (work in + progress), October 2004. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + Email: ben@algroup.co.uk + + + Geoffrey Sisson + Nominet + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 17] + +Internet-Draft nsec3 june 2005 + + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + The Netherlands + + Phone: +31 (53) 485 0485 + Email: roy.arends@telin.nl + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. + + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 ) + 3600 RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l + NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU + S/o/g5C8VM6ftQ== ) + 3600 DNSKEY 257 3 5 ( + AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX + cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 + zsYKWJ7BvR2894hX + ) ; Key ID = 21960 + 3600 DNSKEY 256 3 5 ( + AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU + 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL + ExXT48OGGdbfIme5 + + + +Laurie, et al. Expires December 3, 2005 [Page 18] + +Internet-Draft nsec3 june 2005 + + + ) ; Key ID = 62699 + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z + xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx + mTkunTYzqWJrmQ== ) + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 21960 example. + SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk + ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik + 3w7ZY2UWyYIvpw== ) + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 7nomf47k3vlidh4vxahhpp47l3tgv7a2 + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 + Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ + sb7KfbaUo/vzAg== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B + 766A6A4837206C ) + 3600 RRSIG DS 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + + + +Laurie, et al. Expires December 3, 2005 [Page 19] + +Internet-Draft nsec3 june 2005 + + + 20050612112304 62699 example. + AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk + tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg + VGNmbgPnqDVPiA== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( + deadbeaf + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 + DS NS NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ + ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW + OwQBGbOegrW/Zw== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( + deadbeaf + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + + + +Laurie, et al. Expires December 3, 2005 [Page 20] + +Internet-Draft nsec3 june 2005 + + + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( + deadbeaf + nimwfwcnbeoodmsc6npv3vuaagaevxxu + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy + 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj + xFPFGRIW3wKnrA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ns1.example. 3600 A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( + deadbeaf + wbyijvpnyj33pcpi3i44ecnibnaj7eiw + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W + kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M + 5SNSHIyfpfsi6A== ) + *.w.example. 3600 MX 1 ai.example. + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + x.w.example. 3600 MX 1 xx.example. + + + +Laurie, et al. Expires December 3, 2005 [Page 21] + +Internet-Draft nsec3 june 2005 + + + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + x.y.w.example. 3600 MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20050712112304 ( + 20050612112304 62699 example. + aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 + uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF + 9VrQvJjwbllAfA== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + xx.example. 3600 A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q + OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk + KMf4DgNBDj+dIQ== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baaa + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + + + + +Laurie, et al. Expires December 3, 2005 [Page 22] + +Internet-Draft nsec3 june 2005 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 answer + + A successful query to an authoritative server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 23] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + + ;; Authority + example. 3600 IN NS ns1.example. + example. 3600 IN NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + xx.example. 3600 IN AAAA 2001:db8::f00:baaa + xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + + + + +Laurie, et al. Expires December 3, 2005 [Page 24] + +Internet-Draft nsec3 june 2005 + + + The query returned an MX RRset for "x.w.example". The corresponding + RRSIG RR indicates that the MX RRset was signed by an "example" + DNSKEY with algorithm 5 and key tag 62699. The resolver needs the + corresponding DNSKEY RR in order to authenticate this answer. The + discussion below describes how a resolver might obtain this DNSKEY + RR. + + The RRSIG RR indicates the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG RR's labels field value of 3 indicates that the + answer was not the result of wildcard expansion. The "x.w.example" + MX RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +B.1.1 Authenticating the Example DNSKEY RRset + + This example shows the logical authentication process that starts + from a configured root DNSKEY RRset (or DS RRset) and moves down the + tree to authenticate the desired "example" DNSKEY RRset. Note that + the logical order is presented for clarity. An implementation may + choose to construct the authentication as referrals are received or + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RRset for the + root zone (or a configured DS RRset for the root zone). The resolver + checks whether this configured DNSKEY RRset is present in the root + DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY + RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the + root DNSKEY RRset, and whether the signature lifetime is valid. If + all these conditions are met, all keys in the DNSKEY RRset are + considered authenticated. The resolver then uses one (or more) of + the root DNSKEY RRs to authenticate the "example" DS RRset. Note + that the resolver may have to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + + + +Laurie, et al. Expires December 3, 2005 [Page 25] + +Internet-Draft nsec3 june 2005 + + + DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +B.2 Name Error + + An authoritative name error. The NSEC3 RRs prove that the name does + not exist and that no covering wildcard exists. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 26] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + a.c.x.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ;; Additional + ;; (empty) + + The query returned two NSEC3 RRs that prove that the requested data + does not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are + authenticated in a manner identical to that of the MX RRset discussed + + + +Laurie, et al. Expires December 3, 2005 [Page 27] + +Internet-Draft nsec3 june 2005 + + + above. At least one of the owner names of the NSEC3 RRs will match + the closest encloser. At least one of the NSEC3 RRs prove that there + exists no longer name. At least one of the NSEC3 RRs prove that + there exists no wildcard RRsets that should have been expanded. The + closest encloser can be found by hasing the apex ownername (The SOA + RR's ownername, or the ownername of the DNSKEY RRset referred by an + RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and + if that fails, continue by adding labels. + + In the above example, the name 'x.w.example' hashes to + '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might + be the closest encloser. To prove that 'c.x.w.example' and + '*.x.w.example' do not exists, these names are hashed to respectively + 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and + 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that + these hashed ownernames do not exists, since the names are within the + given intervals. + +B.3 No Data Error + + A "no data" response. The NSEC3 RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 28] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + ;; Additional + ;; (empty) + + The query returned an NSEC3 RR that proves that the requested name + exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), + but the requested RR type does not exist (type MX is absent in the + type code list of the NSEC RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. + +B.3.1 No Data Error, Empty Non-Terminal + + A "no data" response because of an empty non-terminal. The NSEC3 RR + proves that the name exists and that the requested RR type does not. + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 29] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + y.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + + The query returned an NSEC3 RR that proves that the requested name + exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), + but the requested RR type does not exist (Type A is absent in the + type-bit-maps of the NSEC3 RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. Note that, unlike + generic empty non terminal proof using NSECs, this is identical to + proving a No Data Error. This example is solely mentioned to be + complete. + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + +Laurie, et al. Expires December 3, 2005 [Page 30] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR DO RCODE=0 + ;; + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 IN DS 58470 5 1 ( + 3079F1593EBAD6DC121E202A8B766A6A4837 + 206C ) + a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + The query returned a referral to the signed "a.example." zone. The + DS RR is authenticated in a manner identical to that of the MX RRset + discussed above. This DS RR is used to authenticate the "a.example" + DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +B.5 Referral to Unsigned Zone using Opt-In + + Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that + nothing for this delegation was signed in the parent zone. There is + no proof that the delegation exists + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 31] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + The query returned a referral to the unsigned "b.example." zone. The + NSEC3 proves that no authentication leads from "example" to + "b.example", since the hash of "b.example" + ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and + the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +B.6 Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC3 RR proves that + no closer match exists in the zone. + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 32] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + + The query returned an answer that was produced as a result of + wildcard expansion. The answer section contains a wildcard RRset + expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + + + +Laurie, et al. Expires December 3, 2005 [Page 33] + +Internet-Draft nsec3 june 2005 + + + signed by an "example" DNSKEY with algorithm 5 and key tag 62699. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC3 proves that no closer match (exact or closer wildcard) + could have been used to answer this query, and the NSEC3 RR must also + be authenticated before the answer is considered valid. + +B.7 Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC3 RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 34] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ;; (empty) + + The query returned NSEC3 RRs that prove that the requested data does + not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. + +B.8 DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 35] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + + ;; Additional + ;; (empty) + + The query returned NSEC RRs that shows the requested was answered by + a child server ("example" server). The NSEC RR indicates the + presence of an SOA RR, showing that the answer is from the child . + Queries for the "example" DS RRset should be sent to the parent + servers ("root" servers). + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 36] + +Internet-Draft nsec3 june 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Laurie, et al. Expires December 3, 2005 [Page 37] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt new file mode 100644 index 000000000000..5b6d655297e8 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT DSA Information in the DNS +OBSOLETES: RFC 2536 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: January 2006 July 2005 + + + DSA Keying and Signature Information in the DNS + --- ------ --- --------- ----------- -- --- --- + <draft-ietf-dnsext-rfc2536bis-dsa-06.txt> + Donald E. Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + <namedroppers@ops.ietf.org>. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method of encoding US Government Digital Signature + Algorithm keying and signature information for use in the Domain Name + System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society 2005. All Rights Reserved. + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DSA Information in the DNS + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DSA Keying Information..................................3 + 3. DSA Signature Information...............................4 + 4. Performance Considerations..............................4 + 5. Security Considerations.................................5 + 6. IANA Considerations.....................................5 + Copyright and Disclaimer...................................5 + + Normative References.......................................7 + Informative References.....................................7 + + Authors Address............................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DSA Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additional work is underway which would + require the storage of keying and signature information in the DNS. + + This document describes how to encode US Government Digital Signature + Algorithm (DSA) keys and signatures in the DNS. Familiarity with the + US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. + + + +2. DSA Keying Information + + When DSA public keys are stored in the DNS, the structure of the + relevant part of the RDATA part of the RR being used is the fields + listed below in the order given. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + Field Size + ----- ---- + T 1 octet + Q 20 octets + P 64 + T*8 octets + G 64 + T*8 octets + Y 64 + T*8 octets + + As described in [FIPS 186-2] and [Schneier], T is a key size + parameter chosen such that 0 <= T <= 8. (The meaning if the T octet + is greater than 8 is reserved and the remainder of the data may have + a different format in that case.) Q is a prime number selected at + key generation time such that 2**159 < Q < 2**160. Thus Q is always + 20 octets long and, as with all other fields, is stored in "big- + endian" network order. P, G, and Y are calculated as directed by the + [FIPS 186-2] key generation algorithm [Schneier]. P is in the range + 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G + and Y are quantities modulo P and so can be up to the same length as + P and are allocated fixed size fields with the same number of octets + as P. + + During the key generation process, a random number X must be + generated such that 1 <= X <= Q-1. X is the private key and is used + in the final step of public key generation where Y is computed as + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DSA Information in the DNS + + + Y = G**X mod P + + + +3. DSA Signature Information + + The portion of the RDATA area used for US Digital Signature Algorithm + signature information is shown below with fields in the order they + are listed and the contents of each multi-octet field in "big-endian" + network order. + + Field Size + ----- ---- + T 1 octet + R 20 octets + S 20 octets + + First, the data signed must be determined. Then the following steps + are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as + specified in the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate a random K such that 0 < K < Q. + + R = ( G**K mod P ) mod Q + + S = ( K**(-1) * (hash + X*R) ) mod Q + + For information on the SHA-1 hash function see [FIPS 180-2] and [RFC + 3174]. + + Since Q is 160 bits long, R and S can not be larger than 20 octets, + which is the space allocated. + + T is copied from the public key. It is not logically necessary in + the SIG but is present so that values of T > 8 can more conveniently + be used as an escape for extended versions of DSA or other algorithms + as later standardized. + + + +4. Performance Considerations + + General signature generation speeds are roughly the same for RSA [RFC + 3110] and DSA. With sufficient pre-computation, signature generation + with DSA is faster than RSA. Key generation is also faster for DSA. + However, signature verification is an order of magnitude slower than + RSA when the RSA public exponent is chosen to be small, as is + recommended for some applications. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DSA Information in the DNS + + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient, it + is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying and/or signature + inforamtion consistent with adequate security. + + + +5. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + The key size limitation of a maximum of 1024 bits ( T = 8 ) in the + current DSA standard may limit the security of DSA. For particular + applications, implementors are encouraged to consider the range of + available algorithms and key sizes. + + DSA assumes the ability to frequently generate high quality random + numbers. See [random] for guidance. DSA is designed so that if + biased rather than random numbers are used, high bandwidth covert + channels are possible. See [Schneier] and more recent research. The + leakage of an entire DSA private key in only two DSA signatures has + been demonstrated. DSA provides security only if trusted + implementations, including trusted random number generation, are + used. + + + +6. IANA Considerations + + Allocation of meaning to values of the T parameter that are not + defined herein (i.e., > 8 ) requires an IETF standards actions. It + is intended that values unallocated herein be used to cover future + extensions of the DSS standard. + + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DSA Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DSA Information in the DNS + + +Normative References + + [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital + Signature Standard, 27 January 2000. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS)", D. Eastlake 3rd. May 2001. + + [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. + Jones, September 2001. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. + + [Schneier] - "Applied Cryptography Second Edition: protocols, + algorithms, and source code in C" (second edition), Bruce Schneier, + 1996, John Wiley and Sons, ISBN 0-471-11709-9. + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DSA Information in the DNS + + +Authors Address + + Donald E. Eastlake 3rd + Motorola Labortories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554(w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in January 2006. + + Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt new file mode 100644 index 000000000000..2ec9dbec512e --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt @@ -0,0 +1,840 @@ + + + +Network Working Group S. Josefsson +Internet-Draft August 30, 2005 +Expires: March 3, 2006 + + + Storing Certificates in the Domain Name System (DNS) + draft-ietf-dnsext-rfc2538bis-04 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 March 3, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Cryptographic public keys are frequently published and their + authenticity demonstrated by certificates. A CERT resource record + (RR) is defined so that such certificates and related certificate + revocation lists can be stored in the Domain Name System (DNS). + + This document obsoletes RFC 2538. + + + + + + +Josefsson Expires March 3, 2006 [Page 1] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 + 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 + 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5 + 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 + 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 + 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 + 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 + 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 + 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 + Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires March 3, 2006 [Page 2] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +1. Introduction + + Public keys are frequently published in the form of a certificate and + their authenticity is commonly demonstrated by certificates and + related certificate revocation lists (CRLs). A certificate is a + binding, through a cryptographic digital signature, of a public key, + a validity interval and/or conditions, and identity, authorization, + or other information. A certificate revocation list is a list of + certificates that are revoked, and incidental information, all signed + by the signer (issuer) of the revoked certificates. Examples are + X.509 certificates/CRLs in the X.500 directory system or OpenPGP + certificates/revocations used by OpenPGP software. + + Section 2 below specifies a CERT resource record (RR) for the storage + of certificates in the Domain Name System [1] [2]. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 5, and 6 below cover performance, IANA, and security + considerations, respectively. + + 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 [3]. + + +2. The CERT Resource Record + + The CERT resource record (RR) has the structure given below. Its RR + type code is 37. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type | key tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | / + +---------------+ certificate or CRL / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The type field is the certificate type as defined in section 2.1 + below. + + The key tag field is the 16 bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag algorithm described in + Appendix B of [10]. This field is used as an efficiency measure to + pick which CERT RRs may be applicable to a particular key. The key + + + +Josefsson Expires March 3, 2006 [Page 3] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + tag can be calculated for the key in question and then only CERT RRs + with the same key tag need be examined. However, the key must always + be transformed to the format it would have as the public key portion + of a DNSKEY RR before the key tag is computed. This is only possible + if the key is applicable to an algorithm (and limits such as key size + limits) defined for DNS security. If it is not, the algorithm field + MUST BE zero and the tag field is meaningless and SHOULD BE zero. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [10], except that a zero algorithm field + indicates the algorithm is unknown to a secure DNS, which may simply + be the result of the algorithm not having been standardized for + DNSSEC. + +2.1. Certificate Type Values + + The following values are defined or reserved: + + Value Mnemonic Certificate Type + ----- -------- ---------------- + 0 reserved + 1 PKIX X.509 as per PKIX + 2 SPKI SPKI certificate + 3 PGP OpenPGP packet + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The URL of an OpenPGP packet + 7-252 available for IANA assignment + 253 URI URI private + 254 OID OID private + 255-65534 available for IANA assignment + 65535 reserved + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile being defined by the IETF PKIX working group. The + certificate section will start with a one-byte unsigned OID length + and then an X.500 OID indicating the nature of the remainder of the + certificate section (see 2.3 below). (NOTE: X.509 certificates do + not include their X.500 directory type designating OID as a prefix.) + + The SPKI type is reserved to indicate the SPKI certificate format + [13], for use when the SPKI documents are moved from experimental + status. + + The PGP type indicates an OpenPGP packet as described in [6] and its + extensions and successors. Two uses are to transfer public key + material and revocation signatures. The data is binary, and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + + + +Josefsson Expires March 3, 2006 [Page 4] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + transferable public keys as described in section 10.1 of [6], but it + MAY handle additional OpenPGP packets. + + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the + content that would have been in the "certificate, CRL or URL" field + of the corresponding (PKIX, SPKI or PGP) packet types. These types + are known as "indirect". These packet types MUST be used when the + content is too large to fit in the CERT RR, and MAY be used at the + implementer's discretion. They SHOULD NOT be used where the entire + UDP packet would have fit in 512 bytes. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [5] and the data after the null is the private + format certificate itself. The URI SHOULD be such that a retrieval + from it will lead to documentation on the format of the certificate. + Recognition of private certificate types need not be based on URI + equality but can use various forms of pattern matching so that, for + example, subtype or version information can also be encoded into the + URI. + + The OID private type indicates a private format certificate specified + by an ISO OID prefix. The certificate section will start with a one- + byte unsigned OID length and then a BER encoded OID indicating the + nature of the remainder of the certificate section. This can be an + X.509 certificate format or some other format. X.509 certificates + that conform to the IETF PKIX profile SHOULD be indicated by the PKIX + type, not the OID private type. Recognition of private certificate + types need not be based on OID equality but can use various forms of + pattern matching such as OID prefix. + +2.2. Text Representation of CERT RRs + + The RDATA portion of a CERT RR has the type field as an unsigned + decimal integer or as a mnemonic symbol as listed in section 2.1 + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [10]. + + The certificate / CRL portion is represented in base 64 [14] and may + be divided up into any number of white space separated substrings, + down to single base 64 digits, which are concatenated to obtain the + full signature. These substrings can span lines using the standard + parenthesis. + + + + +Josefsson Expires March 3, 2006 [Page 5] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + Note that the certificate / CRL portion may have internal sub-fields, + but these do not appear in the master file representation. For + example, with type 254, there will be an OID size, an OID, and then + the certificate / CRL proper. But only a single logical base 64 + string will appear in the text representation. + +2.3. X.509 OIDs + + OIDs have been defined in connection with the X.500 directory for + user certificates, certification authority certificates, revocations + of certification authority, and revocations of user certificates. + The following table lists the OIDs, their BER encoding, and their + length-prefixed hex format for use in CERT RRs: + + id-at-userCertificate + = { joint-iso-ccitt(2) ds(5) at(4) 36 } + == 0x 03 55 04 24 + id-at-cACertificate + = { joint-iso-ccitt(2) ds(5) at(4) 37 } + == 0x 03 55 04 25 + id-at-authorityRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 38 } + == 0x 03 55 04 26 + id-at-certificateRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 39 } + == 0x 03 55 04 27 + + +3. Appropriate Owner Names for CERT RRs + + It is recommended that certificate CERT RRs be stored under a domain + name related to their subject, i.e., the name of the entity intended + to control the private key corresponding to the public key being + certified. It is recommended that certificate revocation list CERT + RRs be stored under a domain name related to their issuer. + + Following some of the guidelines below may result in the use in DNS + names of characters that require DNS quoting which is to use a + backslash followed by the octal representation of the ASCII code for + the character (e.g., \000 for NULL). + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the clients + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the e-mail address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + + +Josefsson Expires March 3, 2006 [Page 6] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + Therefore, two owner name guidelines are defined: content-based owner + names and purpose-based owner names. A content-based owner name is + derived from the content of the CERT RR data; for example, the + Subject field in an X.509 certificate or the User ID field in OpenPGP + keys. A purpose-based owner name is a name that a client retrieving + CERT RRs MUST already know; for example, the host name of an X.509 + protected service or the Key ID of an OpenPGP key. The content-based + and purpose-based owner name MAY be the same; for example, when a + client looks up a key based on the From: address of an incoming + e-mail. + + Implementations SHOULD use the purpose-based owner name guidelines + described in this document, and MAY use CNAMEs of content-based owner + names (or other names), pointing to the purpose-based owner name. + +3.1. Content-based X.509 CERT RR Names + + Some X.509 versions permit multiple names to be associated with + subjects and issuers under "Subject Alternate Name" and "Issuer + Alternate Name". For example, X.509v3 has such Alternate Names with + an ASN.1 specification as follows: + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] EXPLICIT OR-ADDRESS.&Type, + directoryName [4] EXPLICIT Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER + } + + The recommended locations of CERT storage are as follows, in priority + order: + 1. If a domain name is included in the identification in the + certificate or CRL, that should be used. + 2. If a domain name is not included but an IP address is included, + then the translation of that IP address into the appropriate + inverse domain name should be used. + 3. If neither of the above is used, but a URI containing a domain + name is present, that domain name should be used. + 4. If none of the above is included but a character string name is + included, then it should be treated as described for OpenPGP + names below. + + + + + +Josefsson Expires March 3, 2006 [Page 7] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + 5. If none of the above apply, then the distinguished name (DN) + should be mapped into a domain name as specified in [4]. + + Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ + DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) + string "John (the Man) Doe", (b) domain name john-doe.com, and (c) + uri <https://www.secure.john-doe.com:8080/>. The storage locations + recommended, in priority order, would be + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + Example 2: An X.509v3 certificate is issued to /CN=James Hacker/ + L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) + domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and + (c) string "James Hacker <hacker@mail.widget.foo.example>". The + storage locations recommended, in priority order, would be + 1. widget.foo.example, + 2. 201.13.251.10.in-addr.arpa, and + 3. hacker.mail.widget.foo.example. + +3.2. Purpose-based X.509 CERT RR Names + + Due to the difficulty for clients that do not already possess a + certificate to reconstruct the content-based owner name, purpose- + based owner names are recommended in this section. Recommendations + for purpose-based owner names vary per scenario. The following table + summarizes the purpose-based X.509 CERT RR owner name guidelines for + use with S/MIME [16], SSL/TLS [11], and IPSEC [12]: + + Scenario Owner name + ------------------ ---------------------------------------------- + S/MIME Certificate Standard translation of an RFC 2822 email + address. Example: An S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + "postmaster.example.org". + + TLS Certificate Hostname of the TLS server. + + IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4 + or IPv6 addresses, the fully qualified domain + name in the appropriate reverse domain. + + An alternate approach for IPSEC is to store raw public keys [15]. + + + + + + +Josefsson Expires March 3, 2006 [Page 8] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +3.3. Content-based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + User ID [6]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [8] email address of the party, as in "Leslie + Example <Leslie@host.example>". If such a format is used, the CERT + should be under the standard translation of the email address into a + domain name, which would be leslie.host.example in this case. If no + RFC 2822 name can be extracted from the string name, no specific + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. Example: + + $ORIGIN example.org. + smith IN CERT PGP 0 0 <OpenPGP binary> + john.smith IN CNAME smith + js IN CNAME smith + +3.4. Purpose-based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxilliary data that may be available. In this case, use of an owner + name identical to the key fingerprint and the key ID expressed in + hexadecimal [14] is recommended. Example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored for several owner names, the use + of CNAME may be used to avoid data duplication. Note that CNAME is + not always applicable, because it maps one owner name to the other + for all purposes, which may be sub-optimal when two keys with the + same Key ID are stored. + +3.5. Owner names for IPKIX, ISPKI, and IPGP + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI and PGP types. + + + + + +Josefsson Expires March 3, 2006 [Page 9] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +4. Performance Considerations + + Current Domain Name System (DNS) implementations are optimized for + small transfers, typically not more than 512 bytes including + overhead. While larger transfers will perform correctly and work is + underway to make larger transfers more efficient, it is still + advisable at this time to make every reasonable effort to minimize + the size of certificates stored within the DNS. Steps that can be + taken may include using the fewest possible optional or extension + fields and using short field values for necessary variable length + fields. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR MUST NOT contain + more than 64kb of payload, even if the corresponding certificate or + certificate revocation list is larger. This document addresses this + by defining "indirect" data types for each normal type. + + +5. Contributors + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + + +6. Acknowledgements + + Thanks to David Shaw and Michael Graff for their contributions to + earlier works that motivated, and served as inspiration for, this + document. + + This document was improved by suggestions and comments from Olivier + Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason + Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is + incomplete. We apologize to anyone we left out. + + +7. Security Considerations + + By definition, certificates contain their own authenticating + signature. Thus, it is reasonable to store certificates in non- + secure DNS zones or to retrieve certificates from DNS with DNS + security checking not implemented or deferred for efficiency. The + results MAY be trusted if the certificate chain is verified back to a + known trusted key and this conforms with the user's security policy. + + Alternatively, if certificates are retrieved from a secure DNS zone + with DNS security checking enabled and are verified by DNS security, + + + +Josefsson Expires March 3, 2006 [Page 10] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + the key within the retrieved certificate MAY be trusted without + verifying the certificate chain if this conforms with the user's + security policy. + + If an organization chooses to issue certificates for it's employees, + placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) + is in use, it is possible for someone to enumerate all employees of + the organization. This is usually not considered desirable, for the + same reason enterprise phone listings are not often publicly + published and are even mark confidential. + + When the URI type is used, it should be understood that it introduces + an additional indirection that may allow for a new attack vector. + One method to secure that indirection is to include a hash of the + certificate in the URI itself. + + CERT RRs are not used by DNSSEC [9], so there are no security + considerations related to CERT RRs and securing the DNS itself. + + If DNSSEC is used, then the non-existence of a CERT RR and, + consequently, certificates or revocation lists can be securely + asserted. Without DNSSEC, this is not possible. + + +8. IANA Considerations + + Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can + only be assigned by an IETF standards action [7]. This document + assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate + types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] + based on RFC documentation of the certificate type. The availability + of private types under 0x00FD and 0x00FE should satisfy most + requirements for proprietary or private types. + + The CERT RR reuses the DNS Security Algorithm Numbers registry. In + particular, the CERT RR requires that algorithm number 0 remain + reserved, as described in Section 2. The IANA is directed to + reference the CERT RR as a user of this registry and value 0, in + particular. + + +9. Changes since RFC 2538 + + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and + updating the references to point at latest versions, and to add + some additional references. + + + + +Josefsson Expires March 3, 2006 [Page 11] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add section 3.2 + for purpose-based X.509 CERT owner names, and section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + 9. The SPKI types has been reserved, until RFC 2692/2693 is moved + from the experimental status. + 10. Added indirect types IPKIX, ISPKI, and IPGP. + + +Appendix A. Copying conditions + + Regarding the portion of this document that was written by Simon + Josefsson ("the author", for the remainder of this section), the + author makes no guarantees and is not responsible for any damage + resulting from its use. The author grants irrevocable permission to + anyone to use, modify, and distribute it in any way that does not + diminish the rights of anyone else to use, modify, and distribute it, + provided that redistributed derivative works do not contain + misleading author or version information. Derivative works need not + be licensed under similar terms. + + +10. References + +10.1. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, + + + +Josefsson Expires March 3, 2006 [Page 12] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + +10.2. Informative References + + [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [12] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., + and T. Ylonen, "SPKI Certificate Theory", RFC 2693, + September 1999. + + [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + [15] Richardson, M., "A Method for Storing IPsec Keying Material in + DNS", RFC 4025, March 2005. + + [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, + July 2004. + + + + + + +Josefsson Expires March 3, 2006 [Page 13] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +Author's Address + + Simon Josefsson + + Email: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires March 3, 2006 [Page 14] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Josefsson Expires March 3, 2006 [Page 15] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt new file mode 100644 index 000000000000..5e6cb1d09e2a --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt @@ -0,0 +1,580 @@ + +INTERNET-DRAFT Diffie-Hellman Information in the DNS +OBSOLETES: RFC 2539 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: January 2006 July 2005 + + + + + Storage of Diffie-Hellman Keying Information in the DNS + ------- -- -------------- ------ ----------- -- --- --- + <draft-ietf-dnsext-rfc2539bis-dhk-06.txt> + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + <namedroppers@ops.ietf.org>. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for encoding Diffie-Hellman keys in the Domain + Name System is specified. + + + +Copyright + + Copyright (C) The Internet Society 2005. + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Acknowledgements + + Part of the format for Diffie-Hellman keys and the description + thereof was taken from a work in progress by Ashar Aziz, Tom Markson, + and Hemma Prafullchandra. In addition, the following persons + provided useful comments that were incorporated into the predecessor + of this document: Ran Atkinson, Thomas Narten. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright..................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 1.1 About This Document....................................3 + 1.2 About Diffie-Hellman...................................3 + 2. Encoding Diffie-Hellman Keying Information..............4 + 3. Performance Considerations..............................5 + 4. IANA Considerations.....................................5 + 5. Security Considerations.................................5 + Copyright and Disclaimer...................................5 + + Normative References.......................................7 + Informative Refences.......................................7 + + Author Address.............................................8 + Expiration and File Name...................................8 + + Appendix A: Well known prime/generator pairs...............9 + A.1. Well-Known Group 1: A 768 bit prime..................9 + A.2. Well-Known Group 2: A 1024 bit prime.................9 + A.3. Well-Known Group 3: A 1536 bit prime................10 + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + similar information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additonal work is underway which would use + the storage of keying information in the DNS. + + + +1.1 About This Document + + This document describes how to store Diffie-Hellman keys in the DNS. + Familiarity with the Diffie-Hellman key exchange algorithm is assumed + [Schneier, RFC 2631]. + + + +1.2 About Diffie-Hellman + + Diffie-Hellman requires two parties to interact to derive keying + information which can then be used for authentication. Thus Diffie- + Hellman is inherently a key agreement algorithm. As a result, no + format is defined for Diffie-Hellman "signature information". For + example, assume that two parties have local secrets "i" and "j". + Assume they each respectively calculate X and Y as follows: + + X = g**i ( mod p ) + + Y = g**j ( mod p ) + + They exchange these quantities and then each calculates a Z as + follows: + + Zi = Y**i ( mod p ) + + Zj = X**j ( mod p ) + + Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared + secret between the two parties that an adversary who does not know i + or j will not be able to learn from the exchanged messages (unless + the adversary can derive i or j by performing a discrete logarithm + mod p which is hard for strong p and g). + + The private key for each party is their secret i (or j). The public + key is the pair p and g, which must be the same for the parties, and + their individual X (or Y). + + For further information about Diffie-Hellman and precautions to take + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + in deciding on a p and g, see [RFC 2631]. + + + +2. Encoding Diffie-Hellman Keying Information + + When Diffie-Hellman keys appear within the RDATA portion of a RR, + they are encoded as shown below. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | prime length (or flag) | prime (p) (or special) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / prime (p) (variable length) | generator length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | generator (g) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | public value length | public value (variable length)/ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / public value (g^i mod p) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Prime length is the length of the Diffie-Hellman prime (p) in bytes + if it is 16 or greater. Prime contains the binary representation of + the Diffie-Hellman prime with most significant byte first (i.e., in + network order). If "prime length" field is 1 or 2, then the "prime" + field is actually an unsigned index into a table of 65,536 + prime/generator pairs and the generator length SHOULD be zero. See + Appedix A for defined table entries and Section 4 for information on + allocating additional table entries. The meaning of a zero or 3 + through 15 value for "prime length" is reserved. + + Generator length is the length of the generator (g) in bytes. + Generator is the binary representation of generator with most + significant byte first. PublicValueLen is the Length of the Public + Value (g**i (mod p)) in bytes. PublicValue is the binary + representation of the DH public value with most significant byte + first. + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +3. Performance Considerations + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient. But + it is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying information consistent + with adequate security. + + + +4. IANA Considerations + + Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires + an IETF consensus as defined in [RFC 2434]. + + Well known prime/generator pairs number 0x0000 through 0x07FF can + only be assigned by an IETF standards action. [RFC 2539], the + Proposed Standard predecessor of this document, assigned 0x0001 + through 0x0002. This document additionally assigns 0x0003. Pairs + number 0s0800 through 0xBFFF can be assigned based on RFC + documentation. Pairs number 0xC000 through 0xFFFF are available for + private use and are not centrally coordinated. Use of such private + pairs outside of a closed environment may result in conflicts and/or + security failures. + + + +5. Security Considerations + + Keying information retrieved from the DNS should not be trusted + unless (1) it has been securely obtained from a secure resolver or + independently verified by the user and (2) this secure resolver and + secure obtainment or independent verification conform to security + policies acceptable to the user. As with all cryptographic + algorithms, evaluating the necessary strength of the key is important + and dependent on security policy. + + In addition, the usual Diffie-Hellman key strength considerations + apply. (p-1)/2 should also be prime, g should be primitive mod p, p + should be "large", etc. See [RFC 2631, Schneier]. + + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Normative References + + [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June + 1999. + + [RFC 2434] - "Guidelines for Writing an IANA Considerations Section + in RFCs", T. Narten, H. Alvestrand, October 1998. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative Refences + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, November 1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, November 1987. + + [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley + and Sons. + + + + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Author Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in January 2006. + + Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Appendix A: Well known prime/generator pairs + + These numbers are copied from the IPSEC effort where the derivation of + these values is more fully explained and additional information is + available. + Richard Schroeppel performed all the mathematical and computational + work for this appendix. + + + +A.1. Well-Known Group 1: A 768 bit prime + + The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its + decimal value is + 155251809230070893513091813125848175563133404943451431320235 + 119490296623994910210725866945387659164244291000768028886422 + 915080371891804634263272761303128298374438082089019628850917 + 0691316593175367469551763119843371637221007210577919 + + Prime modulus: Length (32 bit words): 24, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + +A.2. Well-Known Group 2: A 1024 bit prime + + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + Its decimal value is + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007 + + Prime modulus: Length (32 bit words): 32, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +A.3. Well-Known Group 3: A 1536 bit prime + + The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + Its decimal value is + 241031242692103258855207602219756607485695054850245994265411 + 694195810883168261222889009385826134161467322714147790401219 + 650364895705058263194273070680500922306273474534107340669624 + 601458936165977404102716924945320037872943417032584377865919 + 814376319377685986952408894019557734611984354530154704374720 + 774996976375008430892633929555996888245787241299381012913029 + 459299994792636526405928464720973038494721168143446471443848 + 8520940127459844288859336526896320919633919 + + Prime modulus Length (32 bit words): 48, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D + C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F + 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D + 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt new file mode 100644 index 000000000000..0af13c616f99 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt @@ -0,0 +1,755 @@ + + +Network Working Group B. Laurie +Internet-Draft Nominet +Expires: March 2, 2005 R. Loomis + SAIC + September 2004 + + + + Requirements related to DNSSEC Signed Proof of Non-Existence + draft-ietf-dnsext-signed-nonexistence-requirements-01 + + +Status of this Memo + + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + + 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 March 2, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). + + +Abstract + + + DNSSEC-bis uses the NSEC record to provide authenticated denial of + existence of RRsets. NSEC also has the side-effect of permitting + zone enumeration, even if zone transfers have been forbidden. + Because some see this as a problem, this document has been assembled + to detail the possible requirements for denial of existence A/K/A + signed proof of non-existence. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 1] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 + 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 + 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 + 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 + 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 + 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 + 12. Non-overlap of denial records with possible zone records . . 7 + 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 + 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 + 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 + 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 + 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 + 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 + 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 + 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 + 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 + 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 + 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 + 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 + 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 + 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 + 29. Security Considerations . . . . . . . . . . . . . . . . . . 10 + 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 + 30.2 Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . 11 + + + + + + + + + + + + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 2] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +1. Introduction + + + NSEC records allow trivial enumeration of zones - a situation that + has existed for several years but which has recently been raised as a + significant concern for DNSSECbis deployment in several zones. + Alternate proposals have been made that make zone enumeration more + difficult, and some previous proposals to modify DNSSEC had related + requirements/desirements that are relevant to the discussion. In + addition the original designs for NSEC/NXT records were based on + working group discussions and the choices made were not always + documented with context and requirements-- so some of those choices + may need to be restated as requirements. Overall, the working group + needs to better understand the requirements for denial of existence + (and certain other requirements related to DNSSECbis deployment) in + order to evaluate the proposals that may replace NSEC. + + + In the remainder of this document, "NSEC++" is used as shorthand for + "a denial of existence proof that will replace NSEC". "NSECbis" has + also been used as shorthand for this, but we avoid that usage since + NSECbis will not be part of DNSSECbis and therefore there might be + some confusion. + + +2. Non-purposes + + + This document does not currently document the reasons why zone + enumeration might be "bad" from a privacy, security, business, or + other perspective--except insofar as those reasons result in + requirements. Once the list of requirements is complete and vaguely + coherent, the trade-offs (reducing zone enumeration will have X cost, + while providing Y benefit) may be revisited. The editors of this + compendium received inputs on the potential reasons why zone + enumeration is bad (and there was significant discussion on the + DNSEXT WG mailing list) but that information fell outside the scope + of this document. + + + Note also that this document does not assume that NSEC *must* be + replaced with NSEC++, if the requirements can be met through other + methods (e.g., "white lies" with the current NSEC). As is stated + above, this document is focused on requirements collection and + (ideally) prioritization rather than on the actual implementation. + + +3. Zone Enumeration + + + Authenticated denial should not permit trivial zone enumeration. + + + Additional discussion: NSEC (and NXT before it) provide a linked + list that could be "walked" to trivially enumerate all the signed + records in a zone. This requirement is primarily (though not + + + + +Laurie & Loomis Expires March 2, 2005 [Page 3] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + exclusively) important for zones that either are delegation-only/ + -mostly or do not have reverse lookup (PTR) records configured, since + enterprises that have PTR records for all A records have already + provided a similar capability to enumerate the contents of DNS zones. + + + Contributor: various + + +4. Zone Enumeration II + + + Zone enumeration should be at least as difficult as it would be to + effect a dictionary attack using simple DNS queries to do the same in + an unsecured zone. + + + (Editor comment: it is not clear how to measure difficulty in this + case. Some examples could be monetary cost, bandwidth, processing + power or some combination of these. It has also been suggested that + the requirement is that the graph of difficulty of enumeration vs. + the fraction of the zone enumerated should be approximately the same + shape in the two cases) + + + Contributor: Nominet + + +5. Zone Enumeration III + + + Enumeration of a zone with random contents should computationally + infeasible. + + + Editor comment: this is proposed as a way of evaluating the + effectiveness of a proposal rather than as a requirement anyone would + actually have in practice. + + + Contributor: Alex Bligh + + +6. Exposure of Contents + + + NSEC++ should not expose any of the contents of the zone (apart from + the NSEC++ records themselves, of course). + + + Editor comment: this is a weaker requirement than prevention of + enumeration, but certainly any zone that satisfied this requirement + would also satisfy the trivial prevention of enumeration requirement. + + + Contributor: Ed Lewis + + +7. Zone Size + + + Requirement: NSEC++ should make it possible to take precautions + against trivial zone size estimates. Since not all zone owners care + + + + +Laurie & Loomis Expires March 2, 2005 [Page 4] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + about others estimation of the size of a zone, it is not always + necessary to prohibit trivial estimation of the size of the zone but + NSEC++ should allow such measures. + + + Additional Discussion: Even with proposals based on obfuscating names + with hashes it is trivial to give very good estimates of the number + of domains in a certain zone. Just send 10 random queries and look + at the range between the two hash values returned in each NSEC++. As + hash output can be assumed to follow a rectangular random + distribution, using the mean difference between the two values, you + can estimate the total number of records. It is probably sufficient + to look at even one NSEC++, since the two hash values should follow a + (I believe) Poisson distribution. + + + The concern is motivated by some wording remembered from NSEC, which + stated that NSEC MUST only be present for existing owner names in the + zone, and MUST NOT be present for non-existing owner names. If + similar wording were carried over to NSEC++, introducing bogus owner + names in the hash chain (an otherwise simple solution to guard + against trivial estimates of zone size) wouldn't be allowed. + + + One simple attempt at solving this is to describe in the + specifications how zone signer tools can add a number of random + "junk" records. + + + Editor's comment: it is interesting that obfuscating names might + actually make it easier to estimate zone size. + + + Contributor: Simon Josefsson. + + +8. Single Method + + + Requirement: A single NSEC++ method must be able to carry both + old-style denial (i.e. plain labels) and whatever the new style + looks like. Having two separate denial methods could result in + cornercases where one method can deny the other and vice versa. + + + Additional discussion: This requirement can help -bis folks to a + smooth upgrade to -ter. First they'd change the method while the + content is the same, then they can change content of the method. + + + Contributor: Roy Arends. + + +9. Empty Non-terminals + + + Requirement: Empty-non-terminals (ENT) should remain empty. In + other words, adding NSEC++ records to an existing DNS structure + should not cause the creation of NSEC++ records (or related records) + + + + +Laurie & Loomis Expires March 2, 2005 [Page 5] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + at points that are otherwise ENT. + + + Additional discussion: Currently NSEC complies with ENT requirement: + b.example.com NSEC a.c.example.com implies the existence of an ENT + with ownername c.example.com. NSEC2 breaks that requirement, since + the ownername is entirely hashed causing the structure to disappear. + This is why EXIST was introduced. But EXIST causes ENT to be + non-empty-terminals. Next to the dissappearance of ENT, it causes + (some) overhead since an EXIST record needs a SIG, NSEC2 and + SIG(NSEC2). DNSNR honours this requirement by hashing individual + labels instead of ownernames. However this causes very long labels. + Truncation is a measure against very long ownernames, but that is + controversial. There is a fair discussion of the validity of + truncation in the DNSNR draft, but that hasn't got proper review yet. + + + Contributor: Roy Arends. + + + (Editor comment: it is not clear to us that an EXIST record needs an + NSEC2 record, since it is a special purpose record only used for + denial of existence) + + +10. Prevention of Precomputed Dictionary Attacks + + + Requirement: NSEC++ needs to provide a method to reduce the + effectiveness of precomputed dictionary attacks. + + + Additional Discussion: Salt is a measure against dictionary attacks. + There are other possible measures (such as iterating hashes in + NSEC2). The salt needs to be communicated in every response, since + it is needed in every verification. Some have suggested to move the + salt to a special record instead of the denial record. I think this + is not wise. Response size has more priority over zone size. An + extra record causes a larger response than a larger existing record. + + + Contributor: Roy Arends. + + + (Editor comment: the current version of NSEC2 also has the salt in + every NSEC2 record) + + +11. DNSSEC-Adoption and Zone-Growth Relationship + + + Background: Currently with NSEC, when a delegation centric zone + deploys DNSSEC, the zone-size multiplies by a non-trivial factor even + when the DNSSEC-adoption rate of the subzones remains low--because + each delegation point creates at least one NSEC record and + corresponding signature in the parent even if the child is not + signed. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 6] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Requirements: A delegation-only (or delegation-mostly) zone that is + signed but which has no signed child zones should initially need only + to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some + minimal set of NSEC++ records to cover zone contents. Further, + during the transition of a delegation-only zone from 0% signed + children to 100% signed children, the growth in the delegation-only + zone should be roughly proportional to the percentage of signed child + zones. + + + Additional Discussion: This is why DNSNR has the Authoritative Only + bit. This is similar to opt-in for delegations only. This (bit) is + currently the only method to help delegation-centric zone cope with + zone-growth due to DNSSEC adoption. As an example, A delegation only + zone which deploys DNSSEC with the help of this bit, needs to add + SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No + more than that. + + + Contributor: Roy Arends. + + +12. Non-overlap of denial records with possible zone records + + + Requirement: NSEC++ records should in some way be differentiated + from regular zone records, so that there is no possibility that a + record in the zone could be duplicated by a non-existence proof + (NSEC++) record. + + + Additional discussion: This requirement is derived from a discussion + on the DNSEXT mailing list related to copyrights and domain names. + As was outlined there, one solution is to put NSEC++ records in a + separate namespace, e.g.: $ORIGIN co.uk. + 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your + delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... + ; for amazon.co.uk. + + + Contributor: various + + + (Editor comment: One of us still does not see why a conflict + matters. Even if there is an apparent conflict or overlap, the + "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the + other name _never_ appears in NSEC2 records.) + + +13. Exposure of Private Keys + + + Private keys associated with the public keys in the DNS should be + exposed as little as possible. It is highly undesirable for private + keys to be distributed to nameservers, or to otherwise be available + in the run-time environment of nameservers. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 7] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributors: Nominet, Olaf Kolkman, Ed Lewis + + +14. Minimisation of Zone Signing Cost + + + The additional cost of creating an NSEC++ signed zone should not + significantly exceed the cost of creating an ordinary signed zone. + + + Contributor: Nominet + + +15. Minimisation of Asymmetry + + + Nameservers should have to do as little additional work as necessary. + More precisely, it is desirable for any increase in cost incurred by + the nameservers to be offset by a proportionate increase in cost to + DNS `clients', e.g. stub and/or `full-service' resolvers. + + + Contributor: Nominet + + +16. Minimisation of Client Complexity + + + Caching, wildcards, CNAMEs, DNAMEs should continue to work without + adding too much complexity at the client side. + + + Contributor: Olaf Kolkman + + +17. Completeness + + + A proof of nonexistence should be possible for all nonexistent data + in the zone. + + + Contributor: Olaf Kolkman + + +18. Purity of Namespace + + + The name space should not be muddied with fake names or data sets. + + + Contributor: Ed Lewis + + +19. Replay Attacks + + + NSEC++ should not allow a replay to be used to deny existence of an + RR that actually exists. + + + Contributor: Ed Lewis + + +20. Compatibility with NSEC + + + NSEC++ should not introduce changes incompatible with NSEC. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 8] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributor: Ed Lewis + + +21. Compatibility with NSEC II + + + NSEC++ should differ from NSEC in a way that is transparent to the + resolver or validator. + + + Contributor: Ed Lewis + + +22. Compatibility with NSEC III + + + NSEC++ should differ from NSEC as little as possible whilst achieving + other requirements. + + + Contributor: Alex Bligh + + +23. Coexistence with NSEC + + + NSEC++ should be optional, allowing NSEC to be used instead. + + + Contributor: Ed Lewis, Alex Bligh + + +24. Coexistence with NSEC II + + + NSEC++ should not impose extra work on those content with NSEC. + + + Contributor: Ed Lewis + + +25. Protocol Design + + + A good security protocol would allow signing the nonexistence of some + selected names without revealing anything about other names. + + + Contributor: Dan Bernstein + + +26. Process + + + Clearly not all of these requirements can be met. Therefore the next + phase of this document will be to either prioritise them or narrow + them down to a non-contradictory set, which should then allow us to + judge proposals on the basis of their fit. + + +27. Acknowledgements + + +28. Requirements notation + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + + + + +Laurie & Loomis Expires March 2, 2005 [Page 9] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + document are to be interpreted as described in [RFC2119]. + + +29. Security Considerations + + + There are currently no security considerations called out in this + draft. There will be security considerations in the choice of which + requirements will be implemented, but there are no specific security + requirements during the requirements collection process. + + +30. References + + +30.1 Normative References + + + [dnssecbis-protocol] + "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some + Month 2004. + + +30.2 Informative References + + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + + +Authors' Addresses + + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + + + Rip Loomis + Science Applications International Corporation + 7125 Columbia Gateway Drive, Suite 300 + Columbia, MD 21046 + US + + + EMail: gilbert.r.loomis@saic.com + + + + +Laurie & Loomis Expires March 2, 2005 [Page 10] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt new file mode 100644 index 000000000000..9c73c68befdc --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt @@ -0,0 +1,1292 @@ + + + + + +DNS Extensions Yuji Kamite +Internet-Draft NTT Communications +Expires: April 15, 2005 Masaya Nakayama + The University of Tokyo + October 14, 2004 + + + + TKEY Secret Key Renewal Mode + draft-ietf-dnsext-tkey-renewal-mode-05 + + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 15, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines a new mode in TKEY and proposes an atomic + method for changing secret keys used for TSIG periodically. + Originally, TKEY provides methods of setting up shared secrets other + + + +Kamite, et. al. Expires April 15, 2005 [Page 1] + +INTERNET-DRAFT October 2004 + + + than manual exchange, but it cannot control timing of key renewal + very well though it can add or delete shared keys separately. This + proposal is a systematical key renewal procedure intended for + preventing signing DNS messages with old and non-safe keys + permanently. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4 + 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4 + 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5 + 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5 + 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7 + 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7 + 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7 + 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8 + 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8 + 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10 + 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10 + 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11 + 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11 + 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12 + 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13 + 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14 + 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15 + 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15 + 4.2 Authentication Methods Considerations . . . . . . . . . . 15 + 5. Special Considerations for Two Servers' Case . . . . . . . . 16 + 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16 + 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 + 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 23 + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 2] + +INTERNET-DRAFT October 2004 + + +1. Introduction + + TSIG [RFC2845] provides DNS message integrity and the + request/transaction authentication by means of message authentication + codes (MAC). TSIG is a practical solution in view of calculation + speed and availability. However, TSIG does not have exchanging + mechanism of shared secret keys between server and resolver, and + administrators might have to exchange secret keys manually. TKEY + [RFC2930] is introduced to solve such problem and it can exchange + secrets for TSIG via networks. + + In various modes of TKEY, a server and a resolver can add or delete a + secret key be means of TKEY message exchange. However, the existing + TKEY does not care fully about the management of keys which became + too old, or dangerous after long time usage. + + It is ideal that the number of secret which a pair of hosts share + should be limited only one, because having too many keys for the same + purpose might not only be a burden to resolvers for managing and + distinguishing according to servers to query, but also does not seem + to be safe in terms of storage and protection against attackers. + Moreover, perhaps holding old keys long time might give attackers + chances to compromise by scrupulous calculation. + + Therefore, when a new shared secret is established by TKEY, the + previous old secret should be revoked immediately. To accomplish + this, DNS servers must support a protocol for key renewal. This + document specifies procedure to refresh secret keys between two hosts + which is defined within the framework of TKEY, and it is called "TKEY + Secret Key Renewal Mode". + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + +1.1. Defined Words + + * Inception Time: Beginning of the shared secret key lifetime. This + value is determined when the key is generated. + + * Expiry Limit: Time limit of the key's validity. This value is + determined when a new key is generated. After Expiry Limit, server + and client (resolver) must not authenticate TSIG signed with the key. + Therefore, Renewal to the next key should be carried out before + Expiry Limit. + + * Partial Revocation Time: Time when server judges the key is too old + + + +Kamite, et. al. Expires April 15, 2005 [Page 3] + +INTERNET-DRAFT October 2004 + + + and must be updated. It must be between Inception Time and Expiry + Limit. This value is determined by server freely following its + security policy. e.g., If the time from Inception to Partial + Revocation is short, renewal will be carried out more often, which + might be safer. + + * Revocation Time: Time when the key becomes invalid and can be + removed. This value is not determined in advance because it is the + actual time when revocation is completed. + + * Adoption Time: Time when the new key is adopted as the next key + formally. After Adoption, the key is valid and server and client can + generate or verify TSIG making use of it. Adoption Time also means + the time when it becomes possible to remove the previous key, so + Revocation and Adoption are usually done at the same time. + + + Partial + Inception Revocation Revocation Expiry Limit + | | | | + |----------------|- - - - - - >>|- (revoked) -| + | | | | + previous key | | | + |- - - -|-------------------->> time + | | new key + Inception Adoption + + +1.2. New Format and Assigned Numbers + + TSIG + ERROR = (PartialRevoke), TBD + + TKEY + Mode = (server assignment for key renewal), TBD + Mode = (Diffie-Hellman exchange for key renewal), TBD + Mode = (resolver assignment for key renewal), TBD + Mode = (key adoption), TBD + + +1.3. Overview of Secret Key Renewal Mode + + When a server receives a query from a client signed with a TSIG key, + It always checks if the present time is within the range of usage + duration it considers safe. If it is judged that the key is too old, + i.e., after Partial Revocation Time, the server comes to be in + Partial Revocation state about the key, and this key is called + partially revoked. + + + +Kamite, et. al. Expires April 15, 2005 [Page 4] + +INTERNET-DRAFT October 2004 + + + In this state, if a client sends a normal query (e.g., question about + A RR) other than TKEY Renewal request with TSIG signed with the old + key, the server returns an error message to notify that the time to + renew has come. This is called "PartialRevoke" error message. It is + server's choice whether it returns PartialRevoke or not. If and only + if the server is ready for changing its own key, it decides to return + PartialRevoke. + + The client which got this error is able to notice that it is + necessary to refresh the secret. To make a new shared secret, it + sends a TKEY Renewal request, in which several keying methods are + available. It can make use of TSIG authentication signed with the + partially revoked key mentioned above. + + After new secret establishment, the client sends a TKEY Adoption + request for renewal confirmation. This can also be authenticated with + the partially revoked key. If this is admitted by the server, the new + key is formally adopted, and at the same time the corresponding old + secret is invalidated. Then the client can send the first query again + signed with the new key. + + Key renewal procedure is executed based on two-phase commit + mechanism. The first phase is the TKEY Renewal request and its + response, which means preparatory confirmation for key update. The + second phase is Adoption request and its response. If the server gets + request and client receives the response successfully, they can + finish renewal process. If any error happens and renewal process + fails during these phases, client should roll back to the beginning + of the first phase, and send TKEY Renewal request again. This + rollback can be done until the Expiry Limit of the key. + + +2. Shared Secret Key Renewal + + Suppose a server and a client agree to change their TSIG keys + periodically. Key renewal procedure is defined between two hosts. + +2.1. Key Usage Time Check + + Whenever a server receives a query with TSIG and can find a key that + is used for signing it, the server checks its Inception Time, Partial + Revocation Time and Expiry Limit (this information is usually + memorized by the server). + + When the present time is before Inception Time, the server MUST NOT + verify TSIG with the key, and server acts the same way as when the + key used by the client is not recognized. It follows [RFC2845] 4.5.1. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 5] + +INTERNET-DRAFT October 2004 + + + When the present time is equal to Inception Time, or between + Inception Time and Partial Revocation Time, the behavior of the + server is the same as when a valid key is found. It follows [RFC2845] + 4.5.2 and 4.5.3. + + When the present time is the same as the Partial Revocation Time, or + between the Partial Revocation Time and Expiry Limit, the server + comes to be in Partial Revocation state about the TSIG key and + behaves according to the next section. + + When the present time is the same as the Expiry Time or after it, the + server MUST NOT verify TSIG with the key, and returns error messages + in the same way as when the key used by the client is not recognized. + It follows [RFC2845] 4.5.1. + + +2.2. Partial Revocation + + In Partial Revocation state, we say the server has partially revoked + the key and the key has become a "partially revoked key". + + If server has received a query signed with the partially revoked key + for TKEY Renewal request (See section 2.3.) or Key Adoption request + (See section 2.4.), then server does proper process following each + specification. If it is for TKEY key deletion request ([RFC2930] + 4.2), server MAY process usual deletion operation defined therein. + + If server receives other types of query signed with the partially + revoked key, and both the corresponding MAC and signed TIME are + verified, then server begins returning answer whose TSIG error code + is "PartialRevoke" (See section 9.). Server MUST randomly but with + increasing frequency return PartialRevoke when in the Partial + Revocation state. + + Server can decide when it actually sends PartialRevoke, checking if + it is appropriate time for renewal. Server MUST NOT return + PartialRevoke if this is apart long lived TSIG transaction (such as + AXFR) that started before the Partial Revocation Time. + + If the client receives PartialRevoke and understands it, then it MUST + retry the query with the old key unless a new key has been adopted. + Client SHOULD start the process to renew the TSIG key. For key + renewal procedure, see details in Section 2.3 and 2.4. + + PartialRevoke period (i.e., time while server returns PartialRevoke + randomely) SHOULD be small, say 2-5% of key lifetime. This is + server's choice. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 6] + +INTERNET-DRAFT October 2004 + + + Server MUST keep track of clients ignoring PartialRevoke, thus + indicating ignorance of this TKEY mode. + + PartialRevoke error messages have the role to inform clients of the + keys' partial revocation and urge them to send TKEY Renewal requests. + These error responses MUST be signed with those partial revoked keys + if the queries are signed with them. They are sent only when the + signing keys are found to be partially revoked. If the MAC of TSIG + cannot be verified with the partially revoked keys, servers MUST NOT + return PartialRevoke error with MAC, but MUST return another error + such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other + words, a server informs its key's partial revocation only when the + MAC in the received query is valid. + + +2.3. Key Renewal Message Exchange + +2.3.1. Query for Key Renewal + + If a client has received a PartialRevoke error and authenticated the + response based on TSIG MAC, it sends a TKEY query for Key Renewal (in + this document, we call it Renewal request, too.) to the server. The + request MUST be signed with TSIG or SIG(0) [RFC2931] for + authentication. If TSIG is selected, the client can sign it with the + partial revoked key. + + Key Renewal can use one of several keying methods which is indicated + in "Mode" field of TKEY RR, and its message structure is dependent on + that method. + + +2.3.2. Response for Key Renewal + + The server which has received Key Renewal request first tries to + verify TSIG or SIG(0) accompanying it. If the TSIG is signed and + verified with the partially revoked key, the request MUST be + authenticated. + + After authentication, server must check existing old key's validity. + If the partially revoked key indicated in the request TKEY's OldName + and OldAlgorithm field (See section 2.3.4.) does not exist at the + server, "BADKEY" [RFC2845] is given in Error field for response. If + any other error happens, server returns appropriate error messages + following the specification described in section 2.5. If there are no + errors, server returns a Key Renewal answer. This answer MUST be + signed with TSIG or SIG(0) for authentication. + + When this answer is successfully returned and no error is detected by + + + +Kamite, et. al. Expires April 15, 2005 [Page 7] + +INTERNET-DRAFT October 2004 + + + client, a new shared secret can be established. The details of + concrete keying procedure are given in the section 2.5. + + Note: + Sometimes Adoption message and new Renewal request will cross on + the wire. In this case the newly generated key Adoption message is + resent. + + +2.3.3. Attributes of Generated Key + + As a result of this message exchange, client comes to know the newly + generated key's attributes such as key's name, Inception Time and + Expiry Limit. They are decided by the server and told to the client; + in particular, however, once the server has decided Expiry Limit and + returned a response, it should obey the decision as far as it can. In + other words, they SHOULD NOT change time values for checking Expiry + Limit in the future without any special reason, such as security + issue like "Emergency Compulsory Revocation" described in section 8. + + On the other hand, Partial Revocation Time of this generated key is + not decided based on the request, and not informed to the client. The + server can determine any value as long as it is between Inception + Time and Expiry Limit. However, the period from Inception to Partial + Revocation SHOULD be fixed as the server side's configuration or be + set the same as the corresponding old key's one. + + Note: + Even if client sends Key Renewal request though the key described + in OldName has not been partially revoked yet, server does renewal + processes. At the moment when the server accepts such requests + with valid authentication, it MUST forcibly consider the key is + already partially revoked, that is, the key's Partial Revocation + Time must be changed into the present time (i.e., the time when + the server receives the request). + + +2.3.4. TKEY RR structure + + TKEY RR for Key Renewal message has the structure given below. In + principle, format and definition for each field follows [RFC2930]. + Note that each keying scheme sometimes needs different interpretation + of RDATA field; for detail, see section 2.5. + + Field Type Comment + ------- ------ ------- + NAME domain used for a new key, see below + TYPE u_int16_t (defined in [RFC2930]) + + + +Kamite, et. al. Expires April 15, 2005 [Page 8] + +INTERNET-DRAFT October 2004 + + + CLASS u_int16_t (defined in [RFC2930]) + TTL u_int32_t (defined in [RFC2930]) + RDLEN u_int16_t (defined in [RFC2930]) + RDATA: + Algorithm: domain algorithm for a new key + Inception: u_int32_t about the keying material + Expiration: u_int32_t about the keying material + Mode: u_int16_t scheme for key agreement + see section 9. + Error: u_int16_t see description below + Key Size: u_int16_t see description below + Key Data: octet-stream + Other Size: u_int16_t (defined in [RFC2930]) + size of other data + Other Data: newly defined: see description below + + + For "NAME" field, both non-root and root name are allowed. It may + be used for a new key's name in the same manner as [RFC2930] 2.1. + + "Algorithm" specifies which algorithm is used for agreed keying + material, which is used for identification of the next key. + + "Inception" and "Expiration" are used for the valid period of + keying material. The meanings differ somewhat according to whether + the message is request or answer, and its keying scheme. + + "Key Data" has different meanings according to keying schemes. + + "Mode" field stores the value in accordance with the keying method, + and see section 2.5. Servers and clients supporting TKEY Renewal + method MUST implement "Diffie-Hellman exchange for key renewal" + scheme. All other modes are OPTIONAL. + + "Error" is an extended RCODE which includes "PartialRevoke" value + too. See section 9. + + "Other Data" field has the structure given below. They describe + attributes of the key to be renewed. + + in Other Data filed: + + Field Type Comment + ------- ------ ------- + OldNAME domain name of the old key + OldAlgorithm domain algorithm of the old key + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 9] + +INTERNET-DRAFT October 2004 + + + "OldName" indicates the name of the previous key (usually, + this is partially revoked key's name that client noticed by + PartialRevoke answer from server), and "OldAlogirthm" + indicates its algorithm. + + +2.4. Key Adoption + +2.4.1. Query for Key Adoption + + After receiving a TKEY Renewal answer, the client gets the same + secret as the server. Then, it sends a TKEY Adoption request. The + request's question section's QNAME field is the same as the NAME + filed of TKEY written below. In additional section, there is one TKEY + RR that has the structure and values described below. + + "NAME" field is the new key's name to be adopted which was already + generated by Renewal message exchange. "Algorithm" is its + algorithm. "Inception" means the key's Inception Time, and + "Expiration" means Expiry Limit. + + "Mode" field is the value of "key adoption". See section 9. + + "Other Data" field in Adoption has the same structure as that of + Renewal request message. "OldName" means the previous old key, and + "OldAlogirthm" means its algorithm. + + Key Adoption request MUST be signed with TSIG or SIG(0) for + authentication. The client can sign TSIG with the previous key. Note + that until Adoption is finished, the new key is treated as invalid, + thus it cannot be used for authentication immediately. + + +2.4.2. Response for Key Adoption + + The server which has received Adoption request, it verifies TSIG or + SIG(0) accompanying it. If the TSIG is signed with the partially + revoked key and can be verified, the message MUST be authenticated. + + If the next new key indicated by the request TKEY's "NAME" is not + present at the server, BADNAME [RFC2845] is given in Error field and + the error message is returned. + + If the next key exists but it has not been adopted formally yet, the + server confirms the previous key's existence indicated by the + "OldName" and "OldAlgorithm" field. If it succeeds, the server + executes Adoption of the next key and Revocation of the previous key. + Response message duplicates the request's TKEY RR with NOERROR, + + + +Kamite, et. al. Expires April 15, 2005 [Page 10] + +INTERNET-DRAFT October 2004 + + + including "OldName" and "OldAlgorithm" that indicate the revoked key. + + If the next key exists but it is already adopted, the server returns + a response message regardless of the substance of the request TKEY's + "OldName". In this response, Response TKEY RR has the same data as + the request's one except as to its "Other Data" that is changed into + null (i.e., "Other Size" is zero), which is intended for telling the + client that the previous key name was ignored, and the new key is + already available. + + Client sometimes has to retry Adoption request. Suppose the client + sent request signed with the partially revoked key, but its response + did not return successfully (e.g., due to the drop of UDP packet). + Client will probably retry Adoption request; however, the request + will be refused in the form of TSIG "BADKEY" error because the + previous key was already revoked. In this case, client will + retransmit Adoption request signed with the next key, and expect a + response which has null "Other Data" for confirming the completion of + renewal. + + +2.5. Keying Schemes + + In Renewal message exchanges, there are no limitations as to which + keying method is actually used. The specification of keying + algorithms is independent of the general procedure of Renewal that is + described in section 2.3. + + Now this document specifies three algorithms in this section, but + other future documents can make extensions defining other methods. + + +2.5.1. DH Exchange for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.1. This + specification only describes the difference from it and special + notice; assume that all other points, such as keying material + computation, are the exactly same as the specification of [RFC2930] + 4.1. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + the client's Diffie-Hellman public key [RFC2539]. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 11] + +INTERNET-DRAFT October 2004 + + + TKEY "Mode" field stores the value of "DH exchange for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is used as a random, following [RFC2930] 4.1. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. If + any incompatible DH key is found in the request, "BADKEY" + [RFC2845] is given in Error field for response. "FORMERR" is given + if the query included no DH KEY. + + If there are no errors, the server processes a response according + to Diffie-Hellman algorithm and returns the answer. In this + answer, there is one TKEY RR in answer section and KEY RR(s) in + additional section. + + As long as no error has occurred, all values of TKEY are equal to + that of the request message except TKEY NAME, TKEY RDLEN, RDATA's + Inception, Expiration, Key Size and Key Data. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is used as an additional nonce, following + [RFC2930] 4.1. + + The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in + the additional section and a server Diffie-Hellman KEY RR will + also be present in the answer section, following [RFC2930] 4.1. + + +2.5.2. Server Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.4. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.4. + + + +Kamite, et. al. Expires April 15, 2005 [Page 12] + +INTERNET-DRAFT October 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + used in encrypting the response. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "server assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is provided following the specification of + [RFC2930] 4.4. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the query specified no encryption key. + + If there are no errors, the server response contains one TKEY RR + in the answer section, and echoes the KEY RR provided in the query + in the additional information section. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is the assigned keying data encrypted under the + public key in the resolver provided KEY RR, which is the same as + [RFC2930] 4.4. + + +2.5.3. Resolver Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.5. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.5. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 13] + +INTERNET-DRAFT October 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. TKEY RR + has the encrypted keying material and KEY RR is the server public + key used to encrypt the data. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "resolver assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is the encrypted keying material. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the server does not have the corresponding + private key for the KEY RR that was shown sin the request. + + If there are no errors, the server returns a response. The + response contains a TKEY RR in the answer section to tell the + shared key's name and its usage time values. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + +2.6. Considerations about Non-compliant Hosts + + Key Renewal requests and responses must be exchanged between hosts + which can understand them and do proper processes. PartialRevoke + error messages will be only ignored if they should be returned to + non-compliant hosts. + + Note that server does not inform actively the necessity of renewal to + clients, but inform it as responses invoked by client's query. + Server needs not care whether the PartialRevoke errors has reached + + + +Kamite, et. al. Expires April 15, 2005 [Page 14] + +INTERNET-DRAFT October 2004 + + + client or not. If client has not received yet because of any reasons + such as packet drops, it will resend the queries, and finally will be + able to get PartialRevoke information. + + +3. Secret Storage + + Every server keeps all secrets and attached information, e.g., + Inception Time, Expiry Limit, etc. safely to be able to recover from + unexpected stop. To accomplish this, formally adopted keys SHOULD be + memorized not only on memory, but also be stored in the form of some + files. It will become more secure if they are stored in ecrypted + form. + + +4. Compulsory Key Revocation + +4.1. Compulsory Key Revocation by Server + + There is a rare but possible case that although servers have already + partially revoked keys, clients do not try to send any Renewal + requests. If this state continues, in the future it will become the + time of Expiry Limit. After Expiry Limit, the keys will be expired + and completely removed, so this is called Compulsory Key Revocation + by server. + + If Expiry Limit is too distant from the Partial Revocation Time, then + even though very long time passes, clients will be able to refresh + secrets only if they add TSIG signed with those old partially revoked + keys into requests, which is not safe. + + On the other hand, if Expiry Limit is too close to Partial Revocation + Time, perhaps clients might not be able to notice their keys' Partial + Revocation by getting "PartialRevoke" errors. + + Therefore, servers should set proper Expiry Limit to their keys, + considering both their keys' safety, and enough time for clients to + send requests and process renewal. + + +4.2. Authentication Methods Considerations + + It might be ideal to provide both SIG(0) and TSIG as authentication + methods. For example: + + A client and a server start SIG(0) authentication at first, to + establish TSIG shared keys by means of "Query for Diffie-Hellman + Exchanged Keying" as described in [RFC2930] 4.1. Once they get + + + +Kamite, et. al. Expires April 15, 2005 [Page 15] + +INTERNET-DRAFT October 2004 + + + shared secret, they keep using TSIG for queries and responses. + After a while the server returns a "ParitalRevoke" error and they + begin a key renewal process. Both TSIG signed with partially + revoked keys and SIG(0) are okay for authentication, but TSIG would + be easier to use considering calculation efficiency. + + Suppose now client is halted for long time with some reason. + Because server does not execute any renewal process, it will + finally do Compulsory Revocation. Even if client restarts and sends + a key Renewal request, it will fail because old key is already + deleted at server. + + At this moment, however, if client also uses SIG(0) as another + authentication method, it can make a new shared key again and + recover successfully by sending "Query for Diffie-Hellman Exchanged + Keying" with SIG(0). + + +5. Special Considerations for Two servers' Case + + This section refers to the case where both hosts are DNS servers + which can act as full resolvers as well and using one shared key + only. If one server (called Server A) wants to refresh a shared key + (called "Key A-B"), it will await a TKEY Renewal request from the + other server (called Server B). However, perhaps Server A wants to + refresh the key right now. + + In this case, Server A is allowed to send a Renewal request to Server + B, if Server A knows the Key A-B is too old and wants to renew it + immediately. + + Note that the initiative in key renewal belongs to Server A because + it can notice the Partial Revocation Time and decide key renewal. If + Server B has information about Partial Revocation Time as well, it + can also decide for itself to send Renewal request to Server A. + However, it is not essential for both two servers have information + about key renewal timing. + +5.1. To Cope with Collisions of Renewal Requests + + At least one of two hosts which use Key Renewal must know their key + renewal information such as Partial Revocation Time. It is okay that + both hosts have it. + + Provided that both two servers know key renewal timing information, + there is possibility for them to begin partial revocation and sending + Renewal requests to each other at the same time. Such collisions will + not happen so often because Renewal requests are usually invoked when + + + +Kamite, et. al. Expires April 15, 2005 [Page 16] + +INTERNET-DRAFT October 2004 + + + hosts want to send queries, but it is possible. + + When one of two servers tries to send Renewal requests, it MUST + protect old secrets that it has partially revoked and prevent it from + being refreshed by any requests from the other server (i.e., it must + lock the old secret during the process of renewal). While the server + is sending Renewal requests and waiting responses, it ignores the + other server's Renewal requests. + + Therefore, servers might fail to change secrets by means of their own + requests to others. After failure they will try to resend, but they + should wait for random delays by the next retries. If they get any + Renewal requests from others while they are waiting, their shared + keys may be refreshed, then they do not need to send any Renewal + requests now for themselves. + + +6. Key Name Considerations + + Since both servers and clients have only to distinguish new secrets + and old ones, keys' names do not need to be specified strictly. + However, it is recommended that some serial number or key generation + time be added to the name and that the names of keys between the same + pair of hosts should have some common labels among their keys. For + example, suppose A.example.com. and B.example.com. share the key + "<serial number>.A.example.com.B.example.com." such as + "10010.A.example.com.B.example.com.". After key renewal, they change + their secret and name into "10011.A.example.com.B.example.com." + + Servers and clients must be able to use keys properly for each query. + Because TSIG secret keys themselves do not have any particular IDs to + be distinguished and would be identified by their names and + algorithm, it must be understood correctly what keys are refreshed. + + +7. Example Usage of Secret Key Renewal Mode + + This is an example of Renewal mode usage where a Server, + server.example.com, and a Client, client.exmple.com have an initial + shared secret key named "00.client.example.com.server.example.com". + + (1) The time values for key + "00.client.example.com.server.example.com" was set as follows: + Inception Time is at 1:00, Expiry Limit is at 21:00. + + (2) At Server, renewal time has been set: Partial Revocation Time + is at 20:00. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 17] + +INTERNET-DRAFT October 2004 + + + (3) Suppose the present time is 19:55. If Client sends a query + signed with key "00.client.example.com.server.example.com" to ask + the IP address of "www.example.com", finally it will get a proper + answer from Server with valid TSIG (NOERROR). + + (4) At 20:05. Client sends a query to ask the IP address of + "www2.example.com". It is signed with key + "00.client.example.com.server.example.com". Server returns an + answer for the IP address. However, server has begun retuning + PartialRevoke Error randomely. This answer includes valid TSIG MAC + signed with "00.client.example.com.server.example.com", and its + Error Code indicates PartialRevoke. Client understands that the + current key is partially revoked. + + (5) At 20:06. Client sends a Renewal request to Server. This + request is signed with key + "00.client.example.com.server.example.com". It includes data such + as: + + Question Section: + QNAME = 01.client.example.com. (Client can set this freely) + TYPE = TKEY + + Additional Section: + 01.client.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a KEY RR for DH and a TSIG RR. + + (6) As soon as Server receives this request, it verifies TSIG. It + is signed with the partially revoked key + "00.client.example.com.server.example.com". and Server accepts the + request. It creates a new key by Diffie-Hellman calculation and + returns an answer which includes data such as: + + Answer Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + + +Kamite, et. al. Expires April 15, 2005 [Page 18] + +INTERNET-DRAFT October 2004 + + + Answer Section also contains KEY RRs for DH. + + Additional Section also contains a TSIG RR. + This response is signed with key + "00.client.example.com.server.example.com" without error. + + At the same time, Server decides to set the Partial Revocation Time + of this new key "01.client.example.com.server.example.com." as next + day's 15:00. + + (7) Client gets the response and checks TSIG MAC, and calculates + Diffie-Hellman. It will get a new key, and it has been named + "01.client.example.com.server.example.com" by Server. + + (8) At 20:07. Client sends an Adoption request to Server. This + request is signed with the previous key + "00.client.example.com.server.example.com". It includes: + + Question Section: + QNAME = 01.client.example.com.server.example.com. + TYPE = TKEY + + Additional Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (key adoption) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a TSIG RR. + + (9) Server verifies the query's TSIG. It is signed with the + previous key and authenticated. It returns a response whose TKEY RR + is the same as the request's one. The response is signed with key + "00.client.example.com.server.example.com.". As soon as the + response is sent, Server revokes and removes the previous key. At + the same time, key "01.client.example.com.server.example.com." is + validated. + + (10) Client acknowledges the success of Adoption by receiving the + response. Then, it retries to send an original question about + "www2.example.com". It is signed with the adopted key + "01.client.example.com.server.example.com", so Server authenticates + it and returns an answer. + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 19] + +INTERNET-DRAFT October 2004 + + + (11) This key is used until next day's 15:00. After that, it will + be partially revoked again. + + +8. Security Considerations + + This document considers about how to refresh shared secret. Secret + changed by this method is used at servers in support of TSIG + [RFC2845]. + + [RFC2104] says that current attacks to HMAC do not indicate a + specific recommended frequency for key changes but periodic key + refreshment is a fundamental security practice that helps against + potential weaknesses of the function and keys, and limits the damage + of an exposed key. TKEY Secret Key Renewal provides the method of + periodical key refreshment. + + In TKEY Secret Key Renewal, clients need to send two requests + (Renewal and Adoption) and spend time to finish their key renewal + processes. Thus the usage period of secrets should be considered + carefully based on both TKEY processing performance and security. + + This document specifies the procedure of periodical key renewal, but + actually there is possibility for servers to have no choice other + than revoking their secret keys immediately especially when the keys + are found to be compromised by attackers. This is called "Emergency + Compulsory Revocation". For example, suppose the original Expiry + Limit was set at 21:00, Partial Revocation Time at 20:00 and + Inception Time at 1:00. if at 11:00 the key is found to be + compromised, the server sets Expiry Limit forcibly to be 11:00 or + before it. + + Consequently, once Compulsory Revocation (See section 4.) is carried + out, normal renewal process described in this document cannot be done + any more as far as the key is concerned. However, after such + accidents happened, the two hosts are able to establish secret keys + and begin renewal procedure only if they have other (non-compromised) + shared TSIG keys or safe SIG(0) keys for the authentication of + initial secret establishment such as Diffie-Hellman Exchanged Keying. + + +9. IANA Considerations + + IANA needs to allocate a value for "DH exchange for key renewal", + "server assignment for key renewal", "resolver assignment for key + renewal" and "key adoption" in the mode filed of TKEY. It also needs + to allocate a value for "PartialRevoke" from the extended RCODE + space. + + + +Kamite, et. al. Expires April 15, 2005 [Page 20] + +INTERNET-DRAFT October 2004 + + +10. Acknowledgements + + The authors would like to thank Olafur Gudmundsson, whose helpful + input and comments contributed greatly to this document. + + +11. References + +11.1. Normative References + +[RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + +[RFC2539] + D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", RFC 2539, March 1999. + +[RFC2845] + Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, + May 2000. + +[RFC2930] + D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', + RFC 2930, September 2000. + +[RFC2931] + D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s + )", RFC 2931, September 2000. + +11.2. Informative References + +[RFC2104] + H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message + Authentication", RFC2104, February 1997. + + + + + + + + + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 21] + +INTERNET-DRAFT October 2004 + + +Authors' Addresses + + Yuji Kamite + NTT Communications Corporation + Tokyo Opera City Tower + 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo + 163-1421, Japan + EMail: y.kamite@ntt.com + + + Masaya Nakayama + Information Technology Center, The University of Tokyo + 2-11-16 Yayoi, Bunkyo-ku, Tokyo + 113-8658, Japan + EMail: nakayama@nc.u-tokyo.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 22] + +INTERNET-DRAFT October 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 23] + + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt new file mode 100644 index 000000000000..b5aaad2b8599 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt @@ -0,0 +1,1501 @@ +Network Working Group J. Ihren +Internet-Draft Autonomica AB +Expires: April 18, 2005 O. Kolkman + RIPE NCC + B. Manning + EP.net + October 18, 2004 + + + + An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for + DNSSEC Trust Anchors. + draft-ietf-dnsext-trustupdate-threshold-00 + + +Status of this Memo + + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + + 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 18, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + The DNS Security Extensions (DNSSEC) works by validating so called + chains of authority. The start of these chains of authority are + usually public keys that are anchored in the DNS clients. These keys + are known as the so called trust anchors. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 1] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + This memo describes a method how these client trust anchors can be + replaced using the DNS validation and querying mechanisms (in-band) + when the key pairs used for signing by zone owner are rolled. + + + This memo also describes a method to establish the validity of trust + anchors for initial configuration, or priming, using out of band + mechanisms. + + +Table of Contents + + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry + Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 + 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 + 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 + 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 + 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 + 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 + 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 + 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 + 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 + 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 + 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 + 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 + 3.7 No need for resolver-side overlap of old and new keys . . 13 + 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 + 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 + 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 + 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6.1 Threshold-based Trust Update Security Considerations . . . 17 + 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 + B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . 24 + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 2] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +1. Terminology + + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC2119 [1]. + + + The term "zone" refers to the unit of administrative control in the + Domain Name System. In this document "name server" denotes a DNS + name server that is authoritative (i.e. knows all there is to know) + for a DNS zone. A "zone owner" is the entity responsible for signing + and publishing a zone on a name server. The terms "authentication + chain", "bogus", "trust anchors" and "Island of Security" are defined + in [4]. Throughout this document we use the term "resolver" to mean + "Validating Stub Resolvers" as defined in [4]. + + + We use the term "security apex" as the zone for which a trust anchor + has been configured (by validating clients) and which is therefore, + by definition, at the root of an island of security. The + configuration of trust anchors is a client side issue. Therefore a + zone owner may not always know if their zone has become a security + apex. + + + A "stale anchor" is a trust anchor (a public key) that relates to a + key that is not used for signing. Since trust anchors indicate that + a zone is supposed to be secure a validator will mark the all data in + an island of security as bogus when all trust anchors become stale. + + + It is assumed that the reader is familiar with public key + cryptography concepts [REF: Schneier Applied Cryptography] and is + able to distinguish between the private and public parts of a key + based on the context in which we use the term "key". If there is a + possible ambiguity we will explicitly mention if a private or a + public part of a key is used. + + + The term "administrator" is used loosely throughout the text. In + some cases an administrator is meant to be a person, in other cases + the administrator may be a process that has been delegated certain + responsibilities. + + +1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points + + + Although the DNSSEC protocol does not make a distinction between + different keys the operational practice is that a distinction is made + between zone signing keys and key signing keys. A key signing key is + used to exclusively sign the DNSKEY Resource Record (RR) set at the + apex of a zone and the zone signing keys sign all the data in the + zone (including the DNSKEY RRset at the apex). + + + + + +Ihren, et al. Expires April 18, 2005 [Page 3] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Keys that are intended to be used as the start of the authentication + chain for a particular zone, either because they are pointed to by a + parental DS RR or because they are configured as a trust anchor, are + called Secure Entry Point (SEP) keys. In practice these SEP keys + will be key signing keys. + + + In order for the mechanism described herein to work the keys that are + intended to be used as secure entry points MUST have the SEP [2] flag + set. In the examples it is assumed that keys with the SEP flag set + are used as key signing keys and thus exclusively sign the DNSKEY + RRset published at the apex of the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 4] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +2. Introduction and Background + + + When DNSSEC signatures are validated the resolver constructs a chain + of authority from a pre-configured trust anchor to the DNSKEY + Resource Record (RR), which contains the public key that validates + the signature stored in an RRSIG RR. DNSSEC is designed so that the + administrator of a resolver can validate data in multiple islands of + security by configuring multiple trust anchors. + + + It is expected that resolvers will have more than one trust anchor + configured. Although there is no deployment experience it is not + unreasonable to expect resolvers to be configured with a number of + trust anchors that varies between order 1 and order 1000. Because + zone owners are expected to roll their keys, trust anchors will have + to be maintained (in the resolver end) in order not to become stale. + + + Since there is no global key maintenance policy for zone owners and + there are no mechanisms in the DNS to signal the key maintenance + policy it may be very hard for resolvers administrators to keep their + set of trust anchors up to date. For instance, if there is only one + trust anchor configured and the key maintenance policy is clearly + published, through some out of band trusted channel, then a resolver + administrator can probably keep track of key rollovers and update the + trust anchor manually. However, with an increasing number of trust + anchors all rolled according to individual policies that are all + published through different channels this soon becomes an + unmanageable problem. + + +2.1 Dangers of Stale Trust Anchors + + + Whenever a SEP key at a security apex is rolled there exists a danger + that "stale anchors" are created. A stale anchor is a trust anchor + (i.e. a public key configured in a validating resolver) that relates + to a private key that is no longer used for signing. + + + The problem with a stale anchors is that they will (from the + validating resolvers point of view) prove data to be false even + though it is actually correct. This is because the data is either + signed by a new key or is no longer signed and the resolver expects + data to be signed by the old (now stale) key. + + + This situation is arguably worse than not having a trusted key + configured for the secure entry point, since with a stale key no + lookup is typically possible (presuming that the default + configuration of a validating recursive nameserver is to not give out + data that is signed but failed to verify. + + + The danger of making configured trust anchors become stale anchors + + + + +Ihren, et al. Expires April 18, 2005 [Page 5] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + may be a reason for zone owners not to roll their keys. If a + resolver is configured with many trust anchors that need manual + maintenance it may be easy to not notice a key rollover at a security + apex, resulting in a stale anchor. + + + In Section 3 this memo sets out a lightweight, in-DNS, mechanism to + track key rollovers and modify the configured trust anchors + accordingly. The mechanism is stateless and does not need protocol + extensions. The proposed design is that this mechanism is + implemented as a "trust updating machine" that is run entirely + separate from the validating resolver except that the trust updater + will have influence over the trust anchors used by the latter. + + + In Section 4 we describe a method [Editors note: for now only the + frame work and a set of requirements] to install trust anchors. This + method can be used at first configuration or when the trust anchors + became stale (typically due to a failure to track several rollover + events). + + + The choice for which domains trust anchors are to be configured is a + local policy issue. So is the choice which trust anchors has + prevalence if there are multiple chains of trust to a given piece of + DNS data (e.g. when a parent zone and its child both have trust + anchors configured). Both issues are out of the scope of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 6] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3. Threshold-based Trust Anchor Rollover + + +3.1 The Rollover + + + When a key pair is replaced all signatures (in DNSSEC these are the + RRSIG records) created with the old key will be replaced by new + signatures created by the new key. Access to the new public key is + needed to verify these signatures. + + + Since zone signing keys are in "the middle" of a chain of authority + they can be verified using the signature made by a key signing key. + Rollover of zone signing keys is therefore transparent to validators + and requires no action in the validator end. + + + But if a key signing key is rolled a resolver can determine its + authenticity by either following the authorization chain from the + parents DS record, an out-of-DNS authentication mechanism or by + relying on other trust anchors known for the zone in which the key is + rolled. + + + The threshold trust anchor rollover mechanism (or trust update), + described below, is based on using existing trust anchors to verify a + subset of the available signatures. This is then used as the basis + for a decision to accept the new keys as valid trust anchors. + + + Our example pseudo zone below contains a number of key signing keys + numbered 1 through Y and two zone signing keys A and B. During a key + rollover key 2 is replaced by key Y+1. The zone content changes + from: + + + example.com. DNSKEY key1 + example.com. DNSKEY key2 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + + + example.com. DNSKEY keyA + example.com. DNSKEY keyB + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key2) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + to: + + + + +Ihren, et al. Expires April 18, 2005 [Page 7] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + example.com. DNSKEY key1 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + example.com. DNSKEY keyY+1 + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyY+1) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + When the rollover becomes visible to the verifying stub resolver it + will be able to verify the RRSIGs associated with key1, key3 ... + keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will + not be used for validation, since that key is previously unknown and + therefore not trusted. + + + Note that this example is simplified. Because of operational + considerations described in [5] having a period during which the two + key signing keys are both available is necessary. + + +3.2 Threshold-based Trust Update + + + The threshold-based trust update algorithm applies as follows. If + for a particular secure entry point + o if the DNSKEY RRset in the zone has been replaced by a more recent + one (as determined by comparing the RRSIG inception dates) + and + o if at least M configured trust anchors directly verify the related + RRSIGs over the new DNSKEY RRset + and + o the number of configured trust anchors that verify the related + RRSIGs over the new DNSKEY RRset exceed a locally defined minimum + number that should be greater than one + then all the trust anchors for the particular secure entry point are + replaced by the set of keys from the zones DNSKEY RRset that have the + SEP flag set. + + + The choices for the rollover acceptance policy parameter M is left to + the administrator of the resolver. To be certain that a rollover is + accepted up by resolvers using this mechanism zone owners should roll + as few SEP keys at a time as possible (preferably just one). That + way they comply to the most strict rollover acceptance policy of + M=N-1. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 8] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The value of M has an upper bound, limited by the number of of SEP + keys a zone owner publishes (i.e. N). But there is also a lower + bound, since it will not be safe to base the trust in too few + signatures. The corner case is M=1 when any validating RRSIG will be + sufficient for a complete replacement of the trust anchors for that + secure entry point. This is not a recommended configuration, since + that will allow an attacker to initiate rollover of the trust anchors + himself given access to just one compromised key. Hence M should in + be strictly larger than 1 as shown by the third requirement above. + + + If the rollover acceptance policy is M=1 then the result for the + rollover in our example above should be that the local database of + trust anchors is updated by removing key "key2" from and adding key + "keyY+1" to the key store. + + +3.3 Possible Trust Update States + + + We define five states for trust anchor configuration at the client + side. + PRIMING: There are no trust anchors configured. There may be priming + keys available for initial priming of trust anchors. + IN-SYNC: The set of trust anchors configured exactly matches the set + of SEP keys used by the zone owner to sign the zone. + OUT-OF-SYNC: The set of trust anchors is not exactly the same as the + set of SEP keys used by the zone owner to sign the zone but there + are enough SEP key in use by the zone owner that is also in the + trust anchor configuration. + UNSYNCABLE: There is not enough overlap between the configured trust + anchors and the set of SEP keys used to sign the zone for the new + set to be accepted by the validator (i.e. the number of + signatures that verify is not sufficient). + STALE: There is no overlap between the configured trust anchors and + the set of SEP keys used to sign the zone. Here validation of + data is no longer possible and hence we are in a situation where + the trust anchors are stale. + + + Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of + the automatic trust update mechanism. The PRIMING state is where a + validator is located before acquiring an up-to-date set of trust + anchors. The transition from PRIMING to IN-SYNC is manual (see + Section 4 below). + + + Example: assume a secure entry point with four SEP keys and a + validator with the policy that it will accept any update to the set + of trust anchors as long as no more than two signatures fail to + validate (i.e. M >= N-2) and at least two signature does validate + (i.e. M >= 2). In this case the rollover of a single key will move + the validator from IN-SYNC to OUT-OF-SYNC. When the trust update + + + + +Ihren, et al. Expires April 18, 2005 [Page 9] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + state machine updates the trust anchors it returns to state IN-SYNC. + + + If if for some reason it fails to update the trust anchors then the + next rollover (of a different key) will move the validator from + OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys + that are configured as trust anchors and that is sufficient to accpt + an automatic update of the trust anchors. + + + The UNSYNCABLE state is where a validator is located if it for some + reason fails to incorporate enough updates to the trust anchors to be + able to accept new updates according to its local policy. In this + example (i.e. with the policy specified above) this will either be + because M < N-2 or M < 2, which does not suffice to authenticate a + successful update of trust anchors. + + + Continuing with the previous example where two of the four SEP keys + have already rolled, but the validator has failed to update the set + of trust anchors. When the third key rolls over there will only be + one trust anchor left that can do successful validation. This is not + sufficient to enable automatic update of the trust anchors, hence the + new state is UNSYNCABLE. Note, however, that the remaining + up-to-date trust anchor is still enough to do successful validation + so the validator is still "working" from a DNSSEC point of view. + + + The STALE state, finally, is where a validator ends up when it has + zero remaining current trust anchors. This is a dangerous state, + since the stale trust anchors will cause all validation to fail. The + escape is to remove the stale trust anchors and thereby revert to the + PRIMING state. + + +3.4 Implementation notes + + + The DNSSEC protocol specification ordains that a DNSKEY to which a DS + record points should be self-signed. Since the keys that serve as + trust anchors and the keys that are pointed to by DS records serve + the same purpose, they are both secure entry points, we RECOMMEND + that zone owners who want to facilitate the automated rollover scheme + documented herein self-sign DNSKEYs with the SEP bit set and that + implementation check that DNSKEYs with the SEP bit set are + self-signed. + + + In order to maintain a uniform way of determining that a keyset in + the zone has been replaced by a more recent set the automatic trust + update machine SHOULD only accept new DNSKEY RRsets if the + accompanying RRSIGs show a more recent inception date than the + present set of trust anchors. This is also needed as a safe guard + against possible replay attacks where old updates are replayed + "backwards" (i.e. one change at a time, but going in the wrong + + + + +Ihren, et al. Expires April 18, 2005 [Page 10] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + direction, thereby luring the validator into the UNSYNCABLE and + finally STALE states). + + + In order to be resilient against failures the implementation should + collect the DNSKEY RRsets from (other) authoritative servers if + verification of the self signatures fails. + + + The threshold-based trust update mechanism SHOULD only be applied to + algorithms, as represented in the algorithm field in the DNSKEY/RRSIG + [3], that the resolver is aware of. In other words the SEP keys of + unknown algorithms should not be used when counting the number of + available signatures (the N constant) and the SEP keys of unknown + algorithm should not be entered as trust anchors. + + + When in state UNSYNCABLE or STALE manual intervention will be needed + to return to the IN-SYNC state. These states should be flagged. The + most appropriate action is human audit possibly followed by + re-priming (Section 4) the keyset (i.e. manual transfer to the + PRIMING state through removal of the configured trust anchors). + + + An implementation should regularly probe the the authoritative + nameservers for new keys. Since there is no mechanism to publish + rollover frequencies this document RECOMMENDS zone owners not to roll + their key signing keys more often than once per month and resolver + administrators to probe for key rollsovers (and apply the threshold + criterion for acceptance of trust update) not less often than once + per month. If the rollover frequency is higher than the probing + frequency then trust anchors may become stale. The exact relation + between the frequencies depends on the number of SEP keys rolled by + the zone owner and the value M configured by the resolver + administrator. + + + In all the cases below a transaction where the threshold criterion is + not satisfied should be considered bad (i.e. possibly spoofed or + otherwise corrupted data). The most appropriate action is human + audit. + + + There is one case where a "bad" state may be escaped from in an + automated fashion. This is when entering the STALE state where all + DNSSEC validation starts to fail. If this happens it is concievable + that it is better to completely discard the stale trust anchors + (thereby reverting to the PRIMING state where validation is not + possible). A local policy that automates removal of stale trust + anchors is therefore suggested. + + +3.5 Possible transactions + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 11] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3.5.1 Single DNSKEY replaced + + + This is probably the most typical transaction on the zone owners + part. The result should be that if the threshold criterion is + satisfied then the key store is updated by removal of the old trust + anchor and addition of the new key as a new trust anchor. Note that + if the DNSKEY RRset contains exactly M keys replacement of keys is + not possible, i.e. for automatic rollover to work M must be stricly + less than N. + + +3.5.2 Addition of a new DNSKEY (no removal) + + + If the threshold criterion is satisfied then the new key is added as + a configured trust anchor. Not more than N-M keys can be added at + once, since otherwise the algorithm will fail. + + +3.5.3 Removal of old DNSKEY (no addition) + + + If the threshold criterion is satisfied then the old key is removed + from being a configured trust anchor. Note that it is not possible + to reduce the size of the DNSKEY RRset to a size smaller than the + minimum required value for M. + + +3.5.4 Multiple DNSKEYs replaced + + + Arguably it is not a good idea for the zone administrator to replace + several keys at the same time, but from the resolver point of view + this is exactly what will happen if the validating resolver for some + reason failed to notice a previous rollover event. + + + Not more than N-M keys can be replaced at one time or the threshold + criterion will not be satisfied. Or, expressed another way: as long + as the number of changed keys is less than or equal to N-M the + validator is in state OUT-OF-SYNC. When the number of changed keys + becomes greater than N-M the state changes to UNSYNCABLE and manual + action is needed. + + +3.6 Removal of trust anchors for a trust point + + + If the parent of a secure entry point gets signed and it's trusted + keys get configured in the key store of the validating resolver then + the configured trust anchors for the child should be removed entirely + unless explicitly configured (in the utility configuration) to be an + exception. + + + The reason for such a configuration would be that the resolver has a + local policy that requires maintenance of trusted keys further down + the tree hierarchy than strictly needed from the point of view. + + + + +Ihren, et al. Expires April 18, 2005 [Page 12] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The default action when the parent zone changes from unsigned to + signed should be to remove the configured trust anchors for the + child. This form of "garbage collect" will ensure that the automatic + rollover machinery scales as DNSSEC deployment progresses. + + +3.7 No need for resolver-side overlap of old and new keys + + + It is worth pointing out that there is no need for the resolver to + keep state about old keys versus new keys, beyond the requirement of + tracking signature inception time for the covering RRSIGs as + described in Section 3.4. + + + From the resolver point of view there are only trusted and not + trusted keys. The reason is that the zone owner needs to do proper + maintenance of RRSIGs regardless of the resolver rollover mechanism + and hence must ensure that no key rolled out out the DNSKEY set until + there cannot be any RRSIGs created by this key still legally cached. + + + Hence the rollover mechanism is entirely stateless with regard to the + keys involved: as soon as the resolver (or in this case the rollover + tracking utility) detects a change in the DNSKEY RRset (i.e. it is + now in the state OUT-OF-SYNC) with a sufficient number of matching + RRSIGs the configured trust anchors are immediately updated (and + thereby the machine return to state IN-SYNC). I.e. the rollover + machine changes states (mostly oscillating between IN-SYNC and + OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 13] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +4. Bootstrapping automatic rollovers + + + It is expected that with the ability to automatically roll trust + anchors at trust points will follow a diminished unwillingness to + roll these keys, since the risks associated with stale keys are + minimized. + + + The problem of "priming" the trust anchors, or bringing them into + sync (which could happen if a resolver is off line for a long period + in which a set of SEP keys in a zone 'evolve' away from its trust + anchor configuration) remains. + + + For (re)priming we can rely on out of band technology and we propose + the following framework. + + +4.1 Priming Keys + + + If all the trust anchors roll somewhat frequently (on the order of + months or at most about a year) then it will not be possible to + design a device, or a software distribution that includes trust + anchors, that after being manufactured is put on a shelf for several + key rollover periods before being brought into use (since no trust + anchors that were known at the time of manufacture remain active). + + + To alleviate this we propose the concept of "priming keys". Priming + keys are ordinary DNSSEC Key Signing Keys with the characteristic + that + o The private part of a priming key signs the DNSKEY RRset at the + security apex, i.e. at least one RRSIG DNSKEY is created by a + priming key rather than by an "ordinary" trust anchor + o the public parts of priming keys are not included in the DNSKEY + RRset. Instead the public parts of priming keys are only + available out-of-band. + o The public parts of the priming keys have a validity period. + Within this period they can be used to obtain trust anchors. + o The priming key pairs are long lived (relative to the key rollover + period.) + + +4.1.1 Bootstrapping trust anchors using a priming key + + + To install the trust anchors for a particular security apex an + administrator of a validating resolver will need to: + o query for the DNSKEY RRset of the zone at the security apex; + o verify the self signatures of all DNSKEYs in the RRset; + o verify the signature of the RRSIG made with a priming key -- + verification using one of the public priming keys that is valid at + that moment is sufficient; + + + + + +Ihren, et al. Expires April 18, 2005 [Page 14] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + o create the trust anchors by extracting the DNSKEY RRs with the SEP + flag set. + The SEP keys with algorithms unknown to the validating resolver + SHOULD be ignored during the creation of the trust anchors. + + +4.1.2 Distribution of priming keys + + + The public parts of the priming keys SHOULD be distributed + exclusively through out-of-DNS mechanisms. The requirements for a + distribution mechanism are: + o it can carry the "validity" period for the priming keys; + o it can carry the self-signature of the priming keys; + o and it allows for verification using trust relations outside the + DNS. + A distribution mechanism would benefit from: + o the availability of revocation lists; + o the ability of carrying zone owners policy information such as + recommended values for "M" and "N" and a rollover frequency; + o and the technology on which is based is readily available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 15] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +5. The Threshold Rollover Mechanism vs Priming + + + There is overlap between the threshold-based trust updater and the + Priming method. One could exclusively use the Priming method for + maintaining the trust anchors. However the priming method probably + relies on "non-DNS' technology and may therefore not be available for + all devices that have a resolver. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 16] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +6. Security Considerations + + +6.1 Threshold-based Trust Update Security Considerations + + + A clear issue for resolvers will be how to ensure that they track all + rollover events for the zones they have configure trust anchors for. + Because of temporary outages validating resolvers may have missed a + rollover of a KSK. The parameters that determine the robustness + against failures are: the length of the period between rollovers + during which the KSK set is stable and validating resolvers can + actually notice the change; the number of available KSKs (i.e. N) + and the number of signatures that may fail to validate (i.e. N-M). + + + With a large N (i.e. many KSKs) and a small value of M this + operation becomes more robust since losing one key, for whatever + reason, will not be crucial. Unfortunately the choice for the number + of KSKs is a local policy issue for the zone owner while the choice + for the parameter M is a local policy issue for the resolver + administrator. + + + Higher values of M increase the resilience against attacks somewhat; + more signatures need to verify for a rollover to be approved. On the + other hand the number of rollover events that may pass unnoticed + before the resolver reaches the UNSYNCABLE state goes down. + + + The threshold-based trust update intentionally does not provide a + revocation mechanism. In the case that a sufficient number of + private keys of a zone owner are simultaneously compromised the the + attacker may use these private keys to roll the trust anchors of (a + subset of) the resolvers. This is obviously a bad situation but it + is not different from most other public keys systems. + + + However, it is important to point out that since any reasonable trust + anchor rollover policy (in validating resolvers) will require more + than one RRSIG to validate this proposal does provide security + concious zone administrators with the option of not storing the + individual private keys in the same location and thereby decreasing + the likelihood of simultaneous compromise. + + +6.2 Priming Key Security Considerations + + + Since priming keys are not included in the DNSKEY RR set they are + less sensitive to packet size constraints and can be chosen + relatively large. The private parts are only needed to sign the + DNSKEY RR set during the validity period of the particular priming + key pair. Note that the private part of the priming key is used each + time when a DNSKEY RRset has to be resigned. In practice there is + therefore little difference between the usage pattern of the private + + + + +Ihren, et al. Expires April 18, 2005 [Page 17] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + part of key signing keys and priming keys. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 18] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +7. IANA Considerations + + + NONE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 19] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +8. References + + +8.1 Normative References + + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + + [3] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-10 (work in progress), + September 2004. + + +8.2 Informative References + + + [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-12 (work in progress), September + 2004. + + + [5] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-01 (work in + progress), May 2004. + + + [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and CRL Profile", RFC + 2459, January 1999. + + + +Authors' Addresses + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + + EMail: johani@autonomica.se + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 20] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + + Bill Manning + EP.net + Marina del Rey, CA 90295 + USA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 21] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix A. Acknowledgments + + + The present design for in-band automatic rollovers of DNSSEC trust + anchors is the result of many conversations and it is no longer + possible to remember exactly who contributed what. + + + In addition we've also had appreciated help from (in no particular + order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt + Larson and Mark Kosters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 22] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix B. Document History + + + This appendix will be removed if and when the document is submitted + to the RFC editor. + + + The version you are reading is tagged as $Revision: 1.1.232.1 $. + + + Text between square brackets, other than references, are editorial + comments and will be removed. + + +B.1 prior to version 00 + + + This draft was initially published as a personal submission under the + name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. + + + Kolkman documented the ideas provided by Ihren and Manning. In the + process of documenting (and prototyping) Kolkman changed some of the + details of the M-N algorithms working. Ihren did not have a chance + to review the draft before Kolkman posted; + + + Kolkman takes responsibilities for omissions, fuzzy definitions and + mistakes. + + +B.2 version 00 + o The name of the draft was changed as a result of the draft being + adopted as a working group document. + o A small section on the concept of stale trust anchors was added. + o The different possible states are more clearly defined, including + examples of transitions between states. + o The terminology is changed throughout the document. The old term + "M-N" is replaced by "threshold" (more or less). Also the + interpretation of the constants M and N is significantly + simplified to bring the usage more in line with "standard" + threshold terminlogy. + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 23] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Ihren, et al. Expires April 18, 2005 [Page 24]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt new file mode 100644 index 000000000000..df702b41ec98 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt @@ -0,0 +1,730 @@ + + + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: February 16, 2006 August 15, 2005 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 February 16, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + management behavior (but not resolver resolution behavior), and the + + + +StJohns Expires February 16, 2006 [Page 1] + +Internet-Draft trustanchor-update August 2005 + + + addition of a single flag bit to the DNSKEY record. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 + 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 2] + +Internet-Draft trustanchor-update August 2005 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the + community has come to the realization that there will not be one + signed name space, but rather islands of signed name space each + originating from specific points (i.e. 'trust points') in the DNS + tree. Each of those islands will be identified by the trust point + name, and validated by at least one associated public key. For the + purpose of this document we'll call the association of that name and + a particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key replacement/ + rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1 Compliance Nomenclature + + 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 BCP 14, [RFC2119]. + +1.2 Changes since -00 + + Added the concept of timer triggered resolver queries to refresh the + + + +StJohns Expires February 16, 2006 [Page 3] + +Internet-Draft trustanchor-update August 2005 + + + resolvers view of the trust anchor key RRSet. + + Re-submitted expired draft as -01. Updated DNSSEC RFC References. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1 Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a self- + signed RRSet and the key has the REVOKE bit set to '1'. Once the + resolver sees the REVOKE bit, it MUST NOT use this key as a trust + anchor or for any other purposes except validating the RRSIG over the + DNSKEY RRSet specifically for the purpose of validating the + revocation. Unlike the 'Add' operation below, revocation is + immediate and permanent upon receipt of a valid revocation at the + resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + +2.2 Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + + + +StJohns Expires February 16, 2006 [Page 4] + +Internet-Draft trustanchor-update August 2005 + + + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a hold- + down time to the addition of the trust anchor. When the resolver + sees a new SEP key in a validated trust point DNSKEY RRSet, the + resolver starts an acceptance timer, and remembers all the keys that + validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3 Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + hasn't reappeared, SHOULD discard any information about the key. + + + + + +StJohns Expires February 16, 2006 [Page 5] + +Internet-Draft trustanchor-update August 2005 + + +2.4 Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5 Resolver Parameters + +2.5.1 Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2 Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3 Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + + + +StJohns Expires February 16, 2006 [Page 6] + +Internet-Draft trustanchor-update August 2005 + + + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + +4.1 Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + +4.2 States + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + + + + + +StJohns Expires February 16, 2006 [Page 7] + +Internet-Draft trustanchor-update August 2005 + + + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some + period of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1 Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + 1. Generate a new key pair. + + + + + +StJohns Expires February 16, 2006 [Page 8] + +Internet-Draft trustanchor-update August 2005 + + + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2 Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3 Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4 Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + +5.5 Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + included in the RRSet for the remove hold-down time. + + + +StJohns Expires February 16, 2006 [Page 9] + +Internet-Draft trustanchor-update August 2005 + + +6. Security Considerations + +6.1 Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +6.2 Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +6.3 Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + + +StJohns Expires February 16, 2006 [Page 10] + +Internet-Draft trustanchor-update August 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. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + Email: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 11] + +Internet-Draft trustanchor-update August 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + + + +StJohns Expires February 16, 2006 [Page 12] + +Internet-Draft trustanchor-update August 2005 + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 13] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt new file mode 100644 index 000000000000..a59595f5901d --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt @@ -0,0 +1,580 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +UPDATES RFC 2845 Motorola Laboratories +Expires: December 2005 June 2005 + + + HMAC SHA TSIG Algorithm Identifiers + ---- --- ---- --------- ----------- + <draft-ietf-dnsext-tsig-sha-04.txt> + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + Use of the TSIG DNS resource record requires specification of a + cryptographic message authentication code. Currently identifiers + have been specified only for the HMAC-MD5 and GSS TSIG algorithms. + This document standardizes identifiers and implementation + requirements for additional HMAC SHA TSIG algorithms and standardizes + how to specify and handle the truncation of HMAC values. + + +Copyright Notice + + Copyright (C) The Internet Society 2005. All Rights Reserved. + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + + 2. Algorithms and Identifiers..............................4 + + 3. Specifying Truncation...................................5 + 3.1 Truncation Specification...............................5 + + 4. TSIG Policy Provisions and Truncation Error.............7 + + 5. IANA Considerations.....................................8 + 6. Security Considerations.................................8 + 6. Copyright and Disclaimer................................8 + + 7. Normative References....................................9 + 8. Informative References..................................9 + + Author's Address..........................................10 + Expiration and File Name..................................10 + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +1. Introduction + + [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to + authenticate DNS queries and responses. This RR contains a domain + name syntax data item which names the authentication algorithm used. + [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for + authentication codes using the HMAC [RFC 2104] algorithm with the MD5 + [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an + identifier for TSIG authentication where the cryptographic operations + are delegated to GSS [RFC 3645]. + + In Section 2, this document specifies additional names for TSIG + authentication algorithms based on US NIST SHA algorithms and HMAC + and specifies the implementation requirements for those algorithms. + + In Section 3, this document specifies the meaning of inequality + between the normal output size of the specified hash function and the + length of MAC (message authentication code) data given in the TSIG + RR. In particular, it specifies that a shorter length field value + specifies truncation and a longer length field is an error. + + In Section 4, policy restrictions and implications related to + truncation and a new error code to indicate truncation shorter than + permitted by policy are described and specified. + + The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as + defined in [RFC 2119]. + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +2. Algorithms and Identifiers + + TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS + queries and responses. They are intended to be efficient symmetric + authentication codes based on a shared secret. (Asymmetric signatures + can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) + can be used for transaction signatures.) Used with a strong hash + function, HMAC [RFC 2104] provides a way to calculate such symmetric + authentication codes. The only specified HMAC based TSIG algorithm + identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. + + The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as + compared with the 128 bits for MD5, and additional hash algorithms in + the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, + and 512 bits, may be preferred in some cases particularly since + increasingly successful cryptanalytic attacks are being made on the + shorter hashes. Use of TSIG between a DNS resolver and server is by + mutual agreement. That agreement can include the support of + additional algorithms and may specify policies as to which algorithms + and truncations are acceptable subject to the restrication and + guidelines in Section 3 and 4 below. + + The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the + table below for convenience. Implementations which support TSIG MUST + also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig + and the other algorithms listed below. + + Mandatory HMAC-MD5.SIG-ALG.REG.INT + Mandatory hmac-sha1 + Optional hmac-sha224 + Mandatory hmac-sha256 + Optional hamc-sha384 + Optional hmac-sha512 + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +3. Specifying Truncation + + When space is at a premium and the strength of the full length of an + HMAC is not needed, it is reasonable to truncate the HMAC output and + use the truncated value for authentication. HMAC SHA-1 truncated to + 96 bits is an option available in several IETF protocols including + IPSEC and TLS. + + The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the + size of the MAC field in octets. But [RFC 2845] does not specify what + to do if this MAC size differs from the length of the output of HMAC + for a particular hash function. Truncation is indicated by a MAC size + less than the HMAC size as specified below. + + + +3.1 Truncation Specification + + The specification for TSIG handling is changed as follows: + + 1. If "MAC size" field is greater than HMAC output length: + This case MUST NOT be generated and if received MUST cause the + packet to be dropped and RCODE 1 (FORMERR) to be returned. + + 2. If "MAC size" field equals HMAC output length: + Operation is as described in [RFC 2845] with the entire output + HMAC output present. + + 3. "MAC size" field is less than HMAC output length but greater than + that specified in case 4 below: + This is sent when the signer has truncated the HMAC output to + an allowable length, as described in RFC 2104, taking initial + octets and discarding trailing octets. TSIG truncation can only be + to an integral number of octets. On receipt of a packet with + truncation thus indicated, the locally calculated MAC is similarly + truncated and only the truncated values compared for + authentication. The request MAC used when calculating the TSIG MAC + for a reply is the trucated request MAC. + + 4. "MAC size" field is less than the larger of 10 (octets) and half + the length of the hash function in use: + With the exception of certain TSIG error messages described in + RFC 2845 section 3.2 where it is permitted that the MAC size be + zero, this case MUST NOT be generated and if received MUST cause + the packet to be dropped and RCODE 1 (FORMERR) to be returned. The + size limit for this case can also, for the hash functions + mentioned in this document, be stated as less than half the hash + function length for hash functions other than MD5 and less than 10 + octets for MD5. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + + SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +4. TSIG Policy Provisions and Truncation Error + + Use of TSIG is by mutual agreement between a resolver and server. + Implicit in such "agreement" are policies as to acceptable keys and + algorithms and, with the extensions in this doucment, truncations. In + particular note the following: + + Such policies MAY require the rejection of TSIGs even though they + use an algorithm for which implementation is mandatory. + + When a policy calls for the acceptance of a TSIG with a particular + algorithm and a particular non-zero amount of trunction it SHOULD + also permit the use of that algorithm with lesser truncation (a + longer MAC) up to the full HMAC output. + + Regardless of a lower acceptable truncated MAC length specified by + policy, a reply SHOULD be sent with a MAC at least as long as that in + the corresponding request unless the request specified a MAC length + longer than the HMAC output. + + Implementations permitting policies with multiple acceptable + algorithms and/or truncations SHOULD permit this list to be ordered + by presumed strength and SHOULD allow different truncations for the + same algorithm to be treatred as spearate entities in this list. When + so implemented, policies SHOULD accept a presumed stronger algorithm + and truncation than the minimum strength required by the policy. + + If a TSIG is received with truncation which is permitted under + Section 3 above but the MAC is too short for the policy in force, an + RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +5. IANA Considerations + + This document, on approval for publication as a standards track RFC, + (1) registers the new TSIG algorithm identifiers listed in Section 2 + with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22 + suggested]. + + + + +6. Security Considerations + + For all of the message authentication code algorithms listed herein, + those producing longer values are believed to be stronger; however, + while there have been some arguments that mild truncation can + strengthen a MAC by reducing the information available to an + attacker, excessive truncation clearly weakens authentication by + reducing the number of bits an attacker has to try to brute force + [RFC 2104]. + + Significant progress has been made recently in cryptanalysis of hash + function of the type used herein, all of which ultimately derive from + the design of MD4. While the results so far should not effect HMAC, + the stronger SHA-1 and SHA-256 algorithms are being made mandatory + due to caution. + + See the Security Considerations section of [RFC 2845]. See also the + Security Considerations section of [RFC 2104] from which the limits + on truncation in this RFC were taken. + + + +6. Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +7. Normative References + + [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change Notice 1, + February 2004. + + [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February 1997. + + [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + + +8. Informative References. + + [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction + Signatures ( SIG(0)s )", RFC 2931, September 2000. + + [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, + J., and R. Hall, "Generic Security Service Algorithm for Secret Key + Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October + 2003. + + [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", + September 2004, + + [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms + (SHA)", work in progress. + + + + + + + + + + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in December 2005. + + Its file name is draft-ietf-dnsext-tsig-sha-04.txt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt new file mode 100644 index 000000000000..fad88aedaba9 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt @@ -0,0 +1,956 @@ +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: January 6, 2006 July 6, 2005 +Updates RFC 1034, RFC 2672 + + The Role of Wildcards + in the Domain Name System + draft-ietf-dnsext-wcard-clarify-08.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that + any applicable patent or other IPR claims of which he or she is + aware have been or will be disclosed, and any of which he or she + becomes aware will be disclosed, in accordance with Section 6 of + 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 January 6, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error + condition removed, and the words defining some concepts central + to wildcards are changed. The overall goal is not to change + wildcards, but to refine the definition of RFC 1034. + +Table of Contents + +1. Introduction +1.1 Motivation +1.2 The Original Definition +1.3 Roadmap to This Document +1.3.1 New Terms +1.3.2 Changed Text +1.3.3 Considerations with Special Types +1.4 Standards Terminology +2. Wildcard Syntax +2.1 Identifying a Wildcard +2.1.1 Wild Card Domain Name and Asterisk Label +2.1.2 Asterisks and Other Characters +2.1.3 Non-terminal Wild Card Domain Names +2.2 Existence Rules +2.2.1 An Example +2.2.2 Empty Non-terminals +2.2.3 Yet Another Definition of Existence +2.3 When is a Wild Card Domain Name Not Special +3. Impact of a Wild Card Domain Name On a Response +3.1 Step 2 +3.2 Step 3 +3.3 Part 'c' +3.3.1 Closest Encloser and the Source of Synthesis +3.3.2 Closest Encloser and Source of Synthesis Examples +3.3.3 Type Matching +4. Considerations with Special Types +4.1 SOA RRSet at a Wild Card Domain Name +4.2 NS RRSet at a Wild Card Domain Name +4.2.1 Discarded Notions +4.3 CNAME RRSet at a Wild Card Domain Name +4.4 DNAME RRSet at a Wild Card Domain Name +4.5 SRV RRSet at a Wild Card Domain Name +4.6 DS RRSet at a Wild Card Domain Name +4.7 NSEC RRSet at a Wild Card Domain Name +4.8 RRSIG at a Wild Card Domain Name +4.9 Empty Non-terminal Wild Card Domain Name +5. Security Considerations +6. IANA Considerations +7. References +8. Editor +9. Others Contributing to the Document +10. Trailing Boilerplate + +1. Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the + synthesis of answers from special resource records called + wildcards. The definition in RFC 1034 is incomplete and has + proven to be confusing. This document describes the wildcard + synthesis by adding to the discussion and making limited + modifications. Modifications are made to close inconsistencies + that have led to interoperability issues. This description + does not expand the service intended by the original definition. + + Staying within the spirit and style of the original documents, + this document avoids specifying rules for DNS implementations + regarding wildcards. The intention is to only describe what is + needed for interoperability, not restrict implementation choices. + In addition, consideration is given to minimize any backwards + compatibility issues with implementations that comply with RFC + 1034's definition. + + This document is focused on the concept of wildcards as defined + in RFC 1034. Nothing is implied regarding alternative means of + synthesizing resource record sets, nor are alternatives discussed. + +1.1 Motivation + + Many DNS implementations diverge, in different ways, from the + original definition of wildcards. Although there is clearly a + need to clarify the original documents in light of this alone, + the impetus for this document lay in the engineering of the DNS + security extensions [RFC4033]. With an unclear definition of + wildcards the design of authenticated denial became entangled. + + This document is intended to limit its changes, documenting only + those based on implementation experience, and to remain as close + to the original document as possible. To reinforce that this + document is meant to clarify and adjust and not redefine wildcards, + relevant sections of RFC 1034 are repeated verbatim to facilitate + comparison of the old and new text. + +1.2 The Original Definition + + The defintion of the wildcard concept is comprised by the + documentation of the algorithm by which a name server prepares + a response (in RFC 1034's section 4.3.2) and the way in which + a resource record (set) is identified as being a source of + synthetic data (section 4.3.3). + + This is the definition of the term "wildcard" as it appears in + RFC 1034, section 4.3.3. + +# In the previous algorithm, special treatment was given to RRs with +# owner names starting with the label "*". Such RRs are called +# wildcards. Wildcard RRs can be thought of as instructions for +# synthesizing RRs. When the appropriate conditions are met, the name +# server creates RRs with an owner name equal to the query name and +# contents taken from the wildcard RRs. + + This passage follows the algorithm in which the term wildcard + is first used. In this definition, wildcard refers to resource + records. In other usage, wildcard has referred to domain names, + and it has been used to describe the operational practice of + relying on wildcards to generate answers. It is clear from this + that there is a need to define clear and unambiguous terminology + in the process of discussing wildcards. + + The mention of the use of wildcards in the preparation of a + response is contained in step 3c of RFC 1034's section 4.3.2 + entitled "Algorithm." Note that "wildcard" does not appear in + the algorithm, instead references are made to the "*" label. + The portion of the algorithm relating to wildcards is + deconstructed in detail in section 3 of this document, this is + the beginning of the relevant portion of the "Algorithm." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if [...] +# the "*" label exists. + + The scope of this document is the RFC 1034 definition of + wildcards and the implications of updates to those documents, + such as DNSSEC. Alternate schemes for synthesizing answers are + not considered. (Note that there is no reference listed. No + document is known to describe any alternate schemes, although + there has been some mention of them in mailing lists.) + +1.3 Roadmap to This Document + + This document accomplishes these three items. + o Defines new terms + o Makes minor changes to avoid conflicting concepts + o Describes the actions of certain resource records as wildcards + +1.3.1 New Terms + + To help in discussing what resource records are wildcards, two + terms will be defined - "asterisk label" and "wild card domain + name". These are defined in section 2.1.1. + + To assist in clarifying the role of wildcards in the name server + algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest + encloser" are defined. These definitions are in section 3.3.2. + "Label match" is defined in section 3.2. + + The new terms are used to make discussions of wildcards clearer. + Terminology doesn't directly have an impact on implementations. + +1.3.2 Changed Text + + The definition of "existence" is changed superficially. This + change will not be apparent to implementations; it is needed to + make descriptions more precise. The change appears in section + 2.2.3. + + RFC 1034, section 4.3.3., seems to prohibit having two asterisk + labels in a wildcard owner name. With this document the + restriction is removed entirely. This change and its implications + are in section 2.1.3. + + The actions when a source of synthesis owns a CNAME RR are + changed to mirror the actions if an exact match name owns a + CNAME RR. This is an addition to the words in RFC 1034, + section 4.3.2, step 3, part c. The discussion of this is in + section 3.3.3. + + Only the latter change represents an impact to implementations. + The definition of existence is not a protocol impact. The change + to the restriction on names is unlikely to have an impact, as + RFC 1034 contained no specification on when and how to enforce the + restriction. + +1.3.3 Considerations with Special Types + + This document describes semantics of wildcard RRSets for + "interesting" types as well as empty non-terminal wildcards. + Understanding these situations in the context of wildcards has + been clouded because these types incur special processing if + they are the result of an exact match. This discussion is in + section 4. + + These discussions do not have an implementation impact, they cover + existing knowledge of the types, but to a greater level of detail. + +1.4 Standards Terminology + + This document does not use terms as defined in "Key words for use + in RFCs to Indicate Requirement Levels." [RFC2119] + + Quotations of RFC 1034 are denoted by a '#' in the leftmost + column. References to section "4.3.2" are assumed to refer + to RFC 1034's section 4.3.2, simply titled "Algorithm." + +2. Wildcard Syntax + + The syntax of a wildcard is the same as any other DNS resource + record, across all classes and types. The only significant + feature is the owner name. + + Because wildcards are encoded as resource records with special + names, they are included in zone transfers and incremental zone + transfers[RFC1995] just as non-wildcard resource records are. + This feature has been underappreciated until discussions on + alternative approaches to wildcards appeared on mailing lists. + +2.1 Identifying a Wildcard + + To provide a more accurate description of wildcards, the + definition has to start with a discussion of the domain names + that appear as owners. Two new terms are needed, "Asterisk + Label" and "Wild Card Domain Name." + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "wild card domain name" is defined by having its initial + (i.e., left-most or least significant) label be, in binary format: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC20] + for the '*' character. + + A descriptive name of a label equaling that value is an "asterisk + label." + + RFC 1034's definition of wildcard would be "a resource record + owned by a wild card domain name." + +2.1.2 Asterisks and Other Characters + + No label values other than that in section 2.1.1 are asterisk + labels, hence names beginning with other labels are never wild + card domain names. Labels such as 'the*' and '**' are not + asterisk labels so these labels do not start wild card domain + names. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.<anydomain>", where <anydomain> is any domain name. +# <anydomain> should not contain other * labels...................... + + The restriction is now removed. The original documentation of it + is incomplete and the restriction does not serve any purpose given + years of operational experience. + + There are three possible reasons for putting the restriction in + place, but none of the three has held up over time. One is + that the restriction meant that there would never be subdomains + of wild card domain names, but the restriciton as stated still + permits "example.*.example." for instance. Another is that + wild card domain names are not intended to be empty non-terminals, + but this situation does not disrupt the algorithm in 4.3.2. + Finally, "nested" wild card domain names are not ambiguous once + the concept of the closest encloser had been documented. + + A wild card domain name can have subdomains. There is no need + to inspect the subdomains to see if there is another asterisk + label in any subdomain. + + A wild card domain name can be an empty non-terminal. (See the + upcoming sections on empty non-terminals.) In this case, any + lookup encountering it will terminate as would any empty + non-terminal match. + +2.2 Existence Rules + + The notion that a domain name 'exists' is mentioned in the + definition of wildcards. In section 4.3.3 of RFC 1034: + +# Wildcard RRs do not apply: +# +... +# - When the query name or a name between the wildcard domain and +# the query name is know[n] to exist. For example, if a wildcard + + "Existence" is therefore an important concept in the understanding + of wildcards. Unfortunately, the definition of what exists, in RFC + 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is + taken at the definition of existence. + +2.2.1 An Example + + To illustrate what is meant by existence consider this complete + zone: + + $ORIGIN example. + example. 3600 IN SOA <SOA RDATA> + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wild card" + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> + _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | | + | | | + sub _tcp _tcp + | | + | | + _ssh _ssh + + The following responses would be synthesized from one of the + wildcards in the zone: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard + does. + + The following responses would not be synthesized from any of the + wildcards in the zone: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=sub.*.example., QTYPE=MX, QCLASS=IN + because sub.*.example. exists + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + The final example highlights one common misconception about + wildcards. A wildcard "blocks itself" in the sense that a + wildcard does not match its own subdomains. I.e. "*.example." + does not match all names in the "example." zone, it fails to + match the names below "*.example." To cover names under + "*.example.", another wild card domain name is needed - + "*.*.example." - which covers all but it's own subdomains. + +2.2.2 Empty Non-terminals + + Empty non-terminals [RFC2136, Section 7.16] are domain names + that own no resource records but have subdomains that do. In + section 2.2.1, "_tcp.host1.example." is an example of a empty + non-terminal name. Empty non-terminals are introduced by this + text in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on +# the tree corresponds to a resource set (which may be empty). The +# domain system makes no distinctions between the uses of the +# interior nodes and leaves, and this memo uses the term "node" to +# refer to both. + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized, and that empty non-terminals + "exist." + + Pedantically reading the above paragraph can lead to an + interpretation that all possible domains exist - up to the + suggested limit of 255 octets for a domain name [RFC1035]. + For example, www.example. may have an A RR, and as far as is + practically concerned, is a leaf of the domain tree. But the + definition can be taken to mean that sub.www.example. also + exists, albeit with no data. By extension, all possible domains + exist, from the root on down. + + As RFC 1034 also defines "an authoritative name error indicating + that the name does not exist" in section 4.3.1, so this apparently + is not the intent of the original definition, justifying the + need for an updated definition in the next section. + +2.2.3 Yet Another Definition of Existence + + RFC1034's wording is fixed by the following paragraph: + + The domain name space is a tree structure. Nodes in the tree + either own at least one RRSet and/or have descendants that + collectively own at least one RRSet. A node may exist with no + RRSets only if it has descendents that do, this node is an empty + non-terminal. + + A node with no descendants is a leaf node. Empty leaf nodes do + not exist. + + Note that at a zone boundary, the domain name owns data, + including the NS RR set. In the delegating zone, the NS RR + set is not authoritative, but that is of no consequence here. + The domain name owns data, therefore, it exists. + +2.3 When is a Wild Card Domain Name Not Special + + When a wild card domain name appears in a message's query section, + no special processing occurs. An asterisk label in a query name + only matches a single, corresponding asterisk label in the + existing zone tree when the 4.3.2 algorithm is being followed. + + When a wild card domain name appears in the resource data of a + record, no special processing occurs. An asterisk label in that + context literally means just an asterisk. + +3. Impact of a Wild Card Domain Name On a Response + + RFC 1034's description of how wildcards impact response + generation is in its section 4.3.2. That passage contains the + algorithm followed by a server in constructing a response. + Within that algorithm, step 3, part 'c' defines the behavior of + the wildcard. + + The algorithm in section 4.3.2. is not intended to be pseudo-code, + i.e., its steps are not intended to be followed in strict order. + The "algorithm" is a suggested means of implementing the + requirements. As such, in step 3, parts a, b, and c, do not have + to be implemented in that order, provided that the result of the + implemented code is compliant with the protocol's specification. + +3.1 Step 2 + + Step 2 of the section 4.3.2 reads: + +# 2. Search the available zones for the zone which is the nearest +# ancestor to QNAME. If such a zone is found, go to step 3, +# otherwise step 4. + + In this step, the most appropriate zone for the response is + chosen. The significance of this step is that it means all of + step 3 is being performed within one zone. This has significance + when considering whether or not an SOA RR can be ever be used for + synthesis. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. + But the beginning of the step is important and needs explanation. + +# 3. Start matching down, label by label, in the zone. The +# matching process can terminate several ways: + + The word 'matching' refers to label matching. The concept + is based in the view of the zone as the tree of existing names. + The query name is considered to be an ordered sequence of + labels - as if the name were a path from the root to the owner + of the desired data. (Which it is - 3rd paragraph of RFC 1034, + section 3.1.) + + The process of label matching a query name ends in exactly one of + three choices, the parts 'a', 'b', and 'c'. Either the name is + found, the name is below a cut point, or the name is not found. + + Once one of the parts is chosen, the other parts are not + considered. (E.g., do not execute part 'c' and then change + the execution path to finish in part 'b'.) The process of label + matching is also done independent of the query type (QTYPE). + + Parts 'a' and 'b' are not an issue for this clarification as they + do not relate to record synthesis. Part 'a' is an exact match + that results in an answer, part 'b' is a referral. + +3.3 Part 'c' + + The context of part 'c' is that the process of label matching the + labels of the query name has resulted in a situation in which + there is no corresponding label in the tree. It is as if the + lookup has "fallen off the tree." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if [...] +# the "*" label exists. + + To help describe the process of looking 'to see if [...] the "*" + label exists' a term has been coined to describe the last domain + (node) matched. The term is "closest encloser." + +3.3.1 Closest Encloser and the Source of Synthesis + + The closest encloser is the node in the zone's tree of existing + domain names that has the most labels matching the query name + (consecutively, counting from the root label downward). Each match + is a "label match" and the order of the labels is the same. + + The closest encloser is, by definition, an existing name in the + zone. The closest encloser might be an empty non-terminal or even + be a wild card domain name itself. In no circumstances is the + closest encloser to be used to synthesize records for the current + query. + + The source of synthesis is defined in the context of a query + process as that wild card domain name immediately descending + from the closest encloser, provided that this wild card domain + name exists. "Immediately descending" means that the source + of synthesis has a name of the form: + <asterisk label>.<closest encloser>. + A source of synthesis does not guarantee having a RRSet to use + for synthesis. The source of synthesis could be an empty + non-terminal. + + If the source of synthesis does not exist (not on the domain + tree), there will be no wildcard synthesis. There is no search + for an alternate. + + The important concept is that for any given lookup process, there + is at most one place at which wildcard synthetic records can be + obtained. If the source of synthesis does not exist, the lookup + terminates, the lookup does not look for other wildcard records. + +3.3.2 Closest Encloser and Source of Synthesis Examples + + To illustrate, using the example zone in section 2.2.1 of this + document, the following chart shows QNAMEs and the closest + enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _telnet._tcp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + foobar.*.example. *.example. no source + +3.3.3 Type Matching + + RFC 1034 concludes part 'c' with this: + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. +# +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + The final paragraph covers the role of the QTYPE in the lookup + process. + + Based on implementation feedback and similarities between step + 'a' and step 'c' a change to this passage has been made. + + The change is to add the following text to step 'c' prior to the + instructions to "go to step 6": + + If the data at the source of synthesis is a CNAME, and + QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response changing the owner name + to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + This is essentially the same text in step a covering the + processing of CNAME RRSets. + +4. Considerations with Special Types + + Sections 2 and 3 of this document discuss wildcard synthesis + with respect to names in the domain tree and ignore the impact + of types. In this section, the implication of wildcards of + specific types are discussed. The types covered are those + that have proven to be the most difficult to understand. The + types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and + "none," i.e., empty non-terminal wild card domain names. + +4.1 SOA RRSet at a Wild Card Domain Name + + A wild card domain name owning an SOA RRSet means that the + domain is at the root of the zone (apex). The domain can not + be a source of synthesis because that is, by definition, a + descendent node (of the closest encloser) and a zone apex is + at the top of the zone. + + Although a wild card domain name owning an SOA RRSet can never + be a source of synthesis, there is no reason to forbid the + ownership of an SOA RRSet. + + E.g., given this zone: + $ORIGIN *.example. + @ 3600 IN SOA <SOA RDATA> + 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + www 3600 TXT "the www txt record" + + A query for www.*.example.'s TXT record would still find the + "the www txt record" answer. The reason is that the asterisk + label only becomes significant when section's 4.3.2, step 3 + part 'c' in in effect. + + Of course, there would need to be a delegation in the parent + zone, "example." for this to work too. This is covered in the + next section. + +4.2 NS RRSet at a Wild Card Domain Name + + With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now + in place, the semantics of a wild card domain name owning an + NS RRSet has come to be poorly defined. The dilemma relates to + a conflict between the rules for synthesis in part 'c' and the + fact that the resulting synthesis generates a record for which + the zone is not authoritative. In a DNSSEC signed zone, the + mechanics of signature management (generation and inclusion + in a message) become unclear. + + After some lengthy discussions, there has been no clear "best + answer" on how to document the semantics of such a situation. + Barring such records from the DNS would require definition of + rules for that, as well as introducing a restriction on records + that were once legal. Allowing such records and amending the + process of signature management would entail complicating the + DNSSEC definition. + + There is one more ingredient to the discussion, that being the + utility of a wild card domain name owned NS RRSet. Although + there are cases of this use, it is an operational rarity. + Expending effort to close this topic has proven to be an + exercise in diminishing returns. + + In summary, there is no definition given for wild card domain + names owning an NS RRSet. The semantics are left undefined until + there is a clear need to have a set defined, and until there is + a clear direction to proceed. Operationally, inclusion of wild + card NS RRSets in a zone is discouraged, but not barred. + +4.2.1 Discarded Notions + + Prior to DNSSEC, a wild card domain name owning a NS RRSet + appeared to be workable, and there are some instances in which + it is found in deployments using implementations that support + this. Continuing to allow this in the specificaion is not + tenable with DNSSEC. The reason is that the synthesis of the + NS RRSet is being done in a zone that has delegated away the + responsibility for the name. This "unauthorized" synthesis is + not a problem for the base DNS protocol, but DNSSEC, in affirming + the authorization model for DNS exposes the problem. + + Outright banning of wildcards of type NS is also untenable as + the DNS protocol does not define how to handle "illegal" data. + Implementations may choose not to load a zone, but there is no + protocol definition. The lack of the definition is complicated + by having to cover dynamic update [RFC 2136], zone transfers, + as well as loading at the master server. The case of a client + (resolver, cacheing server) getting a wildcard of type NS in + a reply would also have to be considered. + + Given the daunting challenge of a complete definition of how to + ban such records, dealing with existing implementations that + permit the records today is a further complication. There are + uses of wild card domain name owning NS RRSets. + + One compromise proposed would have redefined wildcards of type + NS to not be used in synthesis, this compromise fell apart + because it would have required significant edits to the DNSSEC + signing and validation work. (Again, DNSSEC catches + unauthorized data.) + + With no clear consensus forming on the solution to this dilemma, + and the realization that wildcards of type NS are a rarity in + operations, the best course of action is to leave this open-ended + until "it matters." + +4.3 CNAME RRSet at a Wild Card Domain Name + + The issue of a CNAME RRSet owned by a wild card domain name has + prompted a suggested change to the last paragraph of step 3c of + the algorithm in 4.3.2. The changed text appears in section + 3.3.3 of this document. + +4.4 DNAME RRSet at a Wild Card Domain Name + + Ownership of a DNAME [RFC2672] RRSet by a wild card domain name + represents a threat to the coherency of the DNS and is to be + avoided or outright rejected. Such a DNAME RRSet represents + non-deterministic synthesis of rules fed to different caches. + As caches are fed the different rules (in an unpredictable + manner) the caches will cease to be coherent. ("As caches + are fed" refers to the storage in a cache of records obtained + in responses by recursive or iterative servers.) + + For example, assume one cache, responding to a recursive + request, obtains the record: + "a.b.example. DNAME foo.bar.example.net." + and another cache obtains: + "b.example. DNAME foo.bar.example.net." + both generated from the record: + "*.example. DNAME foo.bar.example.net." + by an authoritative server. + + The DNAME specification is not clear on whether DNAME records + in a cache are used to rewrite queries. In some interpretations, + the rewrite occurs, in some, it is not. Allowing for the + occurrence of rewriting, queries for "sub.a.b.example. A" may + be rewritten as "sub.foo.bar.tld. A" by the former caching + server and may be rewritten as "sub.a.foo.bar.tld. A" by the + latter. Coherency is lost, an operational nightmare ensues. + + Another justification for banning or avoiding wildcard DNAME + records is the observation that such a record could synthesize + a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." + There is a restriction in the DNAME definition that no domain + exist below a DNAME-owning domain, hence, the wildcard DNAME + is not to be permitted. + +4.5 SRV RRSet at a Wild Card Domain Name + + The definition of the SRV RRset is RFC 2782 [RFC2782]. In the + definition of the record, there is some confusion over the term + "Name." The definition reads as follows: + +# The format of the SRV RR +... +# _Service._Proto.Name TTL Class SRV Priority Weight Port Target +... +# Name +# The domain this RR refers to. The SRV RR is unique in that the +# name one searches for is not this name; the example near the end +# shows this clearly. + + Do not confuse the definition "Name" with the owner name. I.e., + once removing the _Service and _Proto labels from the owner name + of the SRV RRSet, what remains could be a wild card domain name + but this is immaterial to the SRV RRSet. + + E.g., If an SRV record is: + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wild card domain name and although it it the Name + of the SRV RR, it is not the owner (domain name). The owner + domain name is "_foo._udp.*.example." which is not a wild card + domain name. + + The confusion is likely based on the mixture of the specification + of the SRV RR and the description of a "use case." + +4.6 DS RRSet at a Wild Card Domain Name + + A DS RRSet owned by a wild card domain name is meaningless and + harmless. This statement is made in the context that an NS RRSet + at a wild card domain name is undefined. At a non-delegation + point, a DS RRSet has no value (no corresponding DNSKEY RRSet + will be used in DNSSEC validation). If there is a synthesized + DS RRSet, it alone will not be very useful as it exists in the + context of a delegation point. + +4.7 NSEC RRSet at a Wild Card Domain Name + + Wild card domain names in DNSSEC signed zones will have an NSEC + RRSet. Synthesis of these records will only occur when the + query exactly matches the record. Synthesized NSEC RR's will not + be harmful as they will never be used in negative caching or to + generate a negative response. + +4.8 RRSIG at a Wild Card Domain Name + + RRSIG records will be present at a wild card domain name in a + signed zone, and will be synthesized along with data sought in a + query. The fact that the owner name is synthesized is not a + problem as the label count in the RRSIG will instruct the + verifying code to ignore it. + +4.9 Empty Non-terminal Wild Card Domain Name + + If a source of synthesis is an empty non-terminal, then the + response will be one of no error in the return code and no RRSet + in the answer section. + +5. Security Considerations + + This document is refining the specifications to make it more + likely that security can be added to DNS. No functional + additions are being made, just refining what is considered + proper to allow the DNS, security of the DNS, and extending + the DNS to be more predictable. + +6. IANA Considerations + + None. + +7. References + + Normative References + + [RFC20] ASCII Format for Network Interchange, V.G. Cerf, + Oct-16-1969 + + [RFC1034] Domain Names - Concepts and Facilities, + P.V. Mockapetris, Nov-01-1987 + + [RFC1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 + + [RFC2119] Key Words for Use in RFCs to Indicate Requirement + Levels, S Bradner, March 1997 + + [RFC2181] Clarifications to the DNS Specification, R. Elz and + R. Bush, July 1997 + + [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), + M. Andrews, March 1998 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, + August 1999. + + [RFC2782] A DNS RR for specifying the location of services (DNS + SRV), A. Gulbrandsen, et.al., February 2000 + + [RFC4033] DNS Security Introduction and Requirements, R. Arends, + et.al., March 2005 + + [RFC4034] Resource Records for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + [RFC4035] Protocol Modifications for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, + August 1999 + + Informative References + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + April 1997 + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US + Phone: +1-571-434-5468 + Email: ed.lewis@neustar.biz + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Others Contributing to the Document + + This document represents the work of a large working group. The + editor merely recorded the collective wisdom of the working group. + +10. Trailing Boilerplate + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION + HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET + SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO + ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT + INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of + any Intellectual Property Rights or other rights that might + be claimed to pertain to the implementation or use of the + technology described in this document or the extent to which + any license under such rights might or might not be available; + nor does it represent that it has made any independent effort + to identify any such rights. Information on the procedures + with respect to rights in RFC documents can be found in BCP 78 + and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the + use of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR + repository at http://www.ietf.org/ipr. The IETF invites any + interested party to bring to its attention any copyrights, + patents or patent applications, or other proprietary rights + that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +Expiration + + This document expires on or about January 6, 2006. diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt new file mode 100644 index 000000000000..a56969e57f66 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt @@ -0,0 +1,1176 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: January 18, 2006 VeriSign + July 17, 2005 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-04 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 January 18, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + + + +Larson & Barber Expires January 18, 2006 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + 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 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . 5 + 2.1 Aggressive requerying for delegation information . . . . . 5 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 7 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3 Inability to follow multiple levels of indirection . . . . 8 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 9 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 10 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 11 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 12 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 13 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.9 Queries for domain names resembling IPv4 addresses . . . . 14 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . 15 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 15 + 2.11 Suboptimal name server selection algorithm . . . . . . . 15 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 16 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 17 + 4. Security considerations . . . . . . . . . . . . . . . . . . 18 + 5. Internationalization considerations . . . . . . . . . . . . 19 + 6. Informative References . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . 21 + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question (<QNAME, QTYPE, QCLASS>) asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + +1.1 A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + + + +Larson & Barber Expires January 18, 2006 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +2. Observed iterative resolver misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + + + +Larson & Barber Expires January 18, 2006 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [3], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1 Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + + + +Larson & Barber Expires January 18, 2006 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + + 1. is not authoritative for the zone (i.e., lame), or, + + 2. returns a server failure response (RCODE=2), or, + + 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. + + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1 Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple <zone name, class, server IP address>. Zone + name can be derived from the owner name of the NS record that was + + + +Larson & Barber Expires January 18, 2006 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + referenced to query the name server that was discovered to be lame. + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers based on a time interval from + when the server is discovered to be lame. A minimum interval of + thirty minutes is RECOMMENDED. + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates it should be authoritative for that zone. + +2.3 Inability to follow multiple levels of indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + + + + + +Larson & Barber Expires January 18, 2006 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + + + +Larson & Barber Expires January 18, 2006 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + prevents it from receiving responses. If this is the case, all glue- + fetching queries will go answered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + + + +Larson & Barber Expires January 18, 2006 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + servers, which could explain how such a situation could persist + without being detected. + +2.5.1 Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus the "example.com" NS RRset just received + from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + + + +Larson & Barber Expires January 18, 2006 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + + + +Larson & Barber Expires January 18, 2006 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, non- + + + +Larson & Barber Expires January 18, 2006 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1 Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9 Queries for domain names resembling IPv4 addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + + + +Larson & Barber Expires January 18, 2006 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project [8], + which are currently delegated the in-addr.arpa zones corresponding to + RFC 1918 [7] private use address space, would be a possible choice to + receive these delegations. Of course, the proper and usual root zone + change procedures would have to be followed to make such a change to + the root zone. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use + name servers that do not offer recursion, but we are not aware of any + stub resolver implementation that offers any feedback to the user + when so configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + + +Larson & Barber Expires January 18, 2006 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for "a.gtld- + servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +3. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +4. Security considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional denial of service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +5. Internationalization considerations + + There are no new internationalization considerations introduced by + this memo. + +6. Informative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, + RFC 1918, February 1996. + + [8] <http://www.as112.net> + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + Email: mlarson@verisign.com + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + Email: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires January 18, 2006 [Page 20] + +Internet-Draft Observed DNS Resolution Misbehavior July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Larson & Barber Expires January 18, 2006 [Page 21] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt new file mode 100644 index 000000000000..a5d0d6079a70 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt @@ -0,0 +1,1736 @@ + + + +DNSOP O. Kolkman +Internet-Draft RIPE NCC +Expires: September 2, 2005 R. Gieben + NLnet Labs + March 2005 + + + DNSSEC Operational Practices + draft-ietf-dnsop-dnssec-operational-practices-04.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 September 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a set of practices for operating the DNS with + security extensions (DNSSEC). The target audience is zone + administrators deploying DNSSEC. + + The document discusses operational aspects of using keys and + signatures in the DNS. It discusses issues as key generation, key + storage, signature generation, key rollover and related policies. + + + +Kolkman & Gieben Expires September 2, 2005 [Page 1] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 + 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 + 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 + 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 + 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 + 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6 + 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7 + 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8 + 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 + 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10 + 4. Signature generation, Key Rollover and Related Policies . . . 11 + 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11 + 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13 + 4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17 + 4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18 + 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19 + 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19 + 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20 + 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20 + 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20 + 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21 + 4.4.1 Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . 21 + 4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21 + 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22 + 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25 + B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26 + C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26 + D. Document Details and Changes . . . . . . . . . . . . . . . . . 29 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29 + D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29 + D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29 + D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29 + D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30 + + + +Kolkman & Gieben Expires September 2, 2005 [Page 2] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + Intellectual Property and Copyright Statements . . . . . . . . 31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 3] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +1. Introduction + + During workshops and early operational deployment tests, operators + and system administrators gained experience about operating the DNS + with security extensions (DNSSEC). This document translates these + experiences into a set of practices for zone administrators. At the + time of writing, there exists very little experience with DNSSEC in + production environments; this document should therefore explicitly + not be seen as representing 'Best Current Practices'. + + The procedures herein are focused on the maintenance of signed zones + (i.e. signing and publishing zones on authoritative servers). It is + intended that maintenance of zones such as resigning or key rollovers + be transparent to any verifying clients on the Internet. + + The structure of this document is as follows. In Section 2 we + discuss the importance of keeping the "chain of trust" intact. + Aspects of key generation and storage of private keys are discussed + in Section 3; the focus in this section is mainly on the private part + of the key(s). Section 4 describes considerations concerning the + public part of the keys. Since these public keys appear in the DNS + one has to take into account all kinds of timing issues, which are + discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the + rollover, or which, of keys. Finally Section 4.4 discusses + considerations on how parents deal with their children's public keys + in order to maintain chains of trust. + + The typographic conventions used in this document are explained in + Appendix C. + + Since this is a document with operational suggestions and there are + no protocol specifications, the RFC2119 [4] language does not apply. + + This document obsoletes RFC2541 [7] + +1.1 The Use of the Term 'key' + + It is assumed that the reader is familiar with the concept of + asymmetric keys on which DNSSEC is based (Public Key Cryptography + [11]). Therefore, this document will use the term 'key' rather + loosely. Where it is written that 'a key is used to sign data' it is + assumed that the reader understands that it is the private part of + the key-pair that is used for signing. It is also assumed that the + reader understands that the public part of the key-pair is published + in the DNSKEY resource record and that it is the public part that is + used in key-exchanges. + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 4] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +1.2 Time Definitions + + In this document we will be using a number of time related terms. + The following definitions apply: + o "Signature validity period" + The period that a signature is valid. It starts at the time + specified in the signature inception field of the RRSIG RR and + ends at the time specified in the expiration field of the RRSIG + RR. + o "Signature publication period" + Time after which a signature (made with a specific key) is + replaced with a new signature (made with the same key). This + replacement takes place by publishing the relevant RRSIG in the + master zone file. + After one stopped publishing an RRSIG in a zone it may take a + while before the RRSIG has expired from caches and has actually + been removed from the DNS. + o "Key effectivity period" + The period which a key pair is expected to be effective. This + period is defined as the time between the first inception time + stamp and the last expiration date of any signature made with + this key. + The key effectivity period can span multiple signature validity + periods. + o "Maximum/Minimum Zone TTL" + The maximum or minimum value of the TTLs from the complete set + of RRs in a zone. + +2. Keeping the Chain of Trust Intact + + Maintaining a valid chain of trust is important because broken chains + of trust will result in data being marked as Bogus (as defined in [2] + section 5), which may cause entire (sub)domains to become invisible + to verifying clients. The administrators of secured zones have to + realize that their zone is, to their clients, part of a chain of + trust. + + As mentioned in the introduction, the procedures herein are intended + to ensure maintenance of zones, such as resigning or key rollovers, + will be transparent to the verifying clients on the Internet. + + Administrators of secured zones will have to keep in mind that data + published on an authoritative primary server will not be immediately + seen by verifying clients; it may take some time for the data to be + transfered to other secondary authoritative nameservers and clients + may be fetching data from caching non-authoritative servers. + + For the verifying clients it is important that data from secured + + + +Kolkman & Gieben Expires September 2, 2005 [Page 5] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + zones can be used to build chains of trust regardless of whether the + data came directly from an authoritative server, a caching nameserver + or some middle box. Only by carefully using the available timing + parameters can a zone administrator assure that the data necessary + for verification can be obtained. + + The responsibility for maintaining the chain of trust is shared by + administrators of secured zones in the chain of trust. This is most + obvious in the case of a 'key compromise' when a trade off between + maintaining a valid chain of trust and replacing the compromised keys + as soon as possible must be made. Then zone administrators will have + to make a trade off, between keeping the chain of trust intact - + thereby allowing for attacks with the compromised key - or to + deliberately break the chain of trust and making secured sub domains + invisible to security aware resolvers. Also see Section 4.3. + +3. Keys Generation and Storage + + This section describes a number of considerations with respect to the + security of keys. It deals with the generation, effectivity period, + size and storage of private keys. + +3.1 Zone and Key Signing Keys + + The DNSSEC validation protocol does not distinguish between DNSKEYs. + All DNSKEYs can be used during the validation. In practice operators + use Key Signing and Zone Signing Keys and use the so-called (Secure + Entry Point) SEP flag to distinguish between them during operations. + The dynamics and considerations are discussed below. + + To make zone resigning and key rollover procedures easier to + implement, it is possible to use one or more keys as Key Signing Keys + (KSK). These keys will only sign the apex DNSKEY RR set in a zone. + Other keys can be used to sign all the RRsets in a zone and are + referred to as Zone Signing Keys (ZSK). In this document we assume + that KSKs are the subset of keys that are used for key exchanges with + the parent and potentially for configuration as trusted anchors - the + SEP keys. In this document we assume a one-to-one mapping between + KSK and SEP keys and we assume the SEP flag [1] to be set on all + KSKs. + +3.1.1 Motivations for the KSK and ZSK Separation + + Differentiating between the KSK and ZSK functions has several + advantages: + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 6] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + o No parent/child interaction is required when ZSKs are updated. + o The KSK can be made stronger (i.e. using more bits in the key + material). This has little operational impact since it is only + used to sign a small fraction of the zone data. Also when + verifying the KSK is only used to verify the zone's keyset. + o As the KSK is only used to sign a key set, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from and in a safer location than the ZSK. + o A KSK can have a longer key effectivity period. + + For almost any method of key management and zone signing the KSK is + used less frequently than the ZSK. Once a key set is signed with the + KSK all the keys in the key set can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the key set. The new key + set is then resigned with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK. If it is an + even number it is a ZSK. + + The zone-signing key can be used to sign all the data in a zone on a + regular basis. When a zone-signing key is to be rolled, no + interaction with the parent is needed. This allows for "Signature + Validity Periods" on the order of days. + + The key-signing key is only to be used to sign the DNSKEY RRs in a + zone. If a key-signing key is to be rolled over, there will be + interactions with parties other than the zone administrator. These + can include the registry of the parent zone or administrators of + verifying resolvers that have the particular key configured as + trusted entry points. Hence, the key effectivity period of these + keys can and should be made much longer. Although, given a long + enough key, the Key Usage Time can be on the order of years we + suggest planning for a key effectivity of the order of a few months + so that a key rollover remains an operational routine. + +3.1.2 KSKs for high level zones + + Higher level zones are generally more sensitive than lower level + zones. Anyone controlling or breaking the security of a zone thereby + obtains authority over all of its sub domains (except in the case of + resolvers that have locally configured the public key of a sub + domain). Therefore, extra care should be taken with high level zones + and strong keys used. + + The root zone is the most critical of all zones. Someone controlling + or compromising the security of the root zone would control the + + + +Kolkman & Gieben Expires September 2, 2005 [Page 7] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + entire DNS name space of all resolvers using that root zone (except + in the case of resolvers that have locally configured the public key + of a sub domain). Therefore, the utmost care must be taken in the + securing of the root zone. The strongest and most carefully handled + keys should be used. The root zone private key should always be kept + off line. + + Many resolvers will start at a root server for their access to and + authentication of DNS data. Securely updating the trust anchors in + an enormous population of resolvers around the world will be + extremely difficult. + +3.2 Randomness + + Careful generation of all keys is a sometimes overlooked but + absolutely essential element in any cryptographically secure system. + The strongest algorithms used with the longest keys are still of no + use if an adversary can guess enough to lower the size of the likely + key space so that it can be exhaustively searched. Technical + suggestions for the generation of random keys will be found in + RFC1750 [3]. One should carefully assess if the random number + generator used during key generation adheres to these suggestions. + + Keys with a long effectivity period are particularly sensitive as + they will represent a more valuable target and be subject to attack + for a longer time than short period keys. It is strongly recommended + that long term key generation occur off-line in a manner isolated + from the network via an air gap or, at a minimum, high level secure + hardware. + +3.3 Key Effectivity Period + + For various reasons keys in DNSSEC need to be changed once in a + while. The longer a key is in use, the greater the probability that + it will have been compromised through carelessness, accident, + espionage, or cryptanalysis. Furthermore when key rollovers are too + rare an event, they will not become part of the operational habit and + there is risk that nobody on-site will remember the procedure for + rollover when the need is there. + + For Key Signing Keys a reasonable key effectivity period is 13 + months, with the intent to replace them after 12 months. An intended + key effectivity period of a month is reasonable for Zone Signing + Keys. + + Using these recommendations will lead to rollovers occurring + frequently enough to become part of 'operational habits'; the + procedure does not have to be reinvented every time a key is + + + +Kolkman & Gieben Expires September 2, 2005 [Page 8] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + replaced. + + Key effectivity periods can be made very short, as in the order of a + few minutes. But when replacing keys one has to take the + considerations from Section 4.1 and Section 4.2 into account. + +3.4 Key Algorithm + + There are currently three different types of algorithms that can be + used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter + is fairly new and still needs to be standardized for usage in DNSSEC. + + RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2000, its use is now also free. + + DSA has been developed by NIST. The creation of signatures is + roughly done at the same speed as with RSA, but is 10 to 40 times as + slow for verification [11]. + + We suggest the use of RSA/SHA-1 as the preferred algorithm for the + key. The current known attacks on RSA can be defeated by making your + key longer. As the MD5 hashing algorithm is showing (theoretical) + cracks, we recommend the usage of SHA1. + + In 2005 some discoveries were made that SHA-1 also has some + weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is + expected that a new hashing algorithm is rolled out, before any + attack becomes practical. + +3.5 Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used and how much data will be signed + during the key publication period. It is hard to give precise + recommendations but Lenstra and Verheul [10] supplied the following + table with lower bound estimates for cryptographic key sizes. Their + recommendations are based on a set of explicitly formulated parameter + settings, combined with existing data points about cryptographic + systems. For details we refer to the original paper. + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 9] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + Year RSA Key Sizes Year RSA Key Sizes + + 2000 952 2015 1613 + 2001 990 2016 1664 + 2002 1028 2017 1717 + 2003 1068 2018 1771 + 2004 1108 2019 1825 + + + 2005 1149 2020 1881 + 2006 1191 2021 1937 + 2007 1235 2022 1995 + 2008 1279 2023 2054 + 2009 1323 2024 2113 + + + 2026 2236 2025 2174 + 2010 1369 2027 2299 + 2011 1416 2028 2362 + 2012 1464 2029 2427 + 2013 1513 + 2014 1562 + + For example, should you wish your key to last three years from 2003, + check the RSA key size values for 2006 in this table. In this case + it should be at least 1191 bits. + + Please keep in mind that nobody can see into the future, and that + these key lengths are only provided here as a guide. + + When determining a key size one should take into account that a large + key will be slower during generation and verification. For RSA, + verification, the most common operation, will vary roughly with the + square of the key size; signing will vary with the cube of the key + size length; and key generation will vary with the fourth power of + the modulus length. Besides larger keys will increase the sizes of + the RRSIG and DNSKEY records and will therefore increase the chance + of DNS UDP packet overflow. Also see Section 3.1.1 for a discussion + of how keys serving different roles (ZSK v. KSK) may need different + key strengths. + +3.6 Private Key Storage + + It is recommended that, where possible, zone private keys and the + zone file master copy be kept and used in off-line, non-network + connected, physically secure machines only. Periodically an + application can be run to add authentication to a zone by adding + RRSIG and NSEC RRs. Then the augmented file can be transferred, + + + +Kolkman & Gieben Expires September 2, 2005 [Page 10] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + perhaps by sneaker-net, to the networked zone primary server machine. + + The ideal situation is to have a one way information flow to the + network to avoid the possibility of tampering from the network. + Keeping the zone master file on-line on the network and simply + cycling it through an off-line signer does not do this. The on-line + version could still be tampered with if the host it resides on is + compromised. For maximum security, the master copy of the zone file + should be off net and should not be updated based on an unsecured + network mediated communication. + + In general keeping a zone-file off-line will not be practical and the + machines on which zone files are maintained will be connected to a + network. Operators are advised to take security measures to shield + unauthorized access to the master copy. + + For dynamically updated secured zones [5] both the master copy and + the private key that is used to update signatures on updated RRs will + need to be on line. + +4. Signature generation, Key Rollover and Related Policies + +4.1 Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA RR's refresh, + retry and expiration timers are counters that are used to determine + the time elapsed after a slave server synchronized (or tried to + synchronize) with a master server. The Time to Live (TTL) value and + the SOA RR minimum TTL parameter [6] are used to determine how long a + forwarder should cache data after it has been fetched from an + authoritative server. By using a signature validity period, DNSSEC + introduces the notion of an absolute time in the DNS. Signatures in + DNSSEC have an expiration date after which the signature is marked as + invalid and the signed data is to be considered Bogus. + +4.1.1 Time Considerations + + Because of the expiration of signatures, one should consider the + following: + o We suggest the Maximum Zone TTL of your zone data to be a fraction + of your signature validity period. + If the TTL would be of similar order as the signature validity + period, then all RRsets fetched during the validity period + would be cached until the signature expiration time. Section + 7.1 of [2] suggests that "the resolver may use the time + remaining before expiration of the signature validity period of + a signed RRset as an upper bound for the TTL". As a result + query load on authoritative servers would peak at signature + + + +Kolkman & Gieben Expires September 2, 2005 [Page 11] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + expiration time, as this is also the time at which records + simultaneously expire from caches. + To avoid query load peaks we suggest the TTL on all the RRs in + your zone to be at least a few times smaller than your + signature validity period. + o We suggest the signature publication period to be at least one + maximum TTL smaller than the signature validity period. + Resigning a zone shortly before the end of the signature + validity period may cause simultaneous expiration of data from + caches. This in turn may lead to peaks in the load on + authoritative servers. + o We suggest the minimum zone TTL to be long enough to both fetch + and verify all the RRs in the authentication chain. A low TTL + could cause two problems: + 1. During validation, some data may expire before the + validation is complete. The validator should be able to keep + all data, until is completed. This applies to all RRs needed + to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the + final answers i.e. the RR set that is returned for the initial + query. + 2. Frequent verification causes load on recursive nameservers. + Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from + caching. The TTL on those should be relatively long. + o Slave servers will need to be able to fetch newly signed zones + well before the RRSIGs in the zone served by the slave server pass + their signature expiration time. + When a slave server is out of sync with its master and data in + a zone is signed by expired signatures it may be better for the + slave server not to give out any answer. + Normally a slave server that is not able to contact a master + server for an extended period will expire a zone. When that + happens the zone will not respond on queries. The time of + expiration is set in the SOA record and is relative to the last + successful refresh between the master and the slave server. + There exists no coupling between the signature expiration of + RRSIGs in the zone and the expire parameter in the SOA. + If the server serves a DNSSEC zone than it may well happen that + the signatures expire well before the SOA expiration timer + counts down to zero. It is not possible to completely prevent + this from happening by tweaking the SOA parameters. + However, the effects can be minimized where the SOA expiration + time is equal or smaller than the signature validity period. + The consequence of an authoritative server not being able to + update a zone, whilst that zone includes expired signatures, is + that non-secure resolvers will continue to be able to resolve + data served by the particular slave servers while security + aware resolvers will experience problems because of answers + being marked as Bogus. + + + +Kolkman & Gieben Expires September 2, 2005 [Page 12] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + We suggest the SOA expiration timer being approximately one + third or one fourth of the signature validity period. It will + allow problems with transfers from the master server to be + noticed before the actual signature time out. + We also suggest that operators of nameservers that supply + secondary services develop 'watch dogs' to spot upcoming + signature expirations in zones they slave, and take appropriate + action. + When determining the value for the expiration parameter one has + to take the following into account: What are the chances that + all my secondary zones expire; How quickly can I reach an + administrator of secondary servers to load a valid zone? All + these arguments are not DNSSEC specific but may influence the + choice of your signature validity intervals. + +4.2 Key Rollovers + + A DNSSEC key cannot be used forever (see Section 3.3). So key + rollovers -- or supercessions, as they are sometimes called -- are a + fact of life when using DNSSEC. Zone administrators who are in the + process of rolling their keys have to take into account that data + published in previous versions of their zone still lives in caches. + When deploying DNSSEC, this becomes an important consideration; + ignoring data that may be in caches may lead to loss of service for + clients. + + The most pressing example of this is when zone material signed with + an old key is being validated by a resolver which does not have the + old zone key cached. If the old key is no longer present in the + current zone, this validation fails, marking the data Bogus. + Alternatively, an attempt could be made to validate data which is + signed with a new key against an old key that lives in a local cache, + also resulting in data being marked Bogus. + +4.2.1 Zone-signing Key Rollovers + + For zone-signing key rollovers there are two ways to make sure that + during the rollover data still cached can be verified with the new + key sets or newly generated signatures can be verified with the keys + still in caches. One schema, described in Section 4.2.1.2, uses + double signatures; the other uses key pre-publication + (Section 4.2.1.1). The pros, cons and recommendations are described + in Section 4.2.1.3. + +4.2.1.1 Pre-publish key set Rollover + + This section shows how to perform a ZSK rollover without the need to + sign all the data in a zone twice - the so-called "pre-publish + + + +Kolkman & Gieben Expires September 2, 2005 [Page 13] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + rollover".This method has advantages in the case of a key compromise. + If the old key is compromised, the new key has already been + distributed in the DNS. The zone administrator is then able to + quickly switch to the new key and remove the compromised key from the + zone. Another major advantage is that the zone size does not double, + as is the case with the double signature ZSK rollover. A small + "HOWTO" for this kind of rollover can be found in Appendix B. + + normal pre-roll roll after + + SOA0 SOA1 SOA2 SOA3 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the zone- + signing key. + pre-roll: DNSKEY 11 is introduced into the key set. Note that no + signatures are generated with this key yet, but this does not + secure against brute force attacks on the public key. The minimum + duration of this pre-roll phase is the time it takes for the data + to propagate to the authoritative servers plus TTL value of the + key set. This equates to two times the Maximum Zone TTL. + roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign + the data in the zone exclusively (i.e. all the signatures from + DNSKEY 10 are removed from the zone). DNSKEY 10 remains published + in the key set. This way data that was loaded into caches from + version 1 of the zone can still be verified with key sets fetched + from version 2 of the zone. + The minimum time that the key set including DNSKEY 10 is to be + published is the time that it takes for zone data from the + previous version of the zone to expire from old caches i.e. the + time it takes for this zone to propagate to all authoritative + servers plus the Maximum Zone TTL value of any of the data in the + previous version of the zone. + after: DNSKEY 10 is removed from the zone. The key set, now only + containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1. + + The above scheme can be simplified by always publishing the "future" + key immediately after the rollover. The scheme would look as follows + (we show two rollovers); the future key is introduced in "after" as + DNSKEY 12 and again a newer one, numbered 13, in "2nd after": + + + +Kolkman & Gieben Expires September 2, 2005 [Page 14] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + normal roll after + + SOA0 SOA2 SOA3 + RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 DNSKEY12 + RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + + + 2nd roll 2nd after + + SOA4 SOA5 + RRSIG12(SOA4) RRSIG12(SOA5) + + DNSKEY1 DNSKEY1 + DNSKEY11 DNSKEY12 + DNSKEY12 DNSKEY13 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG12(DNSKEY) RRSIG12(DNSKEY) + + + Note that the key introduced after the rollover is not used for + production yet; the private key can thus be stored in a physically + secure manner and does not need to be 'fetched' every time a zone + needs to be signed. + +4.2.1.2 Double Signature Zone-signing Key Rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme, aptly named "double sig rollover". + + During the rollover stage the new version of the zone file will need + to propagate to all authoritative servers and the data that exists in + (distant) caches will need to expire, requiring at least the maximum + Zone TTL. + + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 15] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) + RRSIG11(SOA1) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) + RRSIG11(DNSKEY) + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the zone- + signing key. + roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced + into the key set and all the data in the zone is signed with + DNSKEY 10 and DNSKEY 11. The rollover period will need to exist + until all data from version 0 of the zone has expired from remote + caches. This will take at least the maximum Zone TTL of version 0 + of the zone. + after: DNSKEY 10 is removed from the zone. All the signatures from + DNSKEY 10 are removed from the zone. The key set, now only + containing DNSKEY 11, is resigned with DNSKEY 1. + + At every instance, RRSIGs from the previous version of the zone can + be verified with the DNSKEY RRset from the current version and the + other way around. The data from the current version can be verified + with the data from the previous version of the zone. The duration of + the rollover phase and the period between rollovers should be at + least the "Maximum Zone TTL". + + Making sure that the rollover phase lasts until the signature + expiration time of the data in version 0 of the zone is recommended. + This way all caches are cleared of the old signatures. However, this + date could be considerably longer than the Maximum Zone TTL, making + the rollover a lengthy procedure. + + Note that in this example we assumed that the zone was not modified + during the rollover. New data can be introduced in the zone as long + as it is signed with both keys. + +4.2.1.3 Pros and Cons of the Schemes + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 16] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + Pre-publish-key set rollover: This rollover does not involve signing + the zone data twice. Instead, before the actual rollover, the new + key is published in the key set and thus available for + cryptanalysis attacks. A small disadvantage is that this process + requires four steps. Also the pre-publish scheme involves more + parental work when used for KSK rollovers as explained in + Section 4.2. + Double signature rollover: The drawback of this signing scheme is + that during the rollover the number of signatures in your zone + doubles, this may be prohibitive if you have very big zones. An + advantage is that it only requires three steps. + +4.2.2 Key-signing Key Rollovers + + For the rollover of a key-signing key the same considerations as for + the rollover of a zone-signing key apply. However we can use a + double signature scheme to guarantee that old data (only the apex key + set) in caches can be verified with a new key set and vice versa. + + Since only the key set is signed with a KSK, zone size considerations + do not apply. + + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY2 + DNSKEY2 + DNSKEY10 DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) + RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + normal: Version 0 of the zone. The parental DS points to DNSKEY1. + Before the rollover starts the child will have to verify what the + TTL is of the DS RR that points to DNSKEY1 - it is needed during + the rollover and we refer to the value as TTL_DS. + roll: During the rollover phase the zone administrator generates a + second KSK, DNSKEY2. The key is provided to the parent and the + child will have to wait until a new DS RR has been generated that + points to DNSKEY2. After that DS RR has been published on all + servers authoritative for the parent's zone, the zone + administrator has to wait at least TTL_DS to make sure that the + old DS RR has expired from caches. + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 17] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + after: DNSKEY1 has been removed. + + The scenario above puts the responsibility for maintaining a valid + chain of trust with the child. It also is based on the premises that + the parent only has one DS RR (per algorithm) per zone. An + alternative mechanism has been considered. Using an established + trust relation, the interaction can be performed in-band, and the + removal of the keys by the child can possibly be signaled by the + parent. In this mechanism there are periods where there are two DS + RRs at the parent. Since at the moment of writing the protocol for + this interaction has not been developed further discussion is out of + scope for this document. + +4.2.3 Difference Between ZSK and KSK Rollovers + + Note that KSK rollovers and ZSK rollovers are different. A zone-key + rollover can be handled in two different ways: pre-publish (Section + Section 4.2.1.1) and double signature (Section Section 4.2.1.2). + + As the KSK is used to validate the key set and because the KSK is not + changed during a ZSK rollover, a cache is able to validate the new + key set of the zone. The pre-publish method would work for a KSK + rollover. The record that are to be pre-published are the parental + DS RRs. + + The pre-publish method has some drawbacks. We first describe the + rollover scheme and then indicate these drawbacks. + + normal pre-roll roll after + Parent: + SOA0 SOA1 SOA2 SOA3 + RRSIGpar(SOA0) RRSIGpar(SOA1) RRSIGpar(SOA2) RRSIGpar(SOA3) + DS1 DS1 DS1 DS2 + DS2 DS2 + RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) + + + + Child: + SOA0 SOA0 SOA1 SOA1 + RRSIG10(SOA0) RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA1) + + DNSKEY1 DNSKEY1 DNSKEY2 DNSKEY2 + + DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 18] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + When the child zone wants to roll it notifies the parent during the + pre-roll phase and submits the new key to the parent. The parent + publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively. + During the rollover, which can take place as soon as the new DS set + propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2. + Immediately after that it can notify the parent that the old DS + record can be deleted. + + The drawbacks of these scheme are that during the pre-roll phase the + parent cannot verify the match between the DS RR and DNSKEY2 using + the DNS. Besides, we introduce a "security lame" DS record + Section 4.4.3. Finally the child-parent interaction consists of two + steps. The "double signature" method only needs one interaction. + +4.2.4 Automated Key Rollovers + + As keys must be renewed periodically, there is some motivation to + automate the rollover process. Consider that: + + o ZSK rollovers are easy to automate as only the local zone is + involved. + o A KSK rollover needs interaction between the parent and child. + Data exchange is needed to provide the new keys to the parent, + consequently, this data must be authenticated and integrity must + be guaranteed in order to avoid attacks on the rollover. + o All time and TTL considerations presented in Section 4.2 apply to + an automated rollover. + +4.3 Planning for Emergency Key Rollover + + This section deals with preparation for a possible key compromise. + Our advice is to have a documented procedure ready for when a key + compromise is suspected or confirmed. + + When the private material of one of your keys is compromised it can + be used for as long as a valid authentication chain exists. An + authentication chain remains intact for: + o as long as a signature over the compromised key in the + authentication chain is valid, + o as long as a parental DS RR (and signature) points to the + compromised key, + o as long as the key is anchored in a resolver and is used as a + starting point for validation. (This is generally the hardest to + update.) + + While an authentication chain to your compromised key exists, your + name-space is vulnerable to abuse by anyone who has obtained + illegitimate possession of the key.Zone operators have to make a + + + +Kolkman & Gieben Expires September 2, 2005 [Page 19] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + trade off if the abuse of the compromised key is worse than having + data in caches that cannot be validated. If the zone operator + chooses to break the authentication chain to the compromised key, + data in caches signed with this key cannot be validated. However, if + the zone administrator chooses to take the path of a regular roll- + over, the malicious key holder can spoof data so that it appears to + be valid. Note that this kind of attack is more likely to occur in a + localized part of the network topology i.e. downstream from where the + spoof takes place. + + +4.3.1 KSK Compromise + + When the KSK has been compromised the parent must be notified as soon + as possible using secure means. The key set of the zone should be + resigned as soon as possible. Care must be taken to not break the + authentication chain. The local zone can only be resigned with the + new KSK after the parent's zone has created and reloaded its zone + with the DS created from the new KSK. Before this update takes place + it would be best to drop the security status of a zone all together: + the parent removes the DS of the child at the next zone update. + After that the child can be made secure again. + + An additional danger of a key compromise is that the compromised key + can be used to facilitate a legitimate DNSKEY/DS and/or nameserver + rollover at the parent. When that happens the domain can be in + dispute. An authenticated out of band and secure notify mechanism to + contact a parent is needed in this case. + +4.3.2 ZSK Compromise + + Primarily because there is no parental interaction required when a + ZSK is compromised, the situation is less severe than with with a KSK + compromise. The zone must still be resigned with a new ZSK as soon + as possible. As this is a local operation and requires no + communication between the parent and child this can be achieved + fairly quickly. However, one has to take into account that just as + with a normal rollover the immediate disappearance from the old + compromised key may lead to verification problems. The pre- + publication scheme as discussed above minimizes such problems. + +4.3.3 Compromises of Keys Anchored in Resolvers + + A key can also be pre-configured in resolvers. For instance, if + DNSSEC is successfully deployed the root key may be pre-configured in + most security aware resolvers. + + If trust-anchor keys are compromised, the resolvers using these keys + + + +Kolkman & Gieben Expires September 2, 2005 [Page 20] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + should be notified of this fact. Zone administrators may consider + setting up a mailing list to communicate the fact that a SEP key is + about to be rolled over. This communication will of course need to + be authenticated e.g. by using digital signatures. + + End-users faced with the task of updating an anchored key should + always validate the new key. New keys should be authenticated out of + the DNS, for example, looking them up on an SSL secured announcement + website. + +4.4 Parental Policies + +4.4.1 Initial Key Exchanges and Parental Policies Considerations + + The initial key exchange is always subject to the policies set by the + parent (or its registry). When designing a key exchange policy one + should take into account that the authentication and authorization + mechanisms used during a key exchange should be as strong as the + authentication and authorization mechanisms used for the exchange of + delegation information between parent and child. I.e. there is no + implicit need in DNSSEC to make the authentication process stronger + than it was in DNS. + + Using the DNS itself as the source for the actual DNSKEY material, + with an off-band check on the validity of the DNSKEY, has the benefit + that it reduces the chances of user error. A parental DNSKEY + download tool can make use of the SEP bit [1] to select the proper + key from a DNSSEC key set; thereby reducing the chance that the wrong + DNSKEY is sent. It can validate the self-signature over a key; + thereby verifying the ownership of the private key material. + Fetching the DNSKEY from the DNS ensures that the chain of trust + remains intact once the parent publishes the DS RR indicating the + child is secure. + + Note: the off-band verification is still needed when the key-material + is fetched via the DNS. The parent can never be sure whether the + DNSKEY RRs have been spoofed or not. + +4.4.2 Storing Keys or Hashes? + + When designing a registry system one should consider which of the + DNSKEYs and/or the corresponding DSs to store. Since a child zone + might wish to have a DS published using a message digest algorithm + not yet understood by the registry, the registry can't count on being + able to generate the DS record from a raw DNSKEY. Thus, we recommend + that registry system at least support storing DS records. + + It may also be useful to store DNSKEYs, since having them may help + + + +Kolkman & Gieben Expires September 2, 2005 [Page 21] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + during troubleshooting and, so long as the child's chosen message + digest is supported, the overhead of generating DS records from them + is minimal. Having an out-of-band mechanism, such as a Whois + database, to find out which keys are used to generate DS Resource + Records for specific owners and/or zones may also help with + troubleshooting. + + The storage considerations also relate the design of the customer + interface and the method by which data is transfered between + registrant and registry; Will the child zone owner be able to upload + DS RRs with unknown hash algorithms or does the interface only allows + DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP + protocol extensions [9] which allows transfer of DS RRs and + optionally DNSKEY RRs. + +4.4.3 Security Lameness + + Security Lameness is defined as what happens when a parent has a DS + RR pointing to a non-existing DNSKEY RR. During key exchange a + parent should make sure that the child's key is actually configured + in the DNS before publishing a DS RR in its zone. Failure to do so + could cause the child's zone being marked as Bogus. + + Child zones should be very careful removing DNSKEY material, + specifically SEP keys, for which a DS RR exists. + + Once a zone is "security lame", a fix (e.g. removing a DS RR) will + take time to propagate through the DNS. + +4.4.4 DS Signature Validity Period + + Since the DS can be replayed as long as it has a valid signature, a + short signature validity period over the DS minimizes the time a + child is vulnerable in the case of a compromise of the child's + KSK(s). A signature validity period that is too short introduces the + possibility that a zone is marked Bogus in case of a configuration + error in the signer. There may not be enough time to fix the + problems before signatures expire. Something as mundane as operator + unavailability during weekends shows the need for DS signature + validity periods longer than 2 days. We recommend the minimum for a + DS signature validity period of a few days. + + The maximum signature validity period of the DS record depends on how + long child zones are willing to be vulnerable after a key compromise. + Other considerations, such as how often the zone is (re)signed can + also be taken into account. + + We consider a signature validity period of around one week to be a + + + +Kolkman & Gieben Expires September 2, 2005 [Page 22] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + good compromise between the operational constraints of the parent and + minimizing damage for the child. + + In addition to the signature validity period, which sets a lower + bound on the amount of times the zone owner will need to sign the + zone data and which sets an upper bound to the time a child is + vulnerable after key compromise, there is the TTL value on the DS + RRs. By lowering the TTL, the authoritative servers will see more + queries, on the other hand a low TTL increases the speed with which + new DS RRs propagate through the DNS. As argued in Section 4.1.1, + the TTL should be a fraction of the signature validity period. + +5. Security Considerations + + DNSSEC adds data integrity to the DNS. This document tries to assess + the operational considerations to maintain a stable and secure DNSSEC + service. Not taking into account the 'data propagation' properties + in the DNS will cause validation failures and may make secured zones + unavailable to security aware resolvers. + +6. Acknowledgments + + Most of the ideas in this draft were the result of collective efforts + during workshops, discussions and try outs. + + At the risk of forgetting individuals who were the original + contributors of the ideas we would like to acknowledge people who + were actively involved in the compilation of this document. In + random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette + Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly. + + Some material in this document has been shamelessly copied from + RFC2541 [7] by Donald Eastlake. + + Mike StJohns designed the key exchange between parent and child + mentioned in the last paragraph of Section 4.2.2 + + Section 4.2.4 was supplied by G. Guette and O. Courtay. + + Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of + the spelling and style issues. + + Kolkman and Gieben take the blame for introducing all miscakes(SIC). + +7. References + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 23] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +7.1 Normative References + + [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + +7.2 Informative References + + [3] Eastlake, D., Crocker, S., and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [7] Eastlake, D., "DNS Security Operational Considerations", + RFC 2541, March 1999. + + [8] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [9] Hollenbeck, S., "Domain Name System (DNS) Security Extensions + Mapping for the Extensible Provisioning Protocol (EPP)", + draft-hollenbeck-epp-secdns-07 (work in progress), March 2005. + + [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", The Journal of Cryptology 14 (255-293), 2001. + + [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and + Source Code in C", 1996. + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 24] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + The Netherlands + + Phone: +31 20 535 4444 + Email: olaf@ripe.net + URI: http://www.ripe.net/ + + + Miek Gieben + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Email: miek@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + +Appendix A. Terminology + + In this document there is some jargon used that is defined in other + documents. In most cases we have not copied the text from the + documents defining the terms but given a more elaborate explanation + of the meaning. Note that these explanations should not be seen as + authoritative. + + Anchored Key: A DNSKEY configured in resolvers around the globe. + This key is hard to update, hence the term anchored. + Bogus: Also see Section 5 of [2]. An RRset in DNSSEC is marked + "Bogus" when a signature of a RRset does not validate against a + DNSKEY. + Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used + exclusively for signing the apex key set. The fact that a key is + a KSK is only relevant to the signing tool. + Private and Public Keys: DNSSEC secures the DNS through the use of + public key cryptography. Public key cryptography is based on the + existence of two keys, a public key and a private key. The public + keys are published in the DNS by use of the DNSKEY Resource Record + (DNSKEY RR). Private keys should remain private. + Key Rollover: A key rollover (also called key supercession in some + environments) is the act of replacing one key pair by another at + the end of a key effectivity period. + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 25] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + Secure Entry Point key or SEP Key: A KSK that has a parental DS + record pointing to it. Note: this is not enforced in the + protocol. A SEP Key with no parental DS is security lame. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + Signer: The system that has access to the private key material and + signs the Resource Record sets in a zone. A signer may be + configured to sign only parts of the zone e.g. only those RRsets + for which existing signatures are about to expire. + Zone-Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is + used for signing all data in a zone. The fact that a key is a ZSK + is only relevant to the signing tool. + Zone Administrator: The 'role' that is responsible for signing a zone + and publishing it on the primary authoritative server. + +Appendix B. Zone-signing Key Rollover Howto + + Using the pre-published signature scheme and the most conservative + method to assure oneself that data does not live in caches here + follows the "HOWTO". + Step 0: The preparation: Create two keys and publish both in your key + set. Mark one of the keys as "active" and the other as + "published". Use the "active" key for signing your zone data. + Store the private part of the "published" key, preferably off- + line. + The protocol does not provide for attributes to mark a key as + active or published. This is something you have to do on your + own, through the use of a notebook or key management tool. + Step 1: Determine expiration: At the beginning of the rollover make a + note of the highest expiration time of signatures in your zone + file created with the current key marked as "active". + Wait until the expiration time marked in Step 1 has passed + Step 2: Then start using the key that was marked as "published" to + sign your data i.e. mark it as "active". Stop using the key that + was marked as "active", mark it as "rolled". + Step 3: It is safe to engage in a new rollover (Step 1) after at + least one "signature validity period". + +Appendix C. Typographic Conventions + + The following typographic conventions are used in this document: + Key notation: A key is denoted by KEYx, where x is a number, x could + be thought of as the key id. + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 26] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + RRset notations: RRs are only denoted by the type. All other + information - owner, class, rdata and TTL - is left out. Thus: + "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are + a list of RRs. A example of this would be: "A1,A2", specifying + the RRset containing two "A" records. This could again be + abbreviated to just "A". + Signature notation: Signatures are denoted as RRSIGx(RRset), which + means that RRset is signed with DNSKEYx. + Zone representation: Using the above notation we have simplified the + representation of a signed zone by leaving out all unnecessary + details such as the names and by representing all data by "SOAx" + SOA representation: SOA's are represented as SOAx, where x is the + serial number. + Using this notation the following zone: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 27] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + example.net. 600 IN SOA ns.example.net. bert.example.net. ( + 10 ; serial + 450 ; refresh (7 minutes 30 seconds) + 600 ; retry (10 minutes) + 345600 ; expire (4 days) + 300 ; minimum (5 minutes) + ) + 600 RRSIG SOA 5 2 600 20130522213204 ( + 20130422213204 14 example.net. + cmL62SI6iAX46xGNQAdQ... ) + 600 NS a.iana-servers.net. + 600 NS b.iana-servers.net. + 600 RRSIG NS 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + SO5epiJei19AjXoUpFnQ ... ) + 3600 DNSKEY 256 3 5 ( + EtRB9MP5/AvOuVO0I8XDxy0... + ) ; key id = 14 + 3600 DNSKEY 256 3 5 ( + gsPW/Yy19GzYIY+Gnr8HABU... + ) ; key id = 15 + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 14 example.net. + J4zCe8QX4tXVGjV4e1r9... ) + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 15 example.net. + keVDCOpsSeDReyV6O... ) + 600 RRSIG NSEC 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + obj3HEp1GjnmhRjX... ) + a.example.net. 600 IN TXT "A label" + 600 RRSIG TXT 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + IkDMlRdYLmXH7QJnuF3v... ) + 600 NSEC b.example.com. TXT RRSIG NSEC + 600 RRSIG NSEC 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + bZMjoZ3bHjnEz0nIsPMM... ) + + ... + + + is reduced to the following representation: + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 28] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + SOA10 + RRSIG14(SOA10) + + DNSKEY14 + DNSKEY15 + + RRSIG14(KEY) + RRSIG15(KEY) + + The rest of the zone data has the same signature as the SOA record, + i.e a RRSIG created with DNSKEY 14. + +Appendix D. Document Details and Changes + + This section is to be removed by the RFC editor if and when the + document is published. + + $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 + 2005/03/21 15:51:41 dnssec Exp $ + +D.1 draft-ietf-dnsop-dnssec-operational-practices-00 + + Submission as working group document. This document is a modified + and updated version of draft-kolkman-dnssec-operational-practices-00. + +D.2 draft-ietf-dnsop-dnssec-operational-practices-01 + + changed the definition of "Bogus" to reflect the one in the protocol + draft. + + Bad to Bogus + + Style and spelling corrections + + KSK - SEP mapping made explicit. + + Updates from Sam Weiler added + +D.3 draft-ietf-dnsop-dnssec-operational-practices-02 + + Style and errors corrected. + + Added Automatic rollover requirements from I-D.ietf-dnsop-key- + rollover-requirements. + +D.4 draft-ietf-dnsop-dnssec-operational-practices-03 + + Added the definition of Key effectivity period and used that term + + + +Kolkman & Gieben Expires September 2, 2005 [Page 29] + +Internet-Draft DNSSEC Operational Practices March 2005 + + + instead of Key validity period. + + Modified the order of the sections, based on a suggestion by Rip + Loomis. + + Included parts from RFC2541 [7]. Most of its ground was already + covered. This document obsoletes RFC2541 [7]. Section 3.1.2 + deserves some review as it in contrast to RFC2541 does _not_ give + recomendations about root-zone keys. + + added a paragraph to Section 4.4.4 + +D.5 draft-ietf-dnsop-dnssec-operational-practices-04 + + Somewhat more details added about the pre-publish KSK rollover. Also + moved that subsection down a bit. + + Editorial and content nits that came in during wg last call were + fixed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 30] + +Internet-Draft DNSSEC Operational Practices March 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Kolkman & Gieben Expires September 2, 2005 [Page 31] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt new file mode 100644 index 000000000000..bcd0d14e4b54 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt @@ -0,0 +1,396 @@ + + + + + + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months July 2005 + + Encouraging the use of DNS IN-ADDR Mapping + draft-ietf-dnsop-inaddr-required-07.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + 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]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 2004. http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + + + +Senie [Page 6] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + + 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be + accessed at http://www.ietf.org/shadow.html + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + +Senie [Page 7] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt new file mode 100644 index 000000000000..bf2afcdfb3ac --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt @@ -0,0 +1,1848 @@ + + + +DNS Operations WG J. Jeong, Ed. +Internet-Draft ETRI/University of Minnesota +Expires: November 6, 2005 May 5, 2005 + + + IPv6 Host Configuration of DNS Server Information Approaches + draft-ietf-dnsop-ipv6-dns-configuration-06.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 November 6, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational attributes + of three solutions: RA option, DHCPv6 option, and Well-known anycast + addresses for recursive DNS servers. Additionally, it suggests the + deployment scenarios in four kinds of networks, such as ISP, + Enterprise, 3GPP, and Unmanaged networks, considering multi-solution + resolution. Therefore, this document will give the audience a + + + +Jeong Expires November 6, 2005 [Page 1] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + guideline for IPv6 host DNS configuration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 2] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 + 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 + 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 + 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 + 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 + 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 + 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 + 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 + 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 + 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 + 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 + 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 + 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 + 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 + 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 + 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.3.1 Currently Available Mechanisms and Recommendations . . 19 + 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 + 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 + 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 + 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 + 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 + 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 + 5.4.2 Case B: A dual-stack gateway connected to a + dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 + 5.4.3 Case C: A dual-stack gateway connected to an + IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 + 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 + 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 + 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 + 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 + A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 + + + +Jeong Expires November 6, 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Intellectual Property and Copyright Statements . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 4] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide the ways to configure either fixed or + mobile nodes with one or more IPv6 addresses, default routes and some + other parameters [3][4]. To support the access to additional + services in the Internet that are identified by a DNS name, such as a + web server, the configuration of at least one recursive DNS server is + also needed for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 + option [5]-[7], and (c) Well-known anycast addresses for recursive + DNS servers [9]. Also, it suggests the applicable scenarios for four + kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP + network, and (d) Unmanaged network. + + This document is just an analysis of each possible approach, and does + not make any recommendation on a particular one or on a combination + of particular ones. Some approaches may even not be adopted at all + as a result of further discussion. + + Therefore, the objective of this document is to help the audience + select the approaches suitable for IPv6 host configuration of + recursive DNS servers. + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 5] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +2. Terminology + + This document uses the terminology described in [3]-[9]. In + addition, a new term is defined below: + + o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name + server that offers the recursive service of DNS name resolution. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of the three solutions + are described in detail. + +3.1 RA Option + + The RA approach is to define a new ND option called the RDNSS option + that contains a recursive DNS server address. Existing ND transport + mechanisms (i.e., advertisements and solicitations) are used. This + works in the same way that nodes learn about routers and prefixes. + An IPv6 host can configure the IPv6 addresses of one or more RDNSSes + via RA message periodically sent by a router or solicited by a Router + Solicitation (RS) [8]. + + This approach needs RDNSS information to be configured in the routers + doing the advertisements. The configuration of RDNSS addresses can + be performed manually by an operator or other ways, such as automatic + configuration through a DHCPv6 client running on the router. When + advertising more than one RDNSS option, an RA message includes as + many RDNSS options as RDNSSes. + + Through the ND protocol and RDNSS option along with a prefix + information option, an IPv6 host can perform its network + configuration of its IPv6 address and RDNSS simultaneously [3][4]. + The RA option for RDNSS can be used on any network that supports the + use of ND. + + However, it is worth noting that some link layers, such as Wireless + LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, + which means that they cannot guarantee the timely delivery of RA + messages [25]-[28]. This is discussed in Appendix A. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option includes + a lifetime field that allows client to use RDNSSes nearer to the + client. This can be configured to a value that will require the + client to time out the entry and switch over to another RDNSS address + [8]. However, from the viewpoint of implementation, the lifetime + field would seem to make matters a bit more complex. Instead of just + writing to a DNS configuration file, such as resolv.conf for the list + of RDNSS addresses, we have to have a daemon around (or a program + that is called at the defined intervals) that keeps monitoring the + lifetime of RDNSSes all the time. + + The preference value of RDNSS, included in the RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes; this can be + used for the load balancing of RDNSSes [8]. + + + +Jeong Expires November 6, 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3.1.1 Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1. The RA option is an extension of existing ND/Autoconfig + mechanisms [3][4], and does not require a change in the base ND + protocol. + + 2. This approach, like ND, works well on a variety of link types + including point-to-point links, point-to-multipoint, and + multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 + [3] states, however, that there may be some link types on which + ND is not feasible; on such links, some other mechanisms will be + needed for DNS configuration. + + 3. All of the information a host needs to run the basic Internet + applications such as the email, web, ftp, etc., can be obtained + with the addition of this option to ND and address + autoconfiguration. The use of a single mechanism is more + reliable and easier to provide than when the RDNSS information is + learned via another protocol mechanism. Debugging problems when + multiple protocol mechanisms are being used is harder and much + more complex. + + 4. This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that support + broadcast reliably (e.g., Ethernet LANs) but not necessarily on + other links (e.g., Wireless LANs): Refer to Appendix A. Also, + this works well on links that are high performance (e.g., + Ethernet LANs) and low performance (e.g., Cellular networks). In + the latter case, by combining the RDNSS information with the + other information in the RA, the host can learn all of the + information needed to use most Internet applications, such as the + web in a single packet. This not only saves bandwidth where this + is an issue, but also minimizes the delay needed to learn the + RDNSS information. + + 5. The RA approach could be used as a model for other similar types + of configuration information. New RA options for other server + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + + +3.1.2 Disadvantages + + 1. ND is mostly implemented in the kernel of operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the + + + +Jeong Expires November 6, 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + kernel, and complemented by a user-land process. DHCPv6, + however, has more flexibility for the extension of service + discovery because it is an application layer protocol. + + 2. The current ND framework should be modified to facilitate the + synchronization between another ND cache for RDNSSes in the + kernel space and the DNS configuration file in the user space. + Because it is unacceptable to write and rewrite to the DNS + configuration file (e.g., resolv.conf) from the kernel, another + approach is needed. One simple approach to solve this is to have + a daemon listening to what the kernel conveys, and to have the + daemon do these steps, but such a daemon is not needed with the + current ND framework. + + 3. It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be + configured via the RA option. + + +3.1.3 Observations + + The proposed RDNSS RA option along with the IPv6 ND and + Autoconfiguration allows a host to obtain all of the information it + needs to access the basic Internet services like the web, email, ftp, + etc. This is preferable in the environments where hosts use RAs to + autoconfigure their addresses and all the hosts on the subnet share + the same router and server addresses. If the configuration + information can be obtained from a single mechanism, it is preferable + because it does not add additional delay, and it uses a minimum of + bandwidth. The environments like this include the homes, public + cellular networks, and enterprise environments where no per host + configuration is needed, but exclude public WLAN hot spots. + + DHCPv6 is preferable where it is being used for address configuration + and if there is a need for host specific configuration [5]-[7]. The + environments like this are most likely to be the enterprise + environments where the local administration chooses to have per host + configuration control. + +Note + + The observation section is based on what the proponents of each + approach think makes a good overall solution. + +3.2 DHCPv6 Option + + DHCPv6 [5] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + + + +Jeong Expires November 6, 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + servers [7]. The DNS Recursive Name Server option carries a list of + IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by the + DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as stateless + DHCPv6 [6]. + + Stateless DHCPv6 can be deployed either using DHCPv6 servers running + on general-purpose computers, or on router hardware. Several router + vendors currently implement stateless DHCPv6 servers. Deploying + stateless DHCPv6 in routers has the advantage that no special + hardware is required, and should work well for networks where DHCPv6 + is needed for very straightforward configuration of network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router - it can be on a general + purpose computer. This has the potential to give the operator of the + DHCPv6 server more flexibility in how the DHCPv6 server responds to + individual clients - clients can easily be given different + configuration information based on their identity, or for any other + reason. Nothing precludes adding this flexibility to a router, but + generally in current practice, DHCP servers running on general- + purpose hosts tend to have more configuration options than those that + are embedded in routers. + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use a stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. Using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group is currently studying an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns + a lifetime to configuration information obtained through DHCPv6. At + the expiration of the lifetime, the host contacts the DHCPv6 server + to obtain updated configuration information, including the list of + RDNSSes. This lifetime gives the network administrator another + mechanism to configure hosts with new RDNSSes by controlling the time + at which the host refreshes the list. + + + +Jeong Expires November 6, 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + The DHC Working Group has also discussed the possibility of defining + an extension to DHCPv6 that would allow the use of multicast to + provide configuration information to multiple hosts with a single + DHCPv6 message. Because of the lack of deployment experience, the WG + has deferred consideration of multicast DHCPv6 configuration at this + time. Experience with DHCPv4 has not identified a requirement for + multicast message delivery, even in large service provider networks + with tens of thousands of hosts that may initiate a DHCPv4 message + exchange simultaneously. + +3.2.1 Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1. DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. So configuring + DHCPv6 servers allows the network administrator to configure + RDNSSes along with the addresses of other network services, as + well as location-specific information like time zones. + + 2. As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be + managed through a single service, typically with a single user + interface and a single configuration database. + + 3. DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes as well as with other + configuration information. This capability is important in some + network deployments such as service provider networks or WiFi hot + spots. + + 4. A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5. Hosts that require other configuration information such as the + addresses of SIP servers and NTP servers are likely to need + DHCPv6 for other configuration information. + + 6. The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions such as new + options are necessary. + + 7. Interoperability among independent implementations has been + demonstrated. + + + + +Jeong Expires November 6, 2005 [Page 11] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3.2.2 Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These include: + + 1. Update currently requires message from server (however, see + [10]). + + 2. Because DNS information is not contained in RA messages, the host + must receive two messages from the router, and must transmit at + least one message to the router. On networks where bandwidth is + at a premium, this is a disadvantage, although on most networks + it is not a practical concern. + + 3. Increased latency for initial configuration - in addition to + waiting for an RA message, the client must now exchange packets + with a DHCPv6 server; even if it is locally installed on a + router, this will slightly extend the time required to configure + the client. For clients that are moving rapidly from one network + to another, this will be a disadvantage. + + +3.2.3 Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in addition + to a list of RDNSSes or if hosts must be configured selectively, + those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive + name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, on a cell phone network, where bandwidth is at a premium and + extremely low latency is desired. The final DNS configuration draft + should be written so as to allow these special applications to be + handled using DNS information in the RA packet. + +3.3 Well-known Anycast Addresses + + Anycast uses the same routing system as unicast [11]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peers routes to their internal anycast servers, if + they want to prohibit external access from some peers to the servers. + If some advertisement is inevitable (such as the case with default + routes), the packets to the servers should be blocked at the boundary + + + +Jeong Expires November 6, 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + of the entities. Thus, for this anycast, not only unicast routing + but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed at IPv6 Working Group in the past [9]. + It should be noted that "anycast" in this memo is simpler than that + of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be + prohibited to have multiple servers on a single link sharing an + anycast address. That is, on a link, an anycast address is assumed + to be unique. DNS clients today already have redundancy by having + multiple well-known anycast addresses configured as RDNSS addresses. + There is no point in having multiple RDNSSes sharing an anycast + address on a single link. + + The approach with well-known anycast addresses is to set multiple + well-known anycast addresses in clients' resolver configuration files + from the beginning, say, as factory default. Thus, there is no + transport mechanism and no packet format [9]. + + An anycast address is an address shared by multiple servers (in this + case, the servers are RDNSSes). A request from a client to the + anycast address is routed to a server selected by the routing system. + However, it is a bad idea to mandate "site" boundary on anycast + addresses, because most users just do not have their own servers and + want to access their ISPs' across their site boundaries. Larger + sites may also depend on their ISPs or may have their own RDNSSes + within "site" boundaries. + +3.3.1 Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, + + 1. There is no delay to get the response and no further delay by + packet losses. + + 2. The approach can be combined with any other configuration + mechanisms, such as the RA-based approach and DHCP based + approach, as well as the factory default configuration. + + 3. The approach works over any environment where DNS works. + + Another advantage is that the approach needs to configure DNS servers + as a router, but nothing else. Considering that DNS servers do need + configuration, the amount of overall configuration effort is + proportional to the number of the DNS servers and scales linearly. + It should be noted that, in the simplest case where a subscriber to + an ISP does not have any DNS server, the subscriber naturally + + + +Jeong Expires November 6, 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + accesses DNS servers of the ISP even though the subscriber and the + ISP do nothing and there is no protocol to exchange DNS server + information between the subscriber and the ISP. + +3.3.2 Disadvantages + + Well-known anycast addresses approach requires that DNS servers (or + routers near it as a proxy) act as routers to advertise their anycast + addresses to the routing system, which requires some configuration + (see the last paragraph of the previous section on the scalability of + the effort). + +3.3.3 Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce the configuration effort of users. + + The redundancy by multiple RDNSSes is better provided by multiple + servers having different anycast addresses than multiple servers + sharing the same anycast address because the former approach allows + stale servers to still generate routes to their anycast addresses. + Thus, in a routing domain (or domains sharing DNS servers), there + will be only one server having an anycast address unless the domain + is so large that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address which is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, where + the boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be able + to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC 1546 [11] + and RFC 3513 [12] where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related + instability disappears. Thus, anycast in well-known anycast + addresses approach can and should use the anycast address as a source + unicast (according to RFC 3513 [12]) address of packets of UDP and + TCP responses. With TCP, if a route flips and packets to an anycast + address are routed to a new server, it is expected that the flip is + detected by ICMP or sequence number inconsistency and the TCP + connection is reset and retried. + + + + +Jeong Expires November 6, 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork each other. + + For ordering between RA and DHCP approaches, the O (Other stateful + configuration) flag in RA message can be used [8][32]. If no RDNSS + option is included, an IPv6 host may perform DNS configuration + through DHCPv6 [5]-[7] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses as + the default configuration. Moreover, the clients preconfigured with + the well-known anycast addresses can be further configured to use + other approaches to override the well-known addresses, if the + configuration information from other approaches is available. + Otherwise, all the clients need to have the well-known anycast + addresses preconfigured. In order to use the anycast approach along + with two other approaches, there are three choices as follows: + + 1. The first choice is that well-known addresses are used as last + resort, when an IPv6 host cannot get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be + preconfigured in all of IPv6 hosts' resolver configuration files. + + 2. The second is that an IPv6 host can configure well-known + addresses as the most preferable in its configuration file even + though either an RA option or DHCP option is available. + + 3. The last is that the well-known anycast addresses can be set in + RA or DHCP configuration to reduce the configuration effort of + users. According to either the RA or DHCP mechanism, the well- + known addresses can be obtained by an IPv6 host. Because this + approach is the most convenient for users, the last option is + recommended. + + +Note + + This section does not necessarily mean this document suggests + adopting all these three approaches and making them interwork in the + way described here. In fact, some approaches may even not be adopted + at all as a result of further discussion. + + + + + +Jeong Expires November 6, 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5. Deployment Scenarios + + Regarding the DNS configuration on the IPv6 host, several mechanisms + are being considered at the DNSOP Working Group such as RA option, + DHCPv6 option and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. In + this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + +Note + + In the applicable scenarios, authors do not implicitly push any + specific approaches into the restricted environments. No enforcement + is in each scenario and all mentioned scenarios are probable. The + main objective of this work is to provide a useful guideline for IPv6 + DNS configuration. + +5.1 ISP Network + + A characteristic of ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and each PE connects multiple CPE devices to the backbone + network infrastructure [13]. The CPEs may be hosts or routers. + + In the case where the CPE is a router, there is a customer network + that is connected to the ISP backbone through the CPE. Typically, + each customer network gets a different IPv6 prefix from an IPv6 PE + router, but the same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1 RA Option Approach + + When the CPE is a host, the RA option for RDNSS can be used to allow + the CPE to get RDNSS information as well as /64 prefix information + for stateless address autoconfiguration at the same time when the + host is attached to a new subnet [8]. Because an IPv6 host must + receive at least one RA message for stateless address + autoconfiguration and router configuration, the host could receive + RDNSS configuration information in that RA without the overhead of an + additional message exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP, and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in which + + + +Jeong Expires November 6, 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + the host must receive at least an RA message for detecting a new + network, than in other scenarios generally although administrator + should configure RDNSS information on the routers. Secure ND [14] + can provide extended security when using RA messages. + +5.1.2 DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the DNS + option, and can provide other configuration information in the same + message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is + already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or + stateless DHCP [6] is nowhere as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISPs can + handle user identification on its network intentionally, and also + authenticated DHCP [15] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the customer + gateway to assign a /64 prefix to each network in the customer's + network. Prefix delegation with DHCP (DHCPv6 PD) has already been + adopted by ISPs for automating the assignment of the customer prefix + to the customer gateway [17]. DNS configuration can be carried in + the same DHCPv6 message exchange used for DHCPv6 to efficiently + provide that information, along with any other configuration + information needed by the customer gateway or customer network. This + service model can be useful to Home or SOHO subscribers. The Home or + SOHO gateway, which is a customer gateway for ISP, can then pass that + RDNSS configuration information to the hosts in the customer network + through DHCP. + +5.1.3 Well-known Anycast Addresses Approach + + The well-known anycast addresses approach is also a feasible and + simple mechanism for ISP [9]. The use of well-known anycast + addresses avoids some of the security risks in rogue messages sent + through an external protocol like RA or DHCPv6. The configuration of + hosts for the use of well-known anycast addresses requires no + protocol or manual configuration, but the configuration of routing + for the anycast addresses requires intervention on the part of the + network administrator. Also, the number of special addresses would + be equal to the number of RDNSSes that could be made available to + subscribers. + +5.2 Enterprise Network + + Enterprise network is defined as a network that has multiple internal + links, one or more router connections, to one or more Providers and + is actively managed by a network operations entity [16]. An + + + +Jeong Expires November 6, 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + enterprise network can get network prefixes from an ISP by either + manual configuration or prefix delegation [17]. In most cases, + because an enterprise network manages its own DNS domains, it + operates its own DNS servers for the domains. These DNS servers + within enterprise network process recursive DNS name resolution + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the + enterprise network can be performed like in Section 4, in which three + approaches can be used together as follows: + + 1. An IPv6 host can decide which approach is or may be used in its + subnet with the O flag in RA message [8][32]. As the first + choice in Section 4, well-known anycast addresses can be used as + a last resort when RDNSS information cannot be obtained through + either an RA option or DHCP option. This case needs IPv6 hosts + to preconfigure the well-known anycast addresses in their DNS + configuration files. + + 2. When the enterprise prefers the well-known anycast approach to + others, IPv6 hosts should preconfigure the well-known anycast + addresses like in the first choice. + + 3. The last choice, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + because the addresses are delivered to IPv6 hosts via either the + RA option or DHCPv6 option as if they were unicast addresses. + This way is most recommended for the sake of user's convenience. + + +5.3 3GPP Network + + The IPv6 DNS configuration is a missing part of IPv6 + autoconfiguration and an important part of the basic IPv6 + functionality in the 3GPP User Equipment (UE). The higher level + description of the 3GPP architecture can be found in [18], and + transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. + + In the 3GPP architecture, there is a dedicated link between the UE + and the GGSN called the Packet Data Protocol (PDP) Context. This + link is created through the PDP Context activation procedure [21]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If a + 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP + context), it cannot be assumed that (s)he has simultaneously an + active IPv4 PDP context, and DNS queries could be done using IPv4. A + 3GPP UE can thus be an IPv6 node, and it needs to somehow discover + the address of the RDNSS. Before IP-based services (e.g., web + browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses + need to be discovered in the 3GPP UE. + + + + +Jeong Expires November 6, 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the Well-known addresses approach. + Section 5.3.5 finally summarizes the recommendations. + +5.3.1 Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism, in which RDNSS addresses can be + received in the PDP context activation (a control plane mechanism). + That is called the Protocol Configuration Options Information Element + (PCO-IE) mechanism [22]. The RDNSS addresses can also be received + over the air (using text messages), or typed in manually in the UE. + Note that the two last mechanisms are not very well scalable. The UE + user most probably does not want to type IPv6 RDNSS addresses + manually in his/her UE. The use of well-known addresses is briefly + discussed in section 5.3.4. + + It is seen that the mechanisms above most probably are not sufficient + for the 3GPP environment. IPv6 is intended to operate in a zero- + configuration manner, no matter what the underlying network + infrastructure is. Typically, the RDNSS address is needed to make an + IPv6 node operational - and the DNS configuration should be as simple + as the address autoconfiguration mechanism. It must also be noted + that there will be additional IP interfaces in some near future 3GPP + UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such + as PCO-IE [22]) do not work for those IP interfaces. In other words, + a good IPv6 DNS configuration mechanism should also work in a multi- + access network environment. + + From a 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (can be even + hundreds of millions in one operator's network), is automatic and + thus requires no user action. It is suggested to standardize a + lightweight, stateless mechanism that works in all network + environments. The solution could then be used for 3GPP, 3GPP2, WLAN + and other access network technologies. A light, stateless IPv6 DNS + configuration mechanism is thus not only needed in 3GPP networks, but + also 3GPP networks and UEs would certainly benefit from the new + mechanism. + +5.3.2 RA Extension + + Router Advertisement extension [8] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in the 3GPP UE + IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified in + the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs + + + +Jeong Expires November 6, 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + and GGSNs + + In this solution, an IPv6-capable UE configures DNS information via + RA message sent by its default router (GGSN), i.e., RDNSS option for + recursive DNS server is included in the RA message. This solution is + easily scalable for a very large number of UEs. The operator can + configure the RDNSS addresses in the GGSN as a part of normal GGSN + configuration. The IPv6 RDNSS address is received in the Router + Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS + addresses can be avoided. + + If thinking about the cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3 Stateless DHCPv6 + + DHCPv6-based solution needs the implementation of Stateless DHCP [6] + and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the + operator's network. A possible configuration is such that the GGSN + works as a DHCP relay. + + Pros for Stateless DHCPv6-based solution are + + 1. Stateless DHCPv6 is a standardized mechanism. + + 2. DHCPv6 can be used for receiving other configuration information + than RDNSS addresses, e.g., SIP server addresses. + + 3. DHCPv6 works in different network environments. + + 4. When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + Some issues with DHCPv6 in 3GPP networks are listed below: + + 1. DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into a router + already existing, and that means one box more to be maintained. + + 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used), and + not automatically implemented in 3GPP IPv6 UEs. + + + + + +Jeong Expires November 6, 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + 3. Scalability and reliability of DHCPv6 in very large 3GPP networks + (with tens or hundreds of millions of UEs) may be an issue, at + least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as a + router operating system, scalability and reliability is + comparable with other DNS configuration approaches. + + 4. It is sub-optimal to utilize the radio resources in 3GPP networks + for DHCPv6 messages if there is a simpler alternative available. + + * The use of Stateless DHCPv6 adds one round trip delay to the + case in which the UE can start transmitting data right after + the Router Advertisement. + + 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can + not automatically update the UE, see [23]. + + +5.3.4 Well-known Addresses + + Using well-known addresses is also a feasible and a light mechanism + for 3GPP UEs. Those well-known addresses can be preconfigured in the + UE software and the operator makes the corresponding configuration on + the network side. So this is a very easy mechanism for the UE, but + requires some configuration work in the network. When using well- + known addresses, UE forwards queries to any of the preconfigured + addresses. In the current proposal [9], IPv6 anycast addresses are + suggested. + +Note + + The IPv6 DNS configuration proposal based on the use of well-known + site-local addresses developed at the IPv6 Working Group was seen as + a feasible mechanism for 3GPP UEs, but opposition by some people in + the IETF and finally deprecating IPv6 site-local addresses made it + impossible to standardize it. Note that this mechanism is + implemented in some existing operating systems today (also in some + 3GPP UEs) as a last resort of IPv6 DNS configuration. + +5.3.5 Recommendations + + It is suggested that a lightweight, stateless DNS configuration + mechanism is specified as soon as possible. From a 3GPP UE and + network point of view, the Router Advertisement based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can get rid of using well-known site-local + addresses for IPv6 DNS configuration. + + + + +Jeong Expires November 6, 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5.4 Unmanaged Network + + There are 4 deployment scenarios of interest in unmanaged networks + [24]: + + 1. A gateway which does not provide IPv6 at all; + + 2. A dual-stack gateway connected to a dual-stack ISP; + + 3. A dual-stack gateway connected to an IPv4-only ISP; and + + 4. A gateway connected to an IPv6-only ISP. + + +5.4.1 Case A: Gateway does not provide IPv6 at all + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT, that need access to an + IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration + mechanism has to work over the tunnel, and the underlying tunneling + mechanism could be implementing NAT traversal. The tunnel server + assumes the role of a relay (both for DHCP and Well-known anycast + addresses approaches). + + RA-based mechanism is relatively straightforward in its operation, + assuming the tunnel server is also the IPv6 router emitting RAs. + Well-known anycast addresses approach seems also simple in operation + across the tunnel, but the deployment model using Well-known anycast + addresses in a tunneled environment is unclear or not well + understood. + +5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. Except that + Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the + DHCP server is stateful (maintains the state for clients). + +5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity by + managing tunnels, then it is also supposed to provide access to an + RDNSS. Like this, the tunnel for IPv6 connectivity originates from + the dual-stack gateway instead of the host. + + + + +Jeong Expires November 6, 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5.4.4 Case D: A gateway connected to an IPv6-only ISP + + This is similar to Case B. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +6. Security Considerations + + As security requirements depend solely on applications and are + different application by application, there can be no generic + requirement defined at IP or application layer for DNS. + + However, it should be noted that cryptographic security requires + configured secret information that full autoconfiguration and + cryptographic security are mutually exclusive. People insisting on + secure full autoconfiguration will get false security, false + autoconfiguration or both. + + In some deployment scenarios [19], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured through which application + specific configuration data, including those for DNS, can be securely + configured. It should be noted that if applications requiring + cryptographic security depend on DNS, the applications also require + cryptographic security to DNS. Therefore, the full autoconfiguration + of DNS is not acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be acceptable. + That is, with full autoconfiguration, which means there is no + cryptographic security for the autoconfiguration, it is already + assumed that the local environment is secure enough that the + information from the local autoconfiguration server has acceptable + security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, because + DNSSEC [29] needs the configuration and reconfiguration of clients at + root key roll-over [30][31]. Even if additional keys for secure key + roll-over are added at the initial configuration, they are as + vulnerable as the original keys to some forms of attacks, such as + social hacking. Another problem of using DNSSEC and + autoconfiguration together is that DNSSEC requires secure time, which + means secure communication with autoconfigured time servers, which + requires configured secret information. Therefore, in order that the + autoconfiguration may be secure, it requires configured secret + information. + + If DNSSEC [29] is used and the signatures are verified on the client + host, the misconfiguration of a DNS server may be simply denial of + service. Also, if local routing environment is not reliable, clients + may be directed to a false resolver with the same IP address as the + true one. + + + +Jeong Expires November 6, 2005 [Page 24] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +6.1 RA Option + + The security of RA option for RDNSS is the same as the ND protocol + security [3][8]. The RA option does not add any new vulnerability. + + It should be noted that the vulnerability of ND is not worse and is a + subset of the attacks that any node attached to a LAN can do + independently of ND. A malicious node on a LAN can promiscuously + receive packets for any router's MAC address and send packets with + the router's MAC address as the source MAC address in the L2 header. + As a result, the L2 switches send packets addressed to the router to + the malicious node. Also, this attack can send redirects that tell + the hosts to send their traffic somewhere else. The malicious node + can send unsolicited RA or NA replies, answer RS or NS requests, etc. + All of this can be done independently of implementing ND. Therefore, + the RA option for RDNSS does not add to the vulnerability. + + Security issues regarding the ND protocol were discussed at IETF SEND + (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND + security has been published [14]. + +6.2 DHCPv6 Option + + The DNS Recursive Name Server option may be used by an intruder DHCP + server to cause DHCP clients to send DNS queries to an intruder DNS + recursive name server [7]. The results of these misdirected DNS + queries may be used to spoof DNS names. + + To avoid attacks through the DNS Recursive Name Server option, the + DHCP client SHOULD require DHCP authentication (see section + "Authentication of DHCP messages" in RFC 3315 [5]) before installing + a list of DNS recursive name servers obtained through authenticated + DHCP. + +6.3 Well-known Anycast Addresses + + Well-known anycast addresses does not require configuration security + since there is no protocol [9]. + + The DNS server with the preconfigured addresses are still reasonably + reliable, if local environment is reasonably secure, that is, there + is no active attackers receiving queries to the anycast addresses of + the servers and reply to them. + + + + + + + + +Jeong Expires November 6, 2005 [Page 25] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +7. Contributors + + Ralph Droms + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxboro, MA 01719 + US + + Phone: +1 978 936 1674 + Email: rdroms@cisco.com + + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + US + + Phone: +1 650 625 2004 + Email: bob.hinden@nokia.com + + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + US + + Email: Ted.Lemon@nominum.com + + + Masataka Ohta + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + Email: mohta@necom830.hpcl.titech.ac.jp + + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + + + +Jeong Expires November 6, 2005 [Page 26] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Phone: +82 31 200 4508 + Email: soohong.park@samsung.com + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + US + + Email: satapati@cisco.com + + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720, TAMPERE + Finland + + Phone: +358 7180 48372 + Email: juha.wiljakka@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 27] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +8. Acknowledgements + + This draft has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + Also, Tony Bonanno proofread this draft. The authors appreciate + their contribution. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 28] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +9. References + +9.1 Normative References + + [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, + February 2004. + + [2] Bradner, S., "Intellectual Property Rights in IETF Technology", + RFC 3668, February 2004. + + [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [4] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) + Service for IPv6", RFC 3736, April 2004. + + [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + +9.2 Informative References + + [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS + Discovery based on Router Advertisement", + draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), + February 2005. + + [9] Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01.txt (Work in Progress), + February 2004. + + [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in + Progress), January 2005. + + [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 + + + +Jeong Expires November 6, 2005 [Page 29] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + into ISP Networks", RFC 4029, March 2005. + + [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + + [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", + draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), + July 2004. + + [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP + Standards", RFC 3314, September 2002. + + [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", + RFC 3574, August 2003. + + [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in + Progress), October 2004. + + [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless DHCPv6", + draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in + Progress), October 2004. + + [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition + Scenarios", RFC 3750, April 2004. + + [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", + March 1999. + + [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: High-speed + Physical Layer in the 5 GHZ Band", September 1999. + + + +Jeong Expires November 6, 2005 [Page 30] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: Higher-Speed + Physical Layer Extension in the 2.4 GHz Band", September 1999. + + [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) specifications: Further + Higher Data Rate Extension in the 2.4 GHz Band", April 2003. + + [29] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in + Progress), December 2004. + + [31] Guette, G. and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", + draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in + Progress), January 2005. + + [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M + and O Flags of IPv6 Router Advertisement", + draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), + March 2005. + + +Author's Address + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + US + + Phone: +1 651 587 7774 + Fax: +1 612 625 2002 + Email: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 31] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Appendix A. Link-layer Multicast Acknowledgements for RA Option + + One benefit of an RA option [8] is to be able to multicast the + advertisements, reducing the need for duplicated unicast + communications. + + However, some link-layers may not support this as well as others. + Consider, for example, WLAN networks where multicast is unreliable. + The unreliability problem is caused by lack of ACK for multicast, + especially on the path from the Access Point (AP) to the Station + (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 + a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on + the path from the AP to the STA, but acknowledged in the reverse + direction from the STA to the AP [25]. For example, when a router is + placed at wired network connected to an AP, a host may sometimes not + receive RA message advertised through the AP. Therefore, the RA + option solution might not work well on a congested medium that uses + unreliable multicast for RA. + + The fact that this problem has not been addressed in Neighbor + Discovery [3] indicates that the extra link-layer acknowledgements + have not been considered a serious problem till now. + + A possible mitigation technique could be to map all-nodes link- local + multicast address to the link-layer broadcast address, and to rely on + the ND retransmissions for message delivery in order to achieve more + reliability. + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 32] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Jeong Expires November 6, 2005 [Page 33] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt new file mode 100644 index 000000000000..1276f9f91d62 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt @@ -0,0 +1,1682 @@ + + + + +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: January 17, 2006 J. Ihren + Autonomica + P. Savola + CSC/FUNET + July 16, 2005 + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-11.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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 January 17, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + service provisioning and for DNS resolver IPv6 support, + + + +Durand, et al. Expires January 17, 2006 [Page 1] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 + 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 + 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 + 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 + 4. Recommendations for Service Provisioning using DNS . . . . . . 7 + 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 + 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 + 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 + 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 + 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 + 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 13 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + + + +Durand, et al. Expires January 17, 2006 [Page 2] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 + A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 + B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 + B.1 Description of Additional Data Scenarios . . . . . . . . . 26 + B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 + B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 17, 2006 [Page 3] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +1. Introduction + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + The purpose of this document is to give information about various + issues and considerations related to DNS operations with IPv6; it is + not meant to be a normative specification or standard for IPv6 DNS. + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for unique local addressing. + +1.1 Representing IPv6 Addresses in DNS Records + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. tree. See + [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] + for background information. + + In particular one should note that the use of A6 records in the + forward tree or Bitlabels in the reverse tree is not recommended + [RFC3363]. Using DNAME records is not recommended in the reverse + tree in conjunction with A6 records; the document did not mean to + take a stance on any other use of DNAME records [RFC3364]. + +1.2 Independence of DNS Transport and DNS Records + + DNS has been designed to present a single, globally unique name space + [RFC2826]. This property should be maintained, as described here and + + + +Durand, et al. Expires January 17, 2006 [Page 4] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + in Section 1.3. + + The IP version used to transport the DNS queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make + any assumptions about what data to return for Answer and Authority + sections based on the underlying transport used in a query. + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + at all). + + As stated in [RFC3596]: + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines [RFC3901] for more information. + +1.4 Query Type '*' and A/AAAA Records + + QTYPE=* is typically only used for debugging or management purposes; + it is worth keeping in mind that QTYPE=* ("ANY" queries) only return + any available RRsets, not *all* the RRsets, because the caches do not + necessarily have all the RRsets and have no way of guaranteeing that + they have all the RRsets. Therefore, to get both A and AAAA records + reliably, two separate queries must be made. + +2. DNS Considerations about Special IPv6 Addresses + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + + + + + + +Durand, et al. Expires January 17, 2006 [Page 5] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +2.1 Limited-scope Addresses + + The IPv6 addressing architecture [RFC3513] includes two kinds of + local-use addresses: link-local (fe80::/10) and site-local + (fec0::/10). The site-local addresses have been deprecated [RFC3879] + but are discussed with unique local addresses in Appendix A. + + Link-local addresses should never be published in DNS (whether in + forward or reverse tree), because they have only local (to the + connected link) significance [I-D.durand-dnsop-dont-publish]. + +2.2 Temporary Addresses + + Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + "privacy addresses") use a random number as the interface identifier. + Having DNS AAAA records that are updated to always contain the + current value of a node's temporary address would defeat the purpose + of the mechanism and is not recommended. However, it would still be + possible to return a non-identifiable name (e.g., the IPv6 address in + hexadecimal format), as described in [RFC3041]. + +2.3 6to4 Addresses + + 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps + a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of possible ways to do so. + + The main proposal [I-D.huston-6to4-reverse-dns] aims to design an + autonomous reverse-delegation system that anyone being capable of + communicating using a specific 6to4 address would be able to set up a + reverse delegation to the corresponding 6to4 prefix. This could be + deployed by e.g., Regional Internet Registries (RIRs). This is a + practical solution, but may have some scalability concerns. + +2.4 Other Transition Mechanisms + + 6to4 is mentioned as a case of an IPv6 transition mechanism requiring + special considerations. In general, mechanisms which include a + special prefix may need a custom solution; otherwise, for example + when IPv4 address is embedded as the suffix or not embedded at all, + special solutions are likely not needed. + + Note that it does not seem feasible to provide reverse DNS with + another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- + teredo]; this is because the IPv6 address is based on the IPv4 + address and UDP port of the current NAT mapping which is likely to be + + + +Durand, et al. Expires January 17, 2006 [Page 6] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + relatively short-lived. + +3. Observed DNS Implementation Misbehaviour + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + +3.1 Misbehaviour of DNS Servers and Load-balancers + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented [RFC4074]: some + implementations silently drop queries for unimplemented DNS records + types, or provide wrong answers to such queries (instead of a proper + negative reply). While typically these issues are not limited to + AAAA records, the problems are aggravated by the fact that AAAA + records are being queried instead of (mainly) A records. + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- + if the first query is never responded to (instead of properly + returning a negative answer), significant timeouts will occur. + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g., by performing the + lookups somewhat in parallel and reducing the timeout as long as at + least one answer has been received; but such methods remain to be + investigated; slightly more on this is included in Section 5. + +3.2 Misbehaviour of DNS Resolvers + + Several classes of misbehaviour have also been noticed in DNS + resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem + to directly impair IPv6 use, and are only referred to for + completeness. + +4. Recommendations for Service Provisioning using DNS + + When names are added in the DNS to facilitate a service, there are + + + +Durand, et al. Expires January 17, 2006 [Page 7] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + several general guidelines to consider to be able to do it as + smoothly as possible. + +4.1 Use of Service Names instead of Node Names + + It makes sense to keep information about separate services logically + separate in the DNS by using a different DNS hostname for each + service. There are several reasons for doing this, for example: + + o It allows more flexibility and ease for migration of (only a part + of) services from one node to another, + + o It allows configuring different properties (e.g., TTL) for each + service, and + + o It allows deciding separately for each service whether to publish + the IPv6 addresses or not (in cases where some services are more + IPv6-ready than others). + + Using SRV records [RFC2782] would avoid these problems. + Unfortunately, those are not sufficiently widely used to be + applicable in most cases. Hence an operation technique is to use + service names instead of node names (or, "hostnames"). This + operational technique is not specific to IPv6, but required to + understand the considerations described in Section 4.2 and + Section 4.3. + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one could use + e.g., "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of SMTP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. (Obviously, when wanting to reach a specific node, one + should use the hostname rather than a service name.) + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could either be added to "service.example.com", or added + separately under a different name, e.g., in a sub-domain, like, + "service.ipv6.example.com". + + + + +Durand, et al. Expires January 17, 2006 [Page 8] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + These two methods have different characteristics. Using a different + name allows for easier service piloting, minimizing the disturbance + to the "regular" users of IPv4 service; however, the service would + not be used transparently, without the user/application explicitly + finding it and asking for it -- which would be a disadvantage in most + cases. When the different name is under a sub-domain, if the + services are deployed within a restricted network (e.g., inside an + enterprise), it's possible to prefer them transparently, at least to + a degree, by modifying the DNS search path; however, this is a + suboptimal solution. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see + Section 4.3 for more). + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + +4.3 Adding the Records Only when Fully IPv6-enabled + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + 1. The address is assigned to the interface on the node. + + 2. The address is configured on the interface. + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be IPv6- + enabled prior to adding the resource record. + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + The issues are not always so black-and-white. Usually it's important + that the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + + + +Durand, et al. Expires January 17, 2006 [Page 9] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + latency, throughput, low packet loss, general reliability, etc.) -- + this is typically very important especially for interactive or real- + time services. In many cases, the quality of IPv6 connectivity may + not yet be equal to that of IPv4, at least globally -- this has to be + taken into consideration when enabling services. + +4.4 The Use of TTL for IPv4 and IPv6 RRs + + The behaviour of DNS caching when different TTL values are used for + different RRsets of the same name calls for explicit discussion. For + example, let's consider two unrelated zone fragments: + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + ... + + child.example.com. 300 IN NS ns.child.example.com. + ns.child.example.com. 300 IN A 192.0.2.1 + ns.child.example.com. 100 IN AAAA 2001:db8::1 + + In the former case, we have "courtesy" additional data; in the + latter, we have "critical" additional data. See more extensive + background discussion of additional data handling in Appendix B. + +4.4.1 TTL With Courtesy Additional Data + + When a caching resolver asks for the MX record of example.com, it + gets back "foo.example.com". It may also get back either one or both + of the A and AAAA records in the additional section. The resolver + must explicitly query for both A and AAAA records [RFC2821]. + + After 100 seconds, the AAAA record is removed from the cache(s) + because its TTL expired. It could be argued to be useful for the + caching resolvers to discard the A record when the shorter TTL (in + this case, for the AAAA record) expires; this would avoid the + situation where there would be a window of 200 seconds when + incomplete information is returned from the cache. Further argument + for discarding is that in the normal operation, the TTL values are so + high that very likely the incurred additional queries would not be + noticeable, compared to the obtained performance optimization. The + behaviour in this scenario is unspecified. + +4.4.2 TTL With Critical Additional Data + + The difference to courtesy additional data is that the A/AAAA records + served by the parent zone cannot be queried explicitly. Therefore + + + +Durand, et al. Expires January 17, 2006 [Page 10] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + after 100 seconds the AAAA record is removed from the cache(s), but + the A record remains. Queries for the remaining 200 seconds + (provided that there are no further queries from the parent which + could refresh the caches) only return the A record, leading to a + potential opererational situation with unreachable servers. + + Similar cache flushing strategies apply in this scenario; the record. + +4.5 IPv6 Transport Guidelines for DNS Servers + + As described in Section 1.3 and [RFC3901], there should continue to + be at least one authoritative IPv4 DNS server for every zone, even if + the zone has only IPv6 records. (Note that obviously, having more + servers with robust connectivity would be preferable, but this is the + minimum recommendation; also see [RFC2182].) + +5. Recommendations for DNS Resolver IPv6 Support + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + + + +Durand, et al. Expires January 17, 2006 [Page 11] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal, at least without + information sharing between the look-up threads, as that would + probably lead to duplicate non-cached delegation chain lookups). + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records even when the node + does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. + In some cases, the implementation may attempt to connect or send a + datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], + incurring very long protocol timeouts, instead of quickly failing + back to IPv4. + + Now, we can consider the issues specific to each of the three + possibilities: + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [RFC4038]. + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That is, + performing DNS lookups only when a non-link-local address has been + configured on any interface could be beneficial -- this would be an + indication that either the address has been configured either from a + router advertisement, DHCPv6 [RFC3315], or manually. Each would + + + +Durand, et al. Expires January 17, 2006 [Page 12] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + indicate at least some form of IPv6 connectivity, even though there + would not be guarantees of it. + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + +5.2 Obtaining a List of DNS Recursive Resolvers + + In scenarios where DHCPv6 is available, a host can discover a list of + DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" + option [RFC3646]. This option can be passed to a host through a + subset of DHCPv6 [RFC3736]. + + The IETF is considering the development of alternative mechanisms for + obtaining the list of DNS recursive name servers when DHCPv6 is + unavailable or inappropriate. No decision about taking on this + development work has been reached as of this writing (Aug 2004) + [I-D.ietf-dnsop-ipv6-dns-configuration]. + + In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms + under consideration for development include the use of well-known + addresses [I-D.ohta-preconfigured-dns] and the use of Router + Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- + discovery]. + + Note that even though IPv6 DNS resolver discovery is a recommended + procedure, it is not required for dual-stack nodes in dual-stack + networks as IPv6 DNS records can be queried over IPv4 as well as + IPv6. Obviously, nodes which are meant to function without manual + configuration in IPv6-only networks must implement the DNS resolver + discovery function. + +5.3 IPv6 Transport Guidelines for Resolvers + + As described in Section 1.3 and [RFC3901], the recursive resolvers + should be IPv4-only or dual-stack to be able to reach any IPv4-only + DNS server. Note that this requirement is also fulfilled by an IPv6- + only stub resolver pointing to a dual-stack recursive DNS resolver. + +6. Considerations about Forward DNS Updating + + While the topic of how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it should be considered especially due to the advent of + Stateless Address Autoconfiguration [RFC2462]. + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can often be assumed to "own" a + + + +Durand, et al. Expires January 17, 2006 [Page 13] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + certain DNS name -- and we can create a form of security relationship + with the DNS name and the node which is allowed to update it to point + to a new address. + + A more complex form of DNS updates -- adding a whole new name into a + DNS zone, instead of updating an existing name -- is considered out + of scope for this memo as it could require zone-wide authentication. + Adding a new name in the forward zone is a problem which is still + being explored with IPv4, and IPv6 does not seem to add much new in + that area. + +6.1 Manual or Custom DNS Updates + + The DNS mappings can also be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + +6.2 Dynamic DNS + + Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized + mechanism for dynamically updating the DNS. It works equally well + with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + address configuration. It is important to consider how each of these + behave if IP address-based authentication, instead of stronger + mechanisms [RFC3007], was used in the updates. + + 1. manual addresses are static and can be configured + + 2. DHCPv6 addresses could be reasonably static or dynamic, depending + on the deployment, and could or could not be configured on the + DNS server for the long term + + 3. SLAAC addresses are typically stable for a long time, but could + require work to be configured and maintained. + + As relying on IP addresses for Dynamic DNS is rather insecure at + best, stronger authentication should always be used; however, this + requires that the authorization keying will be explicitly configured + using unspecified operational methods. + + Note that with DHCP it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + + + +Durand, et al. Expires January 17, 2006 [Page 14] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + host should not be able to state that its name is "www.example.com"). + DHCP-initiated DDNS updates have been extensively described in + [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and + [I-D.ietf-dnsext-dhcid-rr]. + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authoritative name servers + for the hostname; the second must be configured explicitly unless one + chooses to trust the IP address-based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g., at install time. + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the addresses, so + that if the node is renumbered in a managed fashion, the amount of + stale DNS information is kept to the minimum. That is, if the + preferred lifetime of an address expires, the TTL of the record needs + be modified unless it was already done before the expiration. For + better flexibility, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not been + renewed/refreshed in a while. Some discussion on how an + administrator could manage the DNS TTL is included in [I-D.ietf- + v6ops-renumbering-procedure]; this could be applied to (smart) hosts + as well. + +7. Considerations about Reverse DNS Updating + + Updating the reverse DNS zone may be difficult because of the split + authority over an address. However, first we have to consider the + applicability of reverse DNS in the first place. + +7.1 Applicability of Reverse DNS + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + One additional, maybe slightly more useful usage is ensuring that the + reverse and forward DNS contents match (by looking up the pointer to + the name by the IP address from the reverse tree, and ensuring that a + + + +Durand, et al. Expires January 17, 2006 [Page 15] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + record under the name in the forward tree points to the IP address) + and correspond to a configured name or domain. As a security check, + it is typically accompanied by other mechanisms, such as a user/ + password login; the main purpose of the reverse+forward DNS check is + to weed out the majority of unauthorized users, and if someone + managed to bypass the checks, he would still need to authenticate + "properly". + + It may also be desirable to store IPsec keying material corresponding + to an IP address in the reverse DNS, as justified and described in + [RFC4025]. + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + which use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + The applicability is discussed at more length in [I-D.ietf-dnsop- + inaddr-required]. + +7.2 Manual or Custom DNS Updates + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + As a concrete example, a site (or the site's ISP) could configure the + reverses of the prefix 2001:db8:f00::/48 to point to one name using a + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com." Naturally, such a name could not be verified from + the forward DNS, but would at least provide some form of "topological + information" or "weak authorization" if that is really considered to + be useful. Note that this is not actually updating the DNS as such, + as the whole point is to avoid DNS updates completely by manually + configuring a generic name. + +7.3 DDNS with Stateless Address Autoconfiguration + + Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in + some regard, while being more difficult in another, as described + below. + + The address space administrator decides whether the hosts are trusted + to update their reverse DNS records or not. If they are trusted and + + + +Durand, et al. Expires January 17, 2006 [Page 16] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + deployed at the same site (e.g., not across the Internet), a simple + address-based authorization is typically sufficient (i.e., check that + the DNS update is done from the same IP address as the record being + updated); stronger security can also be used [RFC3007]. If they + aren't allowed to update the reverses, no update can occur. However, + such address-based update authorization operationally requires that + ingress filtering [RFC3704] has been set up at the border of the site + where the updates occur, and as close to the updater as possible. + + Address-based authorization is simpler with reverse DNS (as there is + a connection between the record and the address) than with forward + DNS. However, when a stronger form of security is used, forward DNS + updates are simpler to manage because the host can be assumed to have + an association with the domain. Note that the user may roam to + different networks, and does not necessarily have any association + with the owner of that address space -- so, assuming stronger form of + authorization for reverse DNS updates than an address association is + generally infeasible. + + Moreover, the reverse zones must be cleaned up by an unspecified + janitorial process: the node does not typically know a priori that it + will be disconnected, and cannot send a DNS update using the correct + source address to remove a record. + + A problem with defining the clean-up process is that it is difficult + to ensure that a specific IP address and the corresponding record are + no longer being used. Considering the huge address space, and the + unlikelihood of collision within 64 bits of the interface + identifiers, a process which would remove the record after no traffic + has been seen from a node in a long period of time (e.g., a month or + year) might be one possible approach. + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in + Section 6.2. One way to automate this is looking up the DNS server + authoritative (e.g., through SOA record) for the IP address being + updated, but the security material (unless the IP address-based + authorization is trusted) must also be established by some other + means. + + One should note that Cryptographically Generated Addresses [RFC3972] + (CGAs) may require a slightly different kind of treatment. CGAs are + addresses where the interface identifier is calculated from a public + key, a modifier (used as a nonce), the subnet prefix, and other data. + Depending on the usage profile, CGAs might or might not be changed + periodically due to e.g., privacy reasons. As the CGA address is not + predicatable, a reverse record can only reasonably be inserted in the + DNS by the node which generates the address. + + + +Durand, et al. Expires January 17, 2006 [Page 17] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +7.4 DDNS with DHCP + + With DHCPv4, the reverse DNS name is typically already inserted to + the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + can assume similar practice may become commonplace with DHCPv6 as + well; all such mappings would be pre-configured, and would require no + updating. + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one (if an address + assignment policy that reassigns disused addresses is adopted) and + updating a record seems like a slightly more difficult thing to + secure. However, it is yet uncertain how DHCPv6 is going to be used + for address assignment. + + Note that when using DHCP, either the host or the DHCP server could + perform the DNS updates; see the implications in Section 6.2. + + If disused addresses were to be reassigned, host-based DDNS reverse + updates would need policy considerations for DNS record modification, + as noted above. On the other hand, if disused address were not to be + assigned, host-based DNS reverse updates would have similar + considerations as SLAAC in Section 7.3. Server-based updates have + similar properties except that the janitorial process could be + integrated with DHCP address assignment. + +7.5 DDNS with Dynamic Prefix Delegation + + In cases where a prefix, instead of an address, is being used and + updated, one should consider what is the location of the server where + DDNS updates are made. That is, where the DNS server is located: + + 1. At the same organization as the prefix delegator. + + 2. At the site where the prefixes are delegated to. In this case, + the authority of the DNS reverse zone corresponding to the + delegated prefix is also delegated to the site. + + 3. Elsewhere; this implies a relationship between the site and where + DNS server is located, and such a relationship should be rather + straightforward to secure as well. Like in the previous case, + the authority of the DNS reverse zone is also delegated. + + In the first case, managing the reverse DNS (delegation) is simpler + as the DNS server and the prefix delegator are in the same + administrative domain (as there is no need to delegate anything at + all); alternatively, the prefix delegator might forgo DDNS reverse + + + +Durand, et al. Expires January 17, 2006 [Page 18] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + capability altogether, and use e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slighly more + difficult, particularly as the site will have to configure the DNS + server to be authoritative for the delegated reverse zone, implying + automatic configuration of the DNS server -- as the prefix may be + dynamic. + + Managing the DDNS reverse updates is typically simple in the second + case, as the updated server is located at the local site, and + arguably IP address-based authentication could be sufficient (or if + not, setting up security relationships would be simpler). As there + is an explicit (security) relationship between the parties in the + third case, setting up the security relationships to allow reverse + DDNS updates should be rather straightforward as well (but IP + address-based authentication might not be acceptable). In the first + case, however, setting up and managing such relationships might be a + lot more difficult. + +8. Miscellaneous DNS Considerations + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + +8.1 NAT-PT with DNS-ALG + + The DNS-ALG component of NAT-PT mangles A records to look like AAAA + records to the IPv6-only nodes. Numerous problems have been + identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is + a strong reason not to use NAT-PT in the first place. + +8.2 Renumbering Procedures and Applications' Use of DNS + + One of the most difficult problems of systematic IP address + renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that + an application which looks up a DNS name disregards information such + as TTL, and uses the result obtained from DNS as long as it happens + to be stored in the memory of the application. For applications + which run for a long time, this could be days, weeks or even months; + some applications may be clever enough to organize the data + structures and functions in such a manner that look-ups get refreshed + now and then. + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + + + +Durand, et al. Expires January 17, 2006 [Page 19] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + +9. Acknowledgements + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik + Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided + useful feedback and improvements. Scott Rose, Rob Austein, Masataka + Ohta, and Mark Andrews helped in clarifying the issues regarding + additional data and the use of TTL. Jefsey Morfin, Ralph Droms, + Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and + Rob Austein provided useful feedback during the WG last call. Thomas + Narten provided extensive feedback during the IESG evaluation. + +10. Security Considerations + + This document reviews the operational procedures for IPv6 DNS + operations and does not have security considerations in itself. + + However, it is worth noting that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended -- they could only be considered + in the environments where ingress filtering [RFC3704] has been + deployed. On the other hand, it should be noted that setting up an + authorization mechanism (e.g., a shared secret, or public-private + keys) between a node and the DNS server has to be done manually, and + may require quite a bit of time and expertise. + + To re-emphasize what was already stated, the reverse+forward DNS + check provides very weak security at best, and the only + (questionable) security-related use for them may be in conjunction + with other mechanisms when authenticating a user. + +11. References + +11.1 Normative References + + [I-D.ietf-dnsop-ipv6-dns-configuration] + Jeong, J., "IPv6 Host Configuration of DNS Server + Information Approaches", + draft-ietf-dnsop-ipv6-dns-configuration-06 (work in + progress), May 2005. + + [I-D.ietf-ipv6-unique-local-addr] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in + progress), January 2005. + + + +Durand, et al. Expires January 17, 2006 [Page 20] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + [I-D.ietf-v6ops-renumbering-procedure] + Baker, F., "Procedures for Renumbering an IPv6 Network + without a Flag Day", + draft-ietf-v6ops-renumbering-procedure-05 (work in + progress), March 2005. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + July 1997. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + + + +Durand, et al. Expires January 17, 2006 [Page 21] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational + Guidelines", BCP 91, RFC 3901, September 2004. + + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. + + [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against + DNS Queries for IPv6 Addresses", RFC 4074, May 2005. + +11.2 Informative References + + [I-D.durand-dnsop-dont-publish] + Durand, A. and T. Chown, "To publish, or not to publish, + that is the question.", draft-durand-dnsop-dont-publish-00 + (work in progress), February 2005. + + [I-D.huitema-v6ops-teredo] + Huitema, C., "Teredo: Tunneling IPv6 over UDP through + NATs", draft-huitema-v6ops-teredo-05 (work in progress), + April 2005. + + [I-D.huston-6to4-reverse-dns] + Huston, G., "6to4 Reverse DNS Delegation", + + + +Durand, et al. Expires January 17, 2006 [Page 22] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + draft-huston-6to4-reverse-dns-03 (work in progress), + October 2004. + + [I-D.ietf-dhc-ddns-resolution] + Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among + DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in + progress), June 2005. + + [I-D.ietf-dhc-fqdn-option] + Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", + draft-ietf-dhc-fqdn-option-10 (work in progress), + February 2005. + + [I-D.ietf-dnsext-dhcid-rr] + Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for + encoding DHCP information (DHCID RR)", + draft-ietf-dnsext-dhcid-rr-09 (work in progress), + February 2005. + + [I-D.ietf-dnsop-bad-dns-res] + Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in + progress), October 2004. + + [I-D.ietf-dnsop-inaddr-required] + Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-06 (work in progress), + February 2005. + + [I-D.ietf-v6ops-3gpp-analysis] + Wiljakka, J., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in + progress), October 2004. + + [I-D.ietf-v6ops-mech-v2] + Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 + (work in progress), March 2005. + + [I-D.ietf-v6ops-natpt-to-exprmntl] + Aoun, C. and E. Davies, "Reasons to Move NAT-PT to + Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work + in progress), July 2005. + + [I-D.ietf-v6ops-onlinkassumption] + Roy, S., "IPv6 Neighbor Discovery On-Link Assumption + Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 + (work in progress), May 2005. + + + +Durand, et al. Expires January 17, 2006 [Page 23] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + [I-D.ietf-v6ops-v6onbydefault] + Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack + IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 + (work in progress), July 2004. + + [I-D.jeong-dnsop-ipv6-dns-discovery] + Jeong, J., "IPv6 DNS Configuration based on Router + Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 + (work in progress), February 2005. + + [I-D.ohta-preconfigured-dns] + Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01 (work in progress), + February 2004. + + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, March 2005. + + +Authors' Addresses + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-202 + Menlo Park, CA 94025 + USA + + Email: Alain.Durand@sun.com + + + + + + +Durand, et al. Expires January 17, 2006 [Page 24] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + Email: johani@autonomica.se + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + Email: psavola@funet.fi + +Appendix A. Unique Local Addressing Considerations for DNS + + Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have + replaced the now-deprecated site-local addresses [RFC3879]. From the + perspective of the DNS, the locally generated unique local addresses + (LUL) and site-local addresses have similar properties. + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + To actually use local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that local addresses must not be published in the public DNS. + + To faciliate reverse DNS (if desired) with local addresses, the stub + resolvers must look for DNS information from the local DNS servers, + not e.g. starting from the root servers, so that the local + information may be provided locally. Note that the experience of + private addresses in IPv4 has shown that the root servers get loaded + for requests for private address lookups in any case. This + requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. + +Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments + + DNS responses do not always fit in a single UDP packet. We'll + examine the cases which happen when this is due to too much data in + the Additional Section. + + + + + + +Durand, et al. Expires January 17, 2006 [Page 25] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +B.1 Description of Additional Data Scenarios + + There are two kinds of additional data: + + 1. "critical" additional data; this must be included in all + scenarios, with all the RRsets, and + + 2. "courtesy" additional data; this could be sent in full, with only + a few RRsets, or with no RRsets, and can be fetched separately as + well, but at the cost of additional queries. + + The responding server can algorithmically determine which type the + additional data is by checking whether it's at or below a zone cut. + + Only those additional data records (even if sometimes carelessly + termed "glue") are considered "critical" or real "glue" if and only + if they meet the abovementioned condition, as specified in Section + 4.2.1 of [RFC1034]. + + Remember that resource record sets (RRsets) are never "broken up", so + if a name has 4 A records and 5 AAAA records, you can either return + all 9, all 4 A records, all 5 AAAA records or nothing. In + particular, notice that for the "critical" additional data getting + all the RRsets can be critical. + + In particular, [RFC2181] specifies (in Section 9) that: + + a. if all the "critical" RRsets do not fit, the sender should set + the TC bit, and the recipient should discard the whole response + and retry using mechanism allowing larger responses such as TCP. + + b. "courtesy" additional data should not cause the setting of TC + bit, but instead all the non-fitting additional data RRsets + should be removed. + + An example of the "courtesy" additional data is A/AAAA records in + conjunction with MX records as shown in Section 4.4; an example of + the "critical" additional data is shown below (where getting both the + A and AAAA RRsets is critical w.r.t. to the NS RR): + + child.example.com. IN NS ns.child.example.com. + ns.child.example.com. IN A 192.0.2.1 + ns.child.example.com. IN AAAA 2001:db8::1 + + When there is too much "courtesy" additional data, at least the non- + fitting RRsets should be removed [RFC2181]; however, as the + additional data is not critical, even all of it could be safely + removed. + + + +Durand, et al. Expires January 17, 2006 [Page 26] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + When there is too much "critical" additional data, TC bit will have + to be set, and the recipient should ignore the response and retry + using TCP; if some data were to be left in the UDP response, the + issue is which data could be retained. + + Failing to discard the response with TC bit or omitting critical + information but not setting TC bit lead to an unrecoverable problem. + Omitting only some of the RRsets if all would not fit (but not + setting TC bit) leads to a performance problem. These are discussed + in the next two subsections. + +B.2 Which Additional Data to Keep, If Any? + + If the implementation decides to keep as much data (whether + "critical" or "courtesy") as possible in the UDP responses, it might + be tempting to use the transport of the DNS query as a hint in either + of these cases: return the AAAA records if the query was done over + IPv6, or return the A records if the query was done over IPv4. + However, this breaks the model of independence of DNS transport and + resource records, as noted in Section 1.2. + + With courtesy additional data, as long as enough RRsets will be + removed so that TC will not be set, it is allowed to send as many + complete RRsets as the implementations prefers. However, the + implementations are also free to omit all such RRsets, even if + complete. Omitting all the RRsets (when removing only some would + suffice) may create a performance penalty, whereby the client may + need to issue one or more additional queries to obtain necessary + and/or consistent information. + + With critical additional data, the alternatives are either returning + nothing (and absolutely requiring a retry with TCP) or returning + something (working also in the case if the recipient does not discard + the response and retry using TCP) in addition to setting the TC bit. + If the process for selecting "something" from the critical data would + otherwise be practically "flipping the coin" between A and AAAA + records, it could be argued that if one looked at the transport of + the query, it would have a larger possibility of being right than + just 50/50. In other words, if the returned critical additional data + would have to be selected somehow, using something more sophisticated + than a random process would seem justifiable. + + That is, leaving in some intelligently selected critical additional + data is a tradeoff between creating an optimization for those + resolvers which ignore the "should discard" recommendation, and + causing a protocol problem by propagating inconsistent information + about "critical" records in the caches. + + + + +Durand, et al. Expires January 17, 2006 [Page 27] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Similarly, leaving in the complete courtesy additional data RRsets + instead of removing all the RRsets is a performance tradeoff as + described in the next section. + +B.3 Discussion of the Potential Problems + + As noted above, the temptation for omitting only some of the + additional data could be problematic. This is discussed more below. + + For courtesy additional data, this causes a potential performance + problem as this requires that the clients issue re-queries for the + potentially omitted RRsets. For critical additional data, this + causes a potential unrecoverable problem if the response is not + discarded and the query not re-tried with TCP, as the nameservers + might be reachable only through the omitted RRsets. + + If an implementation would look at the transport used for the query, + it is worth remembering that often the host using the records is + different from the node requesting them from the authoritative DNS + server (or even a caching resolver). So, whichever version the + requestor (e.g., a recursive server in the middle) uses makes no + difference to the ultimate user of the records, whose transport + capabilities might differ from those of the requestor. This might + result in e.g., inappropriately returning A records to an IPv6-only + node, going through a translation, or opening up another IP-level + session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). + Therefore, at least in many scenarios, it would be very useful if the + information returned would be consistent and complete -- or if that + is not feasible, return no misleading information but rather leave it + to the client to query again. + + The problem of too much additional data seems to be an operational + one: the zone administrator entering too many records which will be + returned either truncated (or missing some RRsets, depending on + implementations) to the users. A protocol fix for this is using + EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, + pushing up the relevant threshold. Further, DNS server + implementations should rather omit courtesy additional data + completely rather than including only some RRsets [RFC2181]. An + operational fix for this is having the DNS server implementations + return a warning when the administrators create zones which would + result in too much additional data being returned. Further, DNS + server implementations should warn of or disallow such zone + configurations which are recursive or otherwise difficult to manage + by the protocol. + + Additionally, to avoid the case where an application would not get an + address at all due to some of courtesy additional data being omitted, + + + +Durand, et al. Expires January 17, 2006 [Page 28] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + the resolvers should be able to query the specific records of the + desired protocol, not just rely on getting all the required RRsets in + the additional section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 17, 2006 [Page 29] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Durand, et al. Expires January 17, 2006 [Page 30] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt new file mode 100644 index 000000000000..6bece56182cf --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: July 19, 2005 O. Courtay + Thomson R&D + January 18, 2005 + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-02.txt + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + 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 July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document describes problems that appear during an automated + rollover and gives the requirements for the design of communication + between parent zone and child zone during an automated rollover + process. This document is essentially about in-band key rollover. + + + + +Guette & Courtay Expires July 19, 2005 [Page 1] +Internet-Draft Automated Rollover Requirements January 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 5 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + A. Documents details and changes . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 2] +Internet-Draft Automated Rollover Requirements January 2005 + +1. Introduction + + The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key + cryptography and digital signatures. It stores the public part of + keys in DNSKEY Resource Records (RRs). Because old keys and + frequently used keys are vulnerable, they must be renewed + periodically. In DNSSEC, this is the case for Zone Signing Keys + (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key + exchanges between parents and children is necessary for large zones + because there are too many changes to handle. + + Let us consider for example a zone with 100000 secure delegations. + If the child zones change their keys once a year on average, that + implies 300 changes per day for the parent zone. This amount of + changes is hard to manage manually. + + Automated rollover is optional and resulting from an agreement + between the administrator of the parent zone and the administrator of + the child zone. Of course, key rollover can also be done manually by + administrators. + + This document describes the requirements for a protocol to perform + the automated key rollover process and focusses on interaction + between parent and child zone. + +2. The Key Rollover Process + + Key rollover consists of renewing the DNSSEC keys used to sign + resource records in a given DNS zone file. There are two types of + rollover, ZSK rollovers and KSK rollovers. + + During a ZSK rollover, all changes are local to the zone that renews + its key: there is no need to contact other zones administrators to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + During a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, data must be exchanged between child + and parent zones. + + The key rollover is built from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + can be local to the zone, + o the interaction between parent and child zones. + + One example of manual key rollover [3] is: + o The child zone creates a new KSK, + + +Guette & Courtay Expires July 19, 2005 [Page 3] +Internet-Draft Automated Rollover Requirements January 2005 + + o the child zone waits for the creation of the DS RR in its parent + zone, + o the child zone deletes the old key, + o the parent zone deletes the old DS RR. + + This document concentrates on defining interactions between entities + present in key rollover process. + +3. Basic Requirements + + This section provides the requirements for automated key rollover in + case of normal use. Exceptional case like emergency rollover is + specifically described later in this document. + + The main condition during a key rollover is that the chain of trust + must be preserved to every validating DNS client. No matter if this + client retrieves some of the RRs from recursive caching name server + or from the authoritative servers for the zone involved in the + rollover. + + Automated key rollover solution may be interrupted by a manual + intervention. This manual intervention should not compromise the + security state of the chain of trust. If the chain is safe before + the manual intervention, the chain of trust must remain safe during + and after the manual intervention + + Two entities act during a KSK rollover: the child zone and its parent + zone. These zones are generally managed by different administrators. + These administrators should agree on some parameters like + availability of automated rollover, the maximum delay between + notification of changes in the child zone and the resigning of the + parent zone. The child zone needs to know this delay to schedule its + changes and/or to verify that the changes had been taken into account + in the parent zone. Hence, the child zone can also avoid some + critical cases where all child key are changed prior to the DS RR + creation. + + By keeping some resource records during a given time, the recursive + cache servers can act on the automated rollover. The existence of + recursive cache servers must be taken into account by automated + rollover solution. + + Indeed, during an automated key rollover a name server could have to + retrieve some DNSSEC data. An automated key rollover solution must + ensure that these data are not old DNSSEC material retrieved from a + recursive name server. + + + +Guette & Courtay Expires July 19, 2005 [Page 4] +Internet-Draft Automated Rollover Requirements January 2005 + +4. Messages authentication and information exchanged + + This section addresses in-band rollover, security of out-of-band + mechanisms is out of scope of this document. + + The security provided by DNSSEC must not be compromised by the key + rollover, thus every exchanged message must be authenticated to avoid + fake rollover messages from malicious parties. + + Once the changes related to a KSK are made in a child zone, there are + two ways for the parent zone to take this changes into account: + o the child zone notify directly or not directly its parent zone in + order to create the new DS RR and store this DS RR in parent zone + file, + o or the parent zone poll the child zone. + + In both cases, the parent zone must receive all the child keys that + need the creation of associated DS RRs in the parent zone. + + Because errors could occur during the transmission of keys between + child and parent, the key exchange protocol must be fault tolerant. + Should an error occured during the automated key rollover, an + automated key rollover solution must be able to keep the zone files + in a consistent state. + +5. Emergency Rollover + + Emergency key rollover is a special case of rollover decided by the + zone administrator generally for security reasons. In consequence, + emergency key rollover can break some of the requirement described + above. + + A zone key might be compromised and an attacker can use the + compromised key to create and sign fake records. To avoid this, the + zone administrator may change the compromised key or all its keys as + soon as possible, without waiting for the creation of new DS RRs in + its parent zone. + + Fast changes may break the chain of trust. The part of DNS tree + having this zone as apex can become unverifiable, but the break of + the chain of trust is necessary if the administrator wants to prevent + the compromised key from being used (to spoof DNS data). + + Parent and child zones sharing an automated rollover mechanism, + should have an out-of-band way to re-establish a consistent state at + the delegation point (DS and DNSKEY RRs). This allows to avoid that + a malicious party uses the compromised key to roll the zone keys. + + +Guette & Courtay Expires July 19, 2005 [Page 5] +Internet-Draft Automated Rollover Requirements January 2005 + +6. Security consideration + + The automated key rollover process in DNSSEC allows automated renewal + of any kind of DNS key (ZSK or KSK). It is essential that parent + side and child side can do mutual authentication. Moreover, + integrity of the material exchanged between the parent and child zone + must be provided to ensure the right DS are created. + + As in any application using public key cryptography, in DNSSEC a key + may be compromised. What to do in such a case can be describe in the + zone local policy and can violate some requirements described in this + draft. The emergency rollover can break the chain of trust in order + to protect the zone against the use of the compromised key. + +7. Acknowledgments + + The authors want to thank members of IDsA project for their + contribution to this document. + +8 Normative References + + [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + [3] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practice-01 (work in + progress), May 2004. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October + + +Guette & Courtay Expires July 19, 2005 [Page 6] +Internet-Draft Automated Rollover Requirements January 2005 + + 2004. + +Authors' Addresses + + Gilles Guette + IRISA / INRIA + Campus de Beaulieu + 35042 Rennes CEDEX + FR + + EMail: gilles.guette@irisa.fr + URI: http://www.irisa.fr + + Olivier Courtay + Thomson R&D + 1, avenue Belle Fontaine + 35510 Cesson S?vign? CEDEX + FR + + EMail: olivier.courtay@thomson.net + +Appendix A. Documents details and changes + + This section is to be removed by the RFC editor if and when the + document is published. + + Section about NS RR rollover has been removed + + Remarks from Samuel Weiler and Rip Loomis added + + Clarification about in-band rollover and in emergency section + + Section 3, details about recursive cache servers added + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 7] +Internet-Draft Automated Rollover Requirements January 2005 + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; neither does it represent + that it has made any effort to identify any such rights. + Information on the IETF's procedures with respect to rights in + IETF Documents can be found in BCP 78 and 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights which may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr.org. + + + Full Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Guette & Courtay Expires July 19, 2005 [Page 8] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt new file mode 100644 index 000000000000..63fe2de521ae --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt @@ -0,0 +1,480 @@ + + + + + + + DNSOP Working Group Paul Vixie, ISC + INTERNET-DRAFT Akira Kato, WIDE + <draft-ietf-dnsop-respsize-02.txt> July 2005 + + DNS Response Size Issues + + Status of this Memo + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of 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. + + Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + + + Abstract + + With a mandated default minimum maximum message size of 512 octets, + the DNS protocol presents some special problems for zones wishing to + expose a moderate or high number of authority servers (NS RRs). This + document explains the operational issues caused by, or related to + this response size limit. + + + + + + + Expires December 2005 [Page 1] + + INTERNET-DRAFT July 2005 RESPSIZE + + + 1 - Introduction and Overview + + 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 + octets. Even though this limitation was due to the required minimum UDP + reassembly limit for IPv4, it is a hard DNS protocol limit and is not + implicitly relaxed by changes in transport, for example to IPv6. + + 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger + responses by mutual agreement of the requestor and responder. However, + deployment of EDNS0 cannot be expected to reach every Internet resolver + in the short or medium term. The 512 octet message size limit remains + in practical effect at this time. + + 1.3. Since DNS responses include a copy of the request, the space + available for response data is somewhat less than the full 512 octets. + For negative responses, there is rarely a space constraint. For + positive and delegation responses, though, every octet must be carefully + and sparingly allocated. This document specifically addresses + delegation response sizes. + + 2 - Delegation Details + + 2.1. A delegation response will include the following elements: + + Header Section: fixed length (12 octets) + Question Section: original query (name, class, type) + Answer Section: (empty) + Authority Section: NS RRset (nameserver names) + Additional Section: A and AAAA RRsets (nameserver addresses) + + 2.2. If the total response size would exceed 512 octets, and if the data + that would not fit belonged in the question, answer, or authority + section, then the TC bit will be set (indicating truncation) which may + cause the requestor to retry using TCP, depending on what information + was desired and what information was omitted. If a retry using TCP is + needed, the total cost of the transaction is much higher. (See [RFC1123 + 6.1.3.2] for details on the protocol requirement that UDP be attempted + before falling back to TCP.) + + 2.3. RRsets are never sent partially unless truncation occurs, in which + case the final apparent RRset in the final nonempty section must be + considered "possibly damaged". With or without truncation, the glue + present in the additional data section should be considered "possibly + incomplete", and requestors should be prepared to re-query for any + damaged or missing RRsets. For multi-transport name or mail services, + + + + Expires December 2005 [Page 2] + + INTERNET-DRAFT July 2005 RESPSIZE + + + this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A) + RRset is present. + + 2.4. DNS label compression allows a domain name to be instantiated only + once per DNS message, and then referenced with a two-octet "pointer" + from other locations in that same DNS message. If all nameserver names + in a message are similar (for example, all ending in ".ROOT- + SERVERS.NET"), then more space will be available for uncompressable data + (such as nameserver addresses). + + 2.5. The query name can be as long as 255 characters of presentation + data, which can be up to 256 octets of network data. In this worst case + scenario, the question section will be 260 octets in size, which would + leave only 240 octets for the authority and additional sections (after + deducting 12 octets for the fixed length header.) + + 2.6. Average and maximum question section sizes can be predicted by the + zone owner, since they will know what names actually exist, and can + measure which ones are queried for most often. For cost and performance + reasons, the majority of requests should be satisfied without truncation + or TCP retry. + + 2.7. Requestors who deliberately send large queries to force truncation + are only increasing their own costs, and cannot effectively attack the + resources of an authority server since the requestor would have to retry + using TCP to complete the attack. An attack that always used TCP would + have a lower cost. + + 2.8. The minimum useful number of address records is two, since with + only one address, the probability that it would refer to an unreachable + server is too high. Truncation which occurs after two address records + have been added to the additional data section is therefore less + operationally significant than truncation which occurs earlier. + + 2.9. The best case is no truncation. This is because many requestors + will retry using TCP by reflex, or will automatically re-query for + RRsets that are "possibly truncated", without considering whether the + omitted data was actually necessary. + + 2.10. Each added NS RR for a zone will add a minimum of between 16 and + 44 octets to every untruncated referral or negative response from the + zone's authority servers (16 octets for an NS RR, 16 octets for an A RR, + and 28 octets for an AAAA RR), in addition to whatever space is taken by + the nameserver name (NS NSDNAME and A/AAAA owner name). + + + + + Expires December 2005 [Page 3] + + INTERNET-DRAFT July 2005 RESPSIZE + + + 3 - Analysis + + 3.1. An instrumented protocol trace of a best case delegation response + follows. Note that 13 servers are named, and 13 addresses are given. + This query was artificially designed to exactly reach the 512 octet + limit. + + ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 + ;; QUERY SECTION: + ;; [23456789.123456789.123456789.\ + 123456789.123456789.123456789.com A IN] ;; @80 + + ;; AUTHORITY SECTION: + com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 + com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 + com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 + com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 + com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 + com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 + com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 + com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 + com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 + com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 + com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 + com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 + com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 + + ;; ADDITIONAL SECTION: + A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 + B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 + C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 + D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 + E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 + F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 + G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 + H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 + I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 + J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 + K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 + L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 + M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 + + ;; MSG SIZE sent: 80 rcvd: 512 + + + + + + Expires December 2005 [Page 4] + + INTERNET-DRAFT July 2005 RESPSIZE + + + 3.2. For longer query names, the number of address records supplied will + be lower. Furthermore, it is only by using a common parent name (which + is GTLD-SERVERS.NET in this example) that all 13 addresses are able to + fit. The following output from a response simulator demonstrates these + properties: + + % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br + a.dns.br requires 10 bytes + b.dns.br requires 4 bytes + c.dns.br requires 4 bytes + d.dns.br requires 4 bytes + # of NS: 4 + For maximum size query (255 byte): + if only A is considered: # of A is 4 (green) + if A and AAAA are condered: # of A+AAAA is 3 (yellow) + if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) + For average size query (64 byte): + if only A is considered: # of A is 4 (green) + if A and AAAA are condered: # of A+AAAA is 4 (green) + if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int + ns-ext.isc.org requires 16 bytes + ns.psg.com requires 12 bytes + ns.ripe.net requires 13 bytes + ns.eu.int requires 11 bytes + # of NS: 4 + For maximum size query (255 byte): + if only A is considered: # of A is 4 (green) + if A and AAAA are condered: # of A+AAAA is 3 (yellow) + if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) + For average size query (64 byte): + if only A is considered: # of A is 4 (green) + if A and AAAA are condered: # of A+AAAA is 4 (green) + if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + (Note: The response simulator program is shown in Section 5.) + + Here we use the term "green" if all address records could fit, or + "orange" if two or more could fit, or "red" if fewer than two could fit. + It's clear that without a common parent for nameserver names, much space + would be lost. For these examples we use an average/common name size of + 15 octets, befitting our assumption of GTLD-SERVERS.NET as our common + parent name. + + + + + Expires December 2005 [Page 5] + + INTERNET-DRAFT July 2005 RESPSIZE + + + We're assuming an average query name size of 64 since that is the + typical average maximum size seen in trace data at the time of this + writing. If Internationalized Domain Name (IDN) or any other technology + which results in larger query names be deployed significantly in advance + of EDNS, then new measurements and new estimates will have to be made. + + 4 - Conclusions + + 4.1. The current practice of giving all nameserver names a common parent + (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS + responses and allows for more nameservers to be enumerated than would + otherwise be possible. (Note that in this case it is wise to serve the + common parent domain's zone from the same servers that are named within + it, in order to limit external dependencies when all your eggs are in a + single basket.) + + 4.2. Thirteen (13) seems to be the effective maximum number of + nameserver names usable traditional (non-extended) DNS, assuming a + common parent domain name, and given that response truncation is + undesirable as an average case, and assuming mostly IPv4-only + reachability (only A RRs exist, not AAAA RRs). + + 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a + prototypical delegation that currently contains thirteen (13) IPv4 + nameserver addresses (A RRs) for thirteen (13) nameserver names under a + common parent, would not have a significant negative operational impact + on the domain name system. + + 5 - Source Code + + #!/usr/bin/perl + # + # SYNOPSIS + # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... + # if all queries are assumed to have zone suffux, such as "jp" in + # JP TLD servers, specify it in -z option + # + use strict; + use Getopt::Std; + my ($sz_msg) = (512); + my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); + my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); + my (%namedb, $name, $nssect, %opts, $optz); + my $n_ns = 0; + + + + + Expires December 2005 [Page 6] + + INTERNET-DRAFT July 2005 RESPSIZE + + + getopt('z', opts); + if (defined($opts{'z'})) { + server_name_len($opts{'z'}); # just register it + } + + foreach $name (@ARGV) { + my $len; + $n_ns++; + $len = server_name_len($name); + print "$name requires $len bytes\n"; + $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len; + } + print "# of NS: $n_ns\n"; + arsect(255, $nssect, $n_ns, "maximum"); + arsect(64, $nssect, $n_ns, "average"); + + sub server_name_len { + my ($name) = @_; + my (@labels, $len, $n, $suffix); + + $name =~ tr/A-Z/a-z/; + @labels = split(/./, $name); + $len = length(join('.', @labels)) + 2; + for ($n = 0; $#labels >= 0; $n++, shift @labels) { + $suffix = join('.', @labels); + return length($name) - length($suffix) + $sz_ptr + if (defined($namedb{$suffix})); + $namedb{$suffix} = 1; + } + return $len; + } + + sub arsect { + my ($sz_query, $nssect, $n_ns, $cond) = @_; + my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); + $ansect = $sz_query + 1 + $sz_type + $sz_class; + $space = $sz_msg - $sz_header - $ansect - $nssect; + $n_a = atmost(int($space / $sz_rr_a), $n_ns); + $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); + $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns); + printf "For %s size query (%d byte):\n", $cond, $sz_query; + printf "if only A is considered: "; + printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); + printf "if A and AAAA are condered: "; + printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns); + + + + Expires December 2005 [Page 7] + + INTERNET-DRAFT July 2005 RESPSIZE + + + printf "if prefer_glue A is assumed: "; + printf "# of A is %d, # of AAAA is %d (%s)\n", + $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); + } + + sub judge { + my ($n, $n_ns) = @_; + return "green" if ($n >= $n_ns); + return "yellow" if ($n >= 2); + return "orange" if ($n == 1); + return "red"; + } + + sub atmost { + my ($a, $b) = @_; + return 0 if ($a < 0); + return $b if ($a > $b); + return $a; + } + + Security Considerations + + The recommendations contained in this document have no known security + implications. + + IANA Considerations + + This document does not call for changes or additions to any IANA + registry. + + IPR Statement + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except as + set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR + IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + Expires December 2005 [Page 8] + + INTERNET-DRAFT July 2005 RESPSIZE + + + Authors' Addresses + + Paul Vixie + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + vixie@isc.org + + Akira Kato + University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + +81 3 5841 2750 + kato@wide.ad.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires December 2005 [Page 9] +
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt new file mode 100644 index 000000000000..242aa9ea6296 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt @@ -0,0 +1,616 @@ + + +Network Working Group S. Woolf +Internet-Draft Internet Systems Consortium, Inc. +Expires: September 14, 2005 D. Conrad + Nominum, Inc. + March 13, 2005 + + + Identifying an Authoritative Name Server + draft-ietf-dnsop-serverid-04 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 September 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + + + +Woolf & Conrad Expires September 14, 2005 [Page 1] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + + query would be useful, particularly as a diagnostic aid. Existing ad + hoc mechanisms for addressing this concern are not adequate. This + document attempts to describe the common ad hoc solution to this + problem, including its advantages and disadvantages, and to + characterize an improved mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 2] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid. + + Unfortunately, existing ad-hoc mechanisms for providing such + identification have some shortcomings, not the least of which is the + lack of prior analysis of exactly how such a mechanism should be + designed and deployed. This document describes the existing + convention used in one widely deployed implementation of the DNS + protocol and discusses requirements for an improved solution to the + problem. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 3] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +2. Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. However, relying on the IP address of the name server + has become more problematic due the deployment of various load + balancing solutions, including the use of shared unicast addresses as + documented in [RFC3258]. + + An unfortunate side effect of these load balancing solutions, and + some changes in management practices as the public Internet has + evolved, is that traditional methods of determining which server is + responding can be unreliable. Specifically, non-DNS methods such as + ICMP ping, TCP connections, or non-DNS UDP packets (such as those + generated by tools such as "traceroute"), etc., can end up going to a + different server than that which receives the DNS queries. + + There is a well-known and frequently-used technique for determining + an identity for a nameserver more specific than the + possibly-non-unique "server that answered my query". The widespread + use of the existing convention suggests a need for a documented, + interoperable means of querying the identity of a nameserver that may + be part of an anycast or load-balancing cluster. At the same time, + however, it also has some drawbacks that argue against standardizing + it as it's been practiced so far. + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 4] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +3. Existing Conventions + + Recent versions of the commonly deployed Berkeley Internet Name + Domain implementation of the DNS protocol suite from the Internet + Software Consortium [BIND] support a way of identifying a particular + server via the use of a standard, if somewhat unusual, DNS query. + Specifically, a query to a late model BIND server for a TXT resource + record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will + return a string that can be configured by the name server + administrator to provide a unique identifier for the responding + server (defaulting to the value of a gethostname() call). This + mechanism, which is an extension of the BIND convention of using + CHAOS class TXT RR queries to sub-domains of the "BIND." domain for + version information, has been copied by several name server vendors. + + For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A + query for a TXT RR for this name will return an administratively + defined string which defaults to the version of the server + responding. This is, however, not generally implemented by other + vendors. + +3.1 Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + 1. The "hostname.bind" query response mechanism is within the DNS + protocol itself. An identification mechanism that relies on the + DNS protocol is more likely to be successful (although not + guaranteed) in going to the same machine as a "normal" DNS query. + 2. Since the identity information is requested and returned within + the DNS protocol, it doesn't require allowing any other query + mechanism to the server, such as holes in firewalls for + otherwise-unallowed ICMP Echo requests. Thus it does not require + any special exceptions to site security policy. + 3. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + 4. It allows the administrator complete control of what information + is given out in the response, minimizing passive leakage of + implementation or configuration details. Such details are often + considered sensitive by infrastructure operators. + +3.2 Disadvantages + + At the same time, there are some forbidding drawbacks to the + VERSION.BIND mechanism that argue against standardizing it as it + currently operates. + + + + +Woolf & Conrad Expires September 14, 2005 [Page 5] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + + 1. It requires an additional query to correlate between the answer + to a DNS query under normal conditions and the supposed identity + of the server receiving the query. There are a number of + situations in which this simply isn't reliable. + 2. It reserves an entire class in the DNS (CHAOS) for what amounts + to one zone. While CHAOS class is defined in [RFC1034] and + [RFC1035], it's not clear that supporting it solely for this + purpose is a good use of the namespace or of implementation + effort. + 3. It is implementation specific. BIND is one DNS implementation. + At the time of this writing, it is probably the most prevalent + for authoritative servers. This does not justify standardizing + on its ad hoc solution to a problem shared across many operators + and implementors. + + The first of the listed disadvantages is technically the most + serious. It argues for an attempt to design a good answer to the + problem that "I need to know what nameserver is answering my + queries", not simply a convenient one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 6] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +4. Characteristics of an Implementation Neutral Convention + + The discussion above of advantages and disadvantages to the + HOSTNAME.BIND mechanism suggest some requirements for a better + solution to the server identification problem. These are summarized + here as guidelines for any effort to provide appropriate protocol + extensions: + 1. The mechanism adopted MUST be in-band for the DNS protocol. That + is, it needs to allow the query for the server's identifying + information to be part of a normal, operational query. It SHOULD + also permit a separate, dedicated query for the server's + identifying information. + 2. The new mechanism SHOULD not require dedicated namespaces or + other reserved values outside of the existing protocol mechanisms + for these, i.e. the OPT pseudo-RR. In particular, it should not + propagate the existing drawback of requiring support for a CLASS + and top level domain in the authoritative server (or the querying + tool) to be useful. + 3. Support for the identification functionality SHOULD be easy to + implement and easy to enable. It MUST be easy to disable and + SHOULD lend itself to access controls on who can query for it. + 4. It should be possible to return a unique identifier for a server + without requiring the exposure of information that may be + non-public and considered sensitive by the operator, such as a + hostname or unicast IP address maintained for administrative + purposes. + 5. The identification mechanism SHOULD NOT be + implementation-specific. + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 7] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +5. IANA Considerations + + This document proposes no specific IANA action. Protocol extensions, + if any, to meet the requirements described are out of scope for this + document. Should such extensions be specified and adopted by normal + IETF process, the specification will include appropriate guidance to + IANA. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 8] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +6. Security Considerations + + Providing identifying information as to which server is responding to + a particular query from a particular location in the Internet can be + seen as information leakage and thus a security risk. This motivates + the suggestion above that a new mechanism for server identification + allow the administrator to disable the functionality altogether or + partially restrict availability of the data. It also suggests that + the serverid data should not be readily correlated with a hostname or + unicast IP address that may be considered private to the nameserver + operator's management infrastructure. + + Propagation of protocol or service meta-data can sometimes expose the + application to denial of service or other attack. As DNS is a + critically important infrastructure service for the production + Internet, extra care needs to be taken against this risk for + designers, implementors, and operators of a new mechanism for server + identification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 9] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +7. Acknowledgements + + The technique for host identification documented here was initially + implemented by Paul Vixie of the Internet Software Consortium in the + Berkeley Internet Name Daemon package. Comments and questions on + earlier drafts were provided by Bob Halley, Brian Wellington, Andreas + Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the + ICANN Root Server System Advisory Committee. The newest version + takes a significantly different direction from previous versions, + owing to discussion among contributors to the DNSOP working group and + others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam + Weiler, and Rob Austein. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 14, 2005 [Page 10] + +Internet-Draft Identifying an Authoritative Name Server March 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Woolf & Conrad Expires September 14, 2005 [Page 11] + + diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt new file mode 100644 index 000000000000..31890a4bcbeb --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc3757.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group O. Kolkman +Request for Comments: 3757 RIPE NCC +Updates: 3755, 2535 J. Schlyter +Category: Standards Track NIC-SE + E. Lewis + ARIN + April 2004 + + + Domain Name System KEY (DNSKEY) Resource Record (RR) + Secure Entry Point (SEP) Flag + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + With the Delegation Signer (DS) resource record (RR), the concept of + a public key acting as a secure entry point (SEP) has been + introduced. During exchanges of public keys with the parent there is + a need to differentiate SEP keys from other public keys in the Domain + Name System KEY (DNSKEY) resource record set. A flag bit in the + DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. + The flag bit is intended to assist in operational procedures to + correctly generate DS resource records, or to indicate what DNSKEYs + are intended for static configuration. The flag bit is not to be + used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3755. + + + + + + + + + + + + + + +Kolkman, et al. Standard Track [Page 1] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 + 7. Internationalization Considerations. . . . . . . . . . . . . . 6 + 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 9.2. Informative References . . . . . . . . . . . . . . . . . 6 + 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6]. + + With the definition of the Delegation Signer Resource Record (DS RR) + [5], it has become important to differentiate between the keys in the + DNSKEY RR set that are (to be) pointed to by parental DS RRs and the + other keys in the DNSKEY RR set. We refer to these public keys as + Secure Entry Point (SEP) keys. A SEP key either used to generate a + DS RR or is distributed to resolvers that use the key as the root of + a trusted subtree [3]. + + In early deployment tests, the use of two (kinds of) key pairs for + each zone has been prevalent. For one kind of key pair the private + key is used to sign just the zone's DNSKEY resource record (RR) set. + Its public key is intended to be referenced by a DS RR at the parent + or configured statically in a resolver. The private key of the other + kind of key pair is used to sign the rest of the zone's data sets. + The former key pair is called a key-signing key (KSK) and the latter + is called a zone-signing key (ZSK). In practice there have been + usually one of each kind of key pair, but there will be multiples of + each at times. + + It should be noted that division of keys pairs into KSK's and ZSK's + is not mandatory in any definition of DNSSEC, not even with the + introduction of the DS RR. But, in testing, this distinction has + been helpful when designing key roll over (key super-cession) + schemes. Given that the distinction has proven helpful, the labels + KSK and ZSK have begun to stick. + + + + + + +Kolkman, et al. Standard Track [Page 2] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + + There is a need to differentiate the public keys for the key pairs + that are used for key signing from keys that are not used key signing + (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to + be sent for generating DS RRs, which DNSKEYs are to be distributed to + resolvers, and which keys are fed to the signer application at the + appropriate time. + + In other words, the SEP bit provides an in-band method to communicate + a DNSKEY RR's intended use to third parties. As an example we + present 3 use cases in which the bit is useful: + + The parent is a registry, the parent and the child use secured DNS + queries and responses, with a preexisting trust-relation, or plain + DNS over a secured channel to exchange the child's DNSKEY RR sets. + Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP + bit can be used to isolate the DNSKEYs for which a DS RR needs to + be created. + + An administrator has configured a DNSKEY as root for a trusted + subtree into security aware resolver. Using a special purpose + tool that queries for the KEY RRs from that domain's apex, the + administrator will be able to notice the roll over of the trusted + anchor by a change of the subset of KEY RRs with the DS flag set. + + A signer might use the SEP bit on the public key to determine + which private key to use to exclusively sign the DNSKEY RRset and + which private key to use to sign the other RRsets in the zone. + + As demonstrated in the above examples it is important to be able to + differentiate the SEP keys from the other keys in a DNSKEY RR set in + the flow between signer and (parental) key-collector and in the flow + between the signer and the resolver configuration. The SEP flag is + to be of no interest to the flow between the verifier and the + authoritative data store. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK key pairs is made by the signer, a + key pair could be used as both a KSK and a ZSK at the same time. To + be clear, the term SEP was coined to lessen the confusion caused by + the overlap. (Once this label was applied, it had the side effect of + removing the temptation to have both a KSK flag bit and a ZSK flag + bit.) + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in BCP 14, RFC 2119 [1]. + + + + + +Kolkman, et al. Standard Track [Page 3] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +2. The Secure Entry Point (SEP) Flag + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |S| protocol | algorithm | + | |E| | | + | |P| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DNSKEY RR Format + This document assigns the 15th bit in the flags field as the secure + entry point (SEP) bit. If the bit is set to 1 the key is intended to + be used as secure entry point key. One SHOULD NOT assign special + meaning to the key if the bit is set to 0. Operators can recognize + the secure entry point key by the even or odd-ness of the decimal + representation of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The SEP flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the SEP flag does not change the DNS resolution protocol or the + resolution process. + +4. Operational Guidelines + + The SEP bit is set by the key-pair-generator and MAY be used by the + zone signer to decide whether the public part of the key pair is to + be prepared for input to a DS RR generation function. The SEP bit is + recommended to be set (to 1) whenever the public key of the key pair + will be distributed to the parent zone to build the authentication + chain or if the public key is to be distributed for static + configuration in verifiers. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within + the data that is used to compute the 'key tag field' in the SIG RR, + changing the SEP bit will change the identity of the key within DNS. + In other words, once a key is used to generate signatures, the + setting of the SEP bit is to remain constant. If not, a verifier + will not be able to find the relevant KEY RR. + + + + +Kolkman, et al. Standard Track [Page 4] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + + When signing a zone, it is intended that the key(s) with the SEP bit + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a SEP bit set will sign the + DNSKEY RR set, such keys might be pending retirement or not yet in + use. + + When verifying a RR set, the SEP bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the SEP flag provides a hint on which public key is to be + used as trusted root, administrators can choose to ignore the fact + that a DNSKEY has its SEP bit set or not when configuring a trusted + root for their resolvers. + + Using the SEP flag a key roll over can be automated. The parent can + use an existing trust relation to verify DNSKEY RR sets in which a + new DNSKEY RR with the SEP flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to be used in the resolution + protocol or to determine the security status of a key. The flag is + to be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating public key exchanges, we + think the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a public key + exchange where a DNSKEY RR set, containing two DNSKEY RRs with the + SEP flag set, is sent to the parent. The parent verifies the DNSKEY + RR set with the existing trust relation and creates the new DS RR + from the DNSKEY RR that the current DS RR is not pointing to. This + key exchange might be replayed. Parents are encouraged to implement + a replay defense. A simple defense can be based on a registry of + keys that have been used to generate DS RRs during the most recent + roll over. These same considerations apply to entities that + configure keys in resolvers. + + + + + + + + +Kolkman, et al. Standard Track [Page 5] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +6. IANA Considerations + + IANA has assigned the 15th bit in the DNSKEY Flags Registry (see + Section 4.3 of [4]) as the Secure Entry Point (SEP) bit. + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, there + are no internationalization considerations. + +8. Acknowledgments + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, + Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler + have contributed ideas and provided feedback. + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI in August 2002. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer + (DS)", RFC 3755, April 2004. + +9.2. Informative References + + [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story", ISBN 0151002177 (50th anniversary edition), April 1996. + + + + + + + +Kolkman, et al. Standard Track [Page 6] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +10. Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + NIC-SE + Box 5774 + SE-114 87 Stockholm + Sweden + + EMail: jakob@nic.se + URI: http://www.nic.se/ + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Standard Track [Page 7] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Kolkman, et al. Standard Track [Page 8] + diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt new file mode 100644 index 000000000000..43b7356e6adf --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc3901.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group A. Durand +Request for Comments: 3901 SUN Microsystems, Inc. +BCP: 91 J. Ihren +Category: Best Current Practice Autonomica + September 2004 + + + DNS IPv6 Transport Operational Guidelines + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo provides guidelines and Best Current Practice for operating + DNS in a world where queries and responses are carried in a mixed + environment of IPv4 and IPv6 networks. + +1. Introduction to the Problem of Name Space Fragmentation: + following the referral chain + + A resolver that tries to look up a name starts out at the root, and + follows referrals until it is referred to a name server that is + authoritative for the name. If somewhere down the chain of referrals + it is referred to a name server that is only accessible over a + transport which the resolver cannot use, the resolver is unable to + finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen. The complete DNS + hierarchy then starts to fragment into a graph where authoritative + name servers for certain nodes are only accessible over a certain + transport. The concern is that a resolver using only a particular + version of IP and querying information about another node using the + same version of IP can not do it because somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + + + +Durand & Ihren Best Current Practice [Page 1] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + + through a "translator", i.e., they have to use a recursive name + server on a so-called "dual stack" host as a "forwarder" since they + cannot access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of IPv4 recursive name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in the foreseeable + future. Instead, the transition will be from IPv4 only to a mixture + of IPv4 and IPv6, with three categories of DNS data depending on + whether the information is available only over IPv4 transport, only + over IPv6 or both. + + Having DNS data available on both transports is the best situation. + The major question is how to ensure that it becomes the norm as + quickly as possible. However, while it is obvious that some DNS data + will only be available over v4 transport for a long time it is also + obvious that it is important to avoid fragmenting the name space + available to IPv4 only hosts. For example, during transition it is + not acceptable to break the name space that we presently have + available for IPv4-only hosts. + +2. Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS [1,2] data + is served. Likewise, "IPv6 [4,5,6] name server" indicates a name + server available over IPv6 transport. The phrase "dual-stack name + server" indicates a name server that is actually configured to run + both protocols, IPv4 and IPv6, and not merely a server running on a + system capable of running both but actually configured to run only + one. + +3. Policy Based Avoidance of Name Space Fragmentation + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and most of them can be regarded + as "experimental". However, as soon as the root and top level + domains are available over IPv6 transport, it is reasonable to expect + that it will become more common to have zones served by IPv6 servers. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + + + + +Durand & Ihren Best Current Practice [Page 2] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + + The recommended approach to maintain name space continuity is to use + administrative policies, as described in the next section. + +4. DNS IPv6 Transport recommended Guidelines + + In order to preserve name space continuity, the following + administrative policies are recommended: + + - every recursive name server SHOULD be either IPv4-only or dual + stack, + + This rules out IPv6-only recursive servers. However, one might + design configurations where a chain of IPv6-only name server + forward queries to a set of dual stack recursive name server + actually performing those recursive queries. + + - every DNS zone SHOULD be served by at least one IPv4-reachable + authoritative name server. + + This rules out DNS zones served only by IPv6-only authoritative + name servers. + + Note: zone validation processes SHOULD ensure that there is at least + one IPv4 address record available for the name servers of any child + delegations within the zone. + +5. Security Considerations + + The guidelines described in this memo introduce no new security + considerations into the DNS protocol or associated operational + scenarios. + +6. Acknowledgment + + This document is the result of many conversations that happened in + the DNS community at IETF and elsewhere since 2001. During that + period of time, a number of Internet drafts have been published to + clarify various aspects of the issues at stake. This document + focuses on the conclusion of those discussions. + + The authors would like to acknowledge the role of Pekka Savola in his + thorough review of the document. + + + + + + + + + +Durand & Ihren Best Current Practice [Page 3] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + +7. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + +8. Authors' Addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + + EMail: Alain.Durand@sun.com + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + EMail: johani@autonomica.se + + + + + + + + + + + + + +Durand & Ihren Best Current Practice [Page 4] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Durand & Ihren Best Current Practice [Page 5] + diff --git a/contrib/bind9/doc/rfc/rfc4025.txt b/contrib/bind9/doc/rfc/rfc4025.txt new file mode 100644 index 000000000000..92e7f4007956 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4025.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group M. Richardson +Request for Comments: 4025 SSW +Category: Standards Track February 2005 + + + A Method for Storing IPsec Keying Material in DNS + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a new resource record for the Domain Name + System (DNS). This record may be used to store public keys for use + in IP security (IPsec) systems. The record also includes provisions + for indicating what system should be contacted when an IPsec tunnel + is established with the entity in question. + + This record replaces the functionality of the sub-type #4 of the KEY + Resource Record, which has been obsoleted by RFC 3445. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and + IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3 + 2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3 + 2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4 + 2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4 + 2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4 + 2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5 + 2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5 + 3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6 + 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + + + +Richardson Standards Track [Page 1] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + 4.1. Active Attacks Against Unsecured IPSECKEY Resource + Records . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. Active Attacks Against IPSECKEY Keying + Materials. . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Active Attacks Against IPSECKEY Gateway + Material. . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + Suppose a host wishes (or is required by policy) to establish an + IPsec tunnel with some remote entity on the network prior to allowing + normal communication to take place. In many cases, this end system + will be able to determine the DNS name for the remote entity (either + by having the DNS name given explicitly, by performing a DNS PTR + query for a particular IP address, or through some other means, e.g., + by extracting the DNS portion of a "user@FQDN" name for a remote + entity). In these cases, the host will need to obtain a public key + to authenticate the remote entity, and may also need some guidance + about whether it should contact the entity directly or use another + node as a gateway to the target entity. The IPSECKEY RR provides a + mechanism for storing such information. + + The type number for the IPSECKEY RR is 45. + + This record replaces the functionality of the sub-type #4 of the KEY + Resource Record, which has been obsoleted by RFC 3445 [11]. + +1.1. Overview + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS) [1] name for + use with the IPsec protocol suite. This can be the public key of a + host, network, or application (in the case of per-port keying). + + 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 [3]. + + + + + + + +Richardson Standards Track [Page 2] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA) + + Often a security gateway will only have access to the IP address of + the node with which communication is desired and will not know any + other name for the target node. Because of this, frequently the best + way of looking up IPSECKEY RRs will be by using the IP address as an + index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or + IP6.ARPA for IPv6). + + The lookup is done in the fashion usual for PTR records. The IP + address' octets (IPv4) or nibbles (IPv6) are reversed and looked up + with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be + followed. + + Note: even when the IPsec function is contained in the end-host, + often only the application will know the forward name used. Although + the case where the application knows the forward name is common, the + user could easily have typed in a literal IP address. This storage + mechanism does not preclude using the forward name when it is + available but does not require it. + +1.3. Usage Criteria + + An IPSECKEY resource record SHOULD be used in combination with DNSSEC + [8] unless some other means of authenticating the IPSECKEY resource + record is available. + + It is expected that there will often be multiple IPSECKEY resource + records at the same name. This will be due to the presence of + multiple gateways and a need to roll over keys. + + This resource record is class independent. + +2. Storage Formats + +2.1. IPSECKEY RDATA Format + + The RDATA for an IPSECKEY RR consists of a precedence value, a + gateway type, a public key, algorithm type, and an optional gateway + address. + + + + + + + + + + + +Richardson Standards Track [Page 3] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + +2.2. RDATA Format - Precedence + + This is an 8-bit precedence for this record. It is interpreted in + the same way as the PREFERENCE field described in section 3.3.9 of + RFC 1035 [2]. + + Gateways listed in IPSECKEY records with lower precedence are to be + attempted first. Where there is a tie in precedence, the order + should be non-deterministic. + +2.3. RDATA Format - Gateway Type + + The gateway type field indicates the format of the information that + is stored in the gateway field. + + The following values are defined: + 0 No gateway is present. + 1 A 4-byte IPv4 address is present. + 2 A 16-byte IPv6 address is present. + 3 A wire-encoded domain name is present. The wire-encoded format is + self-describing, so the length is implicit. The domain name MUST + NOT be compressed. (See Section 3.3 of RFC 1035 [2].) + +2.4. RDATA Format - Algorithm Type + + The algorithm type field identifies the public key's cryptographic + algorithm and determines the format of the public key field. + + A value of 0 indicates that no key is present. + + The following values are defined: + 1 A DSA key is present, in the format defined in RFC 2536 [9]. + 2 A RSA key is present, in the format defined in RFC 3110 [10]. + + + + + + +Richardson Standards Track [Page 4] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +2.5. RDATA Format - Gateway + + The gateway field indicates a gateway to which an IPsec tunnel may be + created in order to reach the entity named by this resource record. + + There are three formats: + + A 32-bit IPv4 address is present in the gateway field. The data + portion is an IPv4 address as described in section 3.4.1 of RFC 1035 + [2]. This is a 32-bit number in network byte order. + + A 128-bit IPv6 address is present in the gateway field. The data + portion is an IPv6 address as described in section 2.2 of RFC 3596 + [12]. This is a 128-bit number in network byte order. + + The gateway field is a normal wire-encoded domain name, as described + in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used. + +2.6. RDATA Format - Public Keys + + Both the public key types defined in this document (RSA and DSA) + inherit their public key formats from the corresponding KEY RR + formats. Specifically, the public key field contains the + algorithm-specific portion of the KEY RR RDATA, which is all the KEY + RR DATA after the first four octets. This is the same portion of the + KEY RR that must be specified by documents that define a DNSSEC + algorithm. Those documents also specify a message digest to be used + for generation of SIG RRs; that specification is not relevant for + IPSECKEY RRs. + + Future algorithms, if they are to be used by both DNSSEC (in the KEY + RR) and IPSECKEY, are likely to use the same public key encodings in + both records. Unless otherwise specified, the IPSECKEY public key + field will contain the algorithm-specific portion of the KEY RR RDATA + for the corresponding algorithm. The algorithm must still be + designated for use by IPSECKEY, and an IPSECKEY algorithm type number + (which might be different from the DNSSEC algorithm number) must be + assigned to it. + + The DSA key format is defined in RFC 2536 [9] + + The RSA key format is defined in RFC 3110 [10], with the following + changes: + + The earlier definition of RSA/MD5 in RFC 2065 [4] limited the + exponent and modulus to 2552 bits in length. RFC 3110 extended that + limit to 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no + length limit on RSA public keys, other than the 65535 octet limit + + + +Richardson Standards Track [Page 5] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + imposed by the two-octet length encoding. This length extension is + applicable only to IPSECKEY; it is not applicable to KEY RRs. + +3. Presentation Formats + +3.1. Representation of IPSECKEY RRs + + IPSECKEY RRs may appear in a zone data master file. The precedence, + gateway type, algorithm, and gateway fields are REQUIRED. The base64 + encoded public key block is OPTIONAL; if it is not present, the + public key field of the resource record MUST be construed to be zero + octets in length. + + The algorithm field is an unsigned integer. No mnemonics are + defined. + + If no gateway is to be indicated, then the gateway type field MUST be + zero, and the gateway field MUST be "." + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see RFC 3548 [6], Section 5.2. + + The general presentation for the record is as follows: + + IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) + +3.2. Examples + + An example of a node, 192.0.2.38, that will accept IPsec tunnels on + its own behalf. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38, that has published its key only. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + + + + + + + + +Richardson Standards Track [Page 6] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + An example of a node, 192.0.2.38, that has delegated authority to the + node 192.0.2.3. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.1.38 that has delegated authority to the + node with the identity "mygateway.example.com". + + 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has + delegated authority to the node 2001:0DB8:c000:0200:2::1 + + $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. + 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 + 2001:0DB8:0:8002::2000:1 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + +4. Security Considerations + + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC 2407) + [7]. + + The IPSECKEY resource record contains information that SHOULD be + communicated to the end client in an integral fashion; i.e., free + from modification. The form of this channel is up to the consumer of + the data; there must be a trust relationship between the end consumer + of this resource record and the server. This relationship may be + end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another + secure source, a secure local channel on the host, or some + combination of the above. + + The keying material provided by the IPSECKEY resource record is not + sensitive to passive attacks. The keying material may be freely + disclosed to any party without any impact on the security properties + of the resulting IPsec session. IPsec and IKE provide defense + against both active and passive attacks. + + Any derivative specification that makes use of this resource record + MUST carefully document its trust model and why the trust model of + DNSSEC is appropriate, if that is the secure channel used. + + + + + +Richardson Standards Track [Page 7] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + An active attack on the DNS that caused the wrong IP address to be + retrieved (via forged address), and therefore the wrong QNAME to be + queried, would also result in a man-in-the-middle attack. This + situation is independent of whether the IPSECKEY RR is used. + +4.1. Active Attacks Against Unsecured IPSECKEY Resource Records + + This section deals with active attacks against the DNS. These + attacks require that DNS requests and responses be intercepted and + changed. DNSSEC is designed to defend against attacks of this kind. + This section deals with the situation in which DNSSEC is not + available. This is not the recommended deployment scenario. + +4.1.1. Active Attacks Against IPSECKEY Keying Materials + + The first kind of active attack is when the attacker replaces the + keying material with either a key under its control or with garbage. + + The gateway field is either untouched or is null. The IKE + negotiation will therefore occur with the original end-system. For + this attack to succeed, the attacker must perform a man-in-the-middle + attack on the IKE negotiation. This attack requires that the + attacker be able to intercept and modify packets on the forwarding + path for the IKE and data packets. + + If the attacker is not able to perform this man-in-the-middle attack + on the IKE negotiation, then a denial of service will result, as the + IKE negotiation will fail. + + If the attacker is not only able to mount active attacks against DNS + but also in a position to perform a man-in-the-middle attack on IKE + and IPsec negotiations, then the attacker will be able to compromise + the resulting IPsec channel. Note that an attacker must be able to + perform active DNS attacks on both sides of the IKE negotiation for + this to succeed. + +4.1.2. Active Attacks Against IPSECKEY Gateway Material + + The second kind of active attack is one in which the attacker + replaces the gateway address to point to a node under the attacker's + control. The attacker then either replaces the public key or removes + it. If the public key were removed, then the attacker could provide + an accurate public key of its own in a second record. + + This second form creates a simple man-in-the-middle attacks since the + attacker can then create a second tunnel to the real destination. + Note that, as before, this requires that the attacker also mount an + active attack against the responder. + + + +Richardson Standards Track [Page 8] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + Note that the man-in-the-middle cannot just forward cleartext packets + to the original destination. While the destination may be willing to + speak in the clear, replying to the original sender, the sender will + already have created a policy expecting ciphertext. Thus, the + attacker will need to intercept traffic in both directions. In some + cases, the attacker may be able to accomplish the full intercept by + use of Network Address/Port Translation (NAT/NAPT) technology. + + This attack is easier than the first one because the attacker does + NOT need to be on the end-to-end forwarding path. The attacker need + only be able to modify DNS replies. This can be done by packet + modification, by various kinds of race attacks, or through methods + that pollute DNS caches. + + If the end-to-end integrity of the IPSECKEY RR is suspect, the end + client MUST restrict its use of the IPSECKEY RR to cases where the RR + owner name matches the content of the gateway field. As the RR owner + name is assumed when the gateway field is null, a null gateway field + is considered a match. + + Thus, any records obtained under unverified conditions (e.g., no + DNSSEC or trusted path to source) that have a non-null gateway field + MUST be ignored. + + This restriction eliminates attacks against the gateway field, which + are considered much easier, as the attack does not need to be on the + forwarding path. + + In the case of an IPSECKEY RR with a value of three in its gateway + type field, the gateway field contains a domain name. The subsequent + query required to translate that name into an IP address or IPSECKEY + RR will also be subject to man-in-the-middle attacks. If the + end-to-end integrity of this second query is suspect, then the + provisions above also apply. The IPSECKEY RR MUST be ignored + whenever the resulting gateway does not match the QNAME of the + original IPSECKEY RR query. + +5. IANA Considerations + + This document updates the IANA Registry for DNS Resource Record Types + by assigning type 45 to the IPSECKEY record. + + This document creates two new IANA registries, both specific to the + IPSECKEY Resource Record: + + This document creates an IANA registry for the algorithm type field. + + + + + +Richardson Standards Track [Page 9] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3 + through 255 can be assigned by IETF Consensus (see RFC 2434 [5]). + + This document creates an IANA registry for the gateway type field. + + Values 0, 1, 2, and 3 are defined in Section 2.3. Gateway type + numbers 4 through 255 can be assigned by Standards Action (see RFC + 2434 [5]). + +6. Acknowledgements + + My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob + Austein, and Olafur Gudmundsson, who reviewed this document + carefully. Additional thanks to Olafur Gurmundsson for a reference + implementation. + +7. References + +7.1. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + +7.2. Informative References + + [7] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [8] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [9] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + + +Richardson Standards Track [Page 10] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Standards Track [Page 11] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Richardson Standards Track [Page 12] + diff --git a/contrib/bind9/doc/rfc/rfc4033.txt b/contrib/bind9/doc/rfc/rfc4033.txt new file mode 100644 index 000000000000..7f0a46477319 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4033.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4033 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + DNS Security Introduction and Requirements + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + document introduces these extensions and describes their capabilities + and limitations. This document also discusses the services that the + DNS security extensions do and do not provide. Last, this document + describes the interrelationships between the documents that + collectively describe DNSSEC. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3 + 3. Services Provided by DNS Security . . . . . . . . . . . . . 7 + 3.1. Data Origin Authentication and Data Integrity . . . . 7 + 3.2. Authenticating Name and Type Non-Existence . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . 9 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12 + 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13 + 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 14.1. Normative References . . . . . . . . . . . . . . . . . 17 + 14.2. Informative References . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents ([RFC4034] + and [RFC4035]) update, clarify, and refine the security extensions + defined in [RFC2535] and its predecessors. These security extensions + consist of a set of new resource record types and modifications to + the existing DNS protocol ([RFC1035]). The new records and protocol + modifications are not fully described in this document, but are + described in a family of documents outlined in Section 10. Sections + 3 and 4 describe the capabilities and limitations of the security + extensions in greater detail. Section 5 discusses the scope of the + document set. Sections 6, 7, 8, and 9 discuss the effect that these + security extensions will have on resolvers, stub resolvers, zones, + and name servers. + + This document and its two companions obsolete [RFC2535], [RFC3008], + [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and + [RFC3845]. This document set also updates but does not obsolete + [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], + [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with + DNSSEC. + + + + +Arends, et al. Standards Track [Page 2] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Because this is intended to be useful as a reference while reading + the rest of the document set, first-time readers may wish to skim + this section quickly, read the rest of this document, and then come + back to this section. + + Authentication Chain: An alternating sequence of DNS public key + (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of + signed data, with each link in the chain vouching for the next. A + DNSKEY RR is used to verify the signature covering a DS RR and + allows the DS RR to be authenticated. The DS RR contains a hash + of another DNSKEY RR and this new DNSKEY RR is authenticated by + matching the hash in the DS RR. This new DNSKEY RR in turn + authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in + this set may be used to authenticate another DS RR, and so forth + until the chain finally ends with a DNSKEY RR whose corresponding + private key signs the desired DNS data. For example, the root + DNSKEY RRset can be used to authenticate the DS RRset for + "example." The "example." DS RRset contains a hash that matches + some "example." DNSKEY, and this DNSKEY's corresponding private + key signs the "example." DNSKEY RRset. Private key counterparts + of the "example." DNSKEY RRset sign data records such as + "www.example." and DS RRs for delegations such as + "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and the DNSKEY RR to + which the DS RR refers. Third, the resolver may be able to + determine that a new public key has been signed by the private key + corresponding to another public key that the resolver has + verified. Note that the resolver must always be guided by local + policy when deciding whether to authenticate a new public key, + even if the local policy is simply to authenticate any new public + key for which the resolver is able verify the signature. + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Authoritative RRset: Within the context of a particular zone, an + RRset is "authoritative" if and only if the owner name of the + RRset lies within the subset of the name space that is at or below + the zone apex and at or above the cuts that separate the zone from + its children, if any. All RRsets at the zone apex are + authoritative, except for certain RRsets at this domain name that, + if present, belong to this zone's parent. These RRset could + include a DS RRset, the NSEC RRset referencing this DS RRset (the + "parental NSEC"), and RRSIG RRs associated with these RRsets, all + of which are authoritative in the parent zone. Similarly, if this + zone contains any delegation points, only the parental NSEC RRset, + DS RRsets, and any RRSIG RRs associated with these RRsets are + authoritative for this zone. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). See also zone apex. + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see [RFC4034]). + An island of security is served by security-aware name servers and + may provide authentication chains to any delegated child zones. + Responses from an island of security or its descendents can only + be authenticated if its authentication keys can be authenticated + by some trusted means out of band from the DNS protocol. + + Key Signing Key (KSK): An authentication key that corresponds to a + private key used to sign one or more other authentication keys for + a given zone. Typically, the private key corresponding to a key + signing key will sign a zone signing key, which in turn has a + corresponding private key that will sign other zone data. Local + policy may require that the zone signing key be changed + frequently, while the key signing key may have a longer validity + period in order to provide a more stable secure entry point into + the zone. Designating an authentication key as a key signing key + is purely an operational issue: DNSSEC validation does not + distinguish between key signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. Key signing keys + are discussed in more detail in [RFC3757]. Also see zone signing + key. + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver that trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity that sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server that will + provide these services on behalf of the security-aware stub + resolver. See also security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity that + receives DNS queries, sends DNS responses, supports the EDNS0 + ([RFC2671]) message size extension and the DO bit ([RFC3225]), and + supports the RR types and message header bits defined in this + document set. + + Security-Aware Recursive Name Server: An entity that acts in both the + security-aware name server and security-aware resolver roles. A + more cumbersome but equivalent phrase would be "a security-aware + name server that offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) that understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity that sends DNS queries, + receives DNS responses, supports the EDNS0 ([RFC2671]) message + size extension and the DO bit ([RFC3225]), and is capable of using + the RR types and message header bits defined in this document set + to provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) that has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating", depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also validating stub resolver, non-validating stub resolver. + + + + + +Arends, et al. Standards Track [Page 5] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Security-Oblivious <anything>: An <anything> that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and that contains + properly constructed DNSKEY, Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) DS records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will have to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed. + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but that performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also + security-aware stub resolver, non-validating security-aware stub + resolver. + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Apex: Term used to describe the name at the child's side of a + zone cut. See also delegation point. + + Zone Signing Key (ZSK): An authentication key that corresponds to a + private key used to sign a zone. Typically, a zone signing key + will be part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue; DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also key + signing key. + + + + + + + + +Arends, et al. Standards Track [Page 6] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types: Resource Record Signature (RRSIG), + DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure + (NSEC). It also adds two new message header bits: Checking Disabled + (CD) and Authenticated Data (AD). In order to support the larger DNS + message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support + for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a + security-aware resolver can indicate in its queries that it wishes to + receive DNSSEC RRs in response messages. + + These services protect against most of the threats to the Domain Name + System described in [RFC3833]. Please see Section 12 for a + discussion of the limitations of these extensions. + +3.1. Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the RRSIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible. For example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers. (Public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [RFC2931], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions. The keys associated with transaction security may be + stored in different RR types. See [RFC3755] for details.) + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure and should be stored + offline when practical. To discover a public key reliably via DNS + resolution, the target key itself has to be signed by either a + configured authentication key or another key that has been + + + +Arends, et al. Standards Track [Page 7] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + which in turn either has been configured into the resolver or must + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. + + If the configured trust anchor is a zone signing key, then it will + authenticate the associated zone; if the configured key is a key + signing key, it will authenticate a zone signing key. If the + configured trust anchor is the hash of a key rather than the key + itself, the resolver may have to obtain the key via a DNS query. To + help security-aware resolvers establish this authentication chain, + security-aware name servers attempt to send the signature(s) needed + to authenticate a zone's public key(s) in the DNS reply message along + with the public key itself, provided that there is space available in + the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, may not provide configured knowledge of the root + public key, or may prevent the resolver from using particular public + keys for arbitrary reasons, even if those public keys are properly + signed with verifiable signatures. DNSSEC provides mechanisms by + which a security-aware resolver can determine whether an RRset's + signature is "valid" within the meaning of DNSSEC. In the final + analysis, however, authenticating both DNS keys and data is a matter + of local policy, which may extend or even override the protocol + extensions defined in this document set. See Section 5 for further + discussion. + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +3.2. Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NSEC + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + with the same mechanisms used to authenticate other DNS replies. Use + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + the gaps, or "empty space", between domain names in a zone and list + the types of RRsets present at existing names. Each NSEC record is + signed and authenticated using the mechanisms described in Section + 3.1. + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + ([RFC2136], [RFC3007]). Message authentication schemes described in + [RFC2845] and [RFC2931] address security operations that pertain to + these transactions. + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine the following 4 states: + + Secure: The validating resolver has a trust anchor, has a chain of + trust, and is able to verify all the signatures in the response. + + + +Arends, et al. Standards Track [Page 9] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. This indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have a local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and a secure + delegation indicating that subsidiary data is signed, but the + response fails to validate for some reason: missing signatures, + expired signatures, signatures with unsupported algorithms, data + missing that the relevant NSEC RR says should be present, and so + forth. + + Indeterminate: There is no trust anchor that would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security-aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure"; see [RFC4035]). + + There is a mechanism for security-aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit; see [RFC4035]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure states. + + A method for signaling advanced error codes and policy between a + security-aware stub resolver and security-aware recursive nameservers + is a topic for future work, as is the interface between a security- + aware resolver and the applications that use it. Note, however, that + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + +6. Resolver Considerations + + A security-aware resolver has to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + + + +Arends, et al. Standards Track [Page 10] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + obtain necessary DNSKEY, DS, and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of intermediary device that acts as a proxy for DNS, and if the + recursive name server or intermediary device is not security-aware, + the security-aware resolver may not be capable of operating in a + secure mode. For example, if a security-aware resolver's packets are + routed through a network address translation (NAT) device that + includes a DNS proxy that is not security-aware, the security-aware + resolver may find it difficult or impossible to obtain or validate + signed DNS data. The security-aware resolver may have a particularly + difficult time obtaining DS RRs in such a case, as DS RRs do not + follow the usual DNS rules for ownership of RRs at zone cuts. Note + that this problem is not specific to NATs: any security-oblivious DNS + software of any kind between the security-aware resolver and the + authoritative name servers will interfere with DNSSEC. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature. However, it should also allow for the possibility that + the security-aware resolver's own clock is wrong. Thus, a + security-aware resolver that is part of a security-aware recursive + name server will have to pay careful attention to the DNSSEC + "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers that are clients of this recursive name + server. See [RFC4035] for how a secure recursive server handles + queries with the CD bit set. + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers that use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a security-aware iterative resolver. + + Even a security-oblivious stub resolver may benefit from DNSSEC if + the recursive name servers it uses are security-aware, but for the + stub resolver to place any real reliance on DNSSEC services, the stub + resolver must trust both the recursive name servers in question and + the communication channels between itself and those name servers. + The first of these issues is a local policy issue: in essence, a + security-oblivious stub resolver has no choice but to place itself at + the mercy of the recursive name servers that it uses, as it does not + perform DNSSEC validity checks on its own. The second issue requires + some kind of channel security mechanism; proper use of DNS + transaction authentication mechanisms such as SIG(0) ([RFC2931]) or + TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. + Particular implementations may have other choices available, such as + operating system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the Authenticated Data (AD) bit in the message + header of the response messages it receives. The stub resolver can + use this flag bit as a hint to find out whether the recursive name + server was able to validate signatures for all of the data in the + Answer and Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers that it uses: it can + perform its own signature validation by setting the Checking Disabled + (CD) bit in its query messages. A validating stub resolver is thus + able to treat the DNSSEC signatures as trust relationships between + the zone administrators and the stub resolver itself. + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times that establish a validity period for the signatures + and the zone data the signatures cover. + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +8.1. TTL Values vs. RRSIG Validity Period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR ([RFC4034]), on + the other hand, specify the time period during which the signature + can be used to validate the covered RRset. The signatures associated + with signed zone data are only valid for the time period specified by + these fields in the RRSIG RRs in question. TTL values cannot extend + the validity period of signed RRsets in a resolver's cache, but the + resolver may use the time remaining before expiration of the + signature validity period of a signed RRset as an upper bound for the + TTL of the signed RRset and its associated RRSIG RR in the resolver's + cache. + +8.2. New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency that did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which will in turn require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfer operations. + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries + from resolvers that have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Because inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + + + + +Arends, et al. Standards Track [Page 13] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + it is updated, so the private key corresponding to the zone signing + key will have to be kept online. This is an example of a situation + in which the ability to separate the zone's DNSKEY RRset into zone + signing key(s) and key signing key(s) may be useful, as the key + signing key(s) in such a case can still be kept offline and may have + a longer useful lifetime than the zone signing key(s). + + By itself, DNSSEC is not enough to protect the integrity of an entire + zone during zone transfer operations, as even a signed zone contains + some unsigned, nonauthoritative data if the zone has any children. + Therefore, zone maintenance operations will require some additional + mechanisms (most likely some form of channel security, such as TSIG, + SIG(0), or IPsec). + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents that + form the core of the DNS security extensions: + + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions [RFC4034] + + 3. Protocol Modifications for the DNS Security Extensions [RFC4035] + + Additionally, any document that would add to or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. Please see the appendix on "DNSSEC + Algorithm and Digest Types" in [RFC4034] for a list of the algorithms + that were defined when this core specification was written. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. Although not + + + +Arends, et al. Standards Track [Page 14] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses but may be used to support them. Documents that fall + in this category include those describing the use of DNS in the + storage and distribution of certificates ([RFC2538]). + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [RFC4034] for a complete review of the IANA considerations + introduced by DNSSEC. + +12. Security Considerations + + This document introduces DNS security extensions and describes the + document set that contains the new security records and DNS protocol + modifications. The extensions provide data origin authentication and + data integrity using digital signatures over resource record sets. + This section discusses the limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data that the resolver is only able to obtain through a recursive + name server that is not security-aware. If there is a break in the + authentication chain such that a security-aware resolver cannot + obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism such as TSIG ([RFC2845]) or + SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC + per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers that perform these checks on its behalf and to attacks + on its communication with those security-aware recursive name + + + +Arends, et al. Standards Track [Page 15] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + servers. Non-validating security-aware stub resolvers should use + some form of channel security to defend against the latter threat. + The only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, as an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + consume resources in a security-aware name server that supports DNS + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + Due to a deliberate design choice, DNSSEC does not provide + confidentiality. + + DNSSEC introduces the ability for a hostile party to enumerate all + the names in a zone by following the NSEC chain. NSEC RRs assert + which names do not exist in a zone by linking from existing name to + existing name along a canonical ordering of all the names within a + zone. Thus, an attacker can query these NSEC RRs in sequence to + obtain all the names in a zone. Although this is not an attack on + the DNS itself, it could allow an attacker to map network hosts or + other resources by enumerating the contents of a zone. + + DNSSEC introduces significant additional complexity to the DNS and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. This does not pose a problem when validating + the authentication chain, but it does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be + used to protect zone transfer operations. + + + +Arends, et al. Standards Track [Page 16] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Please see [RFC4034] and [RFC4035] for additional security + considerations. + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. Although explicitly listing + everyone who has contributed during the decade in which DNSSEC has + been under development would be impossible, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Jaap Akkerhuis, + Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, + David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald + Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, + Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip + Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, + Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon + Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, + Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, + Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ + Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob + Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, + Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, + Brian Wellington, and Suzanne Woolf. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + +14. References + +14.1. Normative References + + [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. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for 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. + +14.2. Informative References + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates + in the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 21] + diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt new file mode 100644 index 000000000000..6a12c6b8efc5 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4034.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4034 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Resource Records for the DNS Security Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . 3 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4 + 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4 + 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4 + 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5 + 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5 + 2.1.4. The Public Key Field . . . . . . . . . . . . . 5 + 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5 + 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5 + 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6 + 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7 + 3.1.1. The Type Covered Field . . . . . . . . . . . . 7 + 3.1.2. The Algorithm Number Field . . . . . . . . . . 8 + 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8 + 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8 + 3.1.5. Signature Expiration and Inception Fields. . . 9 + 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9 + 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9 + 3.1.8. The Signature Field. . . . . . . . . . . . . . 9 + 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10 + 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12 + 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13 + 4.1.1. The Next Domain Name Field . . . . . . . . . . 13 + 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13 + 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14 + 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14 + 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15 + 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16 + 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16 + 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16 + 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17 + 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17 + 5.2. Processing of DS RRs When Validating Responses . . . . 17 + 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17 + 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18 + 6. Canonical Form and Order of Resource Records . . . . . . . . 18 + 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18 + 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19 + 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4034 DNSSEC Resource Records March 2005 + + + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . 23 + A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24 + A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24 + A.1.1. Private Algorithm Types. . . . . . . . . . . . 25 + A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25 + B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25 + B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNS Public Key (DNSKEY), Resource Record Signature + (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This + document defines the purpose of each resource record (RR), the RR's + RDATA format, and its presentation format (ASCII representation). + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC, which + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definition of common + terms; the reader is assumed to be familiar with this document. + [RFC4033] also contains a list of other documents updated by and + obsoleted by this document set. + + [RFC4035] defines the DNSSEC protocol operations. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them, particularly [RFC2181] and [RFC2308]. + + This document defines the DNSSEC resource records. All numeric DNS + type codes given in this document are decimal integers. + +1.2. Reserved Words + + 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 [RFC2119]. + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4034 DNSSEC Resource Records March 2005 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [RFC4035]: A zone signs its authoritative RRsets by + using a private key and stores the corresponding public key in a + DNSKEY RR. A resolver can then use the public key to validate + signatures covering the RRsets in the zone, and thus to authenticate + them. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1. DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1. The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's + owner name MUST be the name of a zone. If bit 7 has value 0, then + the DNSKEY record holds some other type of DNS public key and MUST + NOT be used to verify RRSIGs that cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + key intended for use as a secure entry point. This flag is only + + + +Arends, et al. Standards Track [Page 4] + +RFC 4034 DNSSEC Resource Records March 2005 + + + intended to be a hint to zone signing or debugging software as to the + intended use of this DNSKEY record; validators MUST NOT alter their + behavior during the signature validation process in any way based on + the setting of this bit. This also means that a DNSKEY RR with the + SEP bit set would also need the Zone Key flag set in order to be able + to generate signatures legally. A DNSKEY RR with the SEP set and the + Zone Key flag not set MUST NOT be used to verify RRSIGs that cover + RRsets. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR and MUST be ignored upon receipt. + +2.1.2. The Protocol Field + + The Protocol Field MUST have value 3, and the DNSKEY RR MUST be + treated as invalid during signature verification if it is found to be + some value other than 3. + +2.1.3. The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4. The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and is described in + separate documents. + +2.1.5. Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2. The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer. + Given the currently defined flags, the possible values are: 0, 256, + and 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + +Arends, et al. Standards Track [Page 5] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC3548]. + +2.3. DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [RFC4035]. A validator can use these RRSIG RRs + to authenticate RRsets from the zone. The RRSIG RR MUST only be used + to carry verification material (digital signatures) used to secure + DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034], which stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + + + +Arends, et al. Standards Track [Page 6] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR MUST match the TTL value of the RRset it + covers. This is an exception to the [RFC2181] rules for TTL values + of individual RRs within a RRset: individual RRSIG RRs with the same + owner name will have different TTL values if the RRsets they cover + have different TTL values. + +3.1. RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.1.1. The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + + + + + + + +Arends, et al. Standards Track [Page 7] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.2. The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3. The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine whether the answer was synthesized from a + wildcard. If so, it can be used to determine what owner name was + used in generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will have to reconstruct the original owner name in order + to validate the signature. [RFC4035] describes how to use the Labels + field to reconstruct the original owner name. + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when the signature is generated or verified. + +3.1.4. Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. [RFC4035] + describes how to use the Original TTL field value to reconstruct the + original TTL. + + + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.5. Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + The Signature Expiration and Inception field values specify a date + and time in the form of a 32-bit unsigned number of seconds elapsed + since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network + byte order. The longest interval that can be expressed by this + format without wrapping is approximately 136 years. An RRSIG RR can + have an Expiration field value that is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic", as defined in [RFC1982]. As a direct + consequence, the values contained in these fields cannot refer to + dates more than 68 years in either the past or the future. + +3.1.6. The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature, in network byte order. Appendix B explains + how to calculate Key Tag values. + +3.1.7. The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR that a validator is supposed to use to validate this signature. + The Signer's Name field MUST contain the name of the zone of the + covered RRset. A sender MUST NOT use DNS name compression on the + Signer's Name field when transmitting a RRSIG RR. + +3.1.8. The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use, and these formats are described in separate companion documents. + +3.1.8.1. Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6), and the set RR(1),...RR(n) is signed as follows: + + + +Arends, et al. Standards Track [Page 9] + +RFC 4034 DNSSEC Resource Records March 2005 + + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Sections 6.2 and 6.3 for details on canonical form and ordering + of RRsets. + +3.2. The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as an RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597], Section 5, MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic, as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as an unsigned decimal integer indicating seconds + since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in + UTC, where: + + YYYY is the year (0001-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour, in 24 hour notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + Note that it is always possible to distinguish between these two + formats because the YYYYMMDDHHmmSS format will always be exactly 14 + digits, while the decimal representation of a 32-bit unsigned integer + can never be longer than 10 digits. + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3. RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4034 DNSSEC Resource Records March 2005 + + + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicates that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate that this signature + can be authenticated using an example.com zone DNSKEY RR whose + algorithm is 5 and whose key tag is 2642. + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the next owner + name (in the canonical ordering of the zone) that contains + authoritative data or a delegation point NS RRset, and the set of RR + types present at the NSEC RR's owner name [RFC3845]. The complete + set of NSEC RRs in a zone indicates which authoritative RRsets exist + in a zone and also form a chain of authoritative owner names in the + zone. This information is used to provide authenticated denial of + existence for DNS data, as described in [RFC4035]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034], + which stated that if a CNAME is present for a name, it is the only + type allowed at that name. An RRSIG (see Section 3) and NSEC MUST + exist for the same name as does a CNAME resource record in a signed + zone. + + See [RFC4035] for discussion of how a zone signer determines + precisely which NSEC RRs it has to include in a zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching ([RFC2308]). + + + + + + + + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.1. NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.1. The Next Domain Name Field + + The Next Domain field contains the next owner name (in the canonical + ordering of the zone) that has authoritative data or contains a + delegation point NS RRset; see Section 6.1 for an explanation of + canonical ordering. The value of the Next Domain Name field in the + last NSEC record in the zone is the name of the zone apex (the owner + name of the zone's SOA RR). This indicates that the owner name of + the NSEC RR is the last name in the canonical ordering of the zone. + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets for which the given zone is not authoritative + (such as glue records) MUST NOT be listed in the Next Domain Name + unless at least one authoritative RRset exists at the same owner + name. + +4.1.2. The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types that exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + + +Arends, et al. Standards Track [Page 13] + +RFC 4034 DNSSEC Resource Records March 2005 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, and bit 2 to RR type 258. If a bit is + set, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is clear, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be clear, as they do not appear + in zone data. If encountered, they MUST be ignored upon being read. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3. Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for the purposes of generating NSEC RRs. Wildcard owner + names appear in the Next Domain Name field without any wildcard + expansion. [RFC4035] describes the impact of wildcards on + authenticated denial of existence. + +4.2. The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + described in [RFC3597], Section 5, MUST be used. + + + + + +Arends, et al. Standards Track [Page 14] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.3. NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, + and TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or to + prove that there is no AAAA record associated with alfa.example.com. + Authenticated denial of existence is discussed in [RFC4035]. + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [RFC4035]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + + + +Arends, et al. Standards Track [Page 15] + +RFC 4034 DNSSEC Resource Records March 2005 + + + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing but introduces special response + processing requirements for the DS RR; these are described in + [RFC4035]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1. DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet + Algorithm field, a 1 octet Digest Type field, and a Digest field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5.1.1. The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record, in network byte order. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2. The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the + algorithm number types. + + + + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4034 DNSSEC Resource Records March 2005 + + +5.1.3. The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4. The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of this writing, the only defined + digest algorithm is SHA-1, which produces a 20 octet digest. + +5.2. Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC + zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be + used in the validation process. + +5.3. The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4. DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required in order to construct and verify RRSIG + RRs. + +6.1. Canonical DNS Name Order + + For the purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and uppercase + US-ASCII letters are treated as if they were lowercase US-ASCII + letters. + + + + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4034 DNSSEC Resource Records March 2005 + + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + by names ending "z.example". The names within each level are sorted + in the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + +6.2. Canonical RR Form + + For the purposes of DNS security, the canonical form of an RR is the + wire format of the RR where: + + 1. every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. all uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + + 4. if the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. the RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4034 DNSSEC Resource Records March 2005 + + +6.3. Canonical RR Ordering within an RRset + + For the purposes of DNS security, RRs with the same owner name, + class, and type are sorted by treating the RDATA portion of the + canonical form of each RR as a left-justified unsigned octet sequence + in which the absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, it MUST treat this as a protocol + error. If the implementation chooses to handle this protocol error + in the spirit of the robustness principle (being liberal in what it + accepts), it MUST remove all but one of the duplicate RR(s) for the + purposes of calculating the canonical form of the RRset. + +7. IANA Considerations + + This document introduces no new IANA considerations, as all of the + protocol parameters used in this document have already been assigned + by previous specifications. However, since the evolution of DNSSEC + has been long and somewhat convoluted, this section attempts to + describe the current state of the IANA registries and other protocol + parameters that are (or once were) related to DNSSEC. + + Please refer to [RFC4035] for additional IANA considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use + of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction + security protocol described in [RFC2931] and to the transaction + KEY Resource Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]), or both. Values 6-251 are + available for assignment by IETF standards action ([RFC3755]). + See Appendix A for a full listing of the DNS Security Algorithm + Numbers entries at the time of this writing and their status for + use in DNSSEC. + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] reassigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have a + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains assignments for bit 7 (the ZONE bit) + and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). + As stated in [RFC3755], bits 0-6 and 8-14 are available for + assignment by IETF Standards Action. + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [RFC4033] and [RFC4035] for + additional security considerations related to the use of these + records. + + The DS record points to a DNSKEY RR by using a cryptographic digest, + the key algorithm type, and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing a matching DNSKEY depends on the type of + digest algorithm in use. The only currently defined digest algorithm + is SHA-1, and the working group believes that constructing a public + key that would match the algorithm, key tag, and SHA-1 digest given + in a DS record would be a sufficiently difficult problem that such an + attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation that uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. Please see + Appendix B for further details. + + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The table of algorithms in Appendix A and the key tag calculation + algorithms in Appendix B include the RSA/MD5 algorithm for + completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as + explained in [RFC3110]. + +9. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +10. References + +10.1. Normative References + + [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. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, March 1999. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + + + + + +Arends, et al. Standards Track [Page 22] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, 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. + +10.2. Informative References + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain + Name System (DNS)", RFC 2537, March 1999. + + [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant them. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1. DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the + security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs, as described in [RFC2931]. + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED + 2 Diffie-Hellman [DH] n [RFC2539] - + 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + + + + + + + + + +Arends, et al. Standards Track [Page 24] + +RFC 4034 DNSSEC Resource Records March 2005 + + +A.1.1. Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use, and the remainder of the public key + area is determined by that algorithm. Entities should only use + domain names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use, and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2. DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but + it does not uniquely identify a DNSKEY record. Implementations MUST + NOT assume that the key tag uniquely identifies a DNSKEY RR. + + + + + +Arends, et al. Standards Track [Page 25] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First, the + RDATA (in wire format) is treated as a series of 2 octet groups. + These groups are then added together, ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below, with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones-complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + + +Arends, et al. Standards Track [Page 26] + +RFC 4034 DNSSEC Resource Records March 2005 + + +B.1. Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently from the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 29] + diff --git a/contrib/bind9/doc/rfc/rfc4035.txt b/contrib/bind9/doc/rfc/rfc4035.txt new file mode 100644 index 000000000000..b701cd2f235b --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4035.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4035 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Protocol Modifications for the DNS Security Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications that + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving by using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 + 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 + 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 + 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 + 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 + 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 + 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 + 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 + 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 + 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 + 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 + 3.1.6. The AD and CD Bits in an Authoritative Response. 16 + 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 + 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 + 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2. Signature Verification Support . . . . . . . . . . . . . 19 + 4.3. Determining Security Status of Data . . . . . . . . . . 20 + 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 + 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 + 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 + 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 + 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 + 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 + 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 + 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1. Special Considerations for Islands of Security . . . . . 26 + 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 + 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 + 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 + 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 + 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 + 5.3.4. Authenticating a Wildcard Expanded RRset + Positive Response. . . . . . . . . . . . . . . . 32 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 + 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 + 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 9.2. Informative References . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 + B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 + B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 + C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 + C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 + C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 + C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 + C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 + C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 + C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 + C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 + C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications that add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document + defines the concept of a signed zone and lists the requirements for + zone signing. Section 3 describes the modifications to authoritative + name server behavior necessary for handling signed zones. Section 4 + describes the behavior of entities that include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC that + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definitions of + common terms; the reader is assumed to be familiar with this + document. [RFC4033] also contains a list of other documents updated + by and obsoleted by this document set. + + [RFC4034] defines the DNSSEC resource records. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them; particularly, [RFC2181] and [RFC2308]. + + This document defines the DNSSEC protocol operations. + +1.2. Reserved Words + + 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 [RFC2119]. + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) Delegation Signer (DS) records + according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, + respectively. A zone that does not include these records according + to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as does a CNAME RR. + + DNSSEC specifies the placement of two new RR types, NSEC and DS, + which can be placed at the parental side of a zone cut (that is, at a + delegation point). This is an exception to the general prohibition + against putting data in the parent zone at a zone cut. Section 2.6 + describes this change. + + + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +2.1. Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR + containing the corresponding public key. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 + of [RFC4034]). Public keys associated with other DNS operations MAY + be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT + be used to verify RRSIGs. + + If the zone administrator intends a signed zone to be usable other + than as an island of security, the zone apex MUST contain at least + one DNSKEY RR to act as a secure entry point into the zone. This + secure entry point could then be used as the target of a secure + delegation via a corresponding DS RR in the parent zone (see + [RFC4034]). + +2.2. Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets the following requirements: + + o The RRSIG owner name is equal to the RRset owner name. + + o The RRSIG class is equal to the RRset class. + + o The RRSIG Type Covered field is equal to the RRset type. + + o The RRSIG Original TTL field is equal to the TTL of the RRset. + + o The RRSIG RR's TTL is equal to the TTL of the RRset. + + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard. + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset. + + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [RFC4034]. An RRset MAY have multiple RRSIG RRs + associated with it. Note that as RRSIG RRs are closely tied to the + RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS + + + +Arends, et al. Standards Track [Page 5] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RR types, do not form RRsets. In particular, the TTL values among + RRSIG RRs with a common owner name do not follow the RRset rules + described in [RFC2181]. + + An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would + add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3. Including NSEC RRs in a Zone + + Each owner name in the zone that has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [RFC4034]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not + the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Standards Track [Page 6] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part + visible only during the zone signing process, as NSEC RRsets are + authoritative data and are therefore signed. Thus, any owner name + that has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4. Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR that is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. DS RRs that fail to meet these + conditions are not useful for validation, but because the DS RR and + its corresponding DNSKEY RR are in different zones, and because the + DNS is only loosely consistent, temporary mismatches can occur. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5. Changes to the CNAME Resource Record + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed ([RFC3007]). + Other types MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + + + +Arends, et al. Standards Track [Page 7] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6. DNSSEC RR Types Appearing at Zone Cuts + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and seeks to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]), which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7. Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 ([RFC2671]) + message size extension, MUST support a message size of at least 1220 + octets, and SHOULD support a message size of 4000 octets. As IPv6 + packets can only be fragmented by the source host, a security aware + name server SHOULD take steps to ensure that UDP datagrams it + transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 + MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], + and [RFC3226] for further discussion of packet size and fragmentation + issues. + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and + MUST NOT perform any of the additional processing described below. + Because the DS RR type has the peculiar property of only existing in + the parent zone at delegation points, DS RRs always require some + special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types that match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. As long as the response is always + consistent for each query to the name server, the name server MAY + return one of the following: + + o The above-delegation RRsets. + o The below-delegation RRsets. + o Both above and below-delegation RRsets. + o Empty answer section (no records). + o Some other response. + o An error. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Sections 3.1.6, + 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. + + A security aware name server that synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1. Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT + pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs, according to the following rules: + + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1. + + + + + + + +Arends, et al. Standards Track [Page 9] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3. + + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses where the semantics convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1. Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may have to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may have to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MAY retain the RRset while + dropping the RRSIG RRs. If this happens, the name server MUST NOT + set the TC bit solely because these RRSIG RRs didn't fit. + + + + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.2. Including DNSKEY RRs in a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than does + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3. Including NSEC RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> + but does not contain any RRsets that exactly match <SNAME, SCLASS, + STYPE>. + + Name Error: The zone does not contain any RRsets that match <SNAME, + SCLASS> either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> but does contain an RRset that matches + <SNAME, SCLASS, STYPE> via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> and does contain one or more RRsets that + match <SNAME, SCLASS> via wildcard name expansion, but does not + contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard + name expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for <SNAME, SCLASS, STYPE> was + not present in the zone and that the response that the name server is + returning is correct given the data in the zone. + + + + + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.3.1. Including NSEC RRs: No Data Response + + If the zone contains RRsets matching <SNAME, SCLASS> but contains no + RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST + include the NSEC RR for <SNAME, SCLASS> along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove that the + requested RR type does not exist. + +3.1.3.2. Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching <SNAME, SCLASS> + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + + o An NSEC RR proving that there is no exact match for <SNAME, + SCLASS>. + + o An NSEC RR proving that the zone contains no RRsets that would + match <SNAME, SCLASS> via wildcard name expansion. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + that is not the owner name for any RRset but that is the parent name + of one or more RRsets). + +3.1.3.3. Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets that exactly match <SNAME, + SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> + via wildcard name expansion, the name server MUST include the + + + +Arends, et al. Standards Track [Page 12] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for <SNAME, SCLASS>. If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4. Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for <SNAME, SCLASS>, and although the zone + does contain RRsets that match <SNAME, SCLASS> via wildcard + expansion, none of those RRsets matches STYPE. The name server MUST + include the following NSEC RRs in the Authority section, along with + their associated RRSIG RRs: + + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name that matched <SNAME, SCLASS> via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for <SNAME, SCLASS>. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5. Finding the Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server has to locate an NSEC RR + that proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone that would have held + the non-existent RRsets matching SNAME. The algorithm below is + written for clarity, not for efficiency. + + To find the NSEC that proves that no RRsets matching name N exist in + the zone Z that would have held them, construct a sequence, S, + consisting of the owner names of every RRset in Z, sorted into + + + +Arends, et al. Standards Track [Page 13] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + canonical order ([RFC4034]), with no duplicate names. Find the name + M that would have immediately preceded N in S if any RRsets with + owner name N had existed. M is the owner name of the NSEC RR that + proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR that proves that a given name + is not covered by any applicable wildcard is similar but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR that + proves that RRsets with any other owner name do not exist. The part + that's missing is a method of determining the name of the non- + existent applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4. Including DS RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR that proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1. Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, as the name server for the + child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + + +Arends, et al. Standards Track [Page 14] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + + o The name server has received a query for the DS RRset at a zone + cut. + + o The name server is authoritative for the child zone. + + o The name server is not authoritative for the parent zone. + + o The name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5. Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails to meet any of the signing + requirements described in Section 2. The primary objective of a zone + transfer is to ensure that all authoritative name servers have + identical copies of the zone. An authoritative name server that + + + +Arends, et al. Standards Track [Page 15] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + chooses to perform its own zone validation MUST NOT selectively + reject some RRs and accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data. In the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, as the NSEC RR in the child zone's apex will always indicate + the presence of the child zone's SOA RR whereas the parental NSEC RR + at the zone cut will never indicate the presence of an SOA RR. As + with any other authoritative RRs, NSEC RRs MUST be included in zone + transfers of the zone in which they are authoritative data. The + parental NSEC RR at a zone cut MUST be included in zone transfers of + the parent zone, and the NSEC at the zone apex of the child zone MUST + be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut and + are authoritative in whichever zone contains the authoritative RRset + for which the RRSIG RR provides the signature. That is, the RRSIG RR + for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, and the RRSIG for any RRset in the + child zone's apex will be authoritative in the child zone. Parental + and child RRSIG RRs at a zone cut will never be identical to each + other, as the Signer's Name field of an RRSIG RR in the child zone's + apex will indicate a DNSKEY RR in the child zone's apex whereas the + same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6. The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing, even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation. However, the name + server MUST NOT do so unless the name server obtained the + authoritative zone via secure means (such as a secure zone transfer + mechanism) and MUST NOT do so unless this behavior has been + configured explicitly. + + A security-aware name server that supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2. Recursive Name Servers + + As explained in [RFC4033], a security-aware recursive name server is + an entity that acts in both the security-aware name server and + security-aware resolver roles. This section uses the terms "name + server side" and "resolver side" to refer to the code within a + security-aware recursive name server that implements the + security-aware name server role and the code that implements the + security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching that would apply to any security-aware resolver. + +3.2.1. The DO Bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2. The CD Bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the state of the CD bit to the resolver side along with the rest + + + +Arends, et al. Standards Track [Page 17] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + of an initiating query, so that the resolver side will know whether + it is required to verify the response data it returns to the name + server side. If the CD bit is set, it indicates that the originating + resolver is willing to perform whatever authentication its local + policy requires. Thus, the resolver side of the recursive name + server need not perform authentication on the RRsets in the response. + When the CD bit is set, the recursive name server SHOULD, if + possible, return the requested data to the originating resolver, even + if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query that matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the state of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + that are capable of performing their own signature verification + checks while protecting clients that depend on the resolver side of a + security-aware recursive name server to perform such checks. Several + of the possible reasons why signature validation might fail involve + conditions that may not apply equally to the recursive name server + and the client that invoked it. For example, the recursive name + server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security that the recursive name + server does not share. In such cases, "protecting" a client that is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3. The AD Bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backward compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RRs demonstrably could have been synthesized from an authentic DNAME + RR that is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3. Example DNSSEC Responses + + See Appendix B for example response packets. + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1. EDNS Support + + A security-aware resolver MUST include an EDNS ([RFC2671]) OPT + pseudo-RR with the DO ([RFC3225]) bit set when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR + to advertise the message size that it is willing to accept. A + security-aware resolver's IP layer MUST handle fragmented UDP packets + correctly regardless of whether any such fragmented packets were + received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and + [RFC3226] for discussion of these requirements. + +4.2. Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5 and SHOULD apply them to every + received response, except when: + + o the security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + + o the response is the result of a query generated directly via some + form of application interface that instructed the security-aware + resolver not to perform validation for this query; or + + o validation for this query has been disabled by local policy. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security-aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. For example, a zone update may have + changed (or deleted) the desired information between the original and + follow-up queries. + + When attempting to retrieve missing NSEC RRs that reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name. If no NS RRset is present at that name, the + resolver then strips off the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3. Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether it should + expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed and is subject to + signature validation, as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but for which it is unable to + do so, either due to signatures that for some reason fail to + validate or due to missing data that the relevant DNSSEC RRs + indicate should be present. This case may indicate an attack but + may also indicate a configuration error or some form of data + corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether the RRset should be signed, as the resolver is + not able to obtain the necessary DNSSEC RRs. This can occur when + the security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + +4.4. Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + least one trusted public key or DS RR and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also cover key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out-of-band means. + +4.5. Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double <QNAME,QCLASS>. + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + There are two situations for which this is relevant: + + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security-aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security-aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers that follow this + recommendation will have a more consistent view of the namespace. + +4.6. Handling of the CD and AD Bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers that blindly copy + header bits that they do not understand from the query message to the + response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained by using a secure channel + or the resolver was specifically configured to regard the message + header bits without using a secure channel. + +4.7. Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + + + +Arends, et al. Standards Track [Page 22] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Conceptually, caching such data is similar to negative caching + ([RFC2308]), except that instead of caching a valid negative + response, the resolver is caching the fact that a particular answer + failed to validate. This document refers to a cache of data with + invalid signatures as a "BAD cache". + + Resolvers that implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier, + particularly the following: + + o Since RRsets that fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular <QNAME, QTYPE, QCLASS> have failed to + validate exceeds a threshold value. + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8. Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs that could + have been synthesized from the DNAME RR, as described in [RFC2672], + at least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9. Stub Resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +4.9.1. Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application that + invoked it, but is not required to do so. A non-validating stub + resolver that seeks to do this will need to set the DO bit in order + to receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, + because otherwise it will not receive the DNSSEC RRs it needs to + perform signature validation. + +4.9.2. Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless it is requested by the application + layer, as by definition, a non-validating stub resolver depends on + the security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + because otherwise the security-aware recursive name server will + answer the query using the name server's local policy, which may + prevent the stub resolver from receiving data that would be + acceptable to the stub resolver's local policy. + +4.9.3. Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + that sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server. Therefore, there may be little + practical value in checking the status of the AD bit, except perhaps + as a debugging aid. In any case, a security-aware stub resolver MUST + NOT place any reliance on signature validation allegedly performed on + its behalf, except when the security-aware stub resolver obtained the + data in question from a trusted security-aware recursive name server + via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, as, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Standards Track [Page 24] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5. Authenticating DNS Responses + + To use DNSSEC RRs for authentication, a security-aware resolver + requires configured knowledge of at least one authenticated DNSKEY or + DS RR. The process for obtaining and authenticating this initial + trust anchor is achieved via some external mechanism. For example, a + resolver could use some off-line authenticated exchange to obtain a + zone's DNSKEY RR or to obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset by using an initial key, + the resolver MUST: + + 1. verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA + bit 7) set; and + + 2. verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset by using an + initial DNSKEY RR, delegations from that zone can be authenticated by + using DS RRs. This allows a resolver to start from an initial key + and use DS RRsets to proceed recursively down the DNS tree, obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone once the resolver has authenticated a zone's apex + DNSKEY RRset. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + lacks the appropriate DNSSEC RRs, whether due to configuration issues + such as an upstream security-oblivious recursive name server that + + + +Arends, et al. Standards Track [Page 25] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + accidentally interferes with DNSSEC RRs or due to a deliberate attack + in which an adversary forges a response, strips DNSSEC RRs from a + response, or modifies a query so that DNSSEC RRs appear not to be + requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1. Special Considerations for Islands of Security + + Islands of security (see [RFC4033]) are signed zones for which it is + not possible to construct an authentication chain to the zone from + its parent. Validating signatures within an island of security + requires that the validator have some other means of obtaining an + initial authenticated zone key for the island. If a validator cannot + obtain such a key, it SHOULD switch to operating as if the zones in + the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2. Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset and contains a cryptographic digest of the + child zone's DNSKEY RR. Use of a strong cryptographic digest + algorithm ensures that it is computationally infeasible for an + adversary to generate a DNSKEY RR that matches the digest. Thus, + authenticating the digest allows a resolver to authenticate the + matching DNSKEY RR. The resolver can then use this child DNSKEY RR + to authenticate the entire child apex DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3). + + + + + +Arends, et al. Standards Track [Page 26] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset, and, when the DNSKEY RR's owner name and RDATA are hashed + using the digest algorithm specified in the DS RR's Digest Type + field, the resulting digest value matches the Digest field of the + DS RR. + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator cannot authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished because the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3. Authenticating an RRset with an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Sections 5.3.1, 5.3.2, + and 5.3.3 describe each step in detail. + +5.3.1. Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + + o The RRSIG RR and the RRset MUST have the same owner name and the + same class. + + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset. + + o The RRSIG RR's Type Covered field MUST equal the RRset's type. + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field. + + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field. + + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field. + + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset. + + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set. + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, and it MUST try each + matching DNSKEY RR until either the signature is validated or the + validator has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + + o the apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + + o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2. Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the validator has to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + + + +Arends, et al. Standards Track [Page 29] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + The canonical forms for names and RRsets are defined in [RFC4034]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRsets are present at the parent zone. The second NSEC RRset resides + at the child zone and identifies which RRsets are present at the apex + in the child zone. The parent NSEC RRset and child NSEC RRset can + always be distinguished as only a child NSEC RR will indicate that an + SOA RRset exists at the name. When reconstructing the original NSEC + RRset for the delegation from the parent zone, the NSEC RRs MUST NOT + be combined with NSEC RRs from the child zone. When reconstructing + the original NSEC RRset for the apex of the child zone, the NSEC RRs + MUST NOT be combined with NSEC RRs from the parent zone. + + Note that each of the two NSEC RRsets at a delegation point has a + corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + + + + + + + + +Arends, et al. Standards Track [Page 30] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.3. Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] + provides a list of algorithm types and provides pointers to the + documents that define each algorithm's use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR is correct by trying each matching public + key until the validator either succeeds in validating the signature + or runs out of keys to try. + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also has to test these RRSIG + RRs and how to resolve conflicts if these RRSIG RRs lead to differing + results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + + o the RRset's TTL as received in the response; + + o the RRSIG RR's TTL as received in the response; + + o the value in the RRSIG RR's Original TTL field; and + + o the difference of the RRSIG RR's Signature Expiration time and the + current time. + + + + + +Arends, et al. Standards Track [Page 31] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.4. Authenticating a Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature, as described in + Section 5.3, it must take additional steps to verify the non- + existence of an exact match or closer wildcard match for the query. + Section 5.4 discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4. Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Denial of existence is determined by the following rules: + + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [RFC4034], then no RRsets with the requested name exist + in the zone. However, it is possible that a wildcard could be + used to match the requested RR owner name and type, so proving + that the requested RRset does not exist also requires proving that + no possible wildcard RRset exists that could have been used to + generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove the non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + + + +Arends, et al. Standards Track [Page 32] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify the non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5. Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. Also see Section + 4.7 on caching responses that do not validate. + +5.6. Authentication Example + + Appendix C shows an example of the authentication process. + +6. IANA Considerations + + [RFC4034] contains a review of the IANA considerations introduced by + DNSSEC. The following are additional IANA considerations discussed + in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655], and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [RFC4033] for terminology and general security + considerations related to DNSSEC; see [RFC4034] for considerations + specific to the DNSSEC resource record types. + + + + +Arends, et al. Standards Track [Page 33] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection that DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Sections 3.2.2 and 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, as + recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will have to pay close attention to the + behavior of the applications that use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +9. References + +9.1. Normative References + + [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. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + + +Arends, et al. Standards Track [Page 34] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [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 DNS Security Extensions", RFC + 4034, March 2005. + +9.2. Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 35] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Standards Track [Page 36] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Standards Track [Page 37] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Standards Track [Page 38] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Standards Track [Page 39] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Standards Track [Page 40] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key that should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry, "*.w.example". Note that the + name "*.w.example" is used in constructing NSEC chains, and that the + RRSIG covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + + + +Arends, et al. Standards Track [Page 41] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + + + +Arends, et al. Standards Track [Page 42] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.2. Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + +Arends, et al. Standards Track [Page 43] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.3. No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + +B.4. Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + ;; Header: QR DO RCODE=0 + ;; + + + +Arends, et al. Standards Track [Page 44] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + +B.5. Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + + +Arends, et al. Standards Track [Page 45] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + +B.6. Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + + + +Arends, et al. Standards Track [Page 46] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + +B.7. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + + + +Arends, et al. Standards Track [Page 47] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + +B.8. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + + + +Arends, et al. Standards Track [Page 48] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1. Authenticating an Answer + + The query in Appendix B.1 returned an MX RRset for "x.w.example.com". + The corresponding RRSIG indicates that the MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The resolver + needs the corresponding DNSKEY RR in order to authenticate this + answer. The discussion below describes how a resolver might obtain + this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600, and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates that the answer + was not the result of wildcard expansion. The "x.w.example.com" MX + RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +C.1.1. Authenticating the Example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note that the + logical order is presented for clarity. An implementation may choose + to construct the authentication as referrals are received or to + construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks whether this configured DNSKEY RR is present in the root + DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root + DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY + RRset, and whether the signature lifetime is valid. If all these + + + +Arends, et al. Standards Track [Page 49] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + conditions are met, all keys in the DNSKEY RRset are considered + authenticated. The resolver then uses one (or more) of the root + DNSKEY RRs to authenticate the "example" DS RRset. Note that the + resolver may have to query the root zone to obtain the root DNSKEY + RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +C.2. Name Error + + The query in Appendix B.2 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3. No Data Error + + The query in Appendix B.3 returned an NSEC RR that proves that the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4. Referral to Signed Zone + + The query in Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + + + +Arends, et al. Standards Track [Page 50] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +C.5. Referral to Unsigned Zone + + The query in Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example", and the NSEC RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +C.6. Wildcard Expansion + + The query in Appendix B.6 returned an answer that was produced as a + result of wildcard expansion. The answer section contains a wildcard + RRset expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query, and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7. Wildcard No Data Error + + The query in Appendix B.7 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8. DS Child Zone No Data Error + + The query in Appendix B.8 returned NSEC RRs that shows the requested + was answered by a child server ("example" server). The NSEC RR + indicates the presence of an SOA RR, showing that the answer is from + the child . Queries for the "example" DS RRset should be sent to the + parent servers ("root" servers). + + + + + + +Arends, et al. Standards Track [Page 51] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 52] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 53] + diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt new file mode 100644 index 000000000000..d9252b39eb59 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4074.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group Y. Morishita +Request for Comments: 4074 JPRS +Category: Informational T. Jinmei + Toshiba + May 2005 + + + Common Misbehavior Against DNS Queries for IPv6 Addresses + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + There is some known misbehavior of DNS authoritative servers when + they are queried for AAAA resource records. Such behavior can block + IPv4 communication that should actually be available, cause a + significant delay in name resolution, or even make a denial of + service attack. This memo describes details of known cases and + discusses their effects. + +1. Introduction + + Many existing DNS clients (resolvers) that support IPv6 first search + for AAAA Resource Records (RRs) of a target host name, and then for A + RRs of the same name. This fallback mechanism is based on the DNS + specifications, which if not obeyed by authoritative servers, can + produce unpleasant results. In some cases, for example, a web + browser fails to connect to a web server it could otherwise reach. + In the following sections, this memo describes some typical cases of + such misbehavior and its (bad) effects. + + Note that the misbehavior is not specific to AAAA RRs. In fact, all + known examples also apply to the cases of queries for MX, NS, and SOA + RRs. The authors believe this can be generalized for all types of + queries other than those for A RRs. In this memo, however, we + concentrate on the case for AAAA queries, since the problem is + particularly severe for resolvers that support IPv6, which thus + affects many end users. Resolvers at end users normally send A + and/or AAAA queries only, so the problem for the other cases is + relatively minor. + + + +Morishita & Jinmei Informational [Page 1] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +2. Network Model + + In this memo, we assume a typical network model of name resolution + environment using DNS. It consists of three components: stub + resolvers, caching servers, and authoritative servers. A stub + resolver issues a recursive query to a caching server, which then + handles the entire name resolution procedure recursively. The + caching server caches the result of the query and sends the result to + the stub resolver. The authoritative servers respond to queries for + names for which they have the authority, normally in a non-recursive + manner. + +3. Expected Behavior + + Suppose that an authoritative server has an A RR but has no AAAA RR + for a host name. Then, the server should return a response to a + query for an AAAA RR of the name with the response code (RCODE) being + 0 (indicating no error) and with an empty answer section (see + Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that + there is at least one RR of a different type than AAAA for the + queried name, and the stub resolver can then look for A RRs. + + This way, the caching server can cache the fact that the queried name + has no AAAA RR (but may have other types of RRs), and thus improve + the response time to further queries for an AAAA RR of the name. + +4. Problematic Behaviors + + There are some known cases at authoritative servers that do not + conform to the expected behavior. This section describes those + problematic cases. + +4.1. Ignore Queries for AAAA + + Some authoritative servers seem to ignore queries for an AAAA RR, + causing a delay at the stub resolver to fall back to a query for an A + RR. This behavior may cause a fatal timeout at the resolver or at + the application that calls the resolver. Even if the resolver + eventually falls back, the result can be an unacceptable delay for + the application user, especially with interactive applications like + web browsing. + +4.2. Return "Name Error" + + This type of server returns a response with RCODE 3 ("Name Error") to + a query for an AAAA RR, indicating that it does not have any RRs of + any type for the queried name. + + + + +Morishita & Jinmei Informational [Page 2] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + With this response, the stub resolver may immediately give up and + never fall back. Even if the resolver retries with a query for an A + RR, the negative response for the name has been cached in the caching + server, and the caching server will simply return the negative + response. As a result, the stub resolver considers this to be a + fatal error in name resolution. + + Several examples of this behavior are known to the authors. As of + this writing, all have been fixed. + +4.3. Return Other Erroneous Codes + + Other authoritative servers return a response with erroneous response + codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not + Implemented"), indicating that the servers do not support the + requested type of query. + + These cases are less harmful than the previous one; if the stub + resolver falls back to querying for an A RR, the caching server will + process the query correctly and return an appropriate response. + + However, these can still cause a serious effect. There was an + authoritative server implementation that returned RCODE 2 ("Server + failure") to queries for AAAA RRs. One widely deployed mail server + implementation with a certain type of resolver library interpreted + this result as an indication of retry and did not fall back to + queries for A RRs, causing message delivery failure. + + If the caching server receives a response with these response codes, + it does not cache the fact that the queried name has no AAAA RR, + resulting in redundant queries for AAAA RRs in the future. The + behavior will waste network bandwidth and increase the load of the + authoritative server. + + Using RCODE 1 ("Format error") would cause a similar effect, though + the authors have not seen such implementations yet. + +4.4. Return a Broken Response + + Another type of authoritative servers returns broken responses to + AAAA queries. Returning a response whose RR type is AAAA with the + length of the RDATA being 4 bytes is a known behavior of this + category. The 4-byte data looks like the IPv4 address of the queried + host name. + + + + + + + +Morishita & Jinmei Informational [Page 3] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + That is, the RR in the answer section would be described as follows: + + www.bad.example. 600 IN AAAA 192.0.2.1 + + which is, of course, bogus (or at least meaningless). + + A widely deployed caching server implementation transparently returns + the broken response (and caches it) to the stub resolver. Another + known server implementation parses the response by itself, and sends + a separate response with RCODE 2 ("Server failure"). + + In either case, the broken response does not affect queries for an A + RR of the same name. If the stub resolver falls back to A queries, + it will get an appropriate response. + + The latter case, however, causes the same bad effect as that + described in the previous section: redundant queries for AAAA RRs. + +4.5. Make Lame Delegation + + Some authoritative servers respond to AAAA queries in a way that + causes lame delegation. In this case, the parent zone specifies that + the authoritative server should have the authority of a zone, but the + server should not return an authoritative response for AAAA queries + within the zone (i.e., the AA bit in the response is not set). On + the other hand, the authoritative server returns an authoritative + response for A queries. + + When a caching server asks the server for AAAA RRs in the zone, it + recognizes the delegation is lame, and returns a response with RCODE + 2 ("Server failure") to the stub resolver. + + Furthermore, some caching servers record the authoritative server as + lame for the zone and will not use it for a certain period of time. + With this type of caching server, even if the stub resolver falls + back to querying for an A RR, the caching server will simply return a + response with RCODE 2, since all the servers are known to be "lame." + + There is also an implementation that relaxes the behavior a little + bit. It tries to avoid using the lame server, but continues to try + it as a last resort. With this type of caching server, the stub + resolver will get a correct response if it falls back after Server + failure. However, this still causes redundant AAAA queries, as + explained in the previous sections. + + + + + + + +Morishita & Jinmei Informational [Page 4] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +5. Security Considerations + + The CERT/CC pointed out that the response with RCODE 3 ("Name + Error"), described in Section 4.2, can be used for a denial of + service attack [2]. The same argument applies to the case of "lame + delegation", described in Section 4.5, with a certain type of caching + server. + +6. Acknowledgements + + Erik Nordmark encouraged the authors to publish this document as an + RFC. Akira Kato and Paul Vixie reviewed a preliminary version of + this document. Pekka Savola carefully reviewed a previous version + and provided detailed comments. Bill Fenner, Scott Hollenbeck, + Thomas Narten, and Alex Zinin reviewed and helped improve the + document at the last stage for publication. + +7. Informative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from + AAAA queries could cause denial-of-service conditions", + March 2003, <http://www.kb.cert.org/vuls/id/714121>. + +Authors' Addresses + + MORISHITA Orange Yasuhiro + Research and Development Department, Japan Registry Services Co.,Ltd. + Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda + Chiyoda-ku, Tokyo 101-0065 + Japan + + EMail: yasuhiro@jprs.co.jp + + + JINMEI Tatuya + Corporate Research & Development Center, Toshiba Corporation + 1 Komukai Toshiba-cho, Saiwai-ku + Kawasaki-shi, Kanagawa 212-8582 + Japan + + EMail: jinmei@isl.rdc.toshiba.co.jp + + + + + + + +Morishita & Jinmei Informational [Page 5] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Morishita & Jinmei Informational [Page 6] + diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt new file mode 100644 index 000000000000..1ab4bd1ae340 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4159.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group G. Huston +Request for Comments: 4159 APNIC +BCP: 109 August 2005 +Category: Best Current Practice + + + Deprecation of "ip6.int" + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document advises of the deprecation of the use of "ip6.int" for + Standards Conformant IPv6 implementations. + +1. IPv6 Standards Action + + In August 2001 the IETF published [RFC3152], which advised that the + use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses + to DNS names was deprecated. The document noted that the use of + "ip6.int" would be phased out in an orderly fashion. + + As of 1 September 2005, the IETF advises the community that the DNS + domain "ip6.int" should no longer be used to perform reverse mapping + of IPv6 addresses to domain names, and that the domain "ip6.arpa" + should be used henceforth, in accordance with the IANA Considerations + described in [RFC3596]. The domain "ip6.int" is deprecated, and its + use in IPv6 implementations that conform to the IPv6 Internet + Standards is discontinued. + + The Regional Internet Registries (RIRs) are advised that maintenance + of delegation of entries in "ip6.int" is no longer required as part + of infrastructure services in support of Internet Standards + Conformant IPv6 implementations as of 1 September 2005. The RIRs are + requested to work with their communities to adopt a schedule + regarding the cessation of support of registration services for the + "ip6.int" domain. + + + + + + +Huston Best Current Practice [Page 1] + +RFC 4159 ip6.int August 2005 + + +2. IANA Considerations + + IANA is advised that the "ip6.int" domain for reverse mapping of IPv6 + addresses to domain names is no longer part of Internet Standards + Conformant support of IPv6 as of 1 September 2005. + +3. Security Considerations + + While DNS spoofing of address to name mapping has been exploited in + IPv4, removal of the "ip6.int" zone from the standard IPv6 + specification creates no new threats to the security of the internet. + +4. Acknowledgements + + The document was prepared with the assistance of Kurt Lindqvist, + Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian + Haberman, and Bill Manning. + +5. Normative References + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October + 2003. + +Author's Address + + Geoff Huston + APNIC + + EMail: gih@apnic.net + + + + + + + + + + + + + + + + + + +Huston Best Current Practice [Page 2] + +RFC 4159 ip6.int August 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Huston Best Current Practice [Page 3] + diff --git a/contrib/bind9/lib/bind/include/resolv_mt.h b/contrib/bind9/lib/bind/include/resolv_mt.h new file mode 100644 index 000000000000..27963a12077a --- /dev/null +++ b/contrib/bind9/lib/bind/include/resolv_mt.h @@ -0,0 +1,47 @@ +#ifndef _RESOLV_MT_H +#define _RESOLV_MT_H + +#include <sys/types.h> +#include <netinet/in.h> +#include <arpa/nameser.h> +#include <resolv.h> + +/* Access functions for the libresolv private interface */ + +int __res_enable_mt(void); +int __res_disable_mt(void); + +/* Per-thread context */ + +typedef struct { +int no_hosts_fallback_private; +int retry_save; +int retry_private; +char inet_nsap_ntoa_tmpbuf[255*3]; +char sym_ntos_unname[20]; +char sym_ntop_unname[20]; +char p_option_nbuf[40]; +char p_time_nbuf[40]; +char precsize_ntoa_retbuf[sizeof "90000000.00"]; +char loc_ntoa_tmpbuf[sizeof +"1000 60 60.000 N 1000 60 60.000 W -12345678.00m 90000000.00m 90000000.00m 90000000.00m"]; +char p_secstodate_output[15]; +} mtctxres_t; + +/* Thread-specific data (TSD) */ + +mtctxres_t *___mtctxres(void); +#define mtctxres (___mtctxres()) + +/* Various static data that should be TSD */ + +#define sym_ntos_unname (mtctxres->sym_ntos_unname) +#define sym_ntop_unname (mtctxres->sym_ntop_unname) +#define inet_nsap_ntoa_tmpbuf (mtctxres->inet_nsap_ntoa_tmpbuf) +#define p_option_nbuf (mtctxres->p_option_nbuf) +#define p_time_nbuf (mtctxres->p_time_nbuf) +#define precsize_ntoa_retbuf (mtctxres->precsize_ntoa_retbuf) +#define loc_ntoa_tmpbuf (mtctxres->loc_ntoa_tmpbuf) +#define p_secstodate_output (mtctxres->p_secstodate_output) + +#endif /* _RESOLV_MT_H */ diff --git a/contrib/bind9/lib/bind/resolv/mtctxres.c b/contrib/bind9/lib/bind/resolv/mtctxres.c new file mode 100644 index 000000000000..f33cf11e3f42 --- /dev/null +++ b/contrib/bind9/lib/bind/resolv/mtctxres.c @@ -0,0 +1,128 @@ +#include <port_before.h> +#ifdef DO_PTHREADS +#include <pthread.h> +#endif +#include <errno.h> +#include <netdb.h> +#include <stdlib.h> +#include <string.h> +#include <resolv_mt.h> +#include <irs.h> +#include <port_after.h> + +#ifdef DO_PTHREADS +static pthread_key_t key; +static int mt_key_initialized = 0; + +static int __res_init_ctx(void); +static void __res_destroy_ctx(void *); + +#if defined(sun) && !defined(__GNUC__) +#pragma init (_mtctxres_init) +#endif +#endif + +static mtctxres_t sharedctx; + +#ifdef DO_PTHREADS +/* + * Initialize the TSD key. By doing this at library load time, we're + * implicitly running without interference from other threads, so there's + * no need for locking. + */ +static void +_mtctxres_init(void) { + int pthread_keycreate_ret; + + pthread_keycreate_ret = pthread_key_create(&key, __res_destroy_ctx); + if (pthread_keycreate_ret == 0) + mt_key_initialized = 1; +} +#endif + +/* + * To support binaries that used the private MT-safe interface in + * Solaris 8, we still need to provide the __res_enable_mt() + * and __res_disable_mt() entry points. They're do-nothing routines. + */ +int +__res_enable_mt(void) { + return (-1); +} + +int +__res_disable_mt(void) { + return (0); +} + +#ifdef DO_PTHREADS +static int +__res_init_ctx(void) { + + mtctxres_t *mt; + int ret; + + + if (pthread_getspecific(key) != 0) { + /* Already exists */ + return (0); + } + + if ((mt = malloc(sizeof (mtctxres_t))) == 0) { + errno = ENOMEM; + return (-1); + } + + memset(mt, 0, sizeof (mtctxres_t)); + + if ((ret = pthread_setspecific(key, mt)) != 0) { + free(mt); + errno = ret; + return (-1); + } + + return (0); +} + +static void +__res_destroy_ctx(void *value) { + + mtctxres_t *mt = (mtctxres_t *)value; + + if (mt != 0) + free(mt); +} +#endif + +mtctxres_t * +___mtctxres(void) { +#ifdef DO_PTHREADS + mtctxres_t *mt; + + /* + * This if clause should only be executed if we are linking + * statically. When linked dynamically _mtctxres_init() should + * be called at binding time due the #pragma above. + */ + if (!mt_key_initialized) { + static pthread_mutex_t keylock = PTHREAD_MUTEX_INITIALIZER; + pthread_mutex_lock(&keylock); + _mtctxres_init(); + pthread_mutex_unlock(&keylock); + } + + /* + * If we have already been called in this thread return the existing + * context. Otherwise recreat a new context and return it. If + * that fails return a global context. + */ + if (mt_key_initialized) { + if (((mt = pthread_getspecific(key)) != 0) || + (__res_init_ctx() == 0 && + (mt = pthread_getspecific(key)) != 0)) { + return (mt); + } + } +#endif + return (&sharedctx); +} diff --git a/contrib/bind9/lib/lwres/include/lwres/stdlib.h b/contrib/bind9/lib/lwres/include/lwres/stdlib.h new file mode 100644 index 000000000000..f5d4db281872 --- /dev/null +++ b/contrib/bind9/lib/lwres/include/lwres/stdlib.h @@ -0,0 +1,40 @@ +/* + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: stdlib.h,v 1.2.4.1 2005/06/08 02:08:32 marka Exp $ */ + +#ifndef LWRES_STDLIB_H +#define LWRES_STDLIB_H 1 + +/*! \file */ + +#include <stdlib.h> + +#include <lwres/lang.h> +#include <lwres/platform.h> + +#ifdef LWRES_PLATFORM_NEEDSTRTOUL +#define strtoul lwres_strtoul +#endif + +LWRES_LANG_BEGINDECLS + +unsigned long lwres_strtoul(const char *, char **, int); + +LWRES_LANG_ENDDECLS + +#endif diff --git a/contrib/bind9/lib/lwres/strtoul.c b/contrib/bind9/lib/lwres/strtoul.c new file mode 100644 index 000000000000..9cda1947724a --- /dev/null +++ b/contrib/bind9/lib/lwres/strtoul.c @@ -0,0 +1,135 @@ +/* + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2003 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +/* + * Copyright (c) 1990, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/*! \file */ +#if defined(LIBC_SCCS) && !defined(lint) +static char sccsid[] = "@(#)strtoul.c 8.1 (Berkeley) 6/4/93"; +#endif /* LIBC_SCCS and not lint */ + +/* $Id: strtoul.c,v 1.2.4.1 2005/06/08 02:08:31 marka Exp $ */ + +#include <config.h> + +#include <limits.h> +#include <ctype.h> +#include <errno.h> + +#include <lwres/stdlib.h> + +#define DE_CONST(konst, var) \ + do { \ + union { const void *k; void *v; } _u; \ + _u.k = konst; \ + var = _u.v; \ + } while (0) + +/*! + * Convert a string to an unsigned long integer. + * + * Ignores `locale' stuff. Assumes that the upper and lower case + * alphabets and digits are each contiguous. + */ +unsigned long +lwres_strtoul(const char *nptr, char **endptr, int base) { + const char *s = nptr; + unsigned long acc; + unsigned char c; + unsigned long cutoff; + int neg = 0, any, cutlim; + + /* + * See strtol for comments as to the logic used. + */ + do { + c = *s++; + } while (isspace(c)); + if (c == '-') { + neg = 1; + c = *s++; + } else if (c == '+') + c = *s++; + if ((base == 0 || base == 16) && + c == '0' && (*s == 'x' || *s == 'X')) { + c = s[1]; + s += 2; + base = 16; + } + if (base == 0) + base = c == '0' ? 8 : 10; + cutoff = (unsigned long)ULONG_MAX / (unsigned long)base; + cutlim = (unsigned long)ULONG_MAX % (unsigned long)base; + for (acc = 0, any = 0;; c = *s++) { + if (!isascii(c)) + break; + if (isdigit(c)) + c -= '0'; + else if (isalpha(c)) + c -= isupper(c) ? 'A' - 10 : 'a' - 10; + else + break; + if (c >= base) + break; + if (any < 0 || acc > cutoff || (acc == cutoff && c > cutlim)) + any = -1; + else { + any = 1; + acc *= base; + acc += c; + } + } + if (any < 0) { + acc = ULONG_MAX; + errno = ERANGE; + } else if (neg) + acc = -acc; + if (endptr != 0) + DE_CONST(any ? s - 1 : nptr, *endptr); + return (acc); +} |