diff --git a/contrib/bind9/CHANGES b/contrib/bind9/CHANGES index 1673ae0c476..941b946db36 100644 --- a/contrib/bind9/CHANGES +++ b/contrib/bind9/CHANGES @@ -1,4 +1,261 @@ + --- 9.3.2 released --- + + --- 9.3.2rc1 released --- + +1936. [bug] The validator could leak memory. [RT #15544] + +1932. [bug] hpux: LDFLAGS was getting corrupted. [RT #15530] + + --- 9.3.2b2 released --- + +1930. [port] HPUX: ia64 support. [RT #15473] + +1929. [port] FreeBSD: extend use of PTHREAD_SCOPE_SYSTEM. + +1926. [bug] The Windows installer did not check for empty + passwords. BINDinstall was being installed in + the wrong place. [RT #15483] + +1925. [port] All outer level AC_TRY_RUNs need cross compiling + defaults. [RT #15469] + +1924. [port] libbind: hpux ia64 support. [RT #15473] + +1923. [bug] ns_client_detach() called too early. [RT #15499] + + --- 9.3.2b1 released --- + +1917. [doc] funcsynopsisinfo wasn't being treated as verbatim + when generating man pages. [RT #15385] + +1915. [bug] dig +ndots was broken. [RT #15215] + +1914. [protocol] DS is required to accept mnemonic algorithms + (RFC 4034). Still emit numeric algorithms for + compatability with RFC 3658. [RT #15354] + +1911. [bug] Update windows socket code. [RT #14965] + +1910. [bug] dig's +sigchase code overhauled. [RT #14933] + +1909. [bug] The DLV code has been re-worked to make no longer + query order sensitive. [RT #14933] + +1905. [bug] Strings returned from cfg_obj_asstring() should be + treated as read-only. [RT #15256] + +1901. [cleanup] Don't add DNSKEY records to the additional section. + +1900. [bug] ixfr-from-differences failed to ensure that the + serial number increased. [RT #15036] + +1896. [bug] Extend ISC_SOCKADDR_FORMATSIZE and + ISC_NETADDR_FORMATSIZE to allow for scope details. + +1894. [bug] Recursive clients soft quota support wasn't working + as expected. [RT #15103] + +1893. [bug] A escaped character is, potentially, converted to + the output character set too early. [RT #14666] + +1892. [port] Use uintptr_t if available. [RT #14606] + +1889. [port] sunos: non blocking i/o support. [RT #14951] + +1887. [bug] The cache could delete expired records too fast for + clients with a virtual time in the past. [RT #14991] + +1886. [bug] fctx_create() could return success even though it + failed. [RT #14993] + +1884. [cleanup] dighost.c: move external declarations into . + +1883. [bug] dnssec-signzone, dnssec-keygen: handle negative debug + levels. [RT #14962] + +1881. [func] Add a system test for named-checkconf. [RT #14931] + +1877. [bug] Fix unreasonably low quantum on call to + dns_rbt_destroy2(). Remove unnecessay unhash_node() + call. [RT #14919] + +1875. [bug] process_dhtkey() was using the wrong memory context + to free some memory. [RT #14890] + +1874. [port] sunos: portability fixes. [RT #14814] + +1873. [port] win32: isc__errno2result() now reports its caller. + [RT #13753] + +1872. [port] win32: Handle ERROR_NETNAME_DELETED. [RT #13753] + +1867. [bug] It was possible to trigger a INSIST in + dlv_validatezonekey(). [RT #14846] + +1866. [bug] resolv.conf parse errors were being ignored by + dig/host/nslookup. [RT #14841] + +1865. [bug] Silently ignore nameservers in /etc/resolv.conf with + bad addresses. [RT #14841] + +1864. [bug] Don't try the alternative transfer source if you + got a answer / transfer with the main source + address. [RT #14802] + +1863. [bug] rrset-order "fixed" error messages not complete. + +1861. [bug] dig could trigger a INSIST on certain malformed + responses. [RT #14801] + +1860. [port] solaris 2.8: hack_shutup_pthreadmutexinit was + incorrectly set. [RT #14775] + +1858. [bug] The flush-zones-on-shutdown option wasn't being + parsed. [RT #14686] + +1857. [bug] named could trigger a INSIST() if reconfigured / + reloaded too fast. [RT #14673] + +1856. [doc] Switch Docbook toolchain from DSSSL to XSL. + [RT #11398] + +1855. [bug] ixfr-from-differences was failing to detect changes + of ttl due to dns_diff_subtract() was ignoring the ttl + of records. [RT #14616] + +1854. [bug] lwres also needs to know the print format for + (long long). [RT #13754] + +1853. [bug] Rework how DLV interacts with proveunsecure(). + [RT #13605] + +1852. [cleanup] Remove last vestiges of dnssec-signkey and + dnssec-makekeyset (removed from Makefile years ago). + +1850. [bug] Memory leak in lwres_getipnodebyaddr(). [RT #14591] + +1849. [doc] All forms of the man pages (docbook, man, html) should + have consistant copyright dates. + +1848. [bug] Improve SMF integration. [RT #13238] + +1847. [bug] isc_ondestroy_init() is called too late in + dns_rbtdb_create()/dns_rbtdb64_create(). + [RT #13661] + +1846. [contrib] query-loc-0.3.0 from Stephane Bortzmeyer + . + +1845. [bug] Improve error reporting to distingish between + accept()/fcntl() and socket()/fcntl() errors. + [RT #13745] + +1844. [bug] inet_pton() accepted more that 4 hexadecimal digits + for each 16 bit piece of the IPv6 address. The text + representation of a IPv6 address has been tighted + to disallow this (draft-ietf-ipv6-addr-arch-v4-02.txt). + [RT #5662] + +1843. [cleanup] CINCLUDES takes precedence over CFLAGS. This helps + when CFLAGS contains "-I /usr/local/include" + resulting in old header files being used. + +1842. [port] cmsg_len() could produce incorrect results on + some platform. [RT #13744] + +1841. [bug] "dig +nssearch" now makes a recursive query to + find the list of nameservers to query. [RT #13694] + +1839. [bug] was not being installed. + +1838. [cleanup] Don't allow Linux capabilities to be inherited. + [RT #13707] + +1837. [bug] Compile time option ISC_FACILITY was not effective + for 'named -u '. [RT #13714] + +1836. [cleanup] Silence compiler warnings in hash_test.c. + +1835. [bug] Update dnssec-signzone's usage message. [RT #13657] + +1834. [bug] Bad memset in rdata_test.c. [RT #13658] + +1833. [bug] Race condition in isc_mutex_lock_profile(). [RT #13660] + +1832. [bug] named fails to return BADKEY on unknown TSIG algorithm. + [RT #13620] + +1831. [doc] Update named-checkzone documentation. [RT#13604] + +1830. [bug] adb lame cache has sence of test reversed. [RT #13600] + +1829. [bug] win32: "pid-file none;" broken. [RT #13563] + +1828. [bug] isc_rwlock_init() failed to properly cleanup if it + encountered a error. [RT #13549] + +1827. [bug] host: update usage message for '-a'. [RT #37116] + +1826. [bug] Missing DESTROYLOCK() in isc_mem_createx() on out + of memory error. [RT #13537] + +1825. [bug] Missing UNLOCK() on out of memory error from in + rbtdb.c:subtractrdataset(). [RT #13519] + +1824. [bug] Memory leak on dns_zone_setdbtype() failure. + [RT #13510] + +1823. [bug] Wrong macro used to check for point to point interface. + [RT#13418] + +1822. [bug] check-names test for RT was reversed. [RT #13382] + +1821. [doc] acls definitions are no longer required to be + in named.conf prior to reference. They can be + defined after being referenced. + +1820. [bug] Gracefully handle acl loops. [RT #13659] + +1819. [bug] The validator needed to check both the algorithm and + digest types of the DS to determine if it could be + used to introduce a secure zone. [RT #13593] + +1816. [port] UnixWare: failed to compile lib/isc/unix/net.c. + [RT #13597] + +1815. [bug] nsupdate triggered a REQUIRE if the server was set + without also setting the zone and it encountered + a CNAME and was using TSIG. [RT #13086] + +1810. [bug] configure, lib/bind/configure make different default + decisions about whether to do a threaded build. + [RT #13212] + +1809. [bug] "make distclean" failed for libbind if the platform + is not supported. + +1807. [bug] When forwarding (forward only) set the active domain + from the forward zone name. [RT #13526] + +1804. [bug] Ensure that if we are queried for glue that it fits + in the additional section or TC is set to tell the + client to retry using TCP. [RT #10114] + +1803. [bug] dnssec-signzone sometimes failed to remove old + RRSIGs. [RT #13483] + +1802. [bug] Handle connection resets better. [RT #11280] + +1799. [bug] 'rndc flushname' failed to flush negative cache + entries. [RT #13438] + +1795. [bug] "rndc dumpdb" was not fully documented. Minor + formating issues with "rndc dumpdb -all". [RT #13396] + +1791. [bug] 'host -t a' still printed out AAAA and MX records. + [RT #13230] + --- 9.3.1 released --- 1818. [bug] 'named-checkconf -z' triggered an INSIST. [RT #13599] diff --git a/contrib/bind9/FAQ b/contrib/bind9/FAQ index f6ed41e422c..9b806cbde53 100644 --- a/contrib/bind9/FAQ +++ b/contrib/bind9/FAQ @@ -1,470 +1,525 @@ - - - Frequently Asked Questions about BIND 9 +------------------------------------------------------------------------------- Q: Why doesn't -u work on Linux 2.2.x when I build with --enable-threads? A: 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. + 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. - 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. + 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. - 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. + 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. - If Linux threads ever work correctly, this restriction will go away. + If Linux threads ever work correctly, this restriction will go away. - Configuring BIND9 with the --disable-threads option (the default) causes a -non-threaded version to be built, which will allow -u to be used. + Configuring BIND9 with the --disable-threads option (the default) causes a + non-threaded version to be built, which will allow -u to be used. +Q: Why does named log the warning message "no TTL specified - using SOA MINTTL + instead"? -Q: Why does named log the warning message "no TTL specified - using SOA -MINTTL instead"? - -A: Your zone file is illegal according to RFC1035. It must either -have a line like +A: Your zone file is illegal according to RFC1035. It must either have a line + like: $TTL 86400 -at the beginning, or the first record in it must have a TTL field, -like the "84600" in this example: + at the beginning, or the first record in it must have a TTL field, like the + "84600" in this example: example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 ) Q: Why do I see 5 (or more) copies of named on Linux? -A: 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. +A: 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. +Q: Why does BIND 9 log "permission denied" errors accessing its configuration + files or zones on my Linux system even though it is running as root? -Q: Why does BIND 9 log "permission denied" errors accessing its -configuration files or zones on my Linux system even though it is running -as root? - -A: 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. - +A: 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. Q: Why do I get errors like "dns_zone_load: zone foo/IN: loading master file -bar: ran out of space" - -A: 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. + bar: ran out of space"? +A: 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. Q: How do I produce a usable core file from a multithreaded named on Linux? -A: 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. - +A: 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. Q: How do I restrict people from looking up the server version? -A: 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. +A: 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. +Q: How do I restrict only remote users from looking up the server version? -Q: How do I restrict only remote users from looking up the server -version? - -A: 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. - - view "chaos" chaos { - match-clients { ; }; - allow-query { none; }; - zone "." { - type hint; - file "/dev/null"; // or any empty file - }; - }; +A: 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. + view "chaos" chaos { + match-clients { ; }; + allow-query { none; }; + zone "." { + type hint; + file "/dev/null"; // or any empty file + }; + }; Q: What do "no source of entropy found" or "could not open entropy source foo" -mean? + mean? A: 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. + 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. +Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why? -Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why? +A: BIND 9 is installed under /usr/local by default. BIND 8 is often installed + under /usr. Check that the correct named is running. -A: BIND 9 is installed under /usr/local by default. BIND 8 is often -installed under /usr. Check that the correct named is running. +Q: 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? +A: This may be a clock skew problem. Check that the the clocks on the client + and server are properly synchronised (e.g., using ntp). -Q: 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? +Q: I'm trying to compile BIND 9, and "make" is failing due to files not being + found. Why? -A: This may be a clock skew problem. Check that the the clocks on -the client and server are properly synchronized (e.g., using ntp). +A: 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. +Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is logging + error messages like "notify to 10.0.0.1#53 failed: unexpected end of input". + What's wrong? -Q: I'm trying to compile BIND 9, and "make" is failing due to files not -being found. Why? +A: 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. -A: 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. +Q: I keep getting log messages like the following. Why? + 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) -Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is -logging error messages like "notify to 10.0.0.1#53 failed: unexpected -end of input". What's wrong? +A: 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. -A: 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. - - -Q: I keep getting log messages like the following. Why? - - 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) - -A: 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. - - -Q: I keep getting log messages like the following. Why? +Q: I keep getting log messages like the following. Why? Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied -A: 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 -for information about how to turn them off. +A: 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 http:// + support.microsoft.com/support/kb/articles/q246/8/04.asp for information + about how to turn them off. - -Q: I see a log message like the following. Why? +Q: I see a log message like the following. Why? couldn't open pid file '/var/run/named.pid': Permission denied -A: 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). +A: 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). +Q: When I do a "dig . ns", many of the A records for the root servers are + missing. Why? -Q: When I do a "dig . ns", many of the A records for the root -servers are missing. Why? +A: 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. -A: 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. + 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. -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. + 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". -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". - - -Q: Zone transfers from my BIND 9 master to my Windows 2000 slave -fail. Why? - -A: 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. +Q: Zone transfers from my BIND 9 master to my Windows 2000 slave fail. Why? +A: 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. Q: Why don't my zones reload when I do an "rndc reload" or SIGHUP? -A: 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. +A: 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. +Q: I can query the nameserver from the nameserver but not from other machines. + Why? -Q: I can query the nameserver from the nameserver but not from other -machines. Why? +A: This is usually the result of the firewall configuration stopping the + queries and / or the replies. -A: This is usually the result of the firewall configuration stopping -the queries and / or the replies. +Q: 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. +A: 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. -Q: 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. + 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; -A: 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. + 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; - e.g. - 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; + You put the external address on the alias so that all the other dns clients + on these boxes see the internal view by default. - 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; +A: BIND 9.3 and later: Use TSIG to select the appropriate view. - You put the external address on the alias so that all the other - dns clients on these boxes see the internal view by default. + 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; + ... + }; -A: (BIND 9.3 and later) Use TSIG to select the appropriate view. + 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; + ... + }; - 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; - ... - }; +Q: I have FreeBSD 4.x and "rndc-confgen -a" just sits there. - 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; - ... - }; +A: /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. + /etc/rc.conf + rand_irqs="3 14 15" -Q: I have Freebsd 4.x and "rndc-confgen -a" just sits there. - -A: /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. - -e.g. - /etc/rc.conf - rand_irqs="3 14 15" - -See also http://people.freebsd.org/~dougb/randomness.html - + See also http://people.freebsd.org/~dougb/randomness.html Q: Why is named listening on UDP port other than 53? -A: 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. +A: 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. +Q: I get error messages like "multiple RRs of singleton type" and "CNAME and + other data" when transferring a zone. What does this mean? -Q: I get error messages like "multiple RRs of singleton type" and -"CNAME and other data" when transferring a zone. What does this mean? +A: 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. -A: 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. + dig axfr example.com @master-server > tmp + named-checkzone example.com tmp - e.g. - dig axfr example.com @master-server > tmp - named-checkzone example.com tmp + A CNAME record cannot exist with the same name as another record except for + the DNSSEC records which prove its existance (NSEC). + RFC 1034, Section 3.6.2: "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." -Q: I get error messages like "named.conf:99: unexpected end of input" where -99 is the last line of named.conf. +Q: I get error messages like "named.conf:99: unexpected end of input" where 99 + is the last line of named.conf. -A: Some text editors (notepad and wordpad) fail to put a line termination -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. +A: 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. - -Q: I get warning messages like "zone example.com/IN: refresh: failure trying master -1.2.3.4#53: timed out". +Q: I get warning messages like "zone example.com/IN: refresh: failure trying + master 1.2.3.4#53: timed out". A: Check that you can make UDP queries from the slave to the master - dig +norec example.com soa @1.2.3.4 + dig +norec example.com soa @1.2.3.4 -A: You could be generating queries faster than the slave can cope with. Lower -the serial query rate. + You could be generating queries faster than the slave can cope with. Lower + the serial query rate. - serial-query-rate 5; // default 20 + serial-query-rate 5; // default 20 Q: How do I share a dynamic zone between multiple views? -A: You choose one view to be master and the second a slave and transfer -the zone between views. +A: You choose one view to be master and the second a slave and transfer the + zone between views. - Master 10.0.1.1: - key "external" { - algorithm hmac-md5; - secret "xxxxxxxx"; - }; + Master 10.0.1.1: + key "external" { + algorithm hmac-md5; + secret "xxxxxxxx"; + }; - key "mykey" { - algorithm hmac-md5; - secret "yyyyyyyy"; - }; + 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 "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 { ... }; - }; - }; + 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 { ... }; + }; + }; Q: I get a error message like "zone wireless.ietf56.ietf.org/IN: loading master -file primaries/wireless.ietf56.ietf.org: no owner". - -A: 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. + file primaries/wireless.ietf56.ietf.org: no owner". +A: 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. Q: Why are my logs in GMT (UTC). A: You are running chrooted (-t) and have not supplied local timzone -information in the chroot area. + information in the chroot area. - FreeBSD: /etc/localtime - Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo - OSF: /etc/zoneinfo/localtime + FreeBSD: /etc/localtime + Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo + OSF: /etc/zoneinfo/localtime - See also tzset(3) and zic(8). + See also tzset(3) and zic(8). +Q: I get the error message "named: capset failed: Operation not permitted" when + starting named. -Q: I get the error message "named: capset failed: Operation not permitted" -when starting named. +A: The capability module, part of "Linux Security Modules/LSM", has not been + loaded into the kernel. See insmod(8). -A: The capset module has not been loaded into the kernel. See insmod(8). - - -Q: I get "rndc: connect failed: connection refused" when I try to run - rndc. +Q: I get "rndc: connect failed: connection refused" when I try to run rndc. A: This is usually a configuration error. - First ensure that named is running and no errors are being - reported at startup (/var/log/messages or equivalent). Running - "named -g " from a terminal can help at this - point. + First ensure that named is running and no errors are being reported at + startup (/var/log/messages or equivalent). Running "named -g " from a title can help at this point. - Secondly ensure that named is configured to use rndc either by - "rndc-confgen -a", rndc-confgen or manually. The Administators - Reference manual has details on how to do this. + 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. - 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). - - 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 arguements. + 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). + 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. Q: I don't get RRSIG's returned when I use "dig +dnssec". A: You need to ensure DNSSEC is enabled (dnssec-enable yes;). - Q: I get "Error 1067" when starting named under Windows. -A: This is the service manager saying that named exited. You need to - examine the Application log in the EventViewer to find out why. +A: This is the service manager saying that named exited. You need to examine + the Application log in the EventViewer to find out why. - 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. + 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. - options { - Directory "C:\windows\dns\etc"; - }; + options { + Directory "C:\windows\dns\etc"; + }; +Q: I get "transfer of 'example.net/IN' from 192.168.4.12#53: failed while + receiving responses: permission denied" error messages. + +A: These indicate a filesystem permission error preventing named creating / + renaming the temporary file. These will usually also have other associated + error messages like + + "dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied" + + 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. + + Note file names are relative to the directory specified in options and any + chroot directory ([/][]). + + 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. + + options { + directory "/var/named"; + }; + + zone "example.net" { + type slave; + file "sl/example.net"; + masters { 192.168.4.12; }; + }; + +Q: How do I intergrate BIND 9 and Solaris SMF + +A: Sun has a blog entry describing how to do this. + + http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris + +Q: Can a NS record refer to a CNAME. + +A: No. The rules for glue (copies of the *address* records in the parent zones) + and additional section processing do not allow it to work. + + 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. + +Q: What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean? + +A: 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 http://as112.net/ for details of the problems you are + causing and the counter measures that have had to be deployed. + + 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. + + 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 . . ( + 1 3600 1200 604800 10800 ) + @ 10800 IN NS . + + Note + + Future versions of named are likely to do this automatically. diff --git a/contrib/bind9/FAQ.xml b/contrib/bind9/FAQ.xml new file mode 100644 index 00000000000..963cd0a8c40 --- /dev/null +++ b/contrib/bind9/FAQ.xml @@ -0,0 +1,1007 @@ + + + + + +
+ Frequently Asked Questions about BIND 9 + + + + + Why doesn't -u work on Linux 2.2.x when I build with + --enable-threads? + + + + + 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. + + + 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. + + + 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. + + + If Linux threads ever work correctly, this restriction will + go away. + + + Configuring BIND9 with the --disable-threads option (the + default) causes a non-threaded version to be built, which + will allow -u to be used. + + + + + + + + Why does named log the warning message no TTL specified - + using SOA MINTTL instead? + + + + + Your zone file is illegal according to RFC1035. It must either + have a line like: + + + +$TTL 86400 + + + at the beginning, or the first record in it must have a TTL field, + like the "84600" in this example: + + + +example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 ) + + + + + + + + Why do I see 5 (or more) copies of named on Linux? + + + + + 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. + + + + + + + + Why does BIND 9 log permission denied errors accessing + its configuration files or zones on my Linux system even + though it is running as root? + + + + + 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. + + + + + + + + Why do I get errors like dns_zone_load: zone foo/IN: loading + master file bar: ran out of space? + + + + + 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. + + + + + + + + How do I produce a usable core file from a multithreaded + named on Linux? + + + + + 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. + + + + + + + + How do I restrict people from looking up the server version? + + + + + 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. + + + + + + + + How do I restrict only remote users from looking up the + server version? + + + + + 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. + + + +view "chaos" chaos { + match-clients { <those to be refused>; }; + allow-query { none; }; + zone "." { + type hint; + file "/dev/null"; // or any empty file + }; +}; + + + + + + + + What do no source of entropy found or could not + open entropy source foo mean? + + + + + 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. + + + + + + + + I installed BIND 9 and restarted named, but it's still BIND 8. Why? + + + + + BIND 9 is installed under /usr/local by default. BIND 8 + is often installed under /usr. Check that the correct named + is running. + + + + + + + + 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? + + + + + This may be a clock skew problem. Check that the the clocks + on the client and server are properly synchronised (e.g., + using ntp). + + + + + + + + I'm trying to compile BIND 9, and "make" is failing due to + files not being found. Why? + + + + + 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. + + + + + + + + I have a BIND 9 master and a BIND 8.2.3 slave, and the + master is logging error messages like notify to 10.0.0.1#53 + failed: unexpected end of input. What's wrong? + + + + + 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. + + + + + + + + I keep getting log messages like the following. Why? + + + 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) + + + + + 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. + + + + + + + + I keep getting log messages like the following. Why? + + + Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied + + + + + 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 + + http://support.microsoft.com/support/kb/articles/q246/8/04.asp + + for information about how to turn them off. + + + + + + + + I see a log message like the following. Why? + + + couldn't open pid file '/var/run/named.pid': Permission denied + + + + + 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). + + + + + + + + When I do a "dig . ns", many of the A records for the root + servers are missing. Why? + + + + + 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. + + + 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. + + + 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". + + + + + + + + Zone transfers from my BIND 9 master to my Windows 2000 + slave fail. Why? + + + + + 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. + + + + + + + + Why don't my zones reload when I do an "rndc reload" or SIGHUP? + + + + + 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. + + + + + + + + I can query the nameserver from the nameserver but not from other + machines. Why? + + + + + This is usually the result of the firewall configuration stopping + the queries and / or the replies. + + + + + + + + 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. + + + + + 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. + + + +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; + + + You put the external address on the alias so that all the other + dns clients on these boxes see the internal view by default. + + + + + BIND 9.3 and later: Use TSIG to select the appropriate view. + + + +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; + ... + }; + + + + + + + + I have FreeBSD 4.x and "rndc-confgen -a" just sits there. + + + + + /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. + + + +/etc/rc.conf +rand_irqs="3 14 15" + + + See also + + http://people.freebsd.org/~dougb/randomness.html + + + + + + + + + Why is named listening on UDP port other than 53? + + + + + 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. + + + + + + + + I get error messages like multiple RRs of singleton type + and CNAME and other data when transferring a zone. What + does this mean? + + + + + 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. + + + +dig axfr example.com @master-server > tmp +named-checkzone example.com tmp + + + A CNAME record cannot exist with the same name as another record + except for the DNSSEC records which prove its existance (NSEC). + + + RFC 1034, Section 3.6.2: 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. + + + + + + + + I get error messages like named.conf:99: unexpected end + of input where 99 is the last line of named.conf. + + + + + 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. + + + + + + + + I get warning messages like zone example.com/IN: refresh: + failure trying master 1.2.3.4#53: timed out. + + + + + Check that you can make UDP queries from the slave to the master + + + +dig +norec example.com soa @1.2.3.4 + + + You could be generating queries faster than the slave can + cope with. Lower the serial query rate. + + + +serial-query-rate 5; // default 20 + + + + + + + + How do I share a dynamic zone between multiple views? + + + + + You choose one view to be master and the second a slave and + transfer the zone between views. + + + +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 { ... }; + }; + }; + + + + + + + + I get a error message like zone wireless.ietf56.ietf.org/IN: + loading master file primaries/wireless.ietf56.ietf.org: no + owner. + + + + + 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. + + + + + + + + Why are my logs in GMT (UTC). + + + + + You are running chrooted (-t) and have not supplied local timzone + information in the chroot area. + + + FreeBSD: /etc/localtime + Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo + OSF: /etc/zoneinfo/localtime + + + See also tzset(3) and zic(8). + + + + + + + + I get the error message named: capset failed: Operation + not permitted when starting named. + + + + + The capability module, part of "Linux Security Modules/LSM", + has not been loaded into the kernel. See insmod(8). + + + + + + + + I get rndc: connect failed: connection refused when + I try to run rndc. + + + + + This is usually a configuration error. + + + 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. + + + 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. + + + 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). + + + 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. + + + + + + + + I don't get RRSIG's returned when I use "dig +dnssec". + + + + + You need to ensure DNSSEC is enabled (dnssec-enable yes;). + + + + + + + + I get Error 1067 when starting named under Windows. + + + + + This is the service manager saying that named exited. You + need to examine the Application log in the EventViewer to + find out why. + + + 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. + + + +options { + Directory "C:\windows\dns\etc"; +}; + + + + + + + + I get transfer of 'example.net/IN' from 192.168.4.12#53: + failed while receiving responses: permission denied error + messages. + + + + + These indicate a filesystem permission error preventing + named creating / renaming the temporary file. These will + usually also have other associated error messages like + + + +"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied" + + + 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. + + + Note file names are relative to the directory specified in + options and any chroot directory ([<chroot + dir>/][<options dir>]). + + + + 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. + + +options { + directory "/var/named"; +}; + +zone "example.net" { + type slave; + file "sl/example.net"; + masters { 192.168.4.12; }; +}; + + + + + + + + How do I intergrate BIND 9 and Solaris SMF + + + + + Sun has a blog entry describing how to do this. + + + + http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris + + + + + + + + + Can a NS record refer to a CNAME. + + + + + No. The rules for glue (copies of the *address* records + in the parent zones) and additional section processing do + not allow it to work. + + + 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. + + + + + + + + What does RFC 1918 response from Internet for + 0.0.0.10.IN-ADDR.ARPA mean? + + + + + 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 http://as112.net/ + for details of the problems you are causing and the counter + measures that have had to be deployed. + + + 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. + + + +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>. + + + Future versions of named are likely to do this automatically. + + + + + +
diff --git a/contrib/bind9/README b/contrib/bind9/README index 8e3d01df5bb..574b07d7324 100644 --- a/contrib/bind9/README +++ b/contrib/bind9/README @@ -43,6 +43,26 @@ BIND 9 Nominum, Inc. +BIND 9.3.2 + + BIND 9.3.2 is a maintenance release, containing fixes for + a number of bugs in 9.3.1. + + libbind: corresponds to that from BIND 8.4.7-REL. + + Known Issues: + + The following INSIST can be triggered with DNSSEC enabled. + +resolver.c:762: INSIST(result != 0 || dns_rdataset_isassociated(event->rdataset) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_any) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_rrsig)) failed + + We are still trying to isolate the cause. If you have core + dump please send a bug report to bind9-bugs@isc.org with + the location of the core, named executable and OS details. + + Note: contrib/nanny contains a perl script to restart named + in the event of a INSIST/REQUIRE/ENSURE failure. + BIND 9.3.1 BIND 9.3.1 is a maintenance release, containing fixes for @@ -210,7 +230,7 @@ Building UnixWare 7.1.1 HP-UX 10.20 BSD/OS 4.2 - Mac OS X 10.1 + Mac OS X 10.1, 10.3.8 To build, just @@ -300,9 +320,11 @@ Building Building with gcc is not supported, unless gcc is the vendor's usual compiler (e.g. the various BSD systems, Linux). + Known compiler issues: * gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86. * gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02. * gcc-3.3.5 powerpc generates incorrect code at -02. + * Irix, MipsPRO 7.4.1m is known to cause problems. A limited test suite can be run with "make test". Many of the tests require you to configure a set of virtual IP addresses diff --git a/contrib/bind9/bin/check/named-checkconf.8 b/contrib/bind9/bin/check/named-checkconf.8 index 25dbdd86ff1..68b745aed29 100644 --- a/contrib/bind9/bin/check/named-checkconf.8 +++ b/contrib/bind9/bin/check/named-checkconf.8 @@ -1,59 +1,70 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2002 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 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, +.\" 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: named-checkconf.8,v 1.11.12.4 2004/06/03 05:35:41 marka Exp $ +.\" $Id: named-checkconf.8,v 1.11.12.7 2005/10/13 02:33:41 marka Exp $ .\" -.TH "NAMED-CHECKCONF" "8" "June 14, 2000" "BIND9" "" -.SH NAME -named-checkconf \- named configuration file syntax checking tool -.SH SYNOPSIS -.sp -\fBnamed-checkconf\fR [ \fB-v\fR ] [ \fB-j\fR ] [ \fB-t \fIdirectory\fB\fR ] \fBfilename\fR [ \fB-z\fR ] +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "NAMED\-CHECKCONF" "8" "June 14, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +named\-checkconf \- named configuration file syntax checking tool +.SH "SYNOPSIS" +.HP 16 +\fBnamed\-checkconf\fR [\fB\-v\fR] [\fB\-j\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] {filename} [\fB\-z\fR] .SH "DESCRIPTION" .PP -\fBnamed-checkconf\fR checks the syntax, but not -the semantics, of a named configuration file. +\fBnamed\-checkconf\fR +checks the syntax, but not the semantics, of a named configuration file. .SH "OPTIONS" .TP -\fB-t \fIdirectory\fB\fR -chroot to \fIdirectory\fR so that include -directives in the configuration file are processed as if -run by a similarly chrooted named. +\-t \fIdirectory\fR +chroot to +\fIdirectory\fR +so that include directives in the configuration file are processed as if run by a similarly chrooted named. .TP -\fB-v\fR -Print the version of the \fBnamed-checkconf\fR +\-v +Print the version of the +\fBnamed\-checkconf\fR program and exit. .TP -\fB-z\fR +\-z Perform a check load the master zonefiles found in \fInamed.conf\fR. .TP -\fB-j\fR +\-j When loading a zonefile read the journal if it exists. .TP -\fBfilename\fR -The name of the configuration file to be checked. If not -specified, it defaults to \fI/etc/named.conf\fR. +filename +The name of the configuration file to be checked. If not specified, it defaults to +\fI/etc/named.conf\fR. .SH "RETURN VALUES" .PP -\fBnamed-checkconf\fR returns an exit status of 1 if -errors were detected and 0 otherwise. +\fBnamed\-checkconf\fR +returns an exit status of 1 if errors were detected and 0 otherwise. .SH "SEE ALSO" .PP \fBnamed\fR(8), -\fIBIND 9 Administrator Reference Manual\fR. +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/check/named-checkconf.docbook b/contrib/bind9/bin/check/named-checkconf.docbook index d1336cfa537..c2529f642fe 100644 --- a/contrib/bind9/bin/check/named-checkconf.docbook +++ b/contrib/bind9/bin/check/named-checkconf.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + Internet Software Consortium. + + + named-checkconf named configuration file syntax checking tool @@ -116,6 +132,7 @@ named-checkconf returns an exit status of 1 if errors were detected and 0 otherwise. + diff --git a/contrib/bind9/bin/check/named-checkconf.html b/contrib/bind9/bin/check/named-checkconf.html index 8d5f38e99c5..14b8ff89cb1 100644 --- a/contrib/bind9/bin/check/named-checkconf.html +++ b/contrib/bind9/bin/check/named-checkconf.html @@ -1,216 +1,92 @@ - - - - -named-checkconf

named-checkconf

Name

named-checkconf -- named configuration file syntax checking tool

Synopsis

named-checkconf [-v] [-j] [-t directory] {filename} [-z]

DESCRIPTION

named-checkconf checks the syntax, but not + + + + +named-checkconf + + +

+
+
+

Name

+

named-checkconf — named configuration file syntax checking tool

+
+
+

Synopsis

+

named-checkconf [-v] [-j] [-t directory] {filename} [-z]

+
+
+

DESCRIPTION

+

+ named-checkconf checks the syntax, but not the semantics, of a named configuration file. -

OPTIONS

-t directory

chroot to directory so that include +

+
+
+

OPTIONS

+
+
-t directory
+

+ chroot to directory so that include directives in the configuration file are processed as if run by a similarly chrooted named. -

-v

Print the version of the named-checkconf +

+
-v
+

+ Print the version of the named-checkconf program and exit. -

-z

Perform a check load the master zonefiles found in - named.conf. -

-j

When loading a zonefile read the journal if it exists. -

filename

The name of the configuration file to be checked. If not - specified, it defaults to /etc/named.conf. -

RETURN VALUES

named-checkconf returns an exit status of 1 if +

+
-z
+

+ Perform a check load the master zonefiles found in + named.conf. +

+
-j
+

+ When loading a zonefile read the journal if it exists. +

+
filename
+

+ The name of the configuration file to be checked. If not + specified, it defaults to /etc/named.conf. +

+
+
+
+

RETURN VALUES

+

+ named-checkconf returns an exit status of 1 if errors were detected and 0 otherwise. -

SEE ALSO

named(8), - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+

+
+
+

SEE ALSO

+

+ named(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/bin/check/named-checkzone.8 b/contrib/bind9/bin/check/named-checkzone.8 index efa600c8e08..33402d5fe8d 100644 --- a/contrib/bind9/bin/check/named-checkzone.8 +++ b/contrib/bind9/bin/check/named-checkzone.8 @@ -1,94 +1,111 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2002 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 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, +.\" 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: named-checkzone.8,v 1.11.2.1.8.4 2004/06/03 05:35:42 marka Exp $ +.\" $Id: named-checkzone.8,v 1.11.2.1.8.8 2005/10/13 02:33:41 marka Exp $ .\" -.TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" "" -.SH NAME -named-checkzone \- zone file validity checking tool -.SH SYNOPSIS -.sp -\fBnamed-checkzone\fR [ \fB-d\fR ] [ \fB-j\fR ] [ \fB-q\fR ] [ \fB-v\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-k \fImode\fB\fR ] [ \fB-n \fImode\fB\fR ] [ \fB-o \fIfilename\fB\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-w \fIdirectory\fB\fR ] [ \fB-D\fR ] \fBzonename\fR \fBfilename\fR +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "NAMED\-CHECKZONE" "8" "June 13, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +named\-checkzone \- zone file validity checking tool +.SH "SYNOPSIS" +.HP 16 +\fBnamed\-checkzone\fR [\fB\-d\fR] [\fB\-j\fR] [\fB\-q\fR] [\fB\-v\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] {zonename} {filename} .SH "DESCRIPTION" .PP -\fBnamed-checkzone\fR checks the syntax and integrity of -a zone file. It performs the same checks as \fBnamed\fR +\fBnamed\-checkzone\fR +checks the syntax and integrity of a zone file. It performs the same checks as +\fBnamed\fR does when loading a zone. This makes -\fBnamed-checkzone\fR useful for checking zone -files before configuring them into a name server. +\fBnamed\-checkzone\fR +useful for checking zone files before configuring them into a name server. .SH "OPTIONS" .TP -\fB-d\fR +\-d Enable debugging. .TP -\fB-q\fR -Quiet mode - exit code only. +\-q +Quiet mode \- exit code only. .TP -\fB-v\fR -Print the version of the \fBnamed-checkzone\fR +\-v +Print the version of the +\fBnamed\-checkzone\fR program and exit. .TP -\fB-j\fR +\-j When loading the zone file read the journal if it exists. .TP -\fB-c \fIclass\fB\fR +\-c \fIclass\fR Specify the class of the zone. If not specified "IN" is assumed. .TP -\fB-k \fImode\fB\fR -Perform \fB"check-name"\fR checks with the specified failure mode. -Possible modes are \fB"fail"\fR, -\fB"warn"\fR (default) and +\-k \fImode\fR +Perform +\fB"check\-name"\fR +checks with the specified failure mode. Possible modes are +\fB"fail"\fR, +\fB"warn"\fR +(default) and \fB"ignore"\fR. .TP -\fB-n \fImode\fB\fR -Specify whether NS records should be checked to see if they -are addresses. Possible modes are \fB"fail"\fR, -\fB"warn"\fR (default) and +\-n \fImode\fR +Specify whether NS records should be checked to see if they are addresses. Possible modes are +\fB"fail"\fR, +\fB"warn"\fR +(default) and \fB"ignore"\fR. .TP -\fB-o \fIfilename\fB\fR -Write zone output to \fIdirectory\fR. +\-o \fIfilename\fR +Write zone output to +\fIfilename\fR. .TP -\fB-t \fIdirectory\fB\fR -chroot to \fIdirectory\fR so that include -directives in the configuration file are processed as if -run by a similarly chrooted named. +\-t \fIdirectory\fR +chroot to +\fIdirectory\fR +so that include directives in the configuration file are processed as if run by a similarly chrooted named. .TP -\fB-w \fIdirectory\fB\fR -chdir to \fIdirectory\fR so that relative -filenames in master file $INCLUDE directives work. This -is similar to the directory clause in +\-w \fIdirectory\fR +chdir to +\fIdirectory\fR +so that relative filenames in master file $INCLUDE directives work. This is similar to the directory clause in \fInamed.conf\fR. .TP -\fB-D\fR +\-D Dump zone file in canonical format. .TP -\fBzonename\fR +zonename The domain name of the zone being checked. .TP -\fBfilename\fR +filename The name of the zone file. .SH "RETURN VALUES" .PP -\fBnamed-checkzone\fR returns an exit status of 1 if -errors were detected and 0 otherwise. +\fBnamed\-checkzone\fR +returns an exit status of 1 if errors were detected and 0 otherwise. .SH "SEE ALSO" .PP \fBnamed\fR(8), -\fIRFC 1035\fR, -\fIBIND 9 Administrator Reference Manual\fR. +RFC 1035, +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/check/named-checkzone.docbook b/contrib/bind9/bin/check/named-checkzone.docbook index 68b0baeeba4..ce0d78bdbdf 100644 --- a/contrib/bind9/bin/check/named-checkzone.docbook +++ b/contrib/bind9/bin/check/named-checkzone.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + Internet Software Consortium. + + + named-checkzone zone file validity checking tool @@ -103,6 +119,7 @@ When loading the zone file read the journal if it exists. + -c class @@ -141,7 +158,7 @@ -o filename - Write zone output to directory. + Write zone output to filename. @@ -205,6 +222,7 @@ named-checkzone returns an exit status of 1 if errors were detected and 0 otherwise. + diff --git a/contrib/bind9/bin/check/named-checkzone.html b/contrib/bind9/bin/check/named-checkzone.html index dd14c1f8fd7..cf544c94728 100644 --- a/contrib/bind9/bin/check/named-checkzone.html +++ b/contrib/bind9/bin/check/named-checkzone.html @@ -1,367 +1,135 @@ - - - - -named-checkzone

named-checkzone

Name

named-checkzone -- zone file validity checking tool

Synopsis

named-checkzone [-d] [-j] [-q] [-v] [-c class] [-k mode] [-n mode] [-o filename] [-t directory] [-w directory] [-D] {zonename} {filename}

DESCRIPTION

named-checkzone checks the syntax and integrity of - a zone file. It performs the same checks as named + + + + +named-checkzone + + +

+
+
+

Name

+

named-checkzone — zone file validity checking tool

+
+
+

Synopsis

+

named-checkzone [-d] [-j] [-q] [-v] [-c class] [-k mode] [-n mode] [-o filename] [-t directory] [-w directory] [-D] {zonename} {filename}

+
+
+

DESCRIPTION

+

+ named-checkzone checks the syntax and integrity of + a zone file. It performs the same checks as named does when loading a zone. This makes - named-checkzone useful for checking zone + named-checkzone useful for checking zone files before configuring them into a name server. -

OPTIONS

-d

Enable debugging. -

-q

Quiet mode - exit code only. -

-v

Print the version of the named-checkzone +

+
+
+

OPTIONS

+
+
-d
+

+ Enable debugging. +

+
-q
+

+ Quiet mode - exit code only. +

+
-v
+

+ Print the version of the named-checkzone program and exit. -

-j

When loading the zone file read the journal if it exists. -

-c class

Specify the class of the zone. If not specified "IN" is assumed. -

-k mode

Perform "check-name" checks with the specified failure mode. - Possible modes are "fail", - "warn" (default) and - "ignore". -

-n mode

Specify whether NS records should be checked to see if they - are addresses. Possible modes are "fail", - "warn" (default) and - "ignore". -

-o filename

Write zone output to directory. -

-t directory

chroot to directory so that include +

+
-j
+

+ When loading the zone file read the journal if it exists. +

+
-c class
+

+ Specify the class of the zone. If not specified "IN" is assumed. +

+
-k mode
+

+ Perform "check-name" checks with the specified failure mode. + Possible modes are "fail", + "warn" (default) and + "ignore". +

+
-n mode
+

+ Specify whether NS records should be checked to see if they + are addresses. Possible modes are "fail", + "warn" (default) and + "ignore". +

+
-o filename
+

+ Write zone output to filename. +

+
-t directory
+

+ chroot to directory so that include directives in the configuration file are processed as if run by a similarly chrooted named. -

-w directory

chdir to directory so that relative +

+
-w directory
+

+ chdir to directory so that relative filenames in master file $INCLUDE directives work. This is similar to the directory clause in - named.conf. -

-D

Dump zone file in canonical format. -

zonename

The domain name of the zone being checked. -

filename

The name of the zone file. -

RETURN VALUES

named-checkzone returns an exit status of 1 if + named.conf. +

+
-D
+

+ Dump zone file in canonical format. +

+
zonename
+

+ The domain name of the zone being checked. +

+
filename
+

+ The name of the zone file. +

+
+
+
+

RETURN VALUES

+

+ named-checkzone returns an exit status of 1 if errors were detected and 0 otherwise. -

SEE ALSO

named(8), - RFC 1035, - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+

+
+
+

SEE ALSO

+

+ named(8), + RFC 1035, + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/bin/dig/dig.1 b/contrib/bind9/bin/dig/dig.1 index f14d9216873..7031217dd2b 100644 --- a/contrib/bind9/bin/dig/dig.1 +++ b/contrib/bind9/bin/dig/dig.1 @@ -1,216 +1,244 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2003 Internet Software Consortium. -.\" +.\" 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, +.\" 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: dig.1,v 1.14.2.4.2.6 2004/06/23 09:11:01 marka Exp $ +.\" $Id: dig.1,v 1.14.2.4.2.10 2005/10/13 02:33:42 marka Exp $ .\" -.TH "DIG" "1" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "DIG" "1" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" dig \- DNS lookup utility -.SH SYNOPSIS -.sp -\fBdig\fR [ \fB@server\fR ] [ \fB-b \fIaddress\fB\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-f \fIfilename\fB\fR ] [ \fB-k \fIfilename\fB\fR ] [ \fB-p \fIport#\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-x \fIaddr\fB\fR ] [ \fB-y \fIname:key\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] [ \fBname\fR ] [ \fBtype\fR ] [ \fBclass\fR ] [ \fBqueryopt\fR\fI...\fR ] -.sp -\fBdig\fR [ \fB-h\fR ] -.sp -\fBdig\fR [ \fBglobal-queryopt\fR\fI...\fR ] [ \fBquery\fR\fI...\fR ] +.SH "SYNOPSIS" +.HP 4 +\fBdig\fR [@server] [\fB\-b\ \fR\fB\fIaddress\fR\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-f\ \fR\fB\fIfilename\fR\fR] [\fB\-k\ \fR\fB\fIfilename\fR\fR] [\fB\-p\ \fR\fB\fIport#\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-x\ \fR\fB\fIaddr\fR\fR] [\fB\-y\ \fR\fB\fIname:key\fR\fR] [\fB\-4\fR] [\fB\-6\fR] [name] [type] [class] [queryopt...] +.HP 4 +\fBdig\fR [\fB\-h\fR] +.HP 4 +\fBdig\fR [global\-queryopt...] [query...] .SH "DESCRIPTION" .PP -\fBdig\fR (domain information groper) is a flexible tool -for interrogating DNS name servers. It performs DNS lookups and -displays the answers that are returned from the name server(s) that -were queried. Most DNS administrators use \fBdig\fR to -troubleshoot DNS problems because of its flexibility, ease of use and -clarity of output. Other lookup tools tend to have less functionality -than \fBdig\fR. +\fBdig\fR +(domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use +\fBdig\fR +to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than +\fBdig\fR. .PP -Although \fBdig\fR is normally used with command-line -arguments, it also has a batch mode of operation for reading lookup -requests from a file. A brief summary of its command-line arguments -and options is printed when the \fB-h\fR option is given. -Unlike earlier versions, the BIND9 implementation of -\fBdig\fR allows multiple lookups to be issued from the -command line. +Although +\fBdig\fR +is normally used with command\-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command\-line arguments and options is printed when the +\fB\-h\fR +option is given. Unlike earlier versions, the BIND9 implementation of +\fBdig\fR +allows multiple lookups to be issued from the command line. .PP Unless it is told to query a specific name server, -\fBdig\fR will try each of the servers listed in +\fBdig\fR +will try each of the servers listed in \fI/etc/resolv.conf\fR. .PP -When no command line arguments or options are given, will perform an -NS query for "." (the root). +When no command line arguments or options are given, will perform an NS query for "." (the root). .PP -It is possible to set per-user defaults for \fBdig\fR via -\fI${HOME}/.digrc\fR. This file is read and any options in it -are applied before the command line arguments. +It is possible to set per\-user defaults for +\fBdig\fR +via +\fI${HOME}/.digrc\fR. This file is read and any options in it are applied before the command line arguments. .SH "SIMPLE USAGE" .PP -A typical invocation of \fBdig\fR looks like: +A typical invocation of +\fBdig\fR +looks like: .sp .nf dig @server name type -.sp .fi +.sp where: .TP \fBserver\fR -is the name or IP address of the name server to query. This can be an IPv4 -address in dotted-decimal notation or an IPv6 -address in colon-delimited notation. When the supplied -\fIserver\fR argument is a hostname, -\fBdig\fR resolves that name before querying that name -server. If no \fIserver\fR argument is provided, -\fBdig\fR consults \fI/etc/resolv.conf\fR -and queries the name servers listed there. The reply from the name -server that responds is displayed. +is the name or IP address of the name server to query. This can be an IPv4 address in dotted\-decimal notation or an IPv6 address in colon\-delimited notation. When the supplied +\fIserver\fR +argument is a hostname, +\fBdig\fR +resolves that name before querying that name server. If no +\fIserver\fR +argument is provided, +\fBdig\fR +consults +\fI/etc/resolv.conf\fR +and queries the name servers listed there. The reply from the name server that responds is displayed. .TP \fBname\fR is the name of the resource record that is to be looked up. .TP \fBtype\fR -indicates what type of query is required \(em -ANY, A, MX, SIG, etc. -\fItype\fR can be any valid query type. If no -\fItype\fR argument is supplied, -\fBdig\fR will perform a lookup for an A record. +indicates what type of query is required \(em ANY, A, MX, SIG, etc. +\fItype\fR +can be any valid query type. If no +\fItype\fR +argument is supplied, +\fBdig\fR +will perform a lookup for an A record. .SH "OPTIONS" .PP -The \fB-b\fR option sets the source IP address of the query -to \fIaddress\fR. This must be a valid address on -one of the host's network interfaces or "0.0.0.0" or "::". An optional port -may be specified by appending "#" +The +\fB\-b\fR +option sets the source IP address of the query to +\fIaddress\fR. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port may be specified by appending "#" .PP The default query class (IN for internet) is overridden by the -\fB-c\fR option. \fIclass\fR is any valid -class, such as HS for Hesiod records or CH for CHAOSNET records. +\fB\-c\fR +option. +\fIclass\fR +is any valid class, such as HS for Hesiod records or CH for CHAOSNET records. .PP -The \fB-f\fR option makes \fBdig \fR operate -in batch mode by reading a list of lookup requests to process from the -file \fIfilename\fR. The file contains a number of -queries, one per line. Each entry in the file should be organised in -the same way they would be presented as queries to -\fBdig\fR using the command-line interface. +The +\fB\-f\fR +option makes +\fBdig \fR +operate in batch mode by reading a list of lookup requests to process from the file +\fIfilename\fR. The file contains a number of queries, one per line. Each entry in the file should be organised in the same way they would be presented as queries to +\fBdig\fR +using the command\-line interface. .PP -If a non-standard port number is to be queried, the -\fB-p\fR option is used. \fIport#\fR is -the port number that \fBdig\fR will send its queries -instead of the standard DNS port number 53. This option would be used -to test a name server that has been configured to listen for queries -on a non-standard port number. +If a non\-standard port number is to be queried, the +\fB\-p\fR +option is used. +\fIport#\fR +is the port number that +\fBdig\fR +will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries on a non\-standard port number. .PP -The \fB-4\fR option forces \fBdig\fR to only -use IPv4 query transport. The \fB-6\fR option forces -\fBdig\fR to only use IPv6 query transport. +The +\fB\-4\fR +option forces +\fBdig\fR +to only use IPv4 query transport. The +\fB\-6\fR +option forces +\fBdig\fR +to only use IPv6 query transport. .PP -The \fB-t\fR option sets the query type to -\fItype\fR. It can be any valid query type which is -supported in BIND9. The default query type "A", unless the -\fB-x\fR option is supplied to indicate a reverse lookup. -A zone transfer can be requested by specifying a type of AXFR. When -an incremental zone transfer (IXFR) is required, -\fItype\fR is set to ixfr=N. -The incremental zone transfer will contain the changes made to the zone -since the serial number in the zone's SOA record was +The +\fB\-t\fR +option sets the query type to +\fItype\fR. It can be any valid query type which is supported in BIND9. The default query type "A", unless the +\fB\-x\fR +option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required, +\fItype\fR +is set to +ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was \fIN\fR. .PP -Reverse lookups - mapping addresses to names - are simplified by the -\fB-x\fR option. \fIaddr\fR is an IPv4 -address in dotted-decimal notation, or a colon-delimited IPv6 address. -When this option is used, there is no need to provide the -\fIname\fR, \fIclass\fR and -\fItype\fR arguments. \fBdig\fR +Reverse lookups \- mapping addresses to names \- are simplified by the +\fB\-x\fR +option. +\fIaddr\fR +is an IPv4 address in dotted\-decimal notation, or a colon\-delimited IPv6 address. When this option is used, there is no need to provide the +\fIname\fR, +\fIclass\fR +and +\fItype\fR +arguments. +\fBdig\fR automatically performs a lookup for a name like -11.12.13.10.in-addr.arpa and sets the query type and -class to PTR and IN respectively. By default, IPv6 addresses are -looked up using nibble format under the IP6.ARPA domain. -To use the older RFC1886 method using the IP6.INT domain -specify the \fB-i\fR option. Bit string labels (RFC2874) -are now experimental and are not attempted. +11.12.13.10.in\-addr.arpa +and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain specify the +\fB\-i\fR +option. Bit string labels (RFC2874) are now experimental and are not attempted. .PP -To sign the DNS queries sent by \fBdig\fR and their -responses using transaction signatures (TSIG), specify a TSIG key file -using the \fB-k\fR option. You can also specify the TSIG -key itself on the command line using the \fB-y\fR option; -\fIname\fR is the name of the TSIG key and -\fIkey\fR is the actual key. The key is a base-64 -encoded string, typically generated by \fBdnssec-keygen\fR(8). -Caution should be taken when using the \fB-y\fR option on -multi-user systems as the key can be visible in the output from -\fBps\fR(1) or in the shell's history file. When -using TSIG authentication with \fBdig\fR, the name -server that is queried needs to know the key and algorithm that is -being used. In BIND, this is done by providing appropriate -\fBkey\fR and \fBserver\fR statements in +To sign the DNS queries sent by +\fBdig\fR +and their responses using transaction signatures (TSIG), specify a TSIG key file using the +\fB\-k\fR +option. You can also specify the TSIG key itself on the command line using the +\fB\-y\fR +option; +\fIname\fR +is the name of the TSIG key and +\fIkey\fR +is the actual key. The key is a base\-64 encoded string, typically generated by +\fBdnssec\-keygen\fR(8). Caution should be taken when using the +\fB\-y\fR +option on multi\-user systems as the key can be visible in the output from +\fBps\fR(1 ) +or in the shell's history file. When using TSIG authentication with +\fBdig\fR, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate +\fBkey\fR +and +\fBserver\fR +statements in \fInamed.conf\fR. .SH "QUERY OPTIONS" .PP -\fBdig\fR provides a number of query options which affect -the way in which lookups are made and the results displayed. Some of -these set or reset flag bits in the query header, some determine which -sections of the answer get printed, and others determine the timeout -and retry strategies. +\fBdig\fR +provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies. .PP -Each query option is identified by a keyword preceded by a plus sign -(+). Some keywords set or reset an option. These may be preceded -by the string no to negate the meaning of that keyword. Other -keywords assign values to options like the timeout interval. They -have the form \fB+keyword=value\fR. -The query options are: +Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string +no +to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form +\fB+keyword=value\fR. The query options are: .TP \fB+[no]tcp\fR -Use [do not use] TCP when querying name servers. The default -behaviour is to use UDP unless an AXFR or IXFR query is requested, in -which case a TCP connection is used. +Use [do not use] TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used. .TP \fB+[no]vc\fR -Use [do not use] TCP when querying name servers. This alternate -syntax to \fI+[no]tcp\fR is provided for backwards -compatibility. The "vc" stands for "virtual circuit". +Use [do not use] TCP when querying name servers. This alternate syntax to +\fI+[no]tcp\fR +is provided for backwards compatibility. The "vc" stands for "virtual circuit". .TP \fB+[no]ignore\fR -Ignore truncation in UDP responses instead of retrying with TCP. By -default, TCP retries are performed. +Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed. .TP \fB+domain=somename\fR Set the search list to contain the single domain \fIsomename\fR, as if specified in a -\fBdomain\fR directive in -\fI/etc/resolv.conf\fR, and enable search list -processing as if the \fI+search\fR option were given. +\fBdomain\fR +directive in +\fI/etc/resolv.conf\fR, and enable search list processing as if the +\fI+search\fR +option were given. .TP \fB+[no]search\fR -Use [do not use] the search list defined by the searchlist or domain -directive in \fIresolv.conf\fR (if any). -The search list is not used by default. +Use [do not use] the search list defined by the searchlist or domain directive in +\fIresolv.conf\fR +(if any). The search list is not used by default. .TP \fB+[no]defname\fR -Deprecated, treated as a synonym for \fI+[no]search\fR +Deprecated, treated as a synonym for +\fI+[no]search\fR .TP \fB+[no]aaonly\fR Sets the "aa" flag in the query. .TP \fB+[no]aaflag\fR -A synonym for \fI+[no]aaonly\fR. +A synonym for +\fI+[no]aaonly\fR. .TP \fB+[no]adflag\fR -Set [do not set] the AD (authentic data) bit in the query. The AD bit -currently has a standard meaning only in responses, not in queries, -but the ability to set the bit in the query is provided for -completeness. +Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness. .TP \fB+[no]cdflag\fR -Set [do not set] the CD (checking disabled) bit in the query. This -requests the server to not perform DNSSEC validation of responses. +Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses. .TP \fB+[no]cl\fR Display [do not display] the CLASS when printing the record. @@ -219,170 +247,164 @@ Display [do not display] the CLASS when printing the record. Display [do not display] the TTL when printing the record. .TP \fB+[no]recurse\fR -Toggle the setting of the RD (recursion desired) bit in the query. -This bit is set by default, which means \fBdig\fR -normally sends recursive queries. Recursion is automatically disabled -when the \fI+nssearch\fR or -\fI+trace\fR query options are used. +Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means +\fBdig\fR +normally sends recursive queries. Recursion is automatically disabled when the +\fI+nssearch\fR +or +\fI+trace\fR +query options are used. .TP \fB+[no]nssearch\fR -When this option is set, \fBdig\fR attempts to find the -authoritative name servers for the zone containing the name being -looked up and display the SOA record that each name server has for the -zone. +When this option is set, +\fBdig\fR +attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone. .TP \fB+[no]trace\fR -Toggle tracing of the delegation path from the root name servers for -the name being looked up. Tracing is disabled by default. When -tracing is enabled, \fBdig\fR makes iterative queries to -resolve the name being looked up. It will follow referrals from the -root servers, showing the answer from each server that was used to -resolve the lookup. +Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, +\fBdig\fR +makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup. .TP \fB+[no]cmd\fR -toggles the printing of the initial comment in the output identifying -the version of \fBdig\fR and the query options that have -been applied. This comment is printed by default. +toggles the printing of the initial comment in the output identifying the version of +\fBdig\fR +and the query options that have been applied. This comment is printed by default. .TP \fB+[no]short\fR -Provide a terse answer. The default is to print the answer in a -verbose form. +Provide a terse answer. The default is to print the answer in a verbose form. .TP \fB+[no]identify\fR -Show [or do not show] the IP address and port number that supplied the -answer when the \fI+short\fR option is enabled. If -short form answers are requested, the default is not to show the -source address and port number of the server that provided the answer. +Show [or do not show] the IP address and port number that supplied the answer when the +\fI+short\fR +option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer. .TP \fB+[no]comments\fR -Toggle the display of comment lines in the output. The default is to -print comments. +Toggle the display of comment lines in the output. The default is to print comments. .TP \fB+[no]stats\fR -This query option toggles the printing of statistics: when the query -was made, the size of the reply and so on. The default behaviour is -to print the query statistics. +This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is to print the query statistics. .TP \fB+[no]qr\fR -Print [do not print] the query as it is sent. -By default, the query is not printed. +Print [do not print] the query as it is sent. By default, the query is not printed. .TP \fB+[no]question\fR -Print [do not print] the question section of a query when an answer is -returned. The default is to print the question section as a comment. +Print [do not print] the question section of a query when an answer is returned. The default is to print the question section as a comment. .TP \fB+[no]answer\fR -Display [do not display] the answer section of a reply. The default -is to display it. +Display [do not display] the answer section of a reply. The default is to display it. .TP \fB+[no]authority\fR -Display [do not display] the authority section of a reply. The -default is to display it. +Display [do not display] the authority section of a reply. The default is to display it. .TP \fB+[no]additional\fR -Display [do not display] the additional section of a reply. -The default is to display it. +Display [do not display] the additional section of a reply. The default is to display it. .TP \fB+[no]all\fR Set or clear all display flags. .TP \fB+time=T\fR Sets the timeout for a query to -\fIT\fR seconds. The default time out is 5 seconds. -An attempt to set \fIT\fR to less than 1 will result -in a query timeout of 1 second being applied. +\fIT\fR +seconds. The default time out is 5 seconds. An attempt to set +\fIT\fR +to less than 1 will result in a query timeout of 1 second being applied. .TP \fB+tries=T\fR Sets the number of times to try UDP queries to server to -\fIT\fR instead of the default, 3. If -\fIT\fR is less than or equal to zero, the number of -tries is silently rounded up to 1. +\fIT\fR +instead of the default, 3. If +\fIT\fR +is less than or equal to zero, the number of tries is silently rounded up to 1. .TP \fB+retry=T\fR Sets the number of times to retry UDP queries to server to -\fIT\fR instead of the default, 2. Unlike -\fI+tries\fR, this does not include the initial -query. +\fIT\fR +instead of the default, 2. Unlike +\fI+tries\fR, this does not include the initial query. .TP \fB+ndots=D\fR Set the number of dots that have to appear in -\fIname\fR to \fID\fR for it to be -considered absolute. The default value is that defined using the -ndots statement in \fI/etc/resolv.conf\fR, or 1 if no -ndots statement is present. Names with fewer dots are interpreted as -relative names and will be searched for in the domains listed in the -\fBsearch\fR or \fBdomain\fR directive in +\fIname\fR +to +\fID\fR +for it to be considered absolute. The default value is that defined using the ndots statement in +\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the +\fBsearch\fR +or +\fBdomain\fR +directive in \fI/etc/resolv.conf\fR. .TP \fB+bufsize=B\fR Set the UDP message buffer size advertised using EDNS0 to -\fIB\fR bytes. The maximum and minimum sizes of this -buffer are 65535 and 0 respectively. Values outside this range are -rounded up or down appropriately. +\fIB\fR +bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately. .TP \fB+[no]multiline\fR -Print records like the SOA records in a verbose multi-line -format with human-readable comments. The default is to print -each record on a single line, to facilitate machine parsing -of the \fBdig\fR output. +Print records like the SOA records in a verbose multi\-line format with human\-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the +\fBdig\fR +output. .TP \fB+[no]fail\fR -Do not try the next server if you receive a SERVFAIL. The default is -to not try the next server which is the reverse of normal stub resolver -behaviour. +Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behaviour. .TP \fB+[no]besteffort\fR -Attempt to display the contents of messages which are malformed. -The default is to not display malformed answers. +Attempt to display the contents of messages which are malformed. The default is to not display malformed answers. .TP \fB+[no]dnssec\fR -Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) -in the OPT record in the additional section of the query. +Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query. .TP \fB+[no]sigchase\fR -Chase DNSSEC signature chains. Requires dig be compiled with --DDIG_SIGCHASE. +Chase DNSSEC signature chains. Requires dig be compiled with \-DDIG_SIGCHASE. .TP -\fB+trusted-key=####\fR -Specify a trusted key to be used with \fB+sigchase\fR. -Requires dig be compiled with -DDIG_SIGCHASE. +\fB+trusted\-key=####\fR +Specifies a file containing trusted keys to be used with +\fB+sigchase\fR. Each DNSKEY record must be on its own line. +.sp +If not specified +\fBdig\fR +will look for +\fI/etc/trusted\-key.key\fR +then +\fItrusted\-key.key\fR +in the current directory. +.sp +Requires dig be compiled with \-DDIG_SIGCHASE. .TP \fB+[no]topdown\fR -When chasing DNSSEC signature chains perform a top down validation. -Requires dig be compiled with -DDIG_SIGCHASE. +When chasing DNSSEC signature chains perform a top down validation. Requires dig be compiled with \-DDIG_SIGCHASE. .SH "MULTIPLE QUERIES" .PP -The BIND 9 implementation of \fBdig \fR supports -specifying multiple queries on the command line (in addition to -supporting the \fB-f\fR batch file option). Each of those -queries can be supplied with its own set of flags, options and query -options. +The BIND 9 implementation of +\fBdig \fR +supports specifying multiple queries on the command line (in addition to supporting the +\fB\-f\fR +batch file option). Each of those queries can be supplied with its own set of flags, options and query options. .PP -In this case, each \fIquery\fR argument represent an -individual query in the command-line syntax described above. Each -consists of any of the standard options and flags, the name to be -looked up, an optional query type and class and any query options that -should be applied to that query. +In this case, each +\fIquery\fR +argument represent an individual query in the command\-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that should be applied to that query. .PP -A global set of query options, which should be applied to all queries, -can also be supplied. These global query options must precede the -first tuple of name, class, type, options, flags, and query options -supplied on the command line. Any global query options (except -the \fB+[no]cmd\fR option) can be -overridden by a query-specific set of query options. For example: +A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except the +\fB+[no]cmd\fR +option) can be overridden by a query\-specific set of query options. For example: .sp .nf -dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr -.sp +dig +qr www.isc.org any \-x 127.0.0.1 isc.org ns +noqr .fi -shows how \fBdig\fR could be used from the command line -to make three lookups: an ANY query for www.isc.org, a -reverse lookup of 127.0.0.1 and a query for the NS records of -isc.org. -A global query option of \fI+qr\fR is applied, so -that \fBdig\fR shows the initial query it made for each -lookup. The final query has a local query option of -\fI+noqr\fR which means that \fBdig\fR +.sp +shows how +\fBdig\fR +could be used from the command line to make three lookups: an ANY query for +www.isc.org, a reverse lookup of 127.0.0.1 and a query for the NS records of +isc.org. A global query option of +\fI+qr\fR +is applied, so that +\fBdig\fR +shows the initial query it made for each lookup. The final query has a local query option of +\fI+noqr\fR +which means that +\fBdig\fR will not print the initial query when it looks up the NS records for isc.org. .SH "FILES" @@ -394,8 +416,8 @@ isc.org. .PP \fBhost\fR(1), \fBnamed\fR(8), -\fBdnssec-keygen\fR(8), -\fIRFC1035\fR. -.SH "BUGS" +\fBdnssec\-keygen\fR(8), +RFC1035. +.SH "BUGS " .PP -There are probably too many query options. +There are probably too many query options. diff --git a/contrib/bind9/bin/dig/dig.c b/contrib/bind9/bin/dig/dig.c index 08f5b5b5280..52df6608685 100644 --- a/contrib/bind9/bin/dig/dig.c +++ b/contrib/bind9/bin/dig/dig.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dig.c,v 1.157.2.13.2.25 2004/09/16 02:14:14 marka Exp $ */ +/* $Id: dig.c,v 1.157.2.13.2.29 2005/10/14 01:38:40 marka Exp $ */ #include #include @@ -45,10 +45,6 @@ #include -extern ISC_LIST(dig_lookup_t) lookup_list; -extern dig_serverlist_t server_list; -extern ISC_LIST(dig_searchlist_t) search_list; - #define ADD_STRING(b, s) { \ if (strlen(s) >= isc_buffer_availablelength(b)) \ return (ISC_R_NOSPACE); \ @@ -58,31 +54,8 @@ extern ISC_LIST(dig_searchlist_t) search_list; #define DIG_MAX_ADDRESSES 20 -extern isc_boolean_t have_ipv4, have_ipv6, specified_source, - usesearch, qr; -extern in_port_t port; -extern unsigned int timeout; -extern isc_mem_t *mctx; -extern dns_messageid_t id; -extern int sendcount; -extern int ndots; -extern int lookup_counter; -extern int exitcode; -extern isc_sockaddr_t bind_address; -extern char keynametext[MXNAME]; -extern char keyfile[MXNAME]; -extern char keysecret[MXNAME]; -#ifdef DIG_SIGCHASE -extern char trustedkey[MXNAME]; -#endif -extern dns_tsigkey_t *key; -extern isc_boolean_t validated; -extern isc_taskmgr_t *taskmgr; -extern isc_task_t *global_task; -extern isc_boolean_t free_now; dig_lookup_t *default_lookup = NULL; -extern isc_boolean_t debugging, memdebugging; static char *batchname = NULL; static FILE *batchfp = NULL; static char *argv0; @@ -133,8 +106,6 @@ static const char *rcodetext[] = { "BADVERS" }; -extern char *progname; - static void print_usage(FILE *fp) { fputs( @@ -593,6 +564,7 @@ buftoosmall: } } } + if (headers && query->lookup->comments && !short_form) printf("\n"); @@ -818,7 +790,7 @@ plus_option(char *option, isc_boolean_t is_batchfile, break; case 'l': /* cl */ FULLCHECK("cl"); - noclass = !state; + noclass = ISC_TF(!state); break; case 'm': /* cmd */ FULLCHECK("cmd"); @@ -892,7 +864,7 @@ plus_option(char *option, isc_boolean_t is_batchfile, lookup->ns_search_only = state; if (state) { lookup->trace_root = ISC_TRUE; - lookup->recurse = ISC_FALSE; + lookup->recurse = ISC_TRUE; lookup->identify = ISC_TRUE; lookup->stats = ISC_FALSE; lookup->comments = ISC_FALSE; @@ -1054,7 +1026,7 @@ plus_option(char *option, isc_boolean_t is_batchfile, break; case 't': /* ttlid */ FULLCHECK("ttlid"); - nottl = !state; + nottl = ISC_TF(!state); break; default: goto invalid_option; diff --git a/contrib/bind9/bin/dig/dig.docbook b/contrib/bind9/bin/dig/dig.docbook index d22ae87064d..87c98ae7b1f 100644 --- a/contrib/bind9/bin/dig/dig.docbook +++ b/contrib/bind9/bin/dig/dig.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -30,6 +32,21 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + + dig DNS lookup utility @@ -38,7 +55,7 @@ dig -@server +@server @@ -49,10 +66,10 @@ -name -type -class -queryopt +name +type +class +queryopt @@ -62,8 +79,8 @@ dig -global-queryopt -query +global-queryopt +query @@ -513,11 +530,24 @@ Chase DNSSEC signature chains. Requires dig be compiled with -DDIG_SIGCHASE. - - -Specify a trusted key to be used with . -Requires dig be compiled with -DDIG_SIGCHASE. - + + + + + Specifies a file containing trusted keys to be used with + . Each DNSKEY record must be + on its own line. + + + If not specified dig will look for + /etc/trusted-key.key then + trusted-key.key in the current directory. + + + Requires dig be compiled with -DDIG_SIGCHASE. + + + diff --git a/contrib/bind9/bin/dig/dig.html b/contrib/bind9/bin/dig/dig.html index e9e1fd4dc77..3425fb3d21b 100644 --- a/contrib/bind9/bin/dig/dig.html +++ b/contrib/bind9/bin/dig/dig.html @@ -1,1174 +1,514 @@ - - - - -dig

dig

Name

dig -- DNS lookup utility

Synopsis

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-p port#] [-t type] [-x addr] [-y name:key] [-4] [-6] [name] [type] [class] [queryopt...]

dig [-h]

dig [global-queryopt...] [query...]

DESCRIPTION

dig (domain information groper) is a flexible tool + + + + +dig + + +

+
+
+

Name

+

dig — DNS lookup utility

+
+
+

Synopsis

+

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-p port#] [-t type] [-x addr] [-y name:key] [-4] [-6] [name] [type] [class] [queryopt...]

+

dig [-h]

+

dig [global-queryopt...] [query...]

+
+
+

DESCRIPTION

+

+dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that -were queried. Most DNS administrators use dig to +were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality -than dig.

Although dig is normally used with command-line +than dig. +

+

+Although dig is normally used with command-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command-line arguments -and options is printed when the -h option is given. +and options is printed when the -h option is given. Unlike earlier versions, the BIND9 implementation of -dig allows multiple lookups to be issued from the -command line.

Unless it is told to query a specific name server, -dig will try each of the servers listed in -/etc/resolv.conf.

When no command line arguments or options are given, will perform an -NS query for "." (the root).

It is possible to set per-user defaults for dig via -${HOME}/.digrc. This file is read and any options in it -are applied before the command line arguments.

SIMPLE USAGE

A typical invocation of dig looks like: -

 dig @server name type
where: +dig allows multiple lookups to be issued from the +command line. +

+

+Unless it is told to query a specific name server, +dig will try each of the servers listed in +/etc/resolv.conf. +

+

+When no command line arguments or options are given, will perform an +NS query for "." (the root). +

+

+It is possible to set per-user defaults for dig via +${HOME}/.digrc. This file is read and any options in it +are applied before the command line arguments. +

+
+
+

SIMPLE USAGE

+

+A typical invocation of dig looks like: +

+
 dig @server name type
+

where: -

server

is the name or IP address of the name server to query. This can be an IPv4 +

+
+
server
+

+is the name or IP address of the name server to query. This can be an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited notation. When the supplied -server argument is a hostname, -dig resolves that name before querying that name -server. If no server argument is provided, -dig consults /etc/resolv.conf +server argument is a hostname, +dig resolves that name before querying that name +server. If no server argument is provided, +dig consults /etc/resolv.conf and queries the name servers listed there. The reply from the name -server that responds is displayed.

name

is the name of the resource record that is to be looked up.

type

indicates what type of query is required — +server that responds is displayed. +

+
name
+

+is the name of the resource record that is to be looked up. +

+
type
+

+indicates what type of query is required — ANY, A, MX, SIG, etc. -type can be any valid query type. If no -type argument is supplied, -dig will perform a lookup for an A record.

OPTIONS

The -b option sets the source IP address of the query -to address. This must be a valid address on +type can be any valid query type. If no +type argument is supplied, +dig will perform a lookup for an A record. +

+
+

+

+
+
+

OPTIONS

+

+The -b option sets the source IP address of the query +to address. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port -may be specified by appending "#<port>"

The default query class (IN for internet) is overridden by the --c option. class is any valid -class, such as HS for Hesiod records or CH for CHAOSNET records.

The -f option makes dig operate +may be specified by appending "#<port>" +

+

+The default query class (IN for internet) is overridden by the +-c option. class is any valid +class, such as HS for Hesiod records or CH for CHAOSNET records. +

+

+The -f option makes dig operate in batch mode by reading a list of lookup requests to process from the -file filename. The file contains a number of +file filename. The file contains a number of queries, one per line. Each entry in the file should be organised in the same way they would be presented as queries to -dig using the command-line interface.

If a non-standard port number is to be queried, the --p option is used. port# is -the port number that dig will send its queries +dig using the command-line interface. +

+

+If a non-standard port number is to be queried, the +-p option is used. port# is +the port number that dig will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries -on a non-standard port number.

The -4 option forces dig to only -use IPv4 query transport. The -6 option forces -dig to only use IPv6 query transport.

The -t option sets the query type to -type. It can be any valid query type which is +on a non-standard port number. +

+

+The -4 option forces dig to only +use IPv4 query transport. The -6 option forces +dig to only use IPv6 query transport. +

+

+The -t option sets the query type to +type. It can be any valid query type which is supported in BIND9. The default query type "A", unless the --x option is supplied to indicate a reverse lookup. +-x option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required, -type is set to ixfr=N. +type is set to ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was -N.

Reverse lookups - mapping addresses to names - are simplified by the --x option. addr is an IPv4 +N. +

+

+Reverse lookups - mapping addresses to names - are simplified by the +-x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no need to provide the -name, class and -type arguments. dig +name, class and +type arguments. dig automatically performs a lookup for a name like -11.12.13.10.in-addr.arpa and sets the query type and +11.12.13.10.in-addr.arpa and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain -specify the -i option. Bit string labels (RFC2874) -are now experimental and are not attempted.

To sign the DNS queries sent by dig and their +specify the -i option. Bit string labels (RFC2874) +are now experimental and are not attempted. +

+

+To sign the DNS queries sent by dig and their responses using transaction signatures (TSIG), specify a TSIG key file -using the -k option. You can also specify the TSIG -key itself on the command line using the -y option; -name is the name of the TSIG key and -key is the actual key. The key is a base-64 -encoded string, typically generated by dnssec-keygen(8). +using the -k option. You can also specify the TSIG +key itself on the command line using the -y option; +name is the name of the TSIG key and +key is the actual key. The key is a base-64 +encoded string, typically generated by dnssec-keygen(8). -Caution should be taken when using the -y option on +Caution should be taken when using the -y option on multi-user systems as the key can be visible in the output from -ps(1) or in the shell's history file. When -using TSIG authentication with dig, the name +ps(1 +) or in the shell's history file. When +using TSIG authentication with dig, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate -key and server statements in -named.conf.

QUERY OPTIONS

dig provides a number of query options which affect +key and server statements in +named.conf. +

+
+
+

QUERY OPTIONS

+

+dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout -and retry strategies.

Each query option is identified by a keyword preceded by a plus sign -(+). Some keywords set or reset an option. These may be preceded -by the string no to negate the meaning of that keyword. Other +and retry strategies. +

+

+Each query option is identified by a keyword preceded by a plus sign +(+). Some keywords set or reset an option. These may be preceded +by the string no to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They -have the form +keyword=value. +have the form +keyword=value. The query options are: -

+[no]tcp

Use [do not use] TCP when querying name servers. The default +

+
+
+[no]tcp
+

+Use [do not use] TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in -which case a TCP connection is used.

+[no]vc

Use [do not use] TCP when querying name servers. This alternate -syntax to +[no]tcp is provided for backwards -compatibility. The "vc" stands for "virtual circuit".

+[no]ignore

Ignore truncation in UDP responses instead of retrying with TCP. By -default, TCP retries are performed.

+domain=somename

Set the search list to contain the single domain -somename, as if specified in a -domain directive in -/etc/resolv.conf, and enable search list -processing as if the +search option were given.

+[no]search

Use [do not use] the search list defined by the searchlist or domain -directive in resolv.conf (if any). -The search list is not used by default.

+[no]defname

Deprecated, treated as a synonym for +[no]search

+[no]aaonly

Sets the "aa" flag in the query.

+[no]aaflag

A synonym for +[no]aaonly.

+[no]adflag

Set [do not set] the AD (authentic data) bit in the query. The AD bit +which case a TCP connection is used. +

+
+[no]vc
+

+Use [do not use] TCP when querying name servers. This alternate +syntax to +[no]tcp is provided for backwards +compatibility. The "vc" stands for "virtual circuit". +

+
+[no]ignore
+

+Ignore truncation in UDP responses instead of retrying with TCP. By +default, TCP retries are performed. +

+
+domain=somename
+

+Set the search list to contain the single domain +somename, as if specified in a +domain directive in +/etc/resolv.conf, and enable search list +processing as if the +search option were given. +

+
+[no]search
+

+Use [do not use] the search list defined by the searchlist or domain +directive in resolv.conf (if any). +The search list is not used by default. +

+
+[no]defname
+

+Deprecated, treated as a synonym for +[no]search +

+
+[no]aaonly
+

+Sets the "aa" flag in the query. +

+
+[no]aaflag
+

+A synonym for +[no]aaonly. +

+
+[no]adflag
+

+Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for -completeness.

+[no]cdflag

Set [do not set] the CD (checking disabled) bit in the query. This -requests the server to not perform DNSSEC validation of responses.

+[no]cl

Display [do not display] the CLASS when printing the record.

+[no]ttlid

Display [do not display] the TTL when printing the record.

+[no]recurse

Toggle the setting of the RD (recursion desired) bit in the query. -This bit is set by default, which means dig +completeness. +

+
+[no]cdflag
+

+Set [do not set] the CD (checking disabled) bit in the query. This +requests the server to not perform DNSSEC validation of responses. +

+
+[no]cl
+

+Display [do not display] the CLASS when printing the record. +

+
+[no]ttlid
+

+Display [do not display] the TTL when printing the record. +

+
+[no]recurse
+

+Toggle the setting of the RD (recursion desired) bit in the query. +This bit is set by default, which means dig normally sends recursive queries. Recursion is automatically disabled -when the +nssearch or -+trace query options are used.

+[no]nssearch

When this option is set, dig attempts to find the +when the +nssearch or ++trace query options are used. +

+
+[no]nssearch
+

+When this option is set, dig attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the -zone.

+[no]trace

Toggle tracing of the delegation path from the root name servers for +zone. +

+
+[no]trace
+

+Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When -tracing is enabled, dig makes iterative queries to +tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to -resolve the lookup.

+[no]cmd

toggles the printing of the initial comment in the output identifying -the version of dig and the query options that have -been applied. This comment is printed by default.

+[no]short

Provide a terse answer. The default is to print the answer in a -verbose form.

+[no]identify

Show [or do not show] the IP address and port number that supplied the -answer when the +short option is enabled. If +resolve the lookup. +

+
+[no]cmd
+

+toggles the printing of the initial comment in the output identifying +the version of dig and the query options that have +been applied. This comment is printed by default. +

+
+[no]short
+

+Provide a terse answer. The default is to print the answer in a +verbose form. +

+
+[no]identify
+

+Show [or do not show] the IP address and port number that supplied the +answer when the +short option is enabled. If short form answers are requested, the default is not to show the -source address and port number of the server that provided the answer.

+[no]comments

Toggle the display of comment lines in the output. The default is to -print comments.

+[no]stats

This query option toggles the printing of statistics: when the query +source address and port number of the server that provided the answer. +

+
+[no]comments
+

+Toggle the display of comment lines in the output. The default is to +print comments. +

+
+[no]stats
+

+This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is -to print the query statistics.

+[no]qr

Print [do not print] the query as it is sent. -By default, the query is not printed.

+[no]question

Print [do not print] the question section of a query when an answer is -returned. The default is to print the question section as a comment.

+[no]answer

Display [do not display] the answer section of a reply. The default -is to display it.

+[no]authority

Display [do not display] the authority section of a reply. The -default is to display it.

+[no]additional

Display [do not display] the additional section of a reply. -The default is to display it.

+[no]all

Set or clear all display flags.

+time=T

Sets the timeout for a query to -T seconds. The default time out is 5 seconds. -An attempt to set T to less than 1 will result -in a query timeout of 1 second being applied.

+tries=T

Sets the number of times to try UDP queries to server to -T instead of the default, 3. If -T is less than or equal to zero, the number of -tries is silently rounded up to 1.

+retry=T

Sets the number of times to retry UDP queries to server to -T instead of the default, 2. Unlike -+tries, this does not include the initial -query.

+ndots=D

Set the number of dots that have to appear in -name to D for it to be +to print the query statistics. +

+
+[no]qr
+

+Print [do not print] the query as it is sent. +By default, the query is not printed. +

+
+[no]question
+

+Print [do not print] the question section of a query when an answer is +returned. The default is to print the question section as a comment. +

+
+[no]answer
+

+Display [do not display] the answer section of a reply. The default +is to display it. +

+
+[no]authority
+

+Display [do not display] the authority section of a reply. The +default is to display it. +

+
+[no]additional
+

+Display [do not display] the additional section of a reply. +The default is to display it. +

+
+[no]all
+

+Set or clear all display flags. +

+
+time=T
+

+ +Sets the timeout for a query to +T seconds. The default time out is 5 seconds. +An attempt to set T to less than 1 will result +in a query timeout of 1 second being applied. +

+
+tries=T
+

+Sets the number of times to try UDP queries to server to +T instead of the default, 3. If +T is less than or equal to zero, the number of +tries is silently rounded up to 1. +

+
+retry=T
+

+Sets the number of times to retry UDP queries to server to +T instead of the default, 2. Unlike ++tries, this does not include the initial +query. +

+
+ndots=D
+

+Set the number of dots that have to appear in +name to D for it to be considered absolute. The default value is that defined using the -ndots statement in /etc/resolv.conf, or 1 if no +ndots statement in /etc/resolv.conf, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the -search or domain directive in -/etc/resolv.conf.

+bufsize=B

Set the UDP message buffer size advertised using EDNS0 to -B bytes. The maximum and minimum sizes of this +search or domain directive in +/etc/resolv.conf. +

+
+bufsize=B
+

+Set the UDP message buffer size advertised using EDNS0 to +B bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are -rounded up or down appropriately.

+[no]multiline

Print records like the SOA records in a verbose multi-line +rounded up or down appropriately. +

+
+[no]multiline
+

+Print records like the SOA records in a verbose multi-line format with human-readable comments. The default is to print each record on a single line, to facilitate machine parsing -of the dig output.

+[no]fail

Do not try the next server if you receive a SERVFAIL. The default is +of the dig output. +

+
+[no]fail
+

+Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver -behaviour.

+[no]besteffort

Attempt to display the contents of messages which are malformed. -The default is to not display malformed answers.

+[no]dnssec

Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) -in the OPT record in the additional section of the query.

+[no]sigchase

Chase DNSSEC signature chains. Requires dig be compiled with --DDIG_SIGCHASE.

+trusted-key=####

Specify a trusted key to be used with +sigchase. -Requires dig be compiled with -DDIG_SIGCHASE.

+[no]topdown

When chasing DNSSEC signature chains perform a top down validation. -Requires dig be compiled with -DDIG_SIGCHASE.

MULTIPLE QUERIES

The BIND 9 implementation of dig supports +behaviour. +

+
+[no]besteffort
+

+Attempt to display the contents of messages which are malformed. +The default is to not display malformed answers. +

+
+[no]dnssec
+

+Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) +in the OPT record in the additional section of the query. +

+
+[no]sigchase
+

+Chase DNSSEC signature chains. Requires dig be compiled with +-DDIG_SIGCHASE. +

+
+trusted-key=####
+
+

+ Specifies a file containing trusted keys to be used with + +sigchase. Each DNSKEY record must be + on its own line. +

+

+ If not specified dig will look for + /etc/trusted-key.key then + trusted-key.key in the current directory. +

+

+ Requires dig be compiled with -DDIG_SIGCHASE. +

+
+
+[no]topdown
+

+When chasing DNSSEC signature chains perform a top down validation. +Requires dig be compiled with -DDIG_SIGCHASE. +

+
+

+ +

+
+
+

MULTIPLE QUERIES

+

+The BIND 9 implementation of dig supports specifying multiple queries on the command line (in addition to -supporting the -f batch file option). Each of those +supporting the -f batch file option). Each of those queries can be supplied with its own set of flags, options and query -options.

In this case, each query argument represent an +options. +

+

+In this case, each query argument represent an individual query in the command-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that -should be applied to that query.

A global set of query options, which should be applied to all queries, +should be applied to that query. +

+

+A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except -the +[no]cmd option) can be +the +[no]cmd option) can be overridden by a query-specific set of query options. For example: -

dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
-shows how dig could be used from the command line -to make three lookups: an ANY query for www.isc.org, a +

+
+dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
+
+

+shows how dig could be used from the command line +to make three lookups: an ANY query for www.isc.org, a reverse lookup of 127.0.0.1 and a query for the NS records of -isc.org. +isc.org. -A global query option of +qr is applied, so -that dig shows the initial query it made for each +A global query option of +qr is applied, so +that dig shows the initial query it made for each lookup. The final query has a local query option of -+noqr which means that dig ++noqr which means that dig will not print the initial query when it looks up the NS records for -isc.org.

FILES

/etc/resolv.conf

${HOME}/.digrc

SEE ALSO

host(1), -named(8), -dnssec-keygen(8), -RFC1035.

BUGS

There are probably too many query options.

+isc.org. +

+
+
+

FILES

+

+/etc/resolv.conf +

+

+${HOME}/.digrc +

+
+
+

SEE ALSO

+

+host(1), +named(8), +dnssec-keygen(8), +RFC1035. +

+
+
+

BUGS

+

+There are probably too many query options. +

+
+
+ diff --git a/contrib/bind9/bin/dig/dighost.c b/contrib/bind9/bin/dig/dighost.c index 63a81105a7d..6129fedb6c6 100644 --- a/contrib/bind9/bin/dig/dighost.c +++ b/contrib/bind9/bin/dig/dighost.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dighost.c,v 1.221.2.19.2.20 2004/11/22 23:30:31 marka Exp $ */ +/* $Id: dighost.c,v 1.221.2.19.2.31 2005/10/14 01:38:40 marka Exp $ */ /* * Notice to programmers: Do not use this code as an example of how to @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #endif @@ -58,6 +57,7 @@ #include #include #include +#include #include #include #ifdef DIG_SIGCHASE @@ -90,9 +90,9 @@ static lwres_context_t *lwctx = NULL; static lwres_conf_t *lwconf; -ISC_LIST(dig_lookup_t) lookup_list; +dig_lookuplist_t lookup_list; dig_serverlist_t server_list; -ISC_LIST(dig_searchlist_t) search_list; +dig_searchlistlist_t search_list; isc_boolean_t have_ipv4 = ISC_FALSE, @@ -146,7 +146,7 @@ dig_lookup_t *current_lookup = NULL; #ifdef DIG_SIGCHASE -isc_result_t get_trusted_key(isc_mem_t *mctx); +isc_result_t get_trusted_key(isc_mem_t *mctx); dns_rdataset_t * sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, isc_boolean_t *lookedup, @@ -156,103 +156,104 @@ dns_rdataset_t * chase_scanname_section(dns_message_t *msg, dns_rdatatype_t type, dns_rdatatype_t covers, int section); -isc_result_t advanced_rrsearch(dns_rdataset_t **rdataset, +isc_result_t advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers, isc_boolean_t *lookedup); -isc_result_t sigchase_verify_sig_key(dns_name_t *name, +isc_result_t sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, dst_key_t* dnsseckey, dns_rdataset_t *sigrdataset, isc_mem_t *mctx); -isc_result_t sigchase_verify_sig(dns_name_t *name, +isc_result_t sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdataset_t *keyrdataset, dns_rdataset_t *sigrdataset, isc_mem_t *mctx); -isc_result_t sigchase_verify_ds(dns_name_t *name, +isc_result_t sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdataset_t *dsrdataset, isc_mem_t *mctx); -void sigchase(dns_message_t *msg); -void print_rdata(dns_rdata_t *rdata, isc_mem_t *mctx); -void print_rdataset(dns_name_t *name, +void sigchase(dns_message_t *msg); +void print_rdata(dns_rdata_t *rdata, isc_mem_t *mctx); +void print_rdataset(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx); -void dup_name(dns_name_t *source, dns_name_t* target, +void dup_name(dns_name_t *source, dns_name_t* target, isc_mem_t *mctx); -void dump_database(void); -void dump_database_section(dns_message_t *msg, int section); +void free_name(dns_name_t *name, isc_mem_t *mctx); +void dump_database(void); +void dump_database_section(dns_message_t *msg, int section); dns_rdataset_t * search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers); -isc_result_t contains_trusted_key(dns_name_t *name, +isc_result_t contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset, isc_mem_t *mctx); -void print_type(dns_rdatatype_t type); -isc_result_t prove_nx_domain(dns_message_t * msg, +void print_type(dns_rdatatype_t type); +isc_result_t prove_nx_domain(dns_message_t * msg, dns_name_t * name, dns_name_t * rdata_name, dns_rdataset_t ** rdataset, dns_rdataset_t ** sigrdataset); -isc_result_t prove_nx_type(dns_message_t * msg, dns_name_t *name, +isc_result_t prove_nx_type(dns_message_t * msg, dns_name_t *name, dns_rdataset_t *nsec, dns_rdataclass_t class, dns_rdatatype_t type, dns_name_t * rdata_name, dns_rdataset_t ** rdataset, dns_rdataset_t ** sigrdataset); -isc_result_t prove_nx(dns_message_t * msg, dns_name_t * name, +isc_result_t prove_nx(dns_message_t * msg, dns_name_t * name, dns_rdataclass_t class, dns_rdatatype_t type, dns_name_t * rdata_name, dns_rdataset_t ** rdataset, dns_rdataset_t ** sigrdataset); static void nameFromString(const char *str, dns_name_t *p_ret); -int inf_name(dns_name_t * name1, dns_name_t * name2); -isc_result_t opentmpkey(isc_mem_t *mctx, const char *file, +int inf_name(dns_name_t * name1, dns_name_t * name2); +isc_result_t opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp); -isc_result_t removetmpkey(isc_mem_t *mctx, const char *file); -void clean_trustedkey(void ); -void insert_trustedkey(dst_key_t * key); +isc_result_t removetmpkey(isc_mem_t *mctx, const char *file); +void clean_trustedkey(void); +void insert_trustedkey(dst_key_t * key); #if DIG_SIGCHASE_BU -isc_result_t getneededrr(dns_message_t *msg); -void sigchase_bottom_up(dns_message_t *msg); -void sigchase_bu(dns_message_t *msg); +isc_result_t getneededrr(dns_message_t *msg); +void sigchase_bottom_up(dns_message_t *msg); +void sigchase_bu(dns_message_t *msg); #endif #if DIG_SIGCHASE_TD -isc_result_t initialization(dns_name_t *name); -isc_result_t prepare_lookup(dns_name_t *name); -isc_result_t grandfather_pb_test(dns_name_t * zone_name, +isc_result_t initialization(dns_name_t *name); +isc_result_t prepare_lookup(dns_name_t *name); +isc_result_t grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t *sigrdataset); -isc_result_t child_of_zone(dns_name_t *name, +isc_result_t child_of_zone(dns_name_t *name, dns_name_t *zone_name, dns_name_t *child_name); -void sigchase_td(dns_message_t *msg); +void sigchase_td(dns_message_t *msg); #endif char trustedkey[MXNAME] = ""; -dns_rdataset_t * chase_rdataset = NULL; -dns_rdataset_t * chase_sigrdataset = NULL; -dns_rdataset_t * chase_dsrdataset = NULL; -dns_rdataset_t * chase_sigdsrdataset = NULL; -dns_rdataset_t * chase_keyrdataset = NULL; -dns_rdataset_t * chase_sigkeyrdataset = NULL; -dns_rdataset_t * chase_nsrdataset = NULL; +dns_rdataset_t *chase_rdataset = NULL; +dns_rdataset_t *chase_sigrdataset = NULL; +dns_rdataset_t *chase_dsrdataset = NULL; +dns_rdataset_t *chase_sigdsrdataset = NULL; +dns_rdataset_t *chase_keyrdataset = NULL; +dns_rdataset_t *chase_sigkeyrdataset = NULL; +dns_rdataset_t *chase_nsrdataset = NULL; -dns_name_t chase_name; /* the query name */ +dns_name_t chase_name; /* the query name */ #if DIG_SIGCHASE_TD /* * the current name is the parent name when we follow delegation */ -dns_name_t chase_current_name; +dns_name_t chase_current_name; /* * the child name is used for delegation (NS DS responses in AUTHORITY section) */ -dns_name_t chase_authority_name; +dns_name_t chase_authority_name; #endif #if DIG_SIGCHASE_BU -dns_name_t chase_signame; +dns_name_t chase_signame; #endif @@ -274,7 +275,7 @@ dns_message_t * error_message = NULL; #endif isc_boolean_t dsvalidating = ISC_FALSE; -isc_boolean_t chase_name_dup = ISC_FALSE; +isc_boolean_t chase_name_dup = ISC_FALSE; ISC_LIST(dig_message_t) chase_message_list; ISC_LIST(dig_message_t) chase_message_list2; @@ -282,11 +283,11 @@ ISC_LIST(dig_message_t) chase_message_list2; #define MAX_TRUSTED_KEY 5 typedef struct struct_trusted_key_list { - dst_key_t * key[MAX_TRUSTED_KEY]; - int nb_tk; + dst_key_t * key[MAX_TRUSTED_KEY]; + int nb_tk; } struct_tk_list; -struct_tk_list tk_list = { {NULL, NULL, NULL, NULL, NULL}, 0}; +struct_tk_list tk_list = { {NULL, NULL, NULL, NULL, NULL}, 0}; #endif @@ -581,7 +582,7 @@ set_nameserver(char *opt) { return; result = bind9_getaddresses(opt, 0, sockaddrs, - DIG_MAX_ADDRESSES, &count); + DIG_MAX_ADDRESSES, &count); if (result != ISC_R_SUCCESS) fatal("couldn't get address for '%s': %s", opt, isc_result_totext(result)); @@ -690,13 +691,13 @@ make_empty_lookup(void) { #ifdef DIG_SIGCHASE looknew->sigchase = ISC_FALSE; #if DIG_SIGCHASE_TD - looknew->do_topdown = ISC_FALSE; + looknew->do_topdown = ISC_FALSE; looknew->trace_root_sigchase = ISC_FALSE; looknew->rdtype_sigchaseset = ISC_FALSE; looknew->rdtype_sigchase = dns_rdatatype_any; looknew->qrdtype_sigchase = dns_rdatatype_any; looknew->rdclass_sigchase = dns_rdataclass_in; - looknew->rdclass_sigchaseset = ISC_FALSE; + looknew->rdclass_sigchaseset = ISC_FALSE; #endif #endif looknew->udpsize = 0; @@ -766,9 +767,9 @@ clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) { #ifdef DIG_SIGCHASE looknew->sigchase = lookold->sigchase; #if DIG_SIGCHASE_TD - looknew->do_topdown = lookold->do_topdown; + looknew->do_topdown = lookold->do_topdown; looknew->trace_root_sigchase = lookold->trace_root_sigchase; - looknew->rdtype_sigchaseset = lookold->rdtype_sigchaseset; + looknew->rdtype_sigchaseset = lookold->rdtype_sigchaseset; looknew->rdtype_sigchase = lookold->rdtype_sigchase; looknew->qrdtype_sigchase = lookold->qrdtype_sigchase; looknew->rdclass_sigchase = lookold->rdclass_sigchase; @@ -944,14 +945,17 @@ setup_system(void) { if (lwresult != LWRES_R_SUCCESS) fatal("lwres_context_create failed"); - (void)lwres_conf_parse(lwctx, RESOLV_CONF); + if (isc_file_exists(RESOLV_CONF)) + lwresult = lwres_conf_parse(lwctx, RESOLV_CONF); + if (lwresult != LWRES_R_SUCCESS) + fatal("parse of %s failed", RESOLV_CONF); + lwconf = lwres_conf_get(lwctx); /* Make the search list */ if (lwconf->searchnxt > 0) create_search_list(lwconf); - else { - /* No search list. Use the domain name if any */ + else { /* No search list. Use the domain name if any */ if (lwconf->domainname != NULL) { domain = make_searchlist_entry(lwconf->domainname); ISC_LIST_INITANDAPPEND(search_list, domain, link); @@ -959,8 +963,10 @@ setup_system(void) { } } - ndots = lwconf->ndots; - debug("ndots is %d.", ndots); + if (ndots == -1) { + ndots = lwconf->ndots; + debug("ndots is %d.", ndots); + } /* If we don't find a nameserver fall back to localhost */ if (lwconf->nsnext == 0) { @@ -985,15 +991,15 @@ setup_system(void) { setup_text_key(); #ifdef DIG_SIGCHASE /* Setup the list of messages for +sigchase */ - ISC_LIST_INIT(chase_message_list); - ISC_LIST_INIT(chase_message_list2); + ISC_LIST_INIT(chase_message_list); + ISC_LIST_INIT(chase_message_list2); dns_name_init(&chase_name, NULL); #if DIG_SIGCHASE_TD dns_name_init(&chase_current_name, NULL); dns_name_init(&chase_authority_name, NULL); #endif #if DIG_SIGCHASE_BU - dns_name_init(&chase_signame, NULL); + dns_name_init(&chase_signame, NULL); #endif #endif @@ -1210,8 +1216,7 @@ try_clear_lookup(dig_lookup_t *lookup) { if (debugging) { q = ISC_LIST_HEAD(lookup->q); while (q != NULL) { - debug("query to %s still pending", - q->servname); + debug("query to %s still pending", q->servname); q = ISC_LIST_NEXT(q, link); } return (ISC_FALSE); @@ -1224,8 +1229,7 @@ try_clear_lookup(dig_lookup_t *lookup) { debug("cleared"); s = ISC_LIST_HEAD(lookup->my_server_list); while (s != NULL) { - debug("freeing server %p belonging to %p", - s, lookup); + debug("freeing server %p belonging to %p", s, lookup); ptr = s; s = ISC_LIST_NEXT(s, link); ISC_LIST_DEQUEUE(lookup->my_server_list, @@ -1278,12 +1282,12 @@ start_lookup(void) { #if DIG_SIGCHASE_TD if (current_lookup->do_topdown && !current_lookup->rdtype_sigchaseset) { - dst_key_t * trustedkey = NULL; + dst_key_t *trustedkey = NULL; isc_buffer_t *b = NULL; isc_region_t r; isc_result_t result; dns_name_t query_name; - dns_name_t * key_name; + dns_name_t *key_name; int i; result = get_trusted_key(mctx); @@ -1296,9 +1300,9 @@ start_lookup(void) { dns_name_init(&query_name, NULL); nameFromString(current_lookup->textname, &query_name); - for (i = 0; i< tk_list.nb_tk; i++) { + for (i = 0; i < tk_list.nb_tk; i++) { key_name = dst_key_name(tk_list.key[i]); - + if (dns_name_issubdomain(&query_name, key_name) == ISC_TRUE) trustedkey = tk_list.key[i]; @@ -1313,35 +1317,32 @@ start_lookup(void) { printf(" isn't a subdomain of any Trusted Keys" ": +sigchase option is disable\n"); current_lookup->sigchase = ISC_FALSE; - dns_name_free(&query_name, mctx); + free_name(&query_name, mctx); goto novalidation; } - dns_name_free(&query_name, mctx); + free_name(&query_name, mctx); - current_lookup->rdtype_sigchase - = current_lookup->rdtype; + = current_lookup->rdtype; current_lookup->rdtype_sigchaseset - = current_lookup->rdtypeset; + = current_lookup->rdtypeset; current_lookup->rdtype = dns_rdatatype_ns; - - + current_lookup->qrdtype_sigchase = current_lookup->qrdtype; current_lookup->qrdtype = dns_rdatatype_ns; - + current_lookup->rdclass_sigchase = current_lookup->rdclass; current_lookup->rdclass_sigchaseset = current_lookup->rdclassset; current_lookup->rdclass = dns_rdataclass_in; - strncpy(current_lookup->textnamesigchase, current_lookup->textname, MXNAME); current_lookup->trace_root_sigchase = ISC_TRUE; - + result = isc_buffer_allocate(mctx, &b, BUFSIZE); check_result(result, "isc_buffer_allocate"); result = dns_name_totext(dst_key_name(trustedkey), @@ -1466,6 +1467,8 @@ followup_lookup(dns_message_t *msg, dig_query_t *query, dns_section_t section) lookup->ns_search_only = query->lookup->ns_search_only; lookup->trace_root = ISC_FALSE; + if (lookup->ns_search_only) + lookup->recurse = ISC_FALSE; } srv = make_server(namestr, namestr); debug("adding server %s", srv->servername); @@ -1636,9 +1639,9 @@ setup_lookup(dig_lookup_t *lookup) { /* XXX New search here? */ if ((count_dots(lookup->textname) >= ndots) || !usesearch) lookup->origin = NULL; /* Force abs lookup */ - else if (lookup->origin == NULL && lookup->new_search && usesearch) { + else if (lookup->origin == NULL && lookup->new_search && usesearch) lookup->origin = ISC_LIST_HEAD(search_list); - } + if (lookup->origin != NULL) { debug("trying origin %s", lookup->origin->origin); result = dns_message_gettempname(lookup->sendmsg, @@ -1922,21 +1925,17 @@ bringup_timer(dig_query_t *query, unsigned int default_timeout) { if (ISC_LIST_NEXT(query, link) != NULL) local_timeout = SERVER_TIMEOUT; else { - if (timeout == 0) { + if (timeout == 0) local_timeout = default_timeout; - } else + else local_timeout = timeout; } debug("have local timeout of %d", local_timeout); isc_interval_set(&l->interval, local_timeout, 0); if (l->timer != NULL) isc_timer_detach(&l->timer); - result = isc_timer_create(timermgr, - isc_timertype_once, - NULL, - &l->interval, - global_task, - connect_timeout, + result = isc_timer_create(timermgr, isc_timertype_once, NULL, + &l->interval, global_task, connect_timeout, l, &l->timer); check_result(result, "isc_timer_create"); } @@ -2029,8 +2028,7 @@ send_udp(dig_query_t *query) { l = query->lookup; bringup_timer(query, UDP_TIMEOUT); l->current_query = query; - debug("working on lookup %p, query %p", - query->lookup, query); + debug("working on lookup %p, query %p", query->lookup, query); if (!query->recv_made) { /* XXX Check the sense of this, need assertion? */ query->waiting_connect = ISC_FALSE; @@ -2056,12 +2054,9 @@ send_udp(dig_query_t *query) { ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); debug("recving with lookup=%p, query=%p, sock=%p", - query->lookup, query, - query->sock); - result = isc_socket_recvv(query->sock, - &query->recvlist, 1, - global_task, recv_done, - query); + query->lookup, query, query->sock); + result = isc_socket_recvv(query->sock, &query->recvlist, 1, + global_task, recv_done, query); check_result(result, "isc_socket_recvv"); recvcount++; debug("recvcount=%d", recvcount); @@ -2097,7 +2092,7 @@ send_udp(dig_query_t *query) { */ static void connect_timeout(isc_task_t *task, isc_event_t *event) { - dig_lookup_t *l = NULL, *n; + dig_lookup_t *l = NULL; dig_query_t *query = NULL, *cq; UNUSED(task); @@ -2133,7 +2128,7 @@ connect_timeout(isc_task_t *task, isc_event_t *event) { debug("making new TCP request, %d tries left", l->retries); l->retries--; - n = requeue_lookup(l, ISC_TRUE); + requeue_lookup(l, ISC_TRUE); cancel_lookup(l); check_next_lookup(l); } @@ -2220,8 +2215,7 @@ tcp_length_done(isc_task_t *task, isc_event_t *event) { ENSURE(ISC_LIST_EMPTY(query->recvlist)); ISC_LINK_INIT(&query->recvbuf, link); ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link); - debug("recving with lookup=%p, query=%p", - query->lookup, query); + debug("recving with lookup=%p, query=%p", query->lookup, query); result = isc_socket_recvv(query->sock, &query->recvlist, length, task, recv_done, query); check_result(result, "isc_socket_recvv"); @@ -2339,8 +2333,7 @@ connect_done(isc_task_t *task, isc_event_t *event) { debug("unsuccessful connection: %s", isc_result_totext(sevent->result)); - isc_sockaddr_format(&query->sockaddr, sockstr, - sizeof(sockstr)); + isc_sockaddr_format(&query->sockaddr, sockstr, sizeof(sockstr)); if (sevent->result != ISC_R_CANCELED) printf(";; Connection to %s(%s) for %s failed: " "%s.\n", sockstr, @@ -2430,8 +2423,7 @@ check_for_more_data(dig_query_t *query, dns_message_t *msg, if ((!query->first_soa_rcvd) && (rdata.type != dns_rdatatype_soa)) { puts("; Transfer failed. " - "Didn't start with " - "SOA answer."); + "Didn't start with SOA answer."); return (ISC_TRUE); } if ((!query->second_rr_rcvd) && @@ -2608,7 +2600,7 @@ recv_done(isc_task_t *task, isc_event_t *event) { char buf2[ISC_SOCKADDR_FORMATSIZE]; isc_sockaddr_t any; - if (isc_sockaddr_pf(&query->sockaddr) == AF_INET) + if (isc_sockaddr_pf(&query->sockaddr) == AF_INET) isc_sockaddr_any(&any); else isc_sockaddr_any6(&any); @@ -2629,7 +2621,7 @@ recv_done(isc_task_t *task, isc_event_t *event) { else #endif /* - * We don't expect a match above when the packet is + * We don't expect a match above when the packet is * sent to 0.0.0.0, :: or to a multicast addresses. * XXXMPA broadcast needs to be handled here as well. */ @@ -2843,9 +2835,6 @@ recv_done(isc_task_t *task, isc_event_t *event) { } if (!l->doing_xfr || l->xfr_q == query) { -#ifdef DIG_SIGCHASE - int count = 0; -#endif if (msg->rcode != dns_rcode_noerror && l->origin != NULL) { if (!next_origin(msg, query)) { printmessage(query, msg, ISC_TRUE); @@ -2858,11 +2847,7 @@ recv_done(isc_task_t *task, isc_event_t *event) { printmessage(query, msg, ISC_TRUE); } else if (l->trace) { int n = 0; -#ifdef DIG_SIGCHASE - count = msg->counts[DNS_SECTION_ANSWER]; -#else int count = msg->counts[DNS_SECTION_ANSWER]; -#endif debug("in TRACE code"); if (!l->ns_search_only) @@ -2885,7 +2870,7 @@ recv_done(isc_task_t *task, isc_event_t *event) { if (l->trace_root) { /* - * This is the initial NS query. + * This is the initial NS query. */ int n; @@ -2900,9 +2885,9 @@ recv_done(isc_task_t *task, isc_event_t *event) { if (!do_sigchase) #endif printmessage(query, msg, ISC_TRUE); - } + } #ifdef DIG_SIGCHASE - if ( do_sigchase) { + if (do_sigchase) { chase_msg = isc_mem_allocate(mctx, sizeof(dig_message_t)); if (chase_msg == NULL) { @@ -2916,16 +2901,16 @@ recv_done(isc_task_t *task, isc_event_t *event) { fatal("dns_message_create in %s:%d", __FILE__, __LINE__); } - + isc_buffer_usedregion(b, &r); result = isc_buffer_allocate(mctx, &buf, r.length); - + check_result(result, "isc_buffer_allocate"); result = isc_buffer_copyregion(buf, &r); check_result(result, "isc_buffer_copyregion"); - + result = dns_message_parse(msg_temp, buf, 0); - + isc_buffer_free(&buf); chase_msg->msg = msg_temp; @@ -2942,9 +2927,9 @@ recv_done(isc_task_t *task, isc_event_t *event) { #endif } - + #ifdef DIG_SIGCHASE - if (l->sigchase && ISC_LIST_EMPTY(lookup_list) ) { + if (l->sigchase && ISC_LIST_EMPTY(lookup_list)) { sigchase(msg_temp); } #endif @@ -3101,7 +3086,7 @@ cancel_all(void) { */ void destroy_libs(void) { -#ifdef DIG_SIGCHASE +#ifdef DIG_SIGCHASE void * ptr; dig_message_t *chase_msg; #endif @@ -3171,7 +3156,7 @@ destroy_libs(void) { debug("Destroy the messages kept for sigchase"); /* Destroy the messages kept for sigchase */ - chase_msg = ISC_LIST_HEAD(chase_message_list); + chase_msg = ISC_LIST_HEAD(chase_message_list); while (chase_msg != NULL) { INSIST(chase_msg->msg != NULL); @@ -3191,16 +3176,16 @@ destroy_libs(void) { isc_mem_free(mctx, ptr); } if (dns_name_dynamic(&chase_name)) - dns_name_free(&chase_name, mctx); + free_name(&chase_name, mctx); #if DIG_SIGCHASE_TD if (dns_name_dynamic(&chase_current_name)) - dns_name_free(&chase_current_name, mctx); + free_name(&chase_current_name, mctx); if (dns_name_dynamic(&chase_authority_name)) - dns_name_free(&chase_authority_name, mctx); + free_name(&chase_authority_name, mctx); #endif #if DIG_SIGCHASE_BU if (dns_name_dynamic(&chase_signame)) - dns_name_free(&chase_signame, mctx); + free_name(&chase_signame, mctx); #endif debug("Destroy memory"); @@ -3212,7 +3197,7 @@ destroy_libs(void) { isc_mem_destroy(&mctx); } - + #ifdef DIG_SIGCHASE @@ -3222,32 +3207,31 @@ print_type(dns_rdatatype_t type) isc_buffer_t * b = NULL; isc_result_t result; isc_region_t r; - + result = isc_buffer_allocate(mctx, &b, 4000); check_result(result, "isc_buffer_allocate"); result = dns_rdatatype_totext(type, b); check_result(result, "print_type"); - + isc_buffer_usedregion(b, &r); r.base[r.length] = '\0'; - + printf("%s", r.base); isc_buffer_free(&b); } - void -dump_database_section( dns_message_t *msg, int section) +dump_database_section(dns_message_t *msg, int section) { dns_name_t *msg_name=NULL; - + dns_rdataset_t *rdataset; do { dns_message_currentname(msg, section, &msg_name); - + for (rdataset = ISC_LIST_HEAD(msg_name->list); rdataset != NULL; rdataset = ISC_LIST_NEXT(rdataset, link)) { dns_name_print(msg_name, stdout); @@ -3256,35 +3240,32 @@ dump_database_section( dns_message_t *msg, int section) printf("end\n"); } msg_name = NULL; - } while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS); + } while (dns_message_nextname(msg, section) == ISC_R_SUCCESS); } - -void dump_database(void) -{ +void +dump_database(void) { dig_message_t * msg; for (msg = ISC_LIST_HEAD(chase_message_list); msg != NULL; msg = ISC_LIST_NEXT(msg, link)) { if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER) - == ISC_R_SUCCESS) + == ISC_R_SUCCESS) dump_database_section(msg->msg, DNS_SECTION_ANSWER); - + if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY) - == ISC_R_SUCCESS) + == ISC_R_SUCCESS) dump_database_section(msg->msg, DNS_SECTION_AUTHORITY); if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL) - == ISC_R_SUCCESS) + == ISC_R_SUCCESS) dump_database_section(msg->msg, DNS_SECTION_ADDITIONAL); } } -dns_rdataset_t * search_type(dns_name_t *name, - dns_rdatatype_t type, - dns_rdatatype_t covers) -{ +dns_rdataset_t * +search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) { dns_rdataset_t *rdataset; dns_rdata_sig_t siginfo; dns_rdata_t sigrdata; @@ -3294,10 +3275,9 @@ dns_rdataset_t * search_type(dns_name_t *name, rdataset = ISC_LIST_NEXT(rdataset, link)) { if (type == dns_rdatatype_any) { if (rdataset->type != dns_rdatatype_rrsig) - return rdataset; - } - else if ((type == dns_rdatatype_rrsig) && - (rdataset->type == dns_rdatatype_rrsig)) { + return (rdataset); + } else if ((type == dns_rdatatype_rrsig) && + (rdataset->type == dns_rdatatype_rrsig)) { dns_rdata_init(&sigrdata); result = dns_rdataset_first(rdataset); check_result(result, "empty rdataset"); @@ -3309,38 +3289,35 @@ dns_rdataset_t * search_type(dns_name_t *name, (covers == dns_rdatatype_any)) { dns_rdata_reset(&sigrdata); dns_rdata_freestruct(&siginfo); - return rdataset; + return (rdataset); } dns_rdata_reset(&sigrdata); dns_rdata_freestruct(&siginfo); - } - else if (rdataset->type == type) - return rdataset; + } else if (rdataset->type == type) + return (rdataset); } - return NULL; + return (NULL); } dns_rdataset_t * -chase_scanname_section(dns_message_t *msg, - dns_name_t *name, - dns_rdatatype_t type, - dns_rdatatype_t covers, +chase_scanname_section(dns_message_t *msg, dns_name_t *name, + dns_rdatatype_t type, dns_rdatatype_t covers, int section) { dns_rdataset_t *rdataset; dns_name_t *msg_name = NULL; - + do { dns_message_currentname(msg, section, &msg_name); if (dns_name_compare(msg_name, name) == 0) { rdataset = search_type(msg_name, type, covers); - if ( rdataset != NULL) - return rdataset; + if (rdataset != NULL) + return (rdataset); } msg_name = NULL; - } while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS); - - return(NULL); + } while (dns_message_nextname(msg, section) == ISC_R_SUCCESS); + + return (NULL); } @@ -3349,7 +3326,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) { dns_rdataset_t *rdataset = NULL; dig_message_t * msg; - + for (msg = ISC_LIST_HEAD(chase_message_list2); msg != NULL; msg = ISC_LIST_NEXT(msg, link)) { if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER) @@ -3358,7 +3335,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) type, covers, DNS_SECTION_ANSWER); if (rdataset != NULL) - return rdataset; + return (rdataset); if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY) == ISC_R_SUCCESS) rdataset = @@ -3366,7 +3343,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) type, covers, DNS_SECTION_AUTHORITY); if (rdataset != NULL) - return rdataset; + return (rdataset); if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL) == ISC_R_SUCCESS) rdataset = @@ -3374,16 +3351,15 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) covers, DNS_SECTION_ADDITIONAL); if (rdataset != NULL) - return rdataset; + return (rdataset); } - return NULL; + return (NULL); } dns_rdataset_t * sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, - isc_boolean_t * lookedup, - dns_name_t *rdata_name ) + isc_boolean_t * lookedup, dns_name_t *rdata_name) { dig_lookup_t *lookup; isc_buffer_t *b = NULL; @@ -3392,18 +3368,17 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, dns_rdataset_t * temp; dns_rdatatype_t querytype; - if ((temp=chase_scanname(rdata_name, type, covers))!=NULL) { - return(temp); - } + temp = chase_scanname(rdata_name, type, covers); + if (temp != NULL) + return (temp); - if (*lookedup == ISC_TRUE) { - return(NULL); - } + if (*lookedup == ISC_TRUE) + return (NULL); lookup = clone_lookup(current_lookup, ISC_TRUE); lookup->trace_root = ISC_FALSE; lookup->new_search = ISC_TRUE; - + result = isc_buffer_allocate(mctx, &b, BUFSIZE); check_result(result, "isc_buffer_allocate"); result = dns_name_totext(rdata_name, ISC_FALSE, b); @@ -3417,9 +3392,10 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, querytype = covers; else querytype = type; + if (querytype == 0 || querytype == 255) { printf("Error in the queried type: %d\n", querytype); - return(NULL); + return (NULL); } lookup->rdtype = querytype; @@ -3431,11 +3407,11 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers, printf("\n\nLaunch a query to find a RRset of type "); print_type(type); printf(" for zone: %s\n", lookup->textname); - return(NULL); + return (NULL); } void -insert_trustedkey(dst_key_t * key) +insert_trustedkey(dst_key_t * key) { if (key == NULL) return; @@ -3443,7 +3419,7 @@ insert_trustedkey(dst_key_t * key) return; tk_list.key[tk_list.nb_tk++] = key; - return; + return; } void @@ -3455,8 +3431,7 @@ clean_trustedkey() if (tk_list.key[i] != NULL) { dst_key_free(&tk_list.key[i]); tk_list.key[i] = NULL; - } - else + } else break; } tk_list.nb_tk = 0; @@ -3467,36 +3442,36 @@ char alphnum[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; isc_result_t -removetmpkey(isc_mem_t *mctx, const char *file) +removetmpkey(isc_mem_t *mctx, const char *file) { char *tempnamekey = NULL; int tempnamekeylen; isc_result_t result; - + tempnamekeylen = strlen(file)+10; - + tempnamekey = isc_mem_allocate(mctx, tempnamekeylen); if (tempnamekey == NULL) return (ISC_R_NOMEMORY); memset(tempnamekey, 0, tempnamekeylen); - + strcat(tempnamekey, file); strcat(tempnamekey,".key"); isc_file_remove(tempnamekey); result = isc_file_remove(tempnamekey); isc_mem_free(mctx, tempnamekey); - return(result); + return (result); } isc_result_t opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) { - FILE *f = NULL; - isc_result_t result; - char *tempname = NULL; + FILE *f = NULL; + isc_result_t result; + char *tempname = NULL; char *tempnamekey = NULL; - int tempnamelen; + int tempnamelen; int tempnamekeylen; char *x; char *cp; @@ -3520,14 +3495,14 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) { isc_mem_free(mctx, tempname); return (ISC_R_FAILURE); } - + x = cp--; while (cp >= tempname && *cp == 'X') { isc_random_get(&which); *cp = alphnum[which % (sizeof(alphnum) - 1)]; x = cp--; } - + tempnamekeylen = tempnamelen+5; tempnamekey = isc_mem_allocate(mctx, tempnamekeylen); if (tempnamekey == NULL) @@ -3537,7 +3512,7 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) { strncpy(tempnamekey, tempname, tempnamelen); strcat(tempnamekey ,".key"); - + if (isc_file_exists(tempnamekey)) { isc_mem_free(mctx, tempnamekey); isc_mem_free(mctx, tempname); @@ -3547,19 +3522,19 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) { if ((f = fopen(tempnamekey, "w")) == NULL) { printf("get_trusted_key(): trusted key not found %s\n", tempnamekey); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } break; } isc_mem_free(mctx, tempnamekey); - *tempp = tempname; - *fp = f; - return (ISC_R_SUCCESS); + *tempp = tempname; + *fp = f; + return (ISC_R_SUCCESS); cleanup: - isc_mem_free(mctx, tempname); + isc_mem_free(mctx, tempname); - return (result); + return (result); } @@ -3567,57 +3542,55 @@ isc_result_t get_trusted_key(isc_mem_t *mctx) { isc_result_t result; - const char * filename = NULL; - char * filetemp =NULL; + const char *filename = NULL; + char *filetemp = NULL; char buf[1500]; - FILE *fp , *fptemp; - dst_key_t * key = NULL; - - result = isc_file_exists(trustedkey); + FILE *fp, *fptemp; + dst_key_t *key = NULL; + + result = isc_file_exists(trustedkey); if (result != ISC_TRUE) { - result = isc_file_exists("/etc/trusted-key.key"); + result = isc_file_exists("/etc/trusted-key.key"); if (result != ISC_TRUE) { - result = isc_file_exists("./trusted-key.key"); + result = isc_file_exists("./trusted-key.key"); if (result != ISC_TRUE) - return ISC_R_FAILURE; + return (ISC_R_FAILURE); else filename = "./trusted-key.key"; - } - else + } else filename = "/etc/trusted-key.key"; - } - else + } else filename = trustedkey; if (filename == NULL) { printf("No trusted key\n"); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } if ((fp = fopen(filename, "r")) == NULL) { printf("get_trusted_key(): trusted key not found %s\n", filename); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } while (fgets(buf, 1500, fp) != NULL) { result = opentmpkey(mctx,"tmp_file", &filetemp, &fptemp); if (result != ISC_R_SUCCESS) { fclose(fp); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } - if (fputs(buf, fptemp)<0) { + if (fputs(buf, fptemp) < 0) { fclose(fp); fclose(fptemp); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } fclose(fptemp); result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC, mctx, &key); removetmpkey(mctx, filetemp); isc_mem_free(mctx, filetemp); - if (result != ISC_R_SUCCESS ) { + if (result != ISC_R_SUCCESS) { fclose(fp); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } insert_trustedkey(key); #if 0 @@ -3625,7 +3598,7 @@ get_trusted_key(isc_mem_t *mctx) #endif key = NULL; } - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } @@ -3648,19 +3621,19 @@ nameFromString(const char *str, dns_name_t *p_ret) { check_result(result, "nameFromString"); if (dns_name_dynamic(p_ret)) - dns_name_free(p_ret, mctx); - + free_name(p_ret, mctx); + result = dns_name_dup(dns_fixedname_name(&fixedname), mctx, p_ret); check_result(result, "nameFromString"); -} +} #if DIG_SIGCHASE_TD -isc_result_t +isc_result_t prepare_lookup(dns_name_t *name) { - isc_result_t result; - dig_lookup_t * lookup = NULL; + isc_result_t result; + dig_lookup_t *lookup = NULL; dig_server_t *s; void *ptr; @@ -3674,7 +3647,7 @@ prepare_lookup(dns_name_t *name) lookup->rdtype = lookup->rdtype_sigchase; lookup->rdtypeset = ISC_TRUE; lookup->qrdtype = lookup->qrdtype_sigchase; - + s = ISC_LIST_HEAD(lookup->my_server_list); while (s != NULL) { debug("freeing server %p belonging to %p", @@ -3685,7 +3658,7 @@ prepare_lookup(dns_name_t *name) (dig_server_t *)ptr, link); isc_mem_free(mctx, ptr); } - + for (result = dns_rdataset_first(chase_nsrdataset); result == ISC_R_SUCCESS; @@ -3694,13 +3667,13 @@ prepare_lookup(dns_name_t *name) dns_rdata_ns_t ns; dns_rdata_t rdata = DNS_RDATA_INIT; dig_server_t * srv = NULL; -#define __FOLLOW_GLUE__ +#define __FOLLOW_GLUE__ #ifdef __FOLLOW_GLUE__ - isc_buffer_t * b = NULL; + isc_buffer_t *b = NULL; isc_result_t result; isc_region_t r; - dns_rdataset_t * rdataset =NULL; - isc_boolean_t true = ISC_TRUE; + dns_rdataset_t *rdataset = NULL; + isc_boolean_t true = ISC_TRUE; #endif memset(namestr, 0, DNS_NAME_FORMATSIZE); @@ -3708,11 +3681,11 @@ prepare_lookup(dns_name_t *name) dns_rdataset_current(chase_nsrdataset, &rdata); (void)dns_rdata_tostruct(&rdata, &ns, NULL); - - - + + + #ifdef __FOLLOW_GLUE__ - + result = advanced_rrsearch(&rdataset, &ns.name, dns_rdatatype_aaaa, dns_rdatatype_any, &true); @@ -3736,12 +3709,12 @@ prepare_lookup(dns_name_t *name) srv = make_server(namestr, namestr); - + ISC_LIST_APPEND(lookup->my_server_list, srv, link); } } - + rdataset = NULL; result = advanced_rrsearch(&rdataset, &ns.name, dns_rdatatype_a, dns_rdatatype_any, &true); @@ -3763,28 +3736,28 @@ prepare_lookup(dns_name_t *name) isc_buffer_free(&b); dns_rdata_reset(&a); printf("ns name: %s\n", namestr); - + srv = make_server(namestr, namestr); - + ISC_LIST_APPEND(lookup->my_server_list, srv, link); } } #else - + dns_name_format(&ns.name, namestr, sizeof(namestr)); printf("ns name: "); dns_name_print(&ns.name, stdout); printf("\n"); srv = make_server(namestr, namestr); - + ISC_LIST_APPEND(lookup->my_server_list, srv, link); -#endif +#endif dns_rdata_freestruct(&ns); dns_rdata_reset(&rdata); - + } ISC_LIST_APPEND(lookup_list, lookup, link); @@ -3794,7 +3767,7 @@ prepare_lookup(dns_name_t *name) printf(" with nameservers:"); printf("\n"); print_rdataset(name, chase_nsrdataset, mctx); - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } @@ -3807,15 +3780,14 @@ child_of_zone(dns_name_t * name, dns_name_t * zone_name, unsigned int nlabelsp; name_reln = dns_name_fullcompare(name, zone_name, &orderp, &nlabelsp); - if ( (name_reln != dns_namereln_subdomain) || - (dns_name_countlabels(name) <= - dns_name_countlabels(zone_name) +1)) { + if (name_reln != dns_namereln_subdomain || + dns_name_countlabels(name) <= dns_name_countlabels(zone_name) + 1) { printf("\n;; ERROR : "); dns_name_print(name, stdout); printf(" is not a subdomain of: "); dns_name_print(zone_name, stdout); printf(" FAILED\n\n"); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } dns_name_getlabelsequence(name, @@ -3823,11 +3795,11 @@ child_of_zone(dns_name_t * name, dns_name_t * zone_name, dns_name_countlabels(zone_name) -1, dns_name_countlabels(zone_name) +1, child_name); - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } isc_result_t -grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t * sigrdataset) +grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t *sigrdataset) { isc_result_t result; dns_rdata_t sigrdata; @@ -3836,31 +3808,31 @@ grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t * sigrdataset) result = dns_rdataset_first(sigrdataset); check_result(result, "empty RRSIG dataset"); dns_rdata_init(&sigrdata); - + do { dns_rdataset_current(sigrdataset, &sigrdata); - + result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); check_result(result, "sigrdata tostruct siginfo"); - + if (dns_name_compare(&siginfo.signer, zone_name) == 0) { dns_rdata_freestruct(&siginfo); dns_rdata_reset(&sigrdata); - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } dns_rdata_freestruct(&siginfo); - + } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); dns_rdata_reset(&sigrdata); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } isc_result_t -initialization(dns_name_t * name) +initialization(dns_name_t *name) { isc_result_t result; isc_boolean_t true = ISC_TRUE; @@ -3871,21 +3843,21 @@ initialization(dns_name_t * name) if (result != ISC_R_SUCCESS) { printf("\n;; NS RRset is missing to continue validation:" " FAILED\n\n"); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } INSIST(chase_nsrdataset != NULL); prepare_lookup(name); dup_name(name, &chase_current_name, mctx); - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } -#endif +#endif void -print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx) +print_rdataset(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx) { - isc_buffer_t * b = NULL; + isc_buffer_t *b = NULL; isc_result_t result; isc_region_t r; @@ -3904,16 +3876,22 @@ print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx) } -void +void dup_name(dns_name_t *source, dns_name_t *target, isc_mem_t *mctx) { - isc_result_t result; - + isc_result_t result; + if (dns_name_dynamic(target)) - dns_name_free(target, mctx); + free_name(target, mctx); result = dns_name_dup(source, mctx, target); check_result(result, "dns_name_dup"); } +void +free_name(dns_name_t *name, isc_mem_t *mctx) { + dns_name_free(name, mctx); + dns_name_init(name, NULL); +} + /* * * take a DNSKEY RRset and the RRSIG RRset corresponding in parameter @@ -3931,13 +3909,12 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, { isc_result_t result; dns_rdata_t rdata; - dst_key_t * trustedKey = NULL; - dst_key_t * dnsseckey = NULL; + dst_key_t *trustedKey = NULL; + dst_key_t *dnsseckey = NULL; int i; - - if (name == NULL || rdataset == NULL) { - return ISC_R_FAILURE; - } + + if (name == NULL || rdataset == NULL) + return (ISC_R_FAILURE); result = dns_rdataset_first(rdataset); check_result(result, "empty rdataset"); @@ -3946,13 +3923,13 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, do { dns_rdataset_current(rdataset, &rdata); INSIST(rdata.type == dns_rdatatype_dnskey); - + result = dns_dnssec_keyfromrdata(name, &rdata, mctx, &dnsseckey); check_result(result, "dns_dnssec_keyfromrdata"); - - for (i = 0; i< tk_list.nb_tk; i++) { + + for (i = 0; i < tk_list.nb_tk; i++) { if (dst_key_compare(tk_list.key[i], dnsseckey) == ISC_TRUE) { dns_rdata_reset(&rdata); @@ -3967,11 +3944,11 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, == ISC_R_SUCCESS) { dst_key_free(&dnsseckey); dnsseckey = NULL; - return ISC_R_SUCCESS; + return (ISC_R_SUCCESS); } } } - + dns_rdata_reset(&rdata); if (dnsseckey != NULL) dst_key_free(&dnsseckey); @@ -3980,8 +3957,8 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset, if (trustedKey != NULL) dst_key_free(&trustedKey); trustedKey = NULL; - - return ISC_R_NOTFOUND; + + return (ISC_R_NOTFOUND); } isc_result_t @@ -3992,7 +3969,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, { isc_result_t result; dns_rdata_t keyrdata; - dst_key_t * dnsseckey = NULL; + dst_key_t *dnsseckey = NULL; result = dns_rdataset_first(keyrdataset); check_result(result, "empty DNSKEY dataset"); @@ -4001,7 +3978,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, do { dns_rdataset_current(keyrdataset, &keyrdata); INSIST(keyrdata.type == dns_rdatatype_dnskey); - + result = dns_dnssec_keyfromrdata(name, &keyrdata, mctx, &dnsseckey); check_result(result, "dns_dnssec_keyfromrdata"); @@ -4011,20 +3988,20 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset, if (result == ISC_R_SUCCESS) { dns_rdata_reset(&keyrdata); dst_key_free(&dnsseckey); - return(ISC_R_SUCCESS); + return (ISC_R_SUCCESS); } dst_key_free(&dnsseckey); } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); - + dns_rdata_reset(&keyrdata); - - return ISC_R_NOTFOUND; + + return (ISC_R_NOTFOUND); } isc_result_t sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, - dst_key_t* dnsseckey, - dns_rdataset_t *sigrdataset, isc_mem_t *mctx) + dst_key_t *dnsseckey, dns_rdataset_t *sigrdataset, + isc_mem_t *mctx) { isc_result_t result; dns_rdata_t sigrdata; @@ -4033,22 +4010,22 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, result = dns_rdataset_first(sigrdataset); check_result(result, "empty RRSIG dataset"); dns_rdata_init(&sigrdata); - + do { dns_rdataset_current(sigrdataset, &sigrdata); result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL); check_result(result, "sigrdata tostruct siginfo"); - + /* * Test if the id of the DNSKEY is * the id of the DNSKEY signer's */ if (siginfo.keyid == dst_key_id(dnsseckey)) { - + result = dns_rdataset_first(rdataset); check_result(result, "empty DS dataset"); - + result = dns_dnssec_verify(name, rdataset, dnsseckey, ISC_FALSE, mctx, &sigrdata); @@ -4058,19 +4035,19 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset, dns_name_print(name, stdout); printf(" with DNSKEY:%d: %s\n", dst_key_id(dnsseckey), isc_result_totext(result)); - + if (result == ISC_R_SUCCESS) { dns_rdata_reset(&sigrdata); - return result; + return (result); } } dns_rdata_freestruct(&siginfo); - + } while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS); dns_rdata_reset(&sigrdata); - return ISC_R_NOTFOUND; + return (ISC_R_NOTFOUND); } @@ -4083,7 +4060,7 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdata_t newdsrdata; dns_rdata_t dsrdata; dns_rdata_ds_t dsinfo; - dst_key_t* dnsseckey = NULL; + dst_key_t *dnsseckey = NULL; unsigned char dsbuf[DNS_DS_BUFFERSIZE]; result = dns_rdataset_first(dsrdataset); @@ -4091,18 +4068,18 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdata_init(&dsrdata); do { dns_rdataset_current(dsrdataset, &dsrdata); - + result = dns_rdata_tostruct(&dsrdata, &dsinfo, NULL); check_result(result, "dns_rdata_tostruct for DS"); - + result = dns_rdataset_first(keyrdataset); check_result(result, "empty KEY dataset"); - dns_rdata_init(&keyrdata); + dns_rdata_init(&keyrdata); do { dns_rdataset_current(keyrdataset, &keyrdata); INSIST(keyrdata.type == dns_rdatatype_dnskey); - + result = dns_dnssec_keyfromrdata(name, &keyrdata, mctx, &dnsseckey); check_result(result, "dns_dnssec_keyfromrdata"); @@ -4117,17 +4094,17 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, result = dns_ds_buildrdata(name, &keyrdata, dsinfo.digest_type, dsbuf, &newdsrdata); - dns_rdata_freestruct(&dsinfo); + dns_rdata_freestruct(&dsinfo); if (result != ISC_R_SUCCESS) { dns_rdata_reset(&keyrdata); dns_rdata_reset(&newdsrdata); dns_rdata_reset(&dsrdata); dst_key_free(&dnsseckey); - dns_rdata_freestruct(&dsinfo); + dns_rdata_freestruct(&dsinfo); printf("Oops: impossible to build" " new DS rdata\n"); - return result; + return (result); } @@ -4138,7 +4115,7 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, printf(";; Now verify that this" " DNSKEY validates the " "DNSKEY RRset\n"); - + result = sigchase_verify_sig_key(name, keyrdataset, dnsseckey, @@ -4149,11 +4126,10 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dns_rdata_reset(&newdsrdata); dns_rdata_reset(&dsrdata); dst_key_free(&dnsseckey); - - return result; + + return (result); } - } - else { + } else { printf(";; This DS is NOT the DS for" " the chasing KEY: FAILED\n"); } @@ -4164,13 +4140,13 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, dnsseckey = NULL; } while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS); dns_rdata_reset(&keyrdata); - + } while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS); #if 0 dns_rdata_reset(&dsrdata); WARNING #endif - - return ISC_R_NOTFOUND; + + return (ISC_R_NOTFOUND); } /* @@ -4182,20 +4158,19 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset, * ISC_R_SUCCESS: if we found the rrset * ISC_R_NOTFOUND: we do not found the rrset in cache * and we do a query on the net - * ISC_R_FAILURE: rrset not found + * ISC_R_FAILURE: rrset not found */ isc_result_t -advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t * name, - dns_rdatatype_t type, - dns_rdatatype_t covers, +advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t *name, + dns_rdatatype_t type, dns_rdatatype_t covers, isc_boolean_t *lookedup) -{ +{ isc_boolean_t tmplookedup; INSIST(rdataset != NULL); if (*rdataset != NULL) - return(ISC_R_SUCCESS); + return (ISC_R_SUCCESS); tmplookedup = *lookedup; if ((*rdataset = sigchase_scanname(type, covers, @@ -4205,20 +4180,19 @@ advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t * name, return (ISC_R_NOTFOUND); } *lookedup = ISC_FALSE; - return(ISC_R_SUCCESS); + return (ISC_R_SUCCESS); } #if DIG_SIGCHASE_TD void -sigchase_td(dns_message_t * msg) +sigchase_td(dns_message_t *msg) { - isc_result_t result; - dns_name_t * name = NULL; - isc_boolean_t have_answer = ISC_FALSE; - - isc_boolean_t true = ISC_TRUE; + isc_result_t result; + dns_name_t *name = NULL; + isc_boolean_t have_answer = ISC_FALSE; + isc_boolean_t true = ISC_TRUE; if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER)) == ISC_R_SUCCESS) { @@ -4228,8 +4202,7 @@ sigchase_td(dns_message_t * msg) return; } have_answer = true; - } - else { + } else { if (!current_lookup->trace_root_sigchase) { result = dns_message_firstname(msg, DNS_SECTION_AUTHORITY); @@ -4249,8 +4222,7 @@ sigchase_td(dns_message_t * msg) " in authority section:"); dns_name_print(name, stdout); printf("\n"); - } - else { + } else { printf("no response and no delegation in " "authority section but a reference" " to: "); @@ -4258,17 +4230,16 @@ sigchase_td(dns_message_t * msg) printf("\n"); error_message = msg; } - } - else { + } else { printf(";; NO ANSWERS: %s\n", isc_result_totext(result)); - dns_name_free(&chase_name, mctx); + free_name(&chase_name, mctx); clean_trustedkey(); return; } } - + if (have_answer) { chase_rdataset = chase_scanname_section(msg, &chase_name, @@ -4320,8 +4291,7 @@ sigchase_td(dns_message_t * msg) chase_keyrdataset, chase_sigkeyrdataset, mctx); - } - else { + } else { INSIST(chase_dsrdataset != NULL); INSIST(chase_sigdsrdataset != NULL); result = sigchase_verify_ds(&chase_current_name, @@ -4329,13 +4299,12 @@ sigchase_td(dns_message_t * msg) chase_dsrdataset, mctx); } - + if (result != ISC_R_SUCCESS) { printf("\n;; chain of trust can't be validated:" " FAILED\n\n"); goto cleanandgo; - } - else { + } else { chase_dsrdataset = NULL; chase_sigdsrdataset = NULL; } @@ -4357,9 +4326,8 @@ sigchase_td(dns_message_t * msg) " FAILED\n\n"); goto cleanandgo; } - - } - else { + + } else { result = advanced_rrsearch(&chase_sigrdataset, &chase_authority_name, dns_rdatatype_rrsig, @@ -4383,20 +4351,19 @@ sigchase_td(dns_message_t * msg) chase_sigrdataset = NULL; have_response = ISC_FALSE; have_delegation_ns = ISC_FALSE; - + dns_name_init(&tmp_name, NULL); result = child_of_zone(&chase_name, &chase_current_name, &tmp_name); if (dns_name_dynamic(&chase_authority_name)) - dns_name_free( &chase_authority_name, mctx); + free_name(&chase_authority_name, mctx); dup_name(&tmp_name, &chase_authority_name, mctx); printf(";; and we try to continue chain of trust" " validation of the zone: "); dns_name_print(&chase_authority_name, stdout); printf("\n"); have_delegation_ns = ISC_TRUE; - } - else { + } else { if (have_response) goto finalstep; else @@ -4420,7 +4387,7 @@ sigchase_td(dns_message_t * msg) return; } INSIST(chase_nsrdataset != NULL); - + result = advanced_rrsearch(&chase_dsrdataset, &chase_authority_name, dns_rdatatype_ds, @@ -4463,8 +4430,8 @@ sigchase_td(dns_message_t * msg) } chase_keyrdataset = NULL; chase_sigkeyrdataset = NULL; - - + + prepare_lookup(&chase_authority_name); have_response = ISC_FALSE; @@ -4472,24 +4439,24 @@ sigchase_td(dns_message_t * msg) delegation_follow = ISC_TRUE; error_message = NULL; dup_name(&chase_authority_name, &chase_current_name, mctx); - dns_name_free(&chase_authority_name, mctx); + free_name(&chase_authority_name, mctx); return; } - + if (error_message != NULL) { - dns_rdataset_t * rdataset; - dns_rdataset_t * sigrdataset; - dns_name_t rdata_name; - isc_result_t ret = ISC_R_FAILURE; + dns_rdataset_t *rdataset; + dns_rdataset_t *sigrdataset; + dns_name_t rdata_name; + isc_result_t ret = ISC_R_FAILURE; dns_name_init(&rdata_name, NULL); result = prove_nx(error_message, &chase_name, current_lookup->rdclass_sigchase, current_lookup->rdtype_sigchase, &rdata_name, &rdataset, &sigrdataset); - if (&rdata_name == NULL || rdataset == NULL || - sigrdataset == NULL) { + if (rdataset == NULL || sigrdataset == NULL || + dns_name_countlabels(&rdata_name) == 0) { printf("\n;; Impossible to verify the non-existence," " the NSEC RRset can't be validated:" " FAILED\n\n"); @@ -4499,18 +4466,17 @@ sigchase_td(dns_message_t * msg) chase_keyrdataset, sigrdataset, mctx); if (ret != ISC_R_SUCCESS) { - dns_name_free(&rdata_name, mctx); + free_name(&rdata_name, mctx); printf("\n;; Impossible to verify the NSEC RR to prove" " the non-existence : FAILED\n\n"); goto cleanandgo; } - dns_name_free(&rdata_name, mctx); + free_name(&rdata_name, mctx); if (result != ISC_R_SUCCESS) { printf("\n;; Impossible to verify the non-existence:" " FAILED\n\n"); goto cleanandgo; - } - else { + } else { printf("\n;; OK the query doesn't have response but" " we have validate this fact : SUCCESS\n\n"); goto cleanandgo; @@ -4520,9 +4486,9 @@ sigchase_td(dns_message_t * msg) cleanandgo: printf(";; cleanandgo \n"); if (dns_name_dynamic(&chase_current_name)) - dns_name_free(&chase_current_name, mctx); + free_name(&chase_current_name, mctx); if (dns_name_dynamic(&chase_authority_name)) - dns_name_free(&chase_authority_name, mctx); + free_name(&chase_authority_name, mctx); clean_trustedkey(); return; @@ -4551,8 +4517,7 @@ sigchase_td(dns_message_t * msg) printf("\n"); */ goto cleanandgo; - } - else { + } else { printf("\n;; The Answer:\n"); print_rdataset(&chase_name , chase_rdataset, mctx); @@ -4562,7 +4527,7 @@ sigchase_td(dns_message_t * msg) } } -#endif +#endif #if DIG_SIGCHASE_BU @@ -4579,12 +4544,10 @@ getneededrr(dns_message_t *msg) if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER)) != ISC_R_SUCCESS) { printf(";; NO ANSWERS: %s\n", isc_result_totext(result)); - - if (chase_name.ndata == NULL) { - return ISC_R_ADDRNOTAVAIL; - } - } - else { + + if (chase_name.ndata == NULL) + return (ISC_R_ADDRNOTAVAIL); + } else { dns_message_currentname(msg, DNS_SECTION_ANSWER, &name); } @@ -4595,7 +4558,7 @@ getneededrr(dns_message_t *msg) dns_rdatatype_any, &true); if (result != ISC_R_SUCCESS) { printf("\n;; No Answers: Validation FAILED\n\n"); - return ISC_R_NOTFOUND; + return (ISC_R_NOTFOUND); } dup_name(name, &chase_name, mctx); printf(";; RRset to chase:\n"); @@ -4613,18 +4576,18 @@ getneededrr(dns_message_t *msg) printf("\n;; RRSIG is missing for continue validation:" " FAILED\n\n"); if (dns_name_dynamic(&chase_name)) - dns_name_free(&chase_name, mctx); - return ISC_R_NOTFOUND; + free_name(&chase_name, mctx); + return (ISC_R_NOTFOUND); } if (result == ISC_R_NOTFOUND) { - return(ISC_R_NOTFOUND); + return (ISC_R_NOTFOUND); } printf("\n;; RRSIG of the RRset to chase:\n"); print_rdataset(&chase_name, chase_sigrdataset, mctx); } INSIST(chase_sigrdataset != NULL); - + /* first find the DNSKEY name */ result = dns_rdataset_first(chase_sigrdataset); check_result(result, "empty RRSIG dataset"); @@ -4635,7 +4598,7 @@ getneededrr(dns_message_t *msg) dup_name(&siginfo.signer, &chase_signame, mctx); dns_rdata_freestruct(&siginfo); dns_rdata_reset(&sigrdata); - + /* Do we have a key? */ if (chase_keyrdataset == NULL) { result = advanced_rrsearch(&chase_keyrdataset, @@ -4646,14 +4609,14 @@ getneededrr(dns_message_t *msg) if (result == ISC_R_FAILURE) { printf("\n;; DNSKEY is missing to continue validation:" " FAILED\n\n"); - dns_name_free(&chase_signame, mctx); + free_name(&chase_signame, mctx); if (dns_name_dynamic(&chase_name)) - dns_name_free(&chase_name, mctx); - return ISC_R_NOTFOUND; + free_name(&chase_name, mctx); + return (ISC_R_NOTFOUND); } if (result == ISC_R_NOTFOUND) { - dns_name_free(&chase_signame, mctx); - return(ISC_R_NOTFOUND); + free_name(&chase_signame, mctx); + return (ISC_R_NOTFOUND); } printf("\n;; DNSKEYset that signs the RRset to chase:\n"); print_rdataset(&chase_signame, chase_keyrdataset, mctx); @@ -4669,14 +4632,14 @@ getneededrr(dns_message_t *msg) if (result == ISC_R_FAILURE) { printf("\n;; RRSIG for DNSKEY is missing to continue" " validation : FAILED\n\n"); - dns_name_free(&chase_signame, mctx); + free_name(&chase_signame, mctx); if (dns_name_dynamic(&chase_name)) - dns_name_free(&chase_name, mctx); - return ISC_R_NOTFOUND; + free_name(&chase_name, mctx); + return (ISC_R_NOTFOUND); } if (result == ISC_R_NOTFOUND) { - dns_name_free(&chase_signame, mctx); - return(ISC_R_NOTFOUND); + free_name(&chase_signame, mctx); + return (ISC_R_NOTFOUND); } printf("\n;; RRSIG of the DNSKEYset that signs the " "RRset to chase:\n"); @@ -4696,15 +4659,15 @@ getneededrr(dns_message_t *msg) printf("\n"); } if (result == ISC_R_NOTFOUND) { - dns_name_free(&chase_signame, mctx); - return(ISC_R_NOTFOUND); + free_name(&chase_signame, mctx); + return (ISC_R_NOTFOUND); } if (chase_dsrdataset != NULL) { printf("\n;; DSset of the DNSKEYset\n"); print_rdataset(&chase_signame, chase_dsrdataset, mctx); } } - + if (chase_dsrdataset != NULL) { /* * if there is no RRSIG of DS, @@ -4722,14 +4685,13 @@ getneededrr(dns_message_t *msg) * because the DNSKEY could be a Trusted Key. */ chase_dsrdataset = NULL; - } - else { + } else { printf("\n;; RRSIG of the DSset of the DNSKEYset\n"); print_rdataset(&chase_signame, chase_sigdsrdataset, mctx); } } - return(1); + return (1); } @@ -4748,28 +4710,29 @@ sigchase_bu(dns_message_t *msg) } } - + ret = getneededrr(msg); if (ret == ISC_R_NOTFOUND) return; if (ret == ISC_R_ADDRNOTAVAIL) { /* We have no response */ - dns_rdataset_t * rdataset; - dns_rdataset_t * sigrdataset; - dns_name_t rdata_name; - dns_name_t query_name; + dns_rdataset_t *rdataset; + dns_rdataset_t *sigrdataset; + dns_name_t rdata_name; + dns_name_t query_name; dns_name_init(&query_name, NULL); + dns_name_init(&rdata_name, NULL); nameFromString(current_lookup->textname, &query_name); - + result = prove_nx(msg, &query_name, current_lookup->rdclass, current_lookup->rdtype, &rdata_name, &rdataset, &sigrdataset); - dns_name_free(&query_name, mctx); - if (&rdata_name == NULL || rdataset == NULL || - sigrdataset == NULL) { + free_name(&query_name, mctx); + if (rdataset == NULL || sigrdataset == NULL || + dns_name_countlabels(&rdata_name) == 0) { printf("\n;; Impossible to verify the Non-existence," " the NSEC RRset can't be validated: " "FAILED\n\n"); @@ -4787,7 +4750,7 @@ sigchase_bu(dns_message_t *msg) " Now we want validate this NSEC\n"); dup_name(&rdata_name, &chase_name, mctx); - dns_name_free(&rdata_name, mctx); + free_name(&rdata_name, mctx); chase_rdataset = rdataset; chase_sigrdataset = sigrdataset; chase_keyrdataset = NULL; @@ -4802,7 +4765,7 @@ sigchase_bu(dns_message_t *msg) clean_trustedkey(); return; } - + printf("\n\n\n;; WE HAVE MATERIAL, WE NOW DO VALIDATION\n"); @@ -4810,8 +4773,8 @@ sigchase_bu(dns_message_t *msg) chase_keyrdataset, chase_sigrdataset, mctx); if (result != ISC_R_SUCCESS) { - dns_name_free(&chase_name, mctx); - dns_name_free(&chase_signame, mctx); + free_name(&chase_name, mctx); + free_name(&chase_signame, mctx); printf(";; No DNSKEY is valid to check the RRSIG" " of the RRset: FAILED\n"); clean_trustedkey(); @@ -4822,8 +4785,8 @@ sigchase_bu(dns_message_t *msg) result = contains_trusted_key(&chase_signame, chase_keyrdataset, chase_sigkeyrdataset, mctx); if (result == ISC_R_SUCCESS) { - dns_name_free(&chase_name, mctx); - dns_name_free(&chase_signame, mctx); + free_name(&chase_name, mctx); + free_name(&chase_signame, mctx); printf("\n;; Ok this DNSKEY is a Trusted Key," " DNSSEC validation is ok: SUCCESS\n\n"); clean_trustedkey(); @@ -4833,8 +4796,8 @@ sigchase_bu(dns_message_t *msg) printf(";; Now, we are going to validate this DNSKEY by the DS\n"); if (chase_dsrdataset == NULL) { - dns_name_free(&chase_name, mctx); - dns_name_free(&chase_signame, mctx); + free_name(&chase_name, mctx); + free_name(&chase_signame, mctx); printf(";; the DNSKEY isn't trusted-key and there isn't" " DS to validate the DNSKEY: FAILED\n"); clean_trustedkey(); @@ -4844,21 +4807,20 @@ sigchase_bu(dns_message_t *msg) result = sigchase_verify_ds(&chase_signame, chase_keyrdataset, chase_dsrdataset, mctx); if (result != ISC_R_SUCCESS) { - dns_name_free(&chase_signame, mctx); - dns_name_free(&chase_name, mctx); + free_name(&chase_signame, mctx); + free_name(&chase_name, mctx); printf(";; ERROR no DS validates a DNSKEY in the" " DNSKEY RRset: FAILED\n"); clean_trustedkey(); return; - } - else + } else printf(";; OK this DNSKEY (validated by the DS) validates" " the RRset of the DNSKEYs, thus the DNSKEY validates" " the RRset\n"); INSIST(chase_sigdsrdataset != NULL); dup_name(&chase_signame, &chase_name, mctx); - dns_name_free(&chase_signame, mctx); + free_name(&chase_signame, mctx); chase_rdataset = chase_dsrdataset; chase_sigrdataset = chase_sigdsrdataset; chase_keyrdataset = NULL; @@ -4867,7 +4829,7 @@ sigchase_bu(dns_message_t *msg) chase_sigdsrdataset = NULL; chase_siglookedup = chase_keylookedup = ISC_FALSE; chase_dslookedup = chase_sigdslookedup = ISC_FALSE; - + printf(";; Now, we want to validate the DS : recursive call\n"); sigchase(msg); return; @@ -4875,8 +4837,7 @@ sigchase_bu(dns_message_t *msg) #endif void -sigchase(dns_message_t * msg) -{ +sigchase(dns_message_t *msg) { #if DIG_SIGCHASE_TD if (current_lookup->do_topdown) { sigchase_td(msg); @@ -4892,12 +4853,12 @@ sigchase(dns_message_t * msg) /* * return 1 if name1 < name2 - * 0 if name1 == name2 - * -1 if name1 > name2 + * 0 if name1 == name2 + * -1 if name1 > name2 * and -2 if problem */ int -inf_name(dns_name_t * name1, dns_name_t * name2) +inf_name(dns_name_t *name1, dns_name_t *name2) { dns_label_t label1; dns_label_t label2; @@ -4920,19 +4881,19 @@ inf_name(dns_name_t * name1, dns_name_t * name2) dns_name_getlabel(name1, nblabel1 -1 - i, &label1); dns_name_getlabel(name2, nblabel2 -1 - i, &label2); if ((ret = isc_region_compare(&label1, &label2)) != 0) { - if (ret <0 ) - return -1; - else if (ret >0 ) - return 1; + if (ret < 0) + return (-1); + else if (ret > 0) + return (1); } } if (nblabel1 == nblabel2) - return 0; + return (0); if (nblabel1 < nblabel2) - return -1; + return (-1); else - return 1; + return (1); } /** @@ -4944,24 +4905,24 @@ isc_result_t prove_nx_domain(dns_message_t *msg, dns_name_t *name, dns_name_t *rdata_name, - dns_rdataset_t ** rdataset, + dns_rdataset_t **rdataset, dns_rdataset_t **sigrdataset) { - isc_result_t ret = ISC_R_FAILURE; - isc_result_t result = ISC_R_NOTFOUND; - dns_rdataset_t * nsecset = NULL; - dns_rdataset_t * signsecset = NULL ; - dns_rdata_t nsec = DNS_RDATA_INIT; - dns_name_t * nsecname; - dns_rdata_nsec_t nsecstruct; - + isc_result_t ret = ISC_R_FAILURE; + isc_result_t result = ISC_R_NOTFOUND; + dns_rdataset_t *nsecset = NULL; + dns_rdataset_t *signsecset = NULL ; + dns_rdata_t nsec = DNS_RDATA_INIT; + dns_name_t *nsecname; + dns_rdata_nsec_t nsecstruct; + if ((result = dns_message_firstname(msg, DNS_SECTION_AUTHORITY)) != ISC_R_SUCCESS) { printf(";; nothing in authority section : impossible to" " validate the non-existence : FAILED\n"); - return(ISC_R_FAILURE); + return (ISC_R_FAILURE); } - + do { nsecname = NULL; dns_message_currentname(msg, DNS_SECTION_AUTHORITY, &nsecname); @@ -4989,7 +4950,7 @@ prove_nx_domain(dns_message_t *msg, printf(";; no RRSIG NSEC in authority section:" " impossible to validate the " "non-existence: FAILED\n"); - return(ISC_R_FAILURE); + return (ISC_R_FAILURE); } ret = dns_rdata_tostruct(&nsec, &nsecstruct, NULL); @@ -5003,8 +4964,8 @@ prove_nx_domain(dns_message_t *msg, *rdataset = nsecset; *sigrdataset = signsecset; dup_name(nsecname, rdata_name, mctx); - - return ISC_R_SUCCESS; + + return (ISC_R_SUCCESS); } dns_rdata_freestruct(&nsecstruct); @@ -5015,7 +4976,7 @@ prove_nx_domain(dns_message_t *msg, *rdataset = NULL; *sigrdataset = NULL; rdata_name = NULL; - return(ISC_R_FAILURE); + return (ISC_R_FAILURE); } /** @@ -5026,27 +4987,22 @@ prove_nx_domain(dns_message_t *msg, * */ isc_result_t -prove_nx_type(dns_message_t * msg, - dns_name_t *name, - dns_rdataset_t *nsecset, - dns_rdataclass_t class, - dns_rdatatype_t type, - dns_name_t * rdata_name, - dns_rdataset_t ** rdataset, - dns_rdataset_t ** sigrdataset) +prove_nx_type(dns_message_t *msg, dns_name_t *name, dns_rdataset_t *nsecset, + dns_rdataclass_t class, dns_rdatatype_t type, + dns_name_t *rdata_name, dns_rdataset_t **rdataset, + dns_rdataset_t **sigrdataset) { - isc_result_t ret; - dns_rdataset_t * signsecset; - dns_rdata_t nsec = DNS_RDATA_INIT; + isc_result_t ret; + dns_rdataset_t *signsecset; + dns_rdata_t nsec = DNS_RDATA_INIT; UNUSED(class); - UNUSED(rdata_name); - + ret = dns_rdataset_first(nsecset); check_result(ret,"dns_rdataset_first"); dns_rdataset_current(nsecset, &nsec); - + ret = dns_nsec_typepresent(&nsec, type); if (ret == ISC_R_SUCCESS) printf("OK the NSEC said that the type doesn't exist \n"); @@ -5057,8 +5013,9 @@ prove_nx_type(dns_message_t * msg, DNS_SECTION_AUTHORITY); if (signsecset == NULL) { printf("There isn't RRSIG NSEC for the zone \n"); - return ISC_R_FAILURE; + return (ISC_R_FAILURE); } + dup_name(name, rdata_name, mctx); *rdataset = nsecset; *sigrdataset = signsecset; @@ -5072,17 +5029,12 @@ prove_nx_type(dns_message_t * msg, * */ isc_result_t -prove_nx(dns_message_t * msg, - dns_name_t * name, - dns_rdataclass_t class, - dns_rdatatype_t type, - dns_name_t * rdata_name, - dns_rdataset_t ** rdataset, - dns_rdataset_t ** sigrdataset) +prove_nx(dns_message_t *msg, dns_name_t *name, dns_rdataclass_t class, + dns_rdatatype_t type, dns_name_t *rdata_name, + dns_rdataset_t **rdataset, dns_rdataset_t **sigrdataset) { isc_result_t ret; - dns_rdataset_t * nsecset = NULL; - + dns_rdataset_t *nsecset = NULL; printf("We want to prove the non-existance of a type of rdata %d" " or of the zone: \n", type); @@ -5091,7 +5043,7 @@ prove_nx(dns_message_t * msg, != ISC_R_SUCCESS) { printf(";; nothing in authority section : impossible to" " validate the non-existence : FAILED\n"); - return(ISC_R_FAILURE); + return (ISC_R_FAILURE); } nsecset = chase_scanname_section(msg, name, dns_rdatatype_nsec, @@ -5104,18 +5056,17 @@ prove_nx(dns_message_t * msg, sigrdataset); if (ret != ISC_R_SUCCESS) { printf("prove_nx: ERROR type exist\n"); - return(ret); + return (ret); } else { printf("prove_nx: OK type does not exist\n"); - return(ISC_R_SUCCESS); + return (ISC_R_SUCCESS); } } else { printf("there is no NSEC for this zone: validating " "that the zone doesn't exist\n"); ret = prove_nx_domain(msg, name, rdata_name, rdataset, sigrdataset); - return(ret); + return (ret); } - /* Never get here */ } #endif diff --git a/contrib/bind9/bin/dig/host.1 b/contrib/bind9/bin/dig/host.1 index c93ab184b57..cf44a5c3f35 100644 --- a/contrib/bind9/bin/dig/host.1 +++ b/contrib/bind9/bin/dig/host.1 @@ -1,132 +1,181 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2002 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000-2002 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, +.\" 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: host.1,v 1.11.2.1.4.4 2004/04/13 04:11:03 marka Exp $ +.\" $Id: host.1,v 1.11.2.1.4.7 2005/10/13 02:33:43 marka Exp $ .\" -.TH "HOST" "1" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "HOST" "1" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" host \- DNS lookup utility -.SH SYNOPSIS -.sp -\fBhost\fR [ \fB-aCdlnrTwv\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-N \fIndots\fB\fR ] [ \fB-R \fInumber\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-W \fIwait\fB\fR ] [ \fB-4\fR ] [ \fB-6\fR ] \fBname\fR [ \fBserver\fR ] +.SH "SYNOPSIS" +.HP 5 +\fBhost\fR [\fB\-aCdlnrTwv\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-N\ \fR\fB\fIndots\fR\fR] [\fB\-R\ \fR\fB\fInumber\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-W\ \fR\fB\fIwait\fR\fR] [\fB\-4\fR] [\fB\-6\fR] {name} [server] .SH "DESCRIPTION" .PP \fBhost\fR -is a simple utility for performing DNS lookups. -It is normally used to convert names to IP addresses and vice versa. -When no arguments or options are given, +is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given, \fBhost\fR prints a short summary of its command line arguments and options. .PP -\fIname\fR is the domain name that is to be looked -up. It can also be a dotted-decimal IPv4 address or a colon-delimited -IPv6 address, in which case \fBhost\fR will by default -perform a reverse lookup for that address. -\fIserver\fR is an optional argument which is either -the name or IP address of the name server that \fBhost\fR +\fIname\fR +is the domain name that is to be looked up. It can also be a dotted\-decimal IPv4 address or a colon\-delimited IPv6 address, in which case +\fBhost\fR +will by default perform a reverse lookup for that address. +\fIserver\fR +is an optional argument which is either the name or IP address of the name server that +\fBhost\fR should query instead of the server or servers listed in \fI/etc/resolv.conf\fR. .PP -The \fB-a\fR (all) option is equivalent to setting the -\fB-v\fR option and asking \fBhost\fR to make -a query of type ANY. +The +\fB\-a\fR +(all) option is equivalent to setting the +\fB\-v\fR +option and asking +\fBhost\fR +to make a query of type ANY. .PP -When the \fB-C\fR option is used, \fBhost\fR +When the +\fB\-C\fR +option is used, +\fBhost\fR will attempt to display the SOA records for zone -\fIname\fR from all the listed authoritative name -servers for that zone. The list of name servers is defined by the NS -records that are found for the zone. +\fIname\fR +from all the listed authoritative name servers for that zone. The list of name servers is defined by the NS records that are found for the zone. .PP -The \fB-c\fR option instructs to make a DNS query of class -\fIclass\fR. This can be used to lookup Hesiod or -Chaosnet class resource records. The default class is IN (Internet). +The +\fB\-c\fR +option instructs to make a DNS query of class +\fIclass\fR. This can be used to lookup Hesiod or Chaosnet class resource records. The default class is IN (Internet). .PP -Verbose output is generated by \fBhost\fR when the -\fB-d\fR or \fB-v\fR option is used. The two -options are equivalent. They have been provided for backwards -compatibility. In previous versions, the \fB-d\fR option -switched on debugging traces and \fB-v\fR enabled verbose -output. +Verbose output is generated by +\fBhost\fR +when the +\fB\-d\fR +or +\fB\-v\fR +option is used. The two options are equivalent. They have been provided for backwards compatibility. In previous versions, the +\fB\-d\fR +option switched on debugging traces and +\fB\-v\fR +enabled verbose output. .PP -List mode is selected by the \fB-l\fR option. This makes -\fBhost\fR perform a zone transfer for zone -\fIname\fR. Transfer the zone printing out the NS, PTR -and address records (A/AAAA). If combined with \fB-a\fR -all records will be printed. +List mode is selected by the +\fB\-l\fR +option. This makes +\fBhost\fR +perform a zone transfer for zone +\fIname\fR. Transfer the zone printing out the NS, PTR and address records (A/AAAA). If combined with +\fB\-a\fR +all records will be printed. .PP -The \fB-i\fR -option specifies that reverse lookups of IPv6 addresses should -use the IP6.INT domain as defined in RFC1886. -The default is to use IP6.ARPA. +The +\fB\-i\fR +option specifies that reverse lookups of IPv6 addresses should use the IP6.INT domain as defined in RFC1886. The default is to use IP6.ARPA. .PP -The \fB-N\fR option sets the number of dots that have to be -in \fIname\fR for it to be considered absolute. The -default value is that defined using the ndots statement in -\fI/etc/resolv.conf\fR, or 1 if no ndots statement is -present. Names with fewer dots are interpreted as relative names and -will be searched for in the domains listed in the \fBsearch\fR -or \fBdomain\fR directive in +The +\fB\-N\fR +option sets the number of dots that have to be in +\fIname\fR +for it to be considered absolute. The default value is that defined using the ndots statement in +\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the +\fBsearch\fR +or +\fBdomain\fR +directive in \fI/etc/resolv.conf\fR. .PP The number of UDP retries for a lookup can be changed with the -\fB-R\fR option. \fInumber\fR indicates -how many times \fBhost\fR will repeat a query that does -not get answered. The default number of retries is 1. If -\fInumber\fR is negative or zero, the number of -retries will default to 1. +\fB\-R\fR +option. +\fInumber\fR +indicates how many times +\fBhost\fR +will repeat a query that does not get answered. The default number of retries is 1. If +\fInumber\fR +is negative or zero, the number of retries will default to 1. .PP -Non-recursive queries can be made via the \fB-r\fR option. -Setting this option clears the \fBRD\fR \(em recursion -desired \(em bit in the query which \fBhost\fR makes. -This should mean that the name server receiving the query will not -attempt to resolve \fIname\fR. The -\fB-r\fR option enables \fBhost\fR to mimic -the behaviour of a name server by making non-recursive queries and -expecting to receive answers to those queries that are usually -referrals to other name servers. +Non\-recursive queries can be made via the +\fB\-r\fR +option. Setting this option clears the +\fBRD\fR +\(em recursion desired \(em bit in the query which +\fBhost\fR +makes. This should mean that the name server receiving the query will not attempt to resolve +\fIname\fR. The +\fB\-r\fR +option enables +\fBhost\fR +to mimic the behaviour of a name server by making non\-recursive queries and expecting to receive answers to those queries that are usually referrals to other name servers. .PP -By default \fBhost\fR uses UDP when making queries. The -\fB-T\fR option makes it use a TCP connection when querying -the name server. TCP will be automatically selected for queries that -require it, such as zone transfer (AXFR) requests. +By default +\fBhost\fR +uses UDP when making queries. The +\fB\-T\fR +option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that require it, such as zone transfer (AXFR) requests. .PP -The \fB-4\fR option forces \fBhost\fR to only -use IPv4 query transport. The \fB-6\fR option forces -\fBhost\fR to only use IPv6 query transport. +The +\fB\-4\fR +option forces +\fBhost\fR +to only use IPv4 query transport. The +\fB\-6\fR +option forces +\fBhost\fR +to only use IPv6 query transport. .PP -The \fB-t\fR option is used to select the query type. -\fItype\fR can be any recognised query type: CNAME, -NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, -\fBhost\fR automatically selects an appropriate query -type. By default it looks for A records, but if the -\fB-C\fR option was given, queries will be made for SOA -records, and if \fIname\fR is a dotted-decimal IPv4 -address or colon-delimited IPv6 address, \fBhost\fR will -query for PTR records. If a query type of IXFR is chosen the starting -serial number can be specified by appending an equal followed by the -starting serial number (e.g. -t IXFR=12345678). +The +\fB\-t\fR +option is used to select the query type. +\fItype\fR +can be any recognised query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, +\fBhost\fR +automatically selects an appropriate query type. By default it looks for A records, but if the +\fB\-C\fR +option was given, queries will be made for SOA records, and if +\fIname\fR +is a dotted\-decimal IPv4 address or colon\-delimited IPv6 address, +\fBhost\fR +will query for PTR records. If a query type of IXFR is chosen the starting serial number can be specified by appending an equal followed by the starting serial number (e.g. \-t IXFR=12345678). .PP The time to wait for a reply can be controlled through the -\fB-W\fR and \fB-w\fR options. The -\fB-W\fR option makes \fBhost\fR wait for -\fIwait\fR seconds. If \fIwait\fR +\fB\-W\fR +and +\fB\-w\fR +options. The +\fB\-W\fR +option makes +\fBhost\fR +wait for +\fIwait\fR +seconds. If +\fIwait\fR is less than one, the wait interval is set to one second. When the -\fB-w\fR option is used, \fBhost\fR will -effectively wait forever for a reply. The time to wait for a response -will be set to the number of seconds given by the hardware's maximum -value for an integer quantity. +\fB\-w\fR +option is used, +\fBhost\fR +will effectively wait forever for a reply. The time to wait for a response will be set to the number of seconds given by the hardware's maximum value for an integer quantity. .SH "FILES" .PP \fI/etc/resolv.conf\fR diff --git a/contrib/bind9/bin/dig/host.c b/contrib/bind9/bin/dig/host.c index b8f2d937933..468d53bf944 100644 --- a/contrib/bind9/bin/dig/host.c +++ b/contrib/bind9/bin/dig/host.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: host.c,v 1.76.2.5.2.10 2004/09/06 01:33:05 marka Exp $ */ +/* $Id: host.c,v 1.76.2.5.2.13 2005/07/04 03:29:45 marka Exp $ */ #include #include @@ -40,21 +40,6 @@ #include -extern ISC_LIST(dig_lookup_t) lookup_list; -extern dig_serverlist_t server_list; -extern ISC_LIST(dig_searchlist_t) search_list; - -extern isc_boolean_t have_ipv4, have_ipv6; -extern isc_boolean_t usesearch; -extern isc_boolean_t debugging; -extern unsigned int timeout; -extern isc_mem_t *mctx; -extern int ndots; -extern int tries; -extern char *progname; -extern isc_task_t *global_task; -extern int fatalexit; - static isc_boolean_t short_form = ISC_TRUE, listed_server = ISC_FALSE; static isc_boolean_t default_lookups = ISC_TRUE; static int seen_error = -1; @@ -604,6 +589,7 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) { } else list_type = rdtype; list_addresses = ISC_FALSE; + default_lookups = ISC_FALSE; break; case 'c': tr.base = isc_commandline_argument; diff --git a/contrib/bind9/bin/dig/host.docbook b/contrib/bind9/bin/dig/host.docbook index 561f7c4397d..2b6e92b76d4 100644 --- a/contrib/bind9/bin/dig/host.docbook +++ b/contrib/bind9/bin/dig/host.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -30,6 +32,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + Internet Software Consortium. + + + host DNS lookup utility @@ -46,8 +62,8 @@ - name - server + name + server diff --git a/contrib/bind9/bin/dig/host.html b/contrib/bind9/bin/dig/host.html index fb011c033b9..7670868ceed 100644 --- a/contrib/bind9/bin/dig/host.html +++ b/contrib/bind9/bin/dig/host.html @@ -1,434 +1,171 @@ - - - - -host

host

Name

host -- DNS lookup utility

Synopsis

host [-aCdlnrTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait] [-4] [-6] {name} [server]

DESCRIPTION

host + + + + +host + + +

+
+
+

Name

+

host — DNS lookup utility

+
+
+

Synopsis

+

host [-aCdlnrTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait] [-4] [-6] {name} [server]

+
+
+

DESCRIPTION

+

+host is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given, -host -prints a short summary of its command line arguments and options.

name is the domain name that is to be looked +host +prints a short summary of its command line arguments and options. +

+

+name is the domain name that is to be looked up. It can also be a dotted-decimal IPv4 address or a colon-delimited -IPv6 address, in which case host will by default +IPv6 address, in which case host will by default perform a reverse lookup for that address. -server is an optional argument which is either -the name or IP address of the name server that host +server is an optional argument which is either +the name or IP address of the name server that host should query instead of the server or servers listed in -/etc/resolv.conf.

The -a (all) option is equivalent to setting the --v option and asking host to make -a query of type ANY.

When the -C option is used, host +/etc/resolv.conf. +

+

+The -a (all) option is equivalent to setting the +-v option and asking host to make +a query of type ANY. +

+

+When the -C option is used, host will attempt to display the SOA records for zone -name from all the listed authoritative name +name from all the listed authoritative name servers for that zone. The list of name servers is defined by the NS -records that are found for the zone.

The -c option instructs to make a DNS query of class -class. This can be used to lookup Hesiod or -Chaosnet class resource records. The default class is IN (Internet).

Verbose output is generated by host when the --d or -v option is used. The two +records that are found for the zone. +

+

+The -c option instructs to make a DNS query of class +class. This can be used to lookup Hesiod or +Chaosnet class resource records. The default class is IN (Internet). +

+

+Verbose output is generated by host when the +-d or -v option is used. The two options are equivalent. They have been provided for backwards -compatibility. In previous versions, the -d option -switched on debugging traces and -v enabled verbose -output.

List mode is selected by the -l option. This makes -host perform a zone transfer for zone -name. Transfer the zone printing out the NS, PTR -and address records (A/AAAA). If combined with -a -all records will be printed.

The -i +compatibility. In previous versions, the -d option +switched on debugging traces and -v enabled verbose +output. +

+

+List mode is selected by the -l option. This makes +host perform a zone transfer for zone +name. Transfer the zone printing out the NS, PTR +and address records (A/AAAA). If combined with -a +all records will be printed. +

+

+The -i option specifies that reverse lookups of IPv6 addresses should use the IP6.INT domain as defined in RFC1886. -The default is to use IP6.ARPA.

The -N option sets the number of dots that have to be -in name for it to be considered absolute. The +The default is to use IP6.ARPA. +

+

+The -N option sets the number of dots that have to be +in name for it to be considered absolute. The default value is that defined using the ndots statement in -/etc/resolv.conf, or 1 if no ndots statement is +/etc/resolv.conf, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and -will be searched for in the domains listed in the search -or domain directive in -/etc/resolv.conf.

The number of UDP retries for a lookup can be changed with the --R option. number indicates -how many times host will repeat a query that does +will be searched for in the domains listed in the search +or domain directive in +/etc/resolv.conf. +

+

+The number of UDP retries for a lookup can be changed with the +-R option. number indicates +how many times host will repeat a query that does not get answered. The default number of retries is 1. If -number is negative or zero, the number of -retries will default to 1.

Non-recursive queries can be made via the -r option. -Setting this option clears the RD — recursion -desired — bit in the query which host makes. +number is negative or zero, the number of +retries will default to 1. +

+

+Non-recursive queries can be made via the -r option. +Setting this option clears the RD — recursion +desired — bit in the query which host makes. This should mean that the name server receiving the query will not -attempt to resolve name. The --r option enables host to mimic +attempt to resolve name. The +-r option enables host to mimic the behaviour of a name server by making non-recursive queries and expecting to receive answers to those queries that are usually -referrals to other name servers.

By default host uses UDP when making queries. The --T option makes it use a TCP connection when querying +referrals to other name servers. +

+

+By default host uses UDP when making queries. The +-T option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that -require it, such as zone transfer (AXFR) requests.

The -4 option forces host to only -use IPv4 query transport. The -6 option forces -host to only use IPv6 query transport.

The -t option is used to select the query type. -type can be any recognised query type: CNAME, +require it, such as zone transfer (AXFR) requests. +

+

+The -4 option forces host to only +use IPv4 query transport. The -6 option forces +host to only use IPv6 query transport. +

+

+The -t option is used to select the query type. +type can be any recognised query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified, -host automatically selects an appropriate query +host automatically selects an appropriate query type. By default it looks for A records, but if the --C option was given, queries will be made for SOA -records, and if name is a dotted-decimal IPv4 -address or colon-delimited IPv6 address, host will +-C option was given, queries will be made for SOA +records, and if name is a dotted-decimal IPv4 +address or colon-delimited IPv6 address, host will query for PTR records. If a query type of IXFR is chosen the starting serial number can be specified by appending an equal followed by the -starting serial number (e.g. -t IXFR=12345678).

The time to wait for a reply can be controlled through the --W and -w options. The --W option makes host wait for -wait seconds. If wait +starting serial number (e.g. -t IXFR=12345678). +

+

+The time to wait for a reply can be controlled through the +-W and -w options. The +-W option makes host wait for +wait seconds. If wait is less than one, the wait interval is set to one second. When the --w option is used, host will +-w option is used, host will effectively wait forever for a reply. The time to wait for a response will be set to the number of seconds given by the hardware's maximum -value for an integer quantity.

FILES

/etc/resolv.conf

SEE ALSO

dig(1), -named(8).

+value for an integer quantity. +

+
+
+

FILES

+

+/etc/resolv.conf +

+
+
+

SEE ALSO

+

+dig(1), +named(8). +

+
+
+ diff --git a/contrib/bind9/bin/dig/include/dig/dig.h b/contrib/bind9/bin/dig/include/dig/dig.h index 4e88b15336e..431d109cf08 100644 --- a/contrib/bind9/bin/dig/include/dig/dig.h +++ b/contrib/bind9/bin/dig/include/dig/dig.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dig.h,v 1.71.2.6.2.7 2004/09/06 01:33:06 marka Exp $ */ +/* $Id: dig.h,v 1.71.2.6.2.11 2005/07/04 03:29:45 marka Exp $ */ #ifndef DIG_H #define DIG_H @@ -35,7 +35,7 @@ #include #include -#define MXSERV 6 +#define MXSERV 20 #define MXNAME (DNS_NAME_MAXTEXT+1) #define MXRD 32 #define BUFSIZE 512 @@ -66,14 +66,6 @@ * in a tight loop of constant lookups. It's value is arbitrary. */ -#define ROOTNS 1 -/* - * Set the number of root servers to ask for information when running in - * trace mode. - * XXXMWS -- trace mode is currently semi-broken, and this number *MUST* - * be 1. - */ - /* * Defaults for the sigchase suboptions. Consolidated here because * these control the layout of dig_lookup_t (among other things). @@ -224,6 +216,46 @@ struct dig_message { ISC_LINK(dig_message_t) link; }; #endif + +typedef ISC_LIST(dig_searchlist_t) dig_searchlistlist_t; +typedef ISC_LIST(dig_lookup_t) dig_lookuplist_t; + +/* + * Externals from dighost.c + */ + +extern dig_lookuplist_t lookup_list; +extern dig_serverlist_t server_list; +extern dig_searchlistlist_t search_list; + +extern isc_boolean_t have_ipv4, have_ipv6, specified_source, + usesearch, qr; +extern in_port_t port; +extern unsigned int timeout; +extern isc_mem_t *mctx; +extern dns_messageid_t id; +extern int sendcount; +extern int ndots; +extern int lookup_counter; +extern int exitcode; +extern isc_sockaddr_t bind_address; +extern char keynametext[MXNAME]; +extern char keyfile[MXNAME]; +extern char keysecret[MXNAME]; +#ifdef DIG_SIGCHASE +extern char trustedkey[MXNAME]; +#endif +extern dns_tsigkey_t *key; +extern isc_boolean_t validated; +extern isc_taskmgr_t *taskmgr; +extern isc_task_t *global_task; +extern isc_boolean_t free_now; +extern isc_boolean_t debugging, memdebugging; + +extern char *progname; +extern int tries; +extern int fatalexit; + /* * Routines in dighost.c. */ diff --git a/contrib/bind9/bin/dig/nslookup.1 b/contrib/bind9/bin/dig/nslookup.1 index 71aa8a131e4..3de04ca4f91 100644 --- a/contrib/bind9/bin/dig/nslookup.1 +++ b/contrib/bind9/bin/dig/nslookup.1 @@ -1,76 +1,72 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" +.\" Copyright (C) 2004, 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, +.\" 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: nslookup.1,v 1.1.6.2 2004/08/20 02:29:39 marka Exp $ +.\" $Id: nslookup.1,v 1.1.6.5 2005/10/13 02:33:43 marka Exp $ .\" -.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" nslookup \- query Internet name servers interactively -.SH SYNOPSIS -.sp -\fBnslookup\fR [ \fB-option\fR ] [ \fBname | -\fR ] [ \fBserver\fR ] +.SH "SYNOPSIS" +.HP 9 +\fBnslookup\fR [\fB\-option\fR] [name\ |\ \-] [server] .SH "DESCRIPTION" .PP \fBNslookup\fR -is a program to query Internet domain name servers. \fBNslookup\fR -has two modes: interactive and non-interactive. Interactive mode allows -the user to query name servers for information about various hosts and -domains or to print a list of hosts in a domain. Non-interactive mode is -used to print just the name and requested information for a host or -domain. +is a program to query Internet domain name servers. +\fBNslookup\fR +has two modes: interactive and non\-interactive. Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain. Non\-interactive mode is used to print just the name and requested information for a host or domain. .SH "ARGUMENTS" .PP Interactive mode is entered in the following cases: -.IP 1. +.TP 3 +1. when no arguments are given (the default name server will be used) -.IP 2. -when the first argument is a hyphen (-) and the second argument is -the host name or Internet address of a name server. +.TP +2. +when the first argument is a hyphen (\-) and the second argument is the host name or Internet address of a name server. .PP -Non-interactive mode is used when the name or Internet address of the -host to be looked up is given as the first argument. The optional second -argument specifies the host name or address of a name server. +Non\-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument. The optional second argument specifies the host name or address of a name server. .PP -Options can also be specified on the command line if they precede the -arguments and are prefixed with a hyphen. For example, to -change the default query type to host information, and the initial timeout to 10 seconds, type: -.PP -.sp -.nf -nslookup -query=hinfo -timeout=10 -.sp -.fi +Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen. For example, to change the default query type to host information, and the initial timeout to 10 seconds, type: +.IP .sp .nf nslookup \-query=hinfo \-timeout=10 .fi .SH "INTERACTIVE COMMANDS" .TP -\fBhost [server]\fR -Look up information for host using the current default server or -using server, if specified. If host is an Internet address and -the query type is A or PTR, the name of the host is returned. -If host is a name and does not have a trailing period, the -search list is used to qualify the name. - -To look up a host not in the current domain, append a period to -the name. +host [server] +Look up information for host using the current default server or using server, if specified. If host is an Internet address and the query type is A or PTR, the name of the host is returned. If host is a name and does not have a trailing period, the search list is used to qualify the name. +.sp +To look up a host not in the current domain, append a period to the name. .TP -\fBserver \fIdomain\fB\fR +\fBserver\fR \fIdomain\fR .TP -\fBlserver \fIdomain\fB\fR -Change the default server to \fIdomain\fR; lserver uses the initial -server to look up information about \fIdomain\fR, while server uses -the current default server. If an authoritative answer can't be -found, the names of servers that might have the answer are -returned. +\fBlserver\fR \fIdomain\fR +Change the default server to +\fIdomain\fR; +\fBlserver\fR +uses the initial server to look up information about +\fIdomain\fR, while +\fBserver\fR +uses the current default server. If an authoritative answer can't be found, the names of servers that might have the answer are returned. .TP \fBroot\fR not implemented @@ -93,17 +89,15 @@ not implemented \fBexit\fR Exits the program. .TP -\fBset \fIkeyword[=value]\fB\fR -This command is used to change state information that affects -the lookups. Valid keywords are: +\fBset\fR \fIkeyword\fR\fI[=value]\fR +This command is used to change state information that affects the lookups. Valid keywords are: .RS .TP \fBall\fR -Prints the current values of the frequently used -options to \fBset\fR. Information about the current default -server and host is also printed. +Prints the current values of the frequently used options to +\fBset\fR. Information about the current default server and host is also printed. .TP -\fBclass=\fIvalue\fB\fR +\fBclass=\fR\fIvalue\fR Change the query class to one of: .RS .TP @@ -119,66 +113,61 @@ the Hesiod class \fBANY\fR wildcard .RE -.PP +.IP The class specifies the protocol group of the information. - +.sp (Default = IN; abbreviation = cl) .TP -\fB\fI[no]\fBdebug\fR -Turn debugging mode on. A lot more information is -printed about the packet sent to the server and the -resulting answer. - -(Default = nodebug; abbreviation = [no]deb) +\fB\fI[no]\fR\fR\fBdebug\fR +Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer. +.sp +(Default = nodebug; abbreviation = +[no]deb) .TP -\fB\fI[no]\fBd2\fR -Turn debugging mode on. A lot more information is -printed about the packet sent to the server and the -resulting answer. - +\fB\fI[no]\fR\fR\fBd2\fR +Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer. +.sp (Default = nod2) .TP -\fBdomain=\fIname\fB\fR -Sets the search list to \fIname\fR. +\fBdomain=\fR\fIname\fR +Sets the search list to +\fIname\fR. .TP -\fB\fI[no]\fBsearch\fR -If the lookup request contains at least one period but -doesn't end with a trailing period, append the domain -names in the domain search list to the request until an -answer is received. - +\fB\fI[no]\fR\fR\fBsearch\fR +If the lookup request contains at least one period but doesn't end with a trailing period, append the domain names in the domain search list to the request until an answer is received. +.sp (Default = search) .TP -\fBport=\fIvalue\fB\fR -Change the default TCP/UDP name server port to \fIvalue\fR. - +\fBport=\fR\fIvalue\fR +Change the default TCP/UDP name server port to +\fIvalue\fR. +.sp (Default = 53; abbreviation = po) .TP -\fBquerytype=\fIvalue\fB\fR +\fBquerytype=\fR\fIvalue\fR .TP -\fBtype=\fIvalue\fB\fR +\fBtype=\fR\fIvalue\fR Change the top of the information query. - +.sp (Default = A; abbreviations = q, ty) .TP -\fB\fI[no]\fBrecurse\fR -Tell the name server to query other servers if it does not have the -information. - +\fB\fI[no]\fR\fR\fBrecurse\fR +Tell the name server to query other servers if it does not have the information. +.sp (Default = recurse; abbreviation = [no]rec) .TP -\fBretry=\fInumber\fB\fR +\fBretry=\fR\fInumber\fR Set the number of retries to number. .TP -\fBtimeout=\fInumber\fB\fR -Change the initial timeout interval for waiting for a -reply to number seconds. +\fBtimeout=\fR\fInumber\fR +Change the initial timeout interval for waiting for a reply to number seconds. .TP -\fB\fI[no]\fBvc\fR +\fB\fI[no]\fR\fR\fBvc\fR Always use a virtual circuit when sending requests to the server. - +.sp (Default = novc) .RE +.IP .SH "FILES" .PP \fI/etc/resolv.conf\fR diff --git a/contrib/bind9/bin/dig/nslookup.c b/contrib/bind9/bin/dig/nslookup.c index b26c605142e..ab9ed68764c 100644 --- a/contrib/bind9/bin/dig/nslookup.c +++ b/contrib/bind9/bin/dig/nslookup.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nslookup.c,v 1.90.2.4.2.8 2004/09/06 01:33:05 marka Exp $ */ +/* $Id: nslookup.c,v 1.90.2.4.2.10 2005/07/12 05:47:42 marka Exp $ */ #include @@ -44,19 +44,6 @@ #include -extern ISC_LIST(dig_lookup_t) lookup_list; -extern dig_serverlist_t server_list; -extern ISC_LIST(dig_searchlist_t) search_list; - -extern isc_boolean_t usesearch, debugging; -extern in_port_t port; -extern unsigned int timeout; -extern isc_mem_t *mctx; -extern int tries; -extern int lookup_counter; -extern isc_task_t *global_task; -extern char *progname; - static isc_boolean_t short_form = ISC_TRUE, tcpmode = ISC_FALSE, identify = ISC_FALSE, stats = ISC_TRUE, diff --git a/contrib/bind9/bin/dig/nslookup.docbook b/contrib/bind9/bin/dig/nslookup.docbook index 134e5b32ec4..189fabe8507 100644 --- a/contrib/bind9/bin/dig/nslookup.docbook +++ b/contrib/bind9/bin/dig/nslookup.docbook @@ -1,6 +1,8 @@ - +]> - + - - - - -nslookup

nslookup

Name

nslookup -- query Internet name servers interactively

Synopsis

nslookup [-option] [name | -] [server]

DESCRIPTION

Nslookup -is a program to query Internet domain name servers. Nslookup + + + + +nslookup + + +

+
+
+

Name

+

nslookup — query Internet name servers interactively

+
+
+

Synopsis

+

nslookup [-option] [name | -] [server]

+
+
+

DESCRIPTION

+

+Nslookup +is a program to query Internet domain name servers. Nslookup has two modes: interactive and non-interactive. Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain. Non-interactive mode is used to print just the name and requested information for a host or -domain.

ARGUMENTS

Interactive mode is entered in the following cases: -

  1. when no arguments are given (the default name server will be used)

  2. when the first argument is a hyphen (-) and the second argument is -the host name or Internet address of a name server.

Non-interactive mode is used when the name or Internet address of the +domain. +

+
+
+

ARGUMENTS

+

+Interactive mode is entered in the following cases: +

+
    +

  1. +when no arguments are given (the default name server will be used) +

    2. +

  2. +when the first argument is a hyphen (-) and the second argument is +the host name or Internet address of a name server. +

    3. +
+

+

+

+Non-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument. The optional second -argument specifies the host name or address of a name server.

Options can also be specified on the command line if they precede the +argument specifies the host name or address of a name server. +

+

+Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen. For example, to change the default query type to host information, and the initial timeout to 10 seconds, type: -

nslookup -query=hinfo  -timeout=10

INTERACTIVE COMMANDS

host [server]

Look up information for host using the current default server or +

+
+nslookup -query=hinfo  -timeout=10
+
+

+

+
+
+

INTERACTIVE COMMANDS

+
+
host [server]
+
+

+Look up information for host using the current default server or using server, if specified. If host is an Internet address and the query type is A or PTR, the name of the host is returned. If host is a name and does not have a trailing period, the -search list is used to qualify the name.

To look up a host not in the current domain, append a period to -the name.

server domain

lserver domain

Change the default server to domain; lserver uses the initial -server to look up information about domain, while server uses +search list is used to qualify the name. +

+

+To look up a host not in the current domain, append a period to +the name. +

+
+
server domain
+

+
lserver domain
+

+Change the default server to domain; lserver uses the initial +server to look up information about domain, while server uses the current default server. If an authoritative answer can't be found, the names of servers that might have the answer are -returned.

root

not implemented

finger

not implemented

ls

not implemented

view

not implemented

help

not implemented

?

not implemented

exit

Exits the program.

set keyword[=value]

This command is used to change state information that affects +returned. +

+
root
+

not implemented

+
finger
+

not implemented

+
ls
+

not implemented

+
view
+

not implemented

+
help
+

not implemented

+
?
+

not implemented

+
exit
+

Exits the program.

+
set keyword[=value]
+
+

This command is used to change state information that affects the lookups. Valid keywords are: -

all

Prints the current values of the frequently used - options to set. Information about the current default +

+
+
all
+

Prints the current values of the frequently used + options to set. Information about the current default server and host is also printed. -

class=value

Change the query class to one of: -

IN

the Internet class

CH

the Chaos class

HS

the Hesiod class

ANY

wildcard

+

+
class=value
+
+

+ Change the query class to one of: +

+
+
IN
+

the Internet class

+
CH
+

the Chaos class

+
HS
+

the Hesiod class

+
ANY
+

wildcard

+
+

The class specifies the protocol group of the information. -

(Default = IN; abbreviation = cl) -

[no]debug

Turn debugging mode on. A lot more information is +

+

+ (Default = IN; abbreviation = cl) +

+
+
[no]debug
+
+

+ Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer. -

(Default = nodebug; abbreviation = [no]deb) -

[no]d2

Turn debugging mode on. A lot more information is +

+

+ (Default = nodebug; abbreviation = [no]deb) +

+
+
[no]d2
+
+

+ Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer. -

(Default = nod2) -

domain=name

Sets the search list to name. -

[no]search

If the lookup request contains at least one period but +

+

+ (Default = nod2) +

+
+
domain=name
+

+ Sets the search list to name. +

+
[no]search
+
+

+ If the lookup request contains at least one period but doesn't end with a trailing period, append the domain names in the domain search list to the request until an answer is received. -

(Default = search) -

port=value

Change the default TCP/UDP name server port to value. -

(Default = 53; abbreviation = po) -

querytype=value

type=value

Change the top of the information query. -

(Default = A; abbreviations = q, ty) -

[no]recurse

Tell the name server to query other servers if it does not have the +

+

+ (Default = search) +

+
+
port=value
+
+

+ Change the default TCP/UDP name server port to value. +

+

+ (Default = 53; abbreviation = po) +

+
+
querytype=value
+

+
type=value
+
+

+ Change the top of the information query. +

+

+ (Default = A; abbreviations = q, ty) +

+
+
[no]recurse
+
+

+ Tell the name server to query other servers if it does not have the information. -

(Default = recurse; abbreviation = [no]rec) -

retry=number

Set the number of retries to number. -

timeout=number

Change the initial timeout interval for waiting for a +

+

+ (Default = recurse; abbreviation = [no]rec) +

+
+
retry=number
+

+ Set the number of retries to number. +

+
timeout=number
+

+ Change the initial timeout interval for waiting for a reply to number seconds. -

[no]vc

Always use a virtual circuit when sending requests to the server. -

(Default = novc) -

FILES

/etc/resolv.conf

SEE ALSO

dig(1), -host(1), -named(8).

Author

Andrew Cherenson

+

+
[no]vc
+
+

+ Always use a virtual circuit when sending requests to the server. +

+

+ (Default = novc) +

+
+
+

+

+ +
+
+
+

FILES

+

+/etc/resolv.conf +

+
+
+

SEE ALSO

+

+dig(1), +host(1), +named(8). +

+
+
+

Author

+

+Andrew Cherenson +

+
+
+ diff --git a/contrib/bind9/bin/dnssec/Makefile.in b/contrib/bind9/bin/dnssec/Makefile.in index 993c54e4067..b9b7bea37c2 100644 --- a/contrib/bind9/bin/dnssec/Makefile.in +++ b/contrib/bind9/bin/dnssec/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2000-2002 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.19.12.9 2004/07/20 07:01:48 marka Exp $ +# $Id: Makefile.in,v 1.19.12.12 2005/05/02 00:25:54 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -58,7 +58,8 @@ dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS} dnssec-keygen.@O@ ${OBJS} ${LIBS} dnssec-signzone.@O@: dnssec-signzone.c - ${LIBTOOL_MODE_COMPILE} ${PURIFY} ${CC} ${ALL_CFLAGS} -c $< + ${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} -DVERSION=\"${VERSION}\" \ + -c ${srcdir}/dnssec-signzone.c dnssec-signzone@EXEEXT@: dnssec-signzone.@O@ ${OBJS} ${DEPLIBS} ${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \ diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.8 b/contrib/bind9/bin/dnssec/dnssec-keygen.8 index 235c26ea32f..0f8f003de42 100644 --- a/contrib/bind9/bin/dnssec/dnssec-keygen.8 +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.8 @@ -1,174 +1,164 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2003 Internet Software Consortium. -.\" +.\" 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, +.\" 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: dnssec-keygen.8,v 1.19.12.5 2004/06/11 02:32:45 marka Exp $ +.\" $Id: dnssec-keygen.8,v 1.19.12.9 2005/10/13 02:33:45 marka Exp $ .\" -.TH "DNSSEC-KEYGEN" "8" "June 30, 2000" "BIND9" "" -.SH NAME -dnssec-keygen \- DNSSEC key generation tool -.SH SYNOPSIS -.sp -\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ] [ \fB-e\fR ] [ \fB-f \fIflag\fB\fR ] [ \fB-g \fIgenerator\fB\fR ] [ \fB-h\fR ] [ \fB-k\fR ] [ \fB-p \fIprotocol\fB\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstrength\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBname\fR +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "DNSSEC\-KEYGEN" "8" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +dnssec\-keygen \- DNSSEC key generation tool +.SH "SYNOPSIS" +.HP 14 +\fBdnssec\-keygen\fR {\-a\ \fIalgorithm\fR} {\-b\ \fIkeysize\fR} {\-n\ \fInametype\fR} [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-e\fR] [\fB\-f\ \fR\fB\fIflag\fR\fR] [\fB\-g\ \fR\fB\fIgenerator\fR\fR] [\fB\-h\fR] [\fB\-k\fR] [\fB\-p\ \fR\fB\fIprotocol\fR\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstrength\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] {name} .SH "DESCRIPTION" .PP -\fBdnssec-keygen\fR generates keys for DNSSEC -(Secure DNS), as defined in RFC 2535 and RFC . It can also generate -keys for use with TSIG (Transaction Signatures), as -defined in RFC 2845. +\fBdnssec\-keygen\fR +generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC . It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845. .SH "OPTIONS" .TP -\fB-a \fIalgorithm\fB\fR +\-a \fIalgorithm\fR Selects the cryptographic algorithm. The value of -\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1, -DSA, DH (Diffie Hellman), or HMAC-MD5. These values -are case insensitive. - -Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, -and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. - -Note 2: HMAC-MD5 and DH automatically set the -k flag. +\fBalgorithm\fR +must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC\-MD5. These values are case insensitive. +.sp +Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended. For TSIG, HMAC\-MD5 is mandatory. +.sp +Note 2: HMAC\-MD5 and DH automatically set the \-k flag. .TP -\fB-b \fIkeysize\fB\fR -Specifies the number of bits in the key. The choice of key -size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between -512 and 2048 bits. Diffie Hellman keys must be between -128 and 4096 bits. DSA keys must be between 512 and 1024 -bits and an exact multiple of 64. HMAC-MD5 keys must be -between 1 and 512 bits. +\-b \fIkeysize\fR +Specifies the number of bits in the key. The choice of key size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC\-MD5 keys must be between 1 and 512 bits. .TP -\fB-n \fInametype\fB\fR +\-n \fInametype\fR Specifies the owner type of the key. The value of -\fBnametype\fR must either be ZONE (for a DNSSEC -zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), -USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are -case insensitive. +\fBnametype\fR +must either be ZONE (for a DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive. .TP -\fB-c \fIclass\fB\fR -Indicates that the DNS record containing the key should have -the specified class. If not specified, class IN is used. +\-c \fIclass\fR +Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used. .TP -\fB-e\fR +\-e If generating an RSAMD5/RSASHA1 key, use a large exponent. .TP -\fB-f \fIflag\fB\fR -Set the specified flag in the flag field of the KEY/DNSKEY record. -The only recognized flag is KSK (Key Signing Key) DNSKEY. +\-f \fIflag\fR +Set the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flag is KSK (Key Signing Key) DNSKEY. .TP -\fB-g \fIgenerator\fB\fR -If generating a Diffie Hellman key, use this generator. -Allowed values are 2 and 5. If no generator -is specified, a known prime from RFC 2539 will be used -if possible; otherwise the default is 2. +\-g \fIgenerator\fR +If generating a Diffie Hellman key, use this generator. Allowed values are 2 and 5. If no generator is specified, a known prime from RFC 2539 will be used if possible; otherwise the default is 2. .TP -\fB-h\fR +\-h Prints a short summary of the options and arguments to -\fBdnssec-keygen\fR. +\fBdnssec\-keygen\fR. .TP -\fB-k\fR +\-k Generate KEY records rather than DNSKEY records. .TP -\fB-p \fIprotocol\fB\fR -Sets the protocol value for the generated key. The protocol -is a number between 0 and 255. The default is 3 (DNSSEC). -Other possible values for this argument are listed in -RFC 2535 and its successors. +\-p \fIprotocol\fR +Sets the protocol value for the generated key. The protocol is a number between 0 and 255. The default is 3 (DNSSEC). Other possible values for this argument are listed in RFC 2535 and its successors. .TP -\fB-r \fIrandomdev\fB\fR -Specifies the source of randomness. If the operating -system does not provide a \fI/dev/random\fR -or equivalent device, the default source of randomness -is keyboard input. \fIrandomdev\fR specifies -the name of a character device or file containing random -data to be used instead of the default. The special value -\fIkeyboard\fR indicates that keyboard -input should be used. +\-r \fIrandomdev\fR +Specifies the source of randomness. If the operating system does not provide a +\fI/dev/random\fR +or equivalent device, the default source of randomness is keyboard input. +\fIrandomdev\fR +specifies the name of a character device or file containing random data to be used instead of the default. The special value +\fIkeyboard\fR +indicates that keyboard input should be used. .TP -\fB-s \fIstrength\fB\fR -Specifies the strength value of the key. The strength is -a number between 0 and 15, and currently has no defined -purpose in DNSSEC. +\-s \fIstrength\fR +Specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in DNSSEC. .TP -\fB-t \fItype\fB\fR -Indicates the use of the key. \fBtype\fR must be -one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default -is AUTHCONF. AUTH refers to the ability to authenticate -data, and CONF the ability to encrypt data. +\-t \fItype\fR +Indicates the use of the key. +\fBtype\fR +must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF. AUTH refers to the ability to authenticate data, and CONF the ability to encrypt data. .TP -\fB-v \fIlevel\fB\fR +\-v \fIlevel\fR Sets the debugging level. .SH "GENERATED KEYS" .PP -When \fBdnssec-keygen\fR completes successfully, -it prints a string of the form \fIKnnnn.+aaa+iiiii\fR -to the standard output. This is an identification string for -the key it has generated. These strings can be used as arguments -to \fBdnssec-makekeyset\fR. -.TP 0.2i +When +\fBdnssec\-keygen\fR +completes successfully, it prints a string of the form +\fIKnnnn.+aaa+iiiii\fR +to the standard output. This is an identification string for the key it has generated. +.TP 3 \(bu -\fInnnn\fR is the key name. -.TP 0.2i +\fInnnn\fR +is the key name. +.TP \(bu -\fIaaa\fR is the numeric representation of the -algorithm. -.TP 0.2i +\fIaaa\fR +is the numeric representation of the algorithm. +.TP \(bu -\fIiiiii\fR is the key identifier (or footprint). +\fIiiiii\fR +is the key identifier (or footprint). .PP -\fBdnssec-keygen\fR creates two file, with names based -on the printed string. \fIKnnnn.+aaa+iiiii.key\fR +\fBdnssec\-keygen\fR +creates two file, with names based on the printed string. +\fIKnnnn.+aaa+iiiii.key\fR contains the public key, and -\fIKnnnn.+aaa+iiiii.private\fR contains the private -key. +\fIKnnnn.+aaa+iiiii.private\fR +contains the private key. .PP +The +\fI.key\fR +file contains a DNS KEY record that can be inserted into a zone file (directly or with a $INCLUDE statement). .PP -The \fI.key\fR file contains a DNS KEY record that -can be inserted into a zone file (directly or with a $INCLUDE -statement). -.PP -.PP -The \fI.private\fR file contains algorithm specific -fields. For obvious security reasons, this file does not have -general read permission. -.PP -.PP -Both \fI.key\fR and \fI.private\fR -files are generated for symmetric encryption algorithm such as -HMAC-MD5, even though the public and private key are equivalent. +The +\fI.private\fR +file contains algorithm specific fields. For obvious security reasons, this file does not have general read permission. .PP +Both +\fI.key\fR +and +\fI.private\fR +files are generated for symmetric encryption algorithm such as HMAC\-MD5, even though the public and private key are equivalent. .SH "EXAMPLE" .PP -To generate a 768-bit DSA key for the domain -\fBexample.com\fR, the following command would be -issued: +To generate a 768\-bit DSA key for the domain +\fBexample.com\fR, the following command would be issued: .PP -\fBdnssec-keygen -a DSA -b 768 -n ZONE example.com\fR +\fBdnssec\-keygen \-a DSA \-b 768 \-n ZONE example.com\fR .PP The command would print a string of the form: .PP \fBKexample.com.+003+26160\fR .PP -In this example, \fBdnssec-keygen\fR creates -the files \fIKexample.com.+003+26160.key\fR and +In this example, +\fBdnssec\-keygen\fR +creates the files +\fIKexample.com.+003+26160.key\fR +and \fIKexample.com.+003+26160.private\fR .SH "SEE ALSO" .PP -\fBdnssec-signzone\fR(8), -\fIBIND 9 Administrator Reference Manual\fR, -\fIRFC 2535\fR, -\fIRFC 2845\fR, -\fIRFC 2539\fR. +\fBdnssec\-signzone\fR(8), +BIND 9 Administrator Reference Manual, +RFC 2535, +RFC 2845, +RFC 2539. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook index a2034d9e804..e1eee228ee6 100644 --- a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,21 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + + dnssec-keygen DNSSEC key generation tool @@ -244,8 +261,7 @@ When dnssec-keygen completes successfully, it prints a string of the form Knnnn.+aaa+iiiii to the standard output. This is an identification string for - the key it has generated. These strings can be used as arguments - to dnssec-makekeyset. + the key it has generated. diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.html b/contrib/bind9/bin/dnssec/dnssec-keygen.html index 734c914ba61..00271faadf4 100644 --- a/contrib/bind9/bin/dnssec/dnssec-keygen.html +++ b/contrib/bind9/bin/dnssec/dnssec-keygen.html @@ -1,544 +1,228 @@ - - - - -dnssec-keygen

dnssec-keygen

Name

dnssec-keygen -- DNSSEC key generation tool

Synopsis

dnssec-keygen {-a algorithm} {-b keysize} {-n nametype} [-c class] [-e] [-f flag] [-g generator] [-h] [-k] [-p protocol] [-r randomdev] [-s strength] [-t type] [-v level] {name}

DESCRIPTION

dnssec-keygen generates keys for DNSSEC + + + + +dnssec-keygen + + +

+
+
+

Name

+

dnssec-keygen — DNSSEC key generation tool

+
+
+

Synopsis

+

dnssec-keygen {-a algorithm} {-b keysize} {-n nametype} [-c class] [-e] [-f flag] [-g generator] [-h] [-k] [-p protocol] [-r randomdev] [-s strength] [-t type] [-v level] {name}

+
+
+

DESCRIPTION

+

+ dnssec-keygen generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC <TBA\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845. -

OPTIONS

-a algorithm

Selects the cryptographic algorithm. The value of - algorithm must be one of RSAMD5 (RSA) or RSASHA1, +

+
+
+

OPTIONS

+
+
-a algorithm
+
+

+ Selects the cryptographic algorithm. The value of + algorithm must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. -

Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, +

+

+ Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. -

Note 2: HMAC-MD5 and DH automatically set the -k flag. -

-b keysize

Specifies the number of bits in the key. The choice of key +

+

+ Note 2: HMAC-MD5 and DH automatically set the -k flag. +

+
+
-b keysize
+

+ Specifies the number of bits in the key. The choice of key size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC-MD5 keys must be between 1 and 512 bits. -

-n nametype

Specifies the owner type of the key. The value of - nametype must either be ZONE (for a DNSSEC +

+
-n nametype
+

+ Specifies the owner type of the key. The value of + nametype must either be ZONE (for a DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive. -

-c class

Indicates that the DNS record containing the key should have +

+
-c class
+

+ Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used. -

-e

If generating an RSAMD5/RSASHA1 key, use a large exponent. -

-f flag

Set the specified flag in the flag field of the KEY/DNSKEY record. +

+
-e
+

+ If generating an RSAMD5/RSASHA1 key, use a large exponent. +

+
-f flag
+

+ Set the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flag is KSK (Key Signing Key) DNSKEY. -

-g generator

If generating a Diffie Hellman key, use this generator. +

+
-g generator
+

+ If generating a Diffie Hellman key, use this generator. Allowed values are 2 and 5. If no generator is specified, a known prime from RFC 2539 will be used if possible; otherwise the default is 2. -

-h

Prints a short summary of the options and arguments to - dnssec-keygen. -

-k

Generate KEY records rather than DNSKEY records. -

-p protocol

Sets the protocol value for the generated key. The protocol +

+
-h
+

+ Prints a short summary of the options and arguments to + dnssec-keygen. +

+
-k
+

+ Generate KEY records rather than DNSKEY records. +

+
-p protocol
+

+ Sets the protocol value for the generated key. The protocol is a number between 0 and 255. The default is 3 (DNSSEC). Other possible values for this argument are listed in RFC 2535 and its successors. -

-r randomdev

Specifies the source of randomness. If the operating - system does not provide a /dev/random +

+
-r randomdev
+

+ Specifies the source of randomness. If the operating + system does not provide a /dev/random or equivalent device, the default source of randomness - is keyboard input. randomdev specifies + is keyboard input. randomdev specifies the name of a character device or file containing random data to be used instead of the default. The special value - keyboard indicates that keyboard + keyboard indicates that keyboard input should be used. -

-s strength

Specifies the strength value of the key. The strength is +

+
-s strength
+

+ Specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in DNSSEC. -

-t type

Indicates the use of the key. type must be +

+
-t type
+

+ Indicates the use of the key. type must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF. AUTH refers to the ability to authenticate data, and CONF the ability to encrypt data. -

-v level

Sets the debugging level. -

GENERATED KEYS

When dnssec-keygen completes successfully, - it prints a string of the form Knnnn.+aaa+iiiii +

+
-v level
+

+ Sets the debugging level. +

+
+
+
+

GENERATED KEYS

+

+ When dnssec-keygen completes successfully, + it prints a string of the form Knnnn.+aaa+iiiii to the standard output. This is an identification string for - the key it has generated. These strings can be used as arguments - to dnssec-makekeyset. -

  • nnnn is the key name. -

  • aaa is the numeric representation of the + the key it has generated. +

    +
      +

    • + nnnn is the key name. +

      • +

    • + aaa is the numeric representation of the algorithm. -

    • iiiii is the key identifier (or footprint). -

    dnssec-keygen creates two file, with names based - on the printed string. Knnnn.+aaa+iiiii.key +

    • +

  • + iiiii is the key identifier (or footprint). +

    • +
+

+ dnssec-keygen creates two file, with names based + on the printed string. Knnnn.+aaa+iiiii.key contains the public key, and - Knnnn.+aaa+iiiii.private contains the private + Knnnn.+aaa+iiiii.private contains the private key. -

The .key file contains a DNS KEY record that +

+

+ The .key file contains a DNS KEY record that can be inserted into a zone file (directly or with a $INCLUDE statement). -

The .private file contains algorithm specific +

+

+ The .private file contains algorithm specific fields. For obvious security reasons, this file does not have general read permission. -

Both .key and .private +

+

+ Both .key and .private files are generated for symmetric encryption algorithm such as HMAC-MD5, even though the public and private key are equivalent. -

EXAMPLE

To generate a 768-bit DSA key for the domain - example.com, the following command would be +

+
+
+

EXAMPLE

+

+ To generate a 768-bit DSA key for the domain + example.com, the following command would be issued: -

dnssec-keygen -a DSA -b 768 -n ZONE example.com -

The command would print a string of the form: -

Kexample.com.+003+26160 -

In this example, dnssec-keygen creates - the files Kexample.com.+003+26160.key and - Kexample.com.+003+26160.private -

SEE ALSO

dnssec-signzone(8), - BIND 9 Administrator Reference Manual, - RFC 2535, - RFC 2845, - RFC 2539. -

AUTHOR

Internet Systems Consortium -

+

+

+ dnssec-keygen -a DSA -b 768 -n ZONE example.com +

+

+ The command would print a string of the form: +

+

+ Kexample.com.+003+26160 +

+

+ In this example, dnssec-keygen creates + the files Kexample.com.+003+26160.key and + Kexample.com.+003+26160.private +

+
+
+

SEE ALSO

+

+ dnssec-signzone(8), + BIND 9 Administrator Reference Manual, + RFC 2535, + RFC 2845, + RFC 2539. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+ + diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.8 b/contrib/bind9/bin/dnssec/dnssec-signzone.8 index a1795b8001a..63ffadba644 100644 --- a/contrib/bind9/bin/dnssec/dnssec-signzone.8 +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.8 @@ -1,167 +1,157 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2003 Internet Software Consortium. -.\" +.\" 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, +.\" 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: dnssec-signzone.8,v 1.23.2.1.4.6 2004/06/11 02:32:46 marka Exp $ +.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.10 2005/10/13 02:33:45 marka Exp $ .\" -.TH "DNSSEC-SIGNZONE" "8" "June 30, 2000" "BIND9" "" -.SH NAME -dnssec-signzone \- DNSSEC zone signing tool -.SH SYNOPSIS -.sp -\fBdnssec-signzone\fR [ \fB-a\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-d \fIdirectory\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-f \fIoutput-file\fB\fR ] [ \fB-g\fR ] [ \fB-h\fR ] [ \fB-k \fIkey\fB\fR ] [ \fB-l \fIdomain\fB\fR ] [ \fB-i \fIinterval\fB\fR ] [ \fB-n \fInthreads\fB\fR ] [ \fB-o \fIorigin\fB\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-t\fR ] [ \fB-v \fIlevel\fB\fR ] [ \fB-z\fR ] \fBzonefile\fR [ \fBkey\fR\fI...\fR ] +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "DNSSEC\-SIGNZONE" "8" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +dnssec\-signzone \- DNSSEC zone signing tool +.SH "SYNOPSIS" +.HP 16 +\fBdnssec\-signzone\fR [\fB\-a\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-d\ \fR\fB\fIdirectory\fR\fR] [\fB\-e\ \fR\fB\fIend\-time\fR\fR] [\fB\-f\ \fR\fB\fIoutput\-file\fR\fR] [\fB\-g\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkey\fR\fR] [\fB\-l\ \fR\fB\fIdomain\fR\fR] [\fB\-i\ \fR\fB\fIinterval\fR\fR] [\fB\-n\ \fR\fB\fInthreads\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [\fB\-p\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstart\-time\fR\fR] [\fB\-t\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-z\fR] {zonefile} [key...] .SH "DESCRIPTION" .PP -\fBdnssec-signzone\fR signs a zone. It generates -NSEC and RRSIG records and produces a signed version of the -zone. The security status of delegations from the signed zone -(that is, whether the child zones are secure or not) is -determined by the presence or absence of a -\fIkeyset\fR file for each child zone. +\fBdnssec\-signzone\fR +signs a zone. It generates NSEC and RRSIG records and produces a signed version of the zone. The security status of delegations from the signed zone (that is, whether the child zones are secure or not) is determined by the presence or absence of a +\fIkeyset\fR +file for each child zone. .SH "OPTIONS" .TP -\fB-a\fR +\-a Verify all generated signatures. .TP -\fB-c \fIclass\fB\fR +\-c \fIclass\fR Specifies the DNS class of the zone. .TP -\fB-k \fIkey\fB\fR -Treat specified key as a key signing key ignoring any -key flags. This option may be specified multiple times. +\-k \fIkey\fR +Treat specified key as a key signing key ignoring any key flags. This option may be specified multiple times. .TP -\fB-l \fIdomain\fB\fR -Generate a DLV set in addition to the key (DNSKEY) and DS sets. -The domain is appended to the name of the records. +\-l \fIdomain\fR +Generate a DLV set in addition to the key (DNSKEY) and DS sets. The domain is appended to the name of the records. .TP -\fB-d \fIdirectory\fB\fR -Look for \fIkeyset\fR files in -\fBdirectory\fR as the directory +\-d \fIdirectory\fR +Look for +\fIkeyset\fR +files in +\fBdirectory\fR +as the directory .TP -\fB-g\fR -Generate DS records for child zones from keyset files. -Existing DS records will be removed. +\-g +Generate DS records for child zones from keyset files. Existing DS records will be removed. .TP -\fB-s \fIstart-time\fB\fR -Specify the date and time when the generated RRSIG records -become valid. This can be either an absolute or relative -time. An absolute start time is indicated by a number -in YYYYMMDDHHMMSS notation; 20000530144500 denotes -14:45:00 UTC on May 30th, 2000. A relative start time is -indicated by +N, which is N seconds from the current time. -If no \fBstart-time\fR is specified, the current -time minus 1 hour (to allow for clock skew) is used. +\-s \fIstart\-time\fR +Specify the date and time when the generated RRSIG records become valid. This can be either an absolute or relative time. An absolute start time is indicated by a number in YYYYMMDDHHMMSS notation; 20000530144500 denotes 14:45:00 UTC on May 30th, 2000. A relative start time is indicated by +N, which is N seconds from the current time. If no +\fBstart\-time\fR +is specified, the current time minus 1 hour (to allow for clock skew) is used. .TP -\fB-e \fIend-time\fB\fR -Specify the date and time when the generated RRSIG records -expire. As with \fBstart-time\fR, an absolute -time is indicated in YYYYMMDDHHMMSS notation. A time relative -to the start time is indicated with +N, which is N seconds from -the start time. A time relative to the current time is -indicated with now+N. If no \fBend-time\fR is -specified, 30 days from the start time is used as a default. +\-e \fIend\-time\fR +Specify the date and time when the generated RRSIG records expire. As with +\fBstart\-time\fR, an absolute time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start time is indicated with +N, which is N seconds from the start time. A time relative to the current time is indicated with now+N. If no +\fBend\-time\fR +is specified, 30 days from the start time is used as a default. .TP -\fB-f \fIoutput-file\fB\fR -The name of the output file containing the signed zone. The -default is to append \fI.signed\fR to the -input file. +\-f \fIoutput\-file\fR +The name of the output file containing the signed zone. The default is to append +\fI.signed\fR +to the input file. .TP -\fB-h\fR +\-h Prints a short summary of the options and arguments to -\fBdnssec-signzone\fR. +\fBdnssec\-signzone\fR. .TP -\fB-i \fIinterval\fB\fR -When a previously signed zone is passed as input, records -may be resigned. The \fBinterval\fR option -specifies the cycle interval as an offset from the current -time (in seconds). If a RRSIG record expires after the -cycle interval, it is retained. Otherwise, it is considered -to be expiring soon, and it will be replaced. - -The default cycle interval is one quarter of the difference -between the signature end and start times. So if neither -\fBend-time\fR or \fBstart-time\fR -are specified, \fBdnssec-signzone\fR generates -signatures that are valid for 30 days, with a cycle -interval of 7.5 days. Therefore, if any existing RRSIG records -are due to expire in less than 7.5 days, they would be -replaced. +\-i \fIinterval\fR +When a previously signed zone is passed as input, records may be resigned. The +\fBinterval\fR +option specifies the cycle interval as an offset from the current time (in seconds). If a RRSIG record expires after the cycle interval, it is retained. Otherwise, it is considered to be expiring soon, and it will be replaced. +.sp +The default cycle interval is one quarter of the difference between the signature end and start times. So if neither +\fBend\-time\fR +or +\fBstart\-time\fR +are specified, +\fBdnssec\-signzone\fR +generates signatures that are valid for 30 days, with a cycle interval of 7.5 days. Therefore, if any existing RRSIG records are due to expire in less than 7.5 days, they would be replaced. .TP -\fB-n \fIncpus\fB\fR -Specifies the number of threads to use. By default, one -thread is started for each detected CPU. +\-n \fIncpus\fR +Specifies the number of threads to use. By default, one thread is started for each detected CPU. .TP -\fB-o \fIorigin\fB\fR -The zone origin. If not specified, the name of the zone file -is assumed to be the origin. +\-o \fIorigin\fR +The zone origin. If not specified, the name of the zone file is assumed to be the origin. .TP -\fB-p\fR -Use pseudo-random data when signing the zone. This is faster, -but less secure, than using real random data. This option -may be useful when signing large zones or when the entropy -source is limited. +\-p +Use pseudo\-random data when signing the zone. This is faster, but less secure, than using real random data. This option may be useful when signing large zones or when the entropy source is limited. .TP -\fB-r \fIrandomdev\fB\fR -Specifies the source of randomness. If the operating -system does not provide a \fI/dev/random\fR -or equivalent device, the default source of randomness -is keyboard input. \fIrandomdev\fR specifies -the name of a character device or file containing random -data to be used instead of the default. The special value -\fIkeyboard\fR indicates that keyboard -input should be used. +\-r \fIrandomdev\fR +Specifies the source of randomness. If the operating system does not provide a +\fI/dev/random\fR +or equivalent device, the default source of randomness is keyboard input. +\fIrandomdev\fR +specifies the name of a character device or file containing random data to be used instead of the default. The special value +\fIkeyboard\fR +indicates that keyboard input should be used. .TP -\fB-t\fR +\-t Print statistics at completion. .TP -\fB-v \fIlevel\fB\fR +\-v \fIlevel\fR Sets the debugging level. .TP -\fB-z\fR +\-z Ignore KSK flag on key when determining what to sign. .TP -\fBzonefile\fR +zonefile The file containing the zone to be signed. -Sets the debugging level. .TP -\fBkey\fR -The keys used to sign the zone. If no keys are specified, the -default all zone keys that have private key files in the -current directory. +key +The keys used to sign the zone. If no keys are specified, the default all zone keys that have private key files in the current directory. .SH "EXAMPLE" .PP -The following command signs the \fBexample.com\fR -zone with the DSA key generated in the \fBdnssec-keygen\fR +The following command signs the +\fBexample.com\fR +zone with the DSA key generated in the +\fBdnssec\-keygen\fR man page. The zone's keys must be in the zone. If there are -\fIkeyset\fR files associated with child zones, -they must be in the current directory. -\fBexample.com\fR, the following command would be -issued: +\fIkeyset\fR +files associated with child zones, they must be in the current directory. +\fBexample.com\fR, the following command would be issued: .PP -\fBdnssec-signzone -o example.com db.example.com Kexample.com.+003+26160\fR +\fBdnssec\-signzone \-o example.com db.example.com Kexample.com.+003+26160\fR .PP The command would print a string of the form: .PP -In this example, \fBdnssec-signzone\fR creates -the file \fIdb.example.com.signed\fR. This file -should be referenced in a zone statement in a -\fInamed.conf\fR file. +In this example, +\fBdnssec\-signzone\fR +creates the file +\fIdb.example.com.signed\fR. This file should be referenced in a zone statement in a +\fInamed.conf\fR +file. .SH "SEE ALSO" .PP -\fBdnssec-keygen\fR(8), -\fIBIND 9 Administrator Reference Manual\fR, -\fIRFC 2535\fR. +\fBdnssec\-keygen\fR(8), +BIND 9 Administrator Reference Manual, +RFC 2535. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.c b/contrib/bind9/bin/dnssec/dnssec-signzone.c index c2c33f8c812..93caf497e26 100644 --- a/contrib/bind9/bin/dnssec/dnssec-signzone.c +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.c @@ -1,5 +1,5 @@ /* - * Portions Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Portions Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Portions Copyright (C) 1999-2003 Internet Software Consortium. * Portions Copyright (C) 1995-2000 by Network Associates, Inc. * @@ -16,7 +16,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dnssec-signzone.c,v 1.139.2.2.4.17 2004/10/25 01:36:06 marka Exp $ */ +/* $Id: dnssec-signzone.c,v 1.139.2.2.4.21 2005/10/14 01:38:41 marka Exp $ */ #include @@ -787,7 +787,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) { dns_rdatasetiter_t *rdsiter; isc_boolean_t isdelegation = ISC_FALSE; isc_boolean_t hasds = ISC_FALSE; - isc_boolean_t atorigin; isc_boolean_t changed = ISC_FALSE; dns_diff_t del, add; char namestr[DNS_NAME_FORMATSIZE]; @@ -795,8 +794,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) { dns_name_format(name, namestr, sizeof(namestr)); - atorigin = dns_name_equal(name, gorigin); - /* * Determine if this is a delegation point. */ @@ -931,13 +928,16 @@ signname(dns_dbnode_t *node, dns_name_t *name) { static inline isc_boolean_t active_node(dns_dbnode_t *node) { - dns_rdatasetiter_t *rdsiter; + dns_rdatasetiter_t *rdsiter = NULL; + dns_rdatasetiter_t *rdsiter2 = NULL; isc_boolean_t active = ISC_FALSE; isc_result_t result; dns_rdataset_t rdataset; + dns_rdatatype_t type; + dns_rdatatype_t covers; + isc_boolean_t found; dns_rdataset_init(&rdataset); - rdsiter = NULL; result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter); check_result(result, "dns_db_allrdatasets()"); result = dns_rdatasetiter_first(rdsiter); @@ -958,36 +958,63 @@ active_node(dns_dbnode_t *node) { if (!active) { /* - * Make sure there is no NSEC / RRSIG records for - * this node. + * The node is empty of everything but NSEC / RRSIG records. */ - result = dns_db_deleterdataset(gdb, node, gversion, - dns_rdatatype_nsec, 0); - if (result == DNS_R_UNCHANGED) - result = ISC_R_SUCCESS; - check_result(result, "dns_db_deleterdataset(nsec)"); - - result = dns_rdatasetiter_first(rdsiter); for (result = dns_rdatasetiter_first(rdsiter); result == ISC_R_SUCCESS; result = dns_rdatasetiter_next(rdsiter)) { dns_rdatasetiter_current(rdsiter, &rdataset); - if (rdataset.type == dns_rdatatype_rrsig) { - dns_rdatatype_t type = rdataset.type; - dns_rdatatype_t covers = rdataset.covers; - result = dns_db_deleterdataset(gdb, node, - gversion, type, - covers); - if (result == DNS_R_UNCHANGED) - result = ISC_R_SUCCESS; - check_result(result, - "dns_db_deleterdataset(rrsig)"); - } + result = dns_db_deleterdataset(gdb, node, gversion, + rdataset.type, + rdataset.covers); + check_result(result, "dns_db_deleterdataset()"); dns_rdataset_disassociate(&rdataset); } if (result != ISC_R_NOMORE) fatal("rdataset iteration failed: %s", isc_result_totext(result)); + } else { + /* + * Delete RRSIGs for types that no longer exist. + */ + result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter2); + check_result(result, "dns_db_allrdatasets()"); + for (result = dns_rdatasetiter_first(rdsiter); + result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(rdsiter)) { + dns_rdatasetiter_current(rdsiter, &rdataset); + type = rdataset.type; + covers = rdataset.covers; + dns_rdataset_disassociate(&rdataset); + if (type != dns_rdatatype_rrsig) + continue; + found = ISC_FALSE; + for (result = dns_rdatasetiter_first(rdsiter2); + !found && result == ISC_R_SUCCESS; + result = dns_rdatasetiter_next(rdsiter2)) { + dns_rdatasetiter_current(rdsiter2, &rdataset); + if (rdataset.type == covers) + found = ISC_TRUE; + dns_rdataset_disassociate(&rdataset); + } + if (!found) { + if (result != ISC_R_NOMORE) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + result = dns_db_deleterdataset(gdb, node, + gversion, type, + covers); + check_result(result, + "dns_db_deleterdataset(rrsig)"); + } else if (result != ISC_R_NOMORE && + result != ISC_R_SUCCESS) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + } + if (result != ISC_R_NOMORE) + fatal("rdataset iteration failed: %s", + isc_result_totext(result)); + dns_rdatasetiter_destroy(&rdsiter2); } dns_rdatasetiter_destroy(&rdsiter); @@ -1423,7 +1450,6 @@ warnifallksk(dns_db_t *db) { dns_dbnode_t *node = NULL; dns_rdataset_t rdataset; dns_rdata_t rdata = DNS_RDATA_INIT; - dst_key_t *pubkey; isc_result_t result; dns_rdata_key_t key; isc_boolean_t have_non_ksk = ISC_FALSE; @@ -1444,7 +1470,6 @@ warnifallksk(dns_db_t *db) { result = dns_rdataset_first(&rdataset); check_result(result, "dns_rdataset_first"); while (result == ISC_R_SUCCESS) { - pubkey = NULL; dns_rdata_reset(&rdata); dns_rdataset_current(&rdataset, &rdata); result = dns_rdata_tostruct(&rdata, &key, NULL); @@ -1615,9 +1640,9 @@ usage(void) { fprintf(stderr, "\t\tdirectory to find keyset files (.)\n"); fprintf(stderr, "\t-g:\t"); fprintf(stderr, "generate DS records from keyset files\n"); - fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); + fprintf(stderr, "\t-s [YYYYMMDDHHMMSS|+offset]:\n"); fprintf(stderr, "\t\tRRSIG start time - absolute|offset (now - 1 hour)\n"); - fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); + fprintf(stderr, "\t-e [YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); fprintf(stderr, "\t\tRRSIG end time - absolute|from start|from now " "(now + 30 days)\n"); fprintf(stderr, "\t-i interval:\n"); diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook index 2b85102a0b5..35f35cc7339 100644 --- a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,21 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + + dnssec-signzone DNSSEC zone signing tool @@ -290,7 +307,6 @@ The file containing the zone to be signed. - Sets the debugging level. diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.html b/contrib/bind9/bin/dnssec/dnssec-signzone.html index 221099fbdbe..5cc8c0747cc 100644 --- a/contrib/bind9/bin/dnssec/dnssec-signzone.html +++ b/contrib/bind9/bin/dnssec/dnssec-signzone.html @@ -1,553 +1,220 @@ - - - - -dnssec-signzone

dnssec-signzone

Name

dnssec-signzone -- DNSSEC zone signing tool

Synopsis

dnssec-signzone [-a] [-c class] [-d directory] [-e end-time] [-f output-file] [-g] [-h] [-k key] [-l domain] [-i interval] [-n nthreads] [-o origin] [-p] [-r randomdev] [-s start-time] [-t] [-v level] [-z] {zonefile} [key...]

DESCRIPTION

dnssec-signzone signs a zone. It generates + + + + +dnssec-signzone + + +

+
+
+

Name

+

dnssec-signzone — DNSSEC zone signing tool

+
+
+

Synopsis

+

dnssec-signzone [-a] [-c class] [-d directory] [-e end-time] [-f output-file] [-g] [-h] [-k key] [-l domain] [-i interval] [-n nthreads] [-o origin] [-p] [-r randomdev] [-s start-time] [-t] [-v level] [-z] {zonefile} [key...]

+
+
+

DESCRIPTION

+

+ dnssec-signzone signs a zone. It generates NSEC and RRSIG records and produces a signed version of the zone. The security status of delegations from the signed zone (that is, whether the child zones are secure or not) is determined by the presence or absence of a - keyset file for each child zone. -

OPTIONS

-a

Verify all generated signatures. -

-c class

Specifies the DNS class of the zone. -

-k key

Treat specified key as a key signing key ignoring any + keyset file for each child zone. +

+
+
+

OPTIONS

+
+
-a
+

+ Verify all generated signatures. +

+
-c class
+

+ Specifies the DNS class of the zone. +

+
-k key
+

+ Treat specified key as a key signing key ignoring any key flags. This option may be specified multiple times. -

-l domain

Generate a DLV set in addition to the key (DNSKEY) and DS sets. +

+
-l domain
+

+ Generate a DLV set in addition to the key (DNSKEY) and DS sets. The domain is appended to the name of the records. -

-d directory

Look for keyset files in - directory as the directory -

-g

Generate DS records for child zones from keyset files. +

+
-d directory
+

+ Look for keyset files in + directory as the directory +

+
-g
+

+ Generate DS records for child zones from keyset files. Existing DS records will be removed. -

-s start-time

Specify the date and time when the generated RRSIG records +

+
-s start-time
+

+ Specify the date and time when the generated RRSIG records become valid. This can be either an absolute or relative time. An absolute start time is indicated by a number in YYYYMMDDHHMMSS notation; 20000530144500 denotes 14:45:00 UTC on May 30th, 2000. A relative start time is indicated by +N, which is N seconds from the current time. - If no start-time is specified, the current + If no start-time is specified, the current time minus 1 hour (to allow for clock skew) is used. -

-e end-time

Specify the date and time when the generated RRSIG records - expire. As with start-time, an absolute +

+
-e end-time
+

+ Specify the date and time when the generated RRSIG records + expire. As with start-time, an absolute time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start time is indicated with +N, which is N seconds from the start time. A time relative to the current time is - indicated with now+N. If no end-time is + indicated with now+N. If no end-time is specified, 30 days from the start time is used as a default. -

-f output-file

The name of the output file containing the signed zone. The - default is to append .signed to the +

+
-f output-file
+

+ The name of the output file containing the signed zone. The + default is to append .signed to the input file. -

-h

Prints a short summary of the options and arguments to - dnssec-signzone. -

-i interval

When a previously signed zone is passed as input, records - may be resigned. The interval option +

+
-h
+

+ Prints a short summary of the options and arguments to + dnssec-signzone. +

+
-i interval
+
+

+ When a previously signed zone is passed as input, records + may be resigned. The interval option specifies the cycle interval as an offset from the current time (in seconds). If a RRSIG record expires after the cycle interval, it is retained. Otherwise, it is considered to be expiring soon, and it will be replaced. -

The default cycle interval is one quarter of the difference +

+

+ The default cycle interval is one quarter of the difference between the signature end and start times. So if neither - end-time or start-time - are specified, dnssec-signzone generates + end-time or start-time + are specified, dnssec-signzone generates signatures that are valid for 30 days, with a cycle interval of 7.5 days. Therefore, if any existing RRSIG records are due to expire in less than 7.5 days, they would be replaced. -

-n ncpus

Specifies the number of threads to use. By default, one +

+
+
-n ncpus
+

+ Specifies the number of threads to use. By default, one thread is started for each detected CPU. -

-o origin

The zone origin. If not specified, the name of the zone file +

+
-o origin
+

+ The zone origin. If not specified, the name of the zone file is assumed to be the origin. -

-p

Use pseudo-random data when signing the zone. This is faster, +

+
-p
+

+ Use pseudo-random data when signing the zone. This is faster, but less secure, than using real random data. This option may be useful when signing large zones or when the entropy source is limited. -

-r randomdev

Specifies the source of randomness. If the operating - system does not provide a /dev/random +

+
-r randomdev
+

+ Specifies the source of randomness. If the operating + system does not provide a /dev/random or equivalent device, the default source of randomness - is keyboard input. randomdev specifies + is keyboard input. randomdev specifies the name of a character device or file containing random data to be used instead of the default. The special value - keyboard indicates that keyboard + keyboard indicates that keyboard input should be used. -

-t

Print statistics at completion. -

-v level

Sets the debugging level. -

-z

Ignore KSK flag on key when determining what to sign. -

zonefile

The file containing the zone to be signed. +

+
-t
+

+ Print statistics at completion. +

+
-v level
+

Sets the debugging level. -

key

The keys used to sign the zone. If no keys are specified, the +

+
-z
+

+ Ignore KSK flag on key when determining what to sign. +

+
zonefile
+

+ The file containing the zone to be signed. +

+
key
+

+ The keys used to sign the zone. If no keys are specified, the default all zone keys that have private key files in the current directory. -

EXAMPLE

The following command signs the example.com - zone with the DSA key generated in the dnssec-keygen +

+
+
+
+

EXAMPLE

+

+ The following command signs the example.com + zone with the DSA key generated in the dnssec-keygen man page. The zone's keys must be in the zone. If there are - keyset files associated with child zones, + keyset files associated with child zones, they must be in the current directory. - example.com, the following command would be + example.com, the following command would be issued: -

dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160 -

The command would print a string of the form: -

In this example, dnssec-signzone creates - the file db.example.com.signed. This file +

+

+ dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160 +

+

+ The command would print a string of the form: +

+

+ In this example, dnssec-signzone creates + the file db.example.com.signed. This file should be referenced in a zone statement in a - named.conf file. -

SEE ALSO

dnssec-keygen(8), - BIND 9 Administrator Reference Manual, - RFC 2535. -

AUTHOR

Internet Systems Consortium -

+ named.conf file. +

+
+
+

SEE ALSO

+

+ dnssec-keygen(8), + BIND 9 Administrator Reference Manual, + RFC 2535. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/bin/dnssec/dnssectool.c b/contrib/bind9/bin/dnssec/dnssectool.c index 1b84de8f48a..83ba76d9128 100644 --- a/contrib/bind9/bin/dnssec/dnssectool.c +++ b/contrib/bind9/bin/dnssec/dnssectool.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dnssectool.c,v 1.31.2.3.2.4 2004/03/08 02:07:38 marka Exp $ */ +/* $Id: dnssectool.c,v 1.31.2.3.2.6 2005/07/02 02:42:43 marka Exp $ */ #include @@ -145,6 +145,8 @@ setup_logging(int verbose, isc_mem_t *mctx, isc_log_t **logp) { isc_log_t *log = NULL; int level; + if (verbose < 0) + verbose = 0; switch (verbose) { case 0: /* diff --git a/contrib/bind9/bin/named/aclconf.c b/contrib/bind9/bin/named/aclconf.c index ef36c5681f4..8b6d0c767d4 100644 --- a/contrib/bind9/bin/named/aclconf.c +++ b/contrib/bind9/bin/named/aclconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: aclconf.c,v 1.27.12.3 2004/03/08 04:04:18 marka Exp $ */ +/* $Id: aclconf.c,v 1.27.12.5 2005/03/17 03:58:25 marka Exp $ */ #include @@ -31,6 +31,8 @@ #include +#define LOOP_MAGIC ISC_MAGIC('L','O','O','P') + void ns_aclconfctx_init(ns_aclconfctx_t *ctx) { ISC_LIST_INIT(ctx->named_acl_cache); @@ -81,6 +83,7 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, isc_result_t result; cfg_obj_t *cacl = NULL; dns_acl_t *dacl; + dns_acl_t loop; char *aclname = cfg_obj_asstring(nameobj); /* Look for an already-converted version. */ @@ -89,6 +92,11 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, dacl = ISC_LIST_NEXT(dacl, nextincache)) { if (strcasecmp(aclname, dacl->name) == 0) { + if (ISC_MAGIC_VALID(dacl, LOOP_MAGIC)) { + cfg_obj_log(nameobj, dns_lctx, ISC_LOG_ERROR, + "acl loop detected: %s", aclname); + return (ISC_R_FAILURE); + } dns_acl_attach(dacl, target); return (ISC_R_SUCCESS); } @@ -100,7 +108,18 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx, "undefined ACL '%s'", aclname); return (result); } + /* + * Add a loop detection element. + */ + memset(&loop, 0, sizeof(loop)); + ISC_LINK_INIT(&loop, nextincache); + loop.name = aclname; + loop.magic = LOOP_MAGIC; + ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache); result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl); + ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache); + loop.magic = 0; + loop.name = NULL; if (result != ISC_R_SUCCESS) return (result); dacl->name = isc_mem_strdup(dacl->mctx, aclname); diff --git a/contrib/bind9/bin/named/client.c b/contrib/bind9/bin/named/client.c index 259f8d9dc29..baecc2345cb 100644 --- a/contrib/bind9/bin/named/client.c +++ b/contrib/bind9/bin/named/client.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.c,v 1.176.2.13.4.23 2004/09/26 22:37:43 marka Exp $ */ +/* $Id: client.c,v 1.176.2.13.4.26 2005/07/27 02:53:14 marka Exp $ */ #include @@ -177,23 +177,29 @@ static void client_request(isc_task_t *task, isc_event_t *event); static void ns_client_dumpmessage(ns_client_t *client, const char *reason); void -ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest) { +ns_client_recursing(ns_client_t *client) { + REQUIRE(NS_CLIENT_VALID(client)); + + LOCK(&client->manager->lock); + ISC_LIST_UNLINK(*client->list, client, link); + ISC_LIST_APPEND(client->manager->recursing, client, link); + client->list = &client->manager->recursing; + UNLOCK(&client->manager->lock); +} + +void +ns_client_killoldestquery(ns_client_t *client) { ns_client_t *oldest; REQUIRE(NS_CLIENT_VALID(client)); LOCK(&client->manager->lock); - if (killoldest) { - oldest = ISC_LIST_HEAD(client->manager->recursing); - if (oldest != NULL) { - ns_query_cancel(oldest); - ISC_LIST_UNLINK(*oldest->list, oldest, link); - ISC_LIST_APPEND(client->manager->active, oldest, link); - oldest->list = &client->manager->active; - } + oldest = ISC_LIST_HEAD(client->manager->recursing); + if (oldest != NULL) { + ns_query_cancel(oldest); + ISC_LIST_UNLINK(*oldest->list, oldest, link); + ISC_LIST_APPEND(client->manager->active, oldest, link); + oldest->list = &client->manager->active; } - ISC_LIST_UNLINK(*client->list, client, link); - ISC_LIST_APPEND(client->manager->recursing, client, link); - client->list = &client->manager->recursing; UNLOCK(&client->manager->lock); } @@ -1603,8 +1609,7 @@ client_timeout(isc_task_t *task, isc_event_t *event) { } static isc_result_t -client_create(ns_clientmgr_t *manager, ns_client_t **clientp) -{ +client_create(ns_clientmgr_t *manager, ns_client_t **clientp) { ns_client_t *client; isc_result_t result; diff --git a/contrib/bind9/bin/named/control.c b/contrib/bind9/bin/named/control.c index b6ff6fe2cbc..c9d17abe027 100644 --- a/contrib/bind9/bin/named/control.c +++ b/contrib/bind9/bin/named/control.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: control.c,v 1.7.2.2.2.11 2004/09/03 03:43:31 marka Exp $ */ +/* $Id: control.c,v 1.7.2.2.2.14 2005/04/29 01:04:47 marka Exp $ */ #include @@ -37,6 +37,9 @@ #include #include #include +#ifdef HAVE_LIBSCF +#include +#endif static isc_boolean_t command_compare(const char *text, const char *command) { @@ -58,6 +61,9 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { isccc_sexpr_t *data; char *command; isc_result_t result; +#ifdef HAVE_LIBSCF + ns_smf_want_disable = 0; +#endif data = isccc_alist_lookup(message, "_data"); if (data == NULL) { @@ -92,11 +98,41 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) { } else if (command_compare(command, NS_COMMAND_RETRANSFER)) { result = ns_server_retransfercommand(ns_g_server, command); } else if (command_compare(command, NS_COMMAND_HALT)) { +#ifdef HAVE_LIBSCF + /* + * If we are managed by smf(5), AND in chroot, then + * we cannot connect to the smf repository, so just + * return with an appropriate message back to rndc. + */ + if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) { + result = ns_smf_add_message(text); + return (result); + } + /* + * If we are managed by smf(5) but not in chroot, + * try to disable ourselves the smf way. + */ + if (ns_smf_got_instance == 1 && ns_smf_chroot == 0) + ns_smf_want_disable = 1; + /* + * If ns_smf_got_instance = 0, ns_smf_chroot + * is not relevant and we fall through to + * isc_app_shutdown below. + */ +#endif ns_server_flushonshutdown(ns_g_server, ISC_FALSE); ns_os_shutdownmsg(command, text); isc_app_shutdown(); result = ISC_R_SUCCESS; } else if (command_compare(command, NS_COMMAND_STOP)) { +#ifdef HAVE_LIBSCF + if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) { + result = ns_smf_add_message(text); + return (result); + } + if (ns_smf_got_instance == 1 && ns_smf_chroot == 0) + ns_smf_want_disable = 1; +#endif ns_server_flushonshutdown(ns_g_server, ISC_TRUE); ns_os_shutdownmsg(command, text); isc_app_shutdown(); diff --git a/contrib/bind9/bin/named/include/named/client.h b/contrib/bind9/bin/named/include/named/client.h index 97951a41683..7097a3bb05b 100644 --- a/contrib/bind9/bin/named/include/named/client.h +++ b/contrib/bind9/bin/named/include/named/client.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: client.h,v 1.60.2.2.10.8 2004/07/23 02:56:52 marka Exp $ */ +/* $Id: client.h,v 1.60.2.2.10.10 2005/07/29 00:13:08 marka Exp $ */ #ifndef NAMED_CLIENT_H #define NAMED_CLIENT_H 1 @@ -322,12 +322,18 @@ ns_client_aclmsg(const char *msg, dns_name_t *name, dns_rdatatype_t type, DNS_RDATACLASS_FORMATSIZE + sizeof(x) + sizeof("'/'")) void -ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest); -/* +ns_client_recursing(ns_client_t *client); +/*% * Add client to end of recursing list. If 'killoldest' is true * kill the oldest recursive client (list head). */ +void +ns_client_killoldestquery(ns_client_t *client); +/*% + * Kill the oldest recursive query (recursing list head). + */ + void ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager); /* 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 00000000000..49aa31dc5c0 --- /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 + +#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/bin/named/log.c b/contrib/bind9/bin/named/log.c index 31af4bdd13c..9032af795d4 100644 --- a/contrib/bind9/bin/named/log.c +++ b/contrib/bind9/bin/named/log.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.c,v 1.33.2.1.10.4 2004/03/08 09:04:14 marka Exp $ */ +/* $Id: log.c,v 1.33.2.1.10.6 2005/05/24 23:58:17 marka Exp $ */ #include @@ -154,6 +154,9 @@ ns_log_setdefaultchannels(isc_logconfig_t *lcfg) { isc_result_t ns_log_setsafechannels(isc_logconfig_t *lcfg) { isc_result_t result; +#if ISC_FACILITY != LOG_DAEMON + isc_logdestination_t destination; +#endif if (! ns_g_logstderr) { result = isc_log_createchannel(lcfg, "default_debug", @@ -172,6 +175,15 @@ ns_log_setsafechannels(isc_logconfig_t *lcfg) { isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel); } +#if ISC_FACILITY != LOG_DAEMON + destination.facility = ISC_FACILITY; + result = isc_log_createchannel(lcfg, "default_syslog", + ISC_LOG_TOSYSLOG, ISC_LOG_INFO, + &destination, 0); + if (result != ISC_R_SUCCESS) + goto cleanup; +#endif + result = ISC_R_SUCCESS; cleanup: diff --git a/contrib/bind9/bin/named/lwresd.8 b/contrib/bind9/bin/named/lwresd.8 index bbc177d0ff6..58f24b06237 100644 --- a/contrib/bind9/bin/named/lwresd.8 +++ b/contrib/bind9/bin/named/lwresd.8 @@ -1,135 +1,135 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwresd.8,v 1.13.208.2 2004/06/03 05:35:47 marka Exp $ +.\" $Id: lwresd.8,v 1.13.208.5 2005/10/13 02:33:47 marka Exp $ .\" -.TH "LWRESD" "8" "June 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRESD" "8" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwresd \- lightweight resolver daemon -.SH SYNOPSIS -.sp -\fBlwresd\fR [ \fB-C \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-i \fIpid-file\fB\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-P \fIport\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ] +.SH "SYNOPSIS" +.HP 7 +\fBlwresd\fR [\fB\-C\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-i\ \fR\fB\fIpid\-file\fR\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-P\ \fR\fB\fIport\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] .SH "DESCRIPTION" .PP -\fBlwresd\fR is the daemon providing name lookup -services to clients that use the BIND 9 lightweight resolver -library. It is essentially a stripped-down, caching-only name -server that answers queries using the BIND 9 lightweight -resolver protocol rather than the DNS protocol. +\fBlwresd\fR +is the daemon providing name lookup services to clients that use the BIND 9 lightweight resolver library. It is essentially a stripped\-down, caching\-only name server that answers queries using the BIND 9 lightweight resolver protocol rather than the DNS protocol. .PP -\fBlwresd\fR listens for resolver queries on a -UDP port on the IPv4 loopback interface, 127.0.0.1. This -means that \fBlwresd\fR can only be used by -processes running on the local machine. By default UDP port -number 921 is used for lightweight resolver requests and -responses. +\fBlwresd\fR +listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that +\fBlwresd\fR +can only be used by processes running on the local machine. By default UDP port number 921 is used for lightweight resolver requests and responses. .PP -Incoming lightweight resolver requests are decoded by the -server which then resolves them using the DNS protocol. When -the DNS lookup completes, \fBlwresd\fR encodes -the answers in the lightweight resolver format and returns -them to the client that made the request. +Incoming lightweight resolver requests are decoded by the server which then resolves them using the DNS protocol. When the DNS lookup completes, +\fBlwresd\fR +encodes the answers in the lightweight resolver format and returns them to the client that made the request. .PP -If \fI/etc/resolv.conf\fR contains any -\fBnameserver\fR entries, \fBlwresd\fR -sends recursive DNS queries to those servers. This is similar -to the use of forwarders in a caching name server. If no -\fBnameserver\fR entries are present, or if -forwarding fails, \fBlwresd\fR resolves the -queries autonomously starting at the root name servers, using -a built-in list of root server hints. +If +\fI/etc/resolv.conf\fR +contains any +\fBnameserver\fR +entries, +\fBlwresd\fR +sends recursive DNS queries to those servers. This is similar to the use of forwarders in a caching name server. If no +\fBnameserver\fR +entries are present, or if forwarding fails, +\fBlwresd\fR +resolves the queries autonomously starting at the root name servers, using a built\-in list of root server hints. .SH "OPTIONS" .TP -\fB-C \fIconfig-file\fB\fR -Use \fIconfig-file\fR as the -configuration file instead of the default, +\-C \fIconfig\-file\fR +Use +\fIconfig\-file\fR +as the configuration file instead of the default, \fI/etc/resolv.conf\fR. .TP -\fB-d \fIdebug-level\fB\fR -Set the daemon's debug level to \fIdebug-level\fR. -Debugging traces from \fBlwresd\fR become -more verbose as the debug level increases. +\-d \fIdebug\-level\fR +Set the daemon's debug level to +\fIdebug\-level\fR. Debugging traces from +\fBlwresd\fR +become more verbose as the debug level increases. .TP -\fB-f\fR +\-f Run the server in the foreground (i.e. do not daemonize). .TP -\fB-g\fR -Run the server in the foreground and force all logging -to \fIstderr\fR. +\-g +Run the server in the foreground and force all logging to +\fIstderr\fR. .TP -\fB-n \fI#cpus\fB\fR -Create \fI#cpus\fR worker threads -to take advantage of multiple CPUs. If not specified, -\fBlwresd\fR will try to determine the -number of CPUs present and create one thread per CPU. -If it is unable to determine the number of CPUs, a -single worker thread will be created. +\-n \fI#cpus\fR +Create +\fI#cpus\fR +worker threads to take advantage of multiple CPUs. If not specified, +\fBlwresd\fR +will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created. .TP -\fB-P \fIport\fB\fR +\-P \fIport\fR Listen for lightweight resolver queries on port -\fIport\fR. If -not specified, the default is port 921. +\fIport\fR. If not specified, the default is port 921. .TP -\fB-p \fIport\fB\fR -Send DNS lookups to port \fIport\fR. If not -specified, the default is port 53. This provides a -way of testing the lightweight resolver daemon with a -name server that listens for queries on a non-standard -port number. +\-p \fIport\fR +Send DNS lookups to port +\fIport\fR. If not specified, the default is port 53. This provides a way of testing the lightweight resolver daemon with a name server that listens for queries on a non\-standard port number. .TP -\fB-s\fR -Write memory usage statistics to \fIstdout\fR +\-s +Write memory usage statistics to +\fIstdout\fR on exit. -.sp .RS .B "Note:" -This option is mainly of interest to BIND 9 developers -and may be removed or changed in a future release. +This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release. .RE -.sp .TP -\fB-t \fIdirectory\fB\fR -\fBchroot()\fR to \fIdirectory\fR after -processing the command line arguments, but before -reading the configuration file. -.sp +\-t \fIdirectory\fR +\fBchroot()\fR +to +\fIdirectory\fR +after processing the command line arguments, but before reading the configuration file. .RS .B "Warning:" This option should be used in conjunction with the -\fB-u\fR option, as chrooting a process -running as root doesn't enhance security on most -systems; the way \fBchroot()\fR is -defined allows a process with root privileges to -escape a chroot jail. +\fB\-u\fR +option, as chrooting a process running as root doesn't enhance security on most systems; the way +\fBchroot()\fR +is defined allows a process with root privileges to escape a chroot jail. .RE -.sp .TP -\fB-u \fIuser\fB\fR -\fBsetuid()\fR to \fIuser\fR after completing -privileged operations, such as creating sockets that -listen on privileged ports. +\-u \fIuser\fR +\fBsetuid()\fR +to +\fIuser\fR +after completing privileged operations, such as creating sockets that listen on privileged ports. .TP -\fB-v\fR +\-v Report the version number and exit. .SH "FILES" .TP -\fB\fI/etc/resolv.conf\fB\fR +\fI/etc/resolv.conf\fR The default configuration file. .TP -\fB\fI/var/run/lwresd.pid\fB\fR -The default process-id file. +\fI/var/run/lwresd.pid\fR +The default process\-id file. .SH "SEE ALSO" .PP \fBnamed\fR(8), diff --git a/contrib/bind9/bin/named/lwresd.docbook b/contrib/bind9/bin/named/lwresd.docbook index 46314c2614e..c1f500bb830 100644 --- a/contrib/bind9/bin/named/lwresd.docbook +++ b/contrib/bind9/bin/named/lwresd.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -29,6 +31,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwresd lightweight resolver daemon diff --git a/contrib/bind9/bin/named/lwresd.html b/contrib/bind9/bin/named/lwresd.html index afe7af22f48..439153aa826 100644 --- a/contrib/bind9/bin/named/lwresd.html +++ b/contrib/bind9/bin/named/lwresd.html @@ -1,497 +1,189 @@ - - - - -lwresd

lwresd

Name

lwresd -- lightweight resolver daemon

Synopsis

lwresd [-C config-file] [-d debug-level] [-f] [-g] [-i pid-file] [-n #cpus] [-P port] [-p port] [-s] [-t directory] [-u user] [-v]

DESCRIPTION

lwresd is the daemon providing name lookup + + + + +lwresd + + +

+
+
+

Name

+

lwresd — lightweight resolver daemon

+
+
+

Synopsis

+

lwresd [-C config-file] [-d debug-level] [-f] [-g] [-i pid-file] [-n #cpus] [-P port] [-p port] [-s] [-t directory] [-u user] [-v]

+
+
+

DESCRIPTION

+

+ lwresd is the daemon providing name lookup services to clients that use the BIND 9 lightweight resolver library. It is essentially a stripped-down, caching-only name server that answers queries using the BIND 9 lightweight resolver protocol rather than the DNS protocol. -

lwresd listens for resolver queries on a +

+

+ lwresd listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This - means that lwresd can only be used by + means that lwresd can only be used by processes running on the local machine. By default UDP port number 921 is used for lightweight resolver requests and responses. -

Incoming lightweight resolver requests are decoded by the +

+

+ Incoming lightweight resolver requests are decoded by the server which then resolves them using the DNS protocol. When - the DNS lookup completes, lwresd encodes + the DNS lookup completes, lwresd encodes the answers in the lightweight resolver format and returns them to the client that made the request. -

If /etc/resolv.conf contains any - nameserver entries, lwresd +

+

+ If /etc/resolv.conf contains any + nameserver entries, lwresd sends recursive DNS queries to those servers. This is similar to the use of forwarders in a caching name server. If no - nameserver entries are present, or if - forwarding fails, lwresd resolves the + nameserver entries are present, or if + forwarding fails, lwresd resolves the queries autonomously starting at the root name servers, using a built-in list of root server hints. -

OPTIONS

-C config-file

Use config-file as the +

+
+
+

OPTIONS

+
+
-C config-file
+

+ Use config-file as the configuration file instead of the default, - /etc/resolv.conf. -

-d debug-level

Set the daemon's debug level to debug-level. - Debugging traces from lwresd become + /etc/resolv.conf. +

+
-d debug-level
+

+ Set the daemon's debug level to debug-level. + Debugging traces from lwresd become more verbose as the debug level increases. -

-f

Run the server in the foreground (i.e. do not daemonize). -

-g

Run the server in the foreground and force all logging - to stderr. -

-n #cpus

Create #cpus worker threads +

+
-f
+

+ Run the server in the foreground (i.e. do not daemonize). +

+
-g
+

+ Run the server in the foreground and force all logging + to stderr. +

+
-n #cpus
+

+ Create #cpus worker threads to take advantage of multiple CPUs. If not specified, - lwresd will try to determine the + lwresd will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created. -

-P port

Listen for lightweight resolver queries on port - port. If +

+
-P port
+

+ Listen for lightweight resolver queries on port + port. If not specified, the default is port 921. -

-p port

Send DNS lookups to port port. If not +

+
-p port
+

+ Send DNS lookups to port port. If not specified, the default is port 53. This provides a way of testing the lightweight resolver daemon with a name server that listens for queries on a non-standard port number. -

-s

Write memory usage statistics to stdout +

+
-s
+
+

+ Write memory usage statistics to stdout on exit. -

Note: This option is mainly of interest to BIND 9 developers +

+
+

Note

+

+ This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release. -

-t directory

chroot() to directory after +

+
+ +
-t directory
+
+

+ chroot() to directory after processing the command line arguments, but before reading the configuration file. -

Warning

This option should be used in conjunction with the - -u option, as chrooting a process +

+
+

Warning

+

+ This option should be used in conjunction with the + -u option, as chrooting a process running as root doesn't enhance security on most - systems; the way chroot() is + systems; the way chroot() is defined allows a process with root privileges to escape a chroot jail. -

-u user

setuid() to user after completing +

+
+ +
-u user
+

+ setuid() to user after completing privileged operations, such as creating sockets that listen on privileged ports. -

-v

Report the version number and exit. -

FILES

/etc/resolv.conf

The default configuration file. -

/var/run/lwresd.pid

The default process-id file. -

SEE ALSO

named(8), - lwres(3), - resolver(5). -

AUTHOR

Internet Systems Consortium -

+

+
-v
+

+ Report the version number and exit. +

+
+ +
+

FILES

+
+
/etc/resolv.conf
+

+ The default configuration file. +

+
/var/run/lwresd.pid
+

+ The default process-id file. +

+
+
+
+

SEE ALSO

+

+ named(8), + lwres(3), + resolver(5). +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+ + diff --git a/contrib/bind9/bin/named/main.c b/contrib/bind9/bin/named/main.c index f78ea247c8a..c155291d6ca 100644 --- a/contrib/bind9/bin/named/main.c +++ b/contrib/bind9/bin/named/main.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: main.c,v 1.119.2.3.2.17 2004/10/25 00:42:54 marka Exp $ */ +/* $Id: main.c,v 1.119.2.3.2.22 2005/04/29 01:04:47 marka Exp $ */ #include @@ -47,10 +47,6 @@ #include -#ifdef HAVE_LIBSCF -#include -#endif - /* * Defining NS_MAIN provides storage declarations (rather than extern) * for variables in named/globals.h. @@ -66,6 +62,9 @@ #include #include #include +#ifdef HAVE_LIBSCF +#include +#endif /* * Include header files for database drivers here. @@ -540,6 +539,9 @@ destroy_managers(void) { static void setup(void) { isc_result_t result; +#ifdef HAVE_LIBSCF + char *instance = NULL; +#endif /* * Get the user and group information before changing the root @@ -555,6 +557,18 @@ setup(void) { ns_os_opendevnull(); +#ifdef HAVE_LIBSCF + /* Check if named is under smf control, before chroot. */ + result = ns_smf_get_instance(&instance, 0, ns_g_mctx); + /* We don't care about instance, just check if we got one. */ + if (result == ISC_R_SUCCESS) + ns_smf_got_instance = 1; + else + ns_smf_got_instance = 0; + if (instance != NULL) + isc_mem_free(ns_g_mctx, instance); +#endif /* HAVE_LIBSCF */ + #ifdef PATH_RANDOMDEV /* * Initialize system's random device as fallback entropy source @@ -699,92 +713,73 @@ ns_main_setmemstats(const char *filename) { #ifdef HAVE_LIBSCF /* - * Get FMRI for the current named process + * Get FMRI for the named process. */ -static char * -scf_get_ins_name(void) { +isc_result_t +ns_smf_get_instance(char **ins_name, int debug, isc_mem_t *mctx) { scf_handle_t *h = NULL; int namelen; - char *ins_name; + char *instance; + + REQUIRE(ins_name != NULL && *ins_name == NULL); if ((h = scf_handle_create(SCF_VERSION)) == NULL) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "scf_handle_create() failed: %s", - scf_strerror(scf_error())); - return (NULL); + if (debug) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_handle_create() failed: %s", + scf_strerror(scf_error())); + return (ISC_R_FAILURE); } if (scf_handle_bind(h) == -1) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "scf_handle_bind() failed: %s", - scf_strerror(scf_error())); + if (debug) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_handle_bind() failed: %s", + scf_strerror(scf_error())); scf_handle_destroy(h); - return (NULL); + return (ISC_R_FAILURE); } if ((namelen = scf_myname(h, NULL, 0)) == -1) { - isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, - NS_LOGMODULE_MAIN, ISC_LOG_INFO, - "scf_myname() failed: %s", - scf_strerror(scf_error())); + if (debug) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_myname() failed: %s", + scf_strerror(scf_error())); scf_handle_destroy(h); - return (NULL); + return (ISC_R_FAILURE); } - if ((ins_name = malloc(namelen + 1)) == NULL) { + if ((instance = isc_mem_allocate(mctx, namelen + 1)) == NULL) { UNEXPECTED_ERROR(__FILE__, __LINE__, - "scf_get_ins_named() memory " + "ns_smf_get_instance memory " "allocation failed: %s", isc_result_totext(ISC_R_NOMEMORY)); scf_handle_destroy(h); - return (NULL); + return (ISC_R_FAILURE); } - if (scf_myname(h, ins_name, namelen + 1) == -1) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "scf_myname() failed: %s", - scf_strerror(scf_error())); + if (scf_myname(h, instance, namelen + 1) == -1) { + if (debug) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "scf_myname() failed: %s", + scf_strerror(scf_error())); scf_handle_destroy(h); - free(ins_name); - return (NULL); + isc_mem_free(mctx, instance); + return (ISC_R_FAILURE); } scf_handle_destroy(h); - isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN, - ISC_LOG_INFO, "instance name:%s", ins_name); - - return (ins_name); + *ins_name = instance; + return (ISC_R_SUCCESS); } - -static void -scf_cleanup(void) { - char *s; - char *ins_name; - - if ((ins_name = scf_get_ins_name()) != NULL) { - if ((s = smf_get_state(ins_name)) != NULL) { - if ((strcmp(SCF_STATE_STRING_ONLINE, s) == 0) || - (strcmp(SCF_STATE_STRING_DEGRADED, s) == 0)) { - if (smf_disable_instance(ins_name, 0) != 0) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "smf_disable_instance() failed: %s", - scf_strerror(scf_error())); - } - } - free(s); - } else { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "smf_get_state() failed: %s", - scf_strerror(scf_error())); - } - free(ins_name); - } -} -#endif +#endif /* HAVE_LIBSCF */ int main(int argc, char *argv[]) { isc_result_t result; +#ifdef HAVE_LIBSCF + char *instance = NULL; +#endif /* * Record version in core image. @@ -856,8 +851,20 @@ main(int argc, char *argv[]) { } while (result != ISC_R_SUCCESS); #ifdef HAVE_LIBSCF - scf_cleanup(); -#endif + if (ns_smf_want_disable == 1) { + result = ns_smf_get_instance(&instance, 1, ns_g_mctx); + if (result == ISC_R_SUCCESS && instance != NULL) { + if (smf_disable_instance(instance, 0) != 0) + UNEXPECTED_ERROR(__FILE__, __LINE__, + "smf_disable_instance() ", + "failed for %s : %s", + instance, + scf_strerror(scf_error())); + } + if (instance != NULL) + isc_mem_free(ns_g_mctx, instance); + } +#endif /* HAVE_LIBSCF */ cleanup(); diff --git a/contrib/bind9/bin/named/named.8 b/contrib/bind9/bin/named/named.8 index cd120ddc6f6..e072c169be3 100644 --- a/contrib/bind9/bin/named/named.8 +++ b/contrib/bind9/bin/named/named.8 @@ -1,177 +1,182 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 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, +.\" 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: named.8,v 1.17.208.3 2004/06/03 05:35:47 marka Exp $ +.\" $Id: named.8,v 1.17.208.6 2005/10/13 02:33:46 marka Exp $ .\" -.TH "NAMED" "8" "June 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "NAMED" "8" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" named \- Internet domain name server -.SH SYNOPSIS -.sp -\fBnamed\fR [ \fB-4\fR ] [ \fB-6\fR ] [ \fB-c \fIconfig-file\fB\fR ] [ \fB-d \fIdebug-level\fB\fR ] [ \fB-f\fR ] [ \fB-g\fR ] [ \fB-n \fI#cpus\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-s\fR ] [ \fB-t \fIdirectory\fB\fR ] [ \fB-u \fIuser\fB\fR ] [ \fB-v\fR ] [ \fB-x \fIcache-file\fB\fR ] +.SH "SYNOPSIS" +.HP 6 +\fBnamed\fR [\fB\-4\fR] [\fB\-6\fR] [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR] .SH "DESCRIPTION" .PP -\fBnamed\fR is a Domain Name System (DNS) server, -part of the BIND 9 distribution from ISC. For more -information on the DNS, see RFCs 1033, 1034, and 1035. +\fBnamed\fR +is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFCs 1033, 1034, and 1035. .PP -When invoked without arguments, \fBnamed\fR will -read the default configuration file -\fI/etc/named.conf\fR, read any initial -data, and listen for queries. +When invoked without arguments, +\fBnamed\fR +will read the default configuration file +\fI/etc/named.conf\fR, read any initial data, and listen for queries. .SH "OPTIONS" .TP -\fB-4\fR +\-4 Use IPv4 only even if the host machine is capable of IPv6. -\fB-4\fR and \fB-6\fR are mutually -exclusive. +\fB\-4\fR +and +\fB\-6\fR +are mutually exclusive. .TP -\fB-6\fR +\-6 Use IPv6 only even if the host machine is capable of IPv4. -\fB-4\fR and \fB-6\fR are mutually -exclusive. +\fB\-4\fR +and +\fB\-6\fR +are mutually exclusive. .TP -\fB-c \fIconfig-file\fB\fR -Use \fIconfig-file\fR as the -configuration file instead of the default, -\fI/etc/named.conf\fR. To -ensure that reloading the configuration file continues -to work after the server has changed its working -directory due to to a possible -\fBdirectory\fR option in the configuration -file, \fIconfig-file\fR should be -an absolute pathname. +\-c \fIconfig\-file\fR +Use +\fIconfig\-file\fR +as the configuration file instead of the default, +\fI/etc/named.conf\fR. To ensure that reloading the configuration file continues to work after the server has changed its working directory due to to a possible +\fBdirectory\fR +option in the configuration file, +\fIconfig\-file\fR +should be an absolute pathname. .TP -\fB-d \fIdebug-level\fB\fR -Set the daemon's debug level to \fIdebug-level\fR. -Debugging traces from \fBnamed\fR become -more verbose as the debug level increases. +\-d \fIdebug\-level\fR +Set the daemon's debug level to +\fIdebug\-level\fR. Debugging traces from +\fBnamed\fR +become more verbose as the debug level increases. .TP -\fB-f\fR +\-f Run the server in the foreground (i.e. do not daemonize). .TP -\fB-g\fR -Run the server in the foreground and force all logging -to \fIstderr\fR. +\-g +Run the server in the foreground and force all logging to +\fIstderr\fR. .TP -\fB-n \fI#cpus\fB\fR -Create \fI#cpus\fR worker threads -to take advantage of multiple CPUs. If not specified, -\fBnamed\fR will try to determine the -number of CPUs present and create one thread per CPU. -If it is unable to determine the number of CPUs, a -single worker thread will be created. +\-n \fI#cpus\fR +Create +\fI#cpus\fR +worker threads to take advantage of multiple CPUs. If not specified, +\fBnamed\fR +will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created. .TP -\fB-p \fIport\fB\fR -Listen for queries on port \fIport\fR. If not -specified, the default is port 53. +\-p \fIport\fR +Listen for queries on port +\fIport\fR. If not specified, the default is port 53. .TP -\fB-s\fR -Write memory usage statistics to \fIstdout\fR on exit. -.sp +\-s +Write memory usage statistics to +\fIstdout\fR +on exit. .RS .B "Note:" -This option is mainly of interest to BIND 9 developers -and may be removed or changed in a future release. +This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release. .RE -.sp .TP -\fB-t \fIdirectory\fB\fR -\fBchroot()\fR to \fIdirectory\fR after -processing the command line arguments, but before -reading the configuration file. -.sp +\-t \fIdirectory\fR +\fBchroot()\fR +to +\fIdirectory\fR +after processing the command line arguments, but before reading the configuration file. .RS .B "Warning:" This option should be used in conjunction with the -\fB-u\fR option, as chrooting a process -running as root doesn't enhance security on most -systems; the way \fBchroot()\fR is -defined allows a process with root privileges to -escape a chroot jail. +\fB\-u\fR +option, as chrooting a process running as root doesn't enhance security on most systems; the way +\fBchroot()\fR +is defined allows a process with root privileges to escape a chroot jail. .RE -.sp .TP -\fB-u \fIuser\fB\fR -\fBsetuid()\fR to \fIuser\fR after completing -privileged operations, such as creating sockets that -listen on privileged ports. -.sp +\-u \fIuser\fR +\fBsetuid()\fR +to +\fIuser\fR +after completing privileged operations, such as creating sockets that listen on privileged ports. .RS .B "Note:" -On Linux, \fBnamed\fR uses the kernel's -capability mechanism to drop all root privileges -except the ability to \fBbind()\fR to a -privileged port and set process resource limits. -Unfortunately, this means that the \fB-u\fR -option only works when \fBnamed\fR is run -on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or -later, since previous kernels did not allow privileges -to be retained after \fBsetuid()\fR. +On Linux, +\fBnamed\fR +uses the kernel's capability mechanism to drop all root privileges except the ability to +\fBbind()\fR +to a privileged port and set process resource limits. Unfortunately, this means that the +\fB\-u\fR +option only works when +\fBnamed\fR +is run on kernel 2.2.18 or later, or kernel 2.3.99\-pre3 or later, since previous kernels did not allow privileges to be retained after +\fBsetuid()\fR. .RE -.sp .TP -\fB-v\fR +\-v Report the version number and exit. .TP -\fB-x \fIcache-file\fB\fR -Load data from \fIcache-file\fR into the -cache of the default view. -.sp +\-x \fIcache\-file\fR +Load data from +\fIcache\-file\fR +into the cache of the default view. .RS .B "Warning:" -This option must not be used. It is only of interest -to BIND 9 developers and may be removed or changed in a -future release. +This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release. .RE -.sp .SH "SIGNALS" .PP -In routine operation, signals should not be used to control -the nameserver; \fBrndc\fR should be used -instead. +In routine operation, signals should not be used to control the nameserver; +\fBrndc\fR +should be used instead. .TP -\fBSIGHUP\fR +SIGHUP Force a reload of the server. .TP -\fBSIGINT, SIGTERM\fR +SIGINT, SIGTERM Shut down the server. .PP The result of sending any other signals to the server is undefined. -.PP .SH "CONFIGURATION" .PP -The \fBnamed\fR configuration file is too complex -to describe in detail here. A complete description is -provided in the \fIBIND 9 Administrator Reference -Manual\fR. +The +\fBnamed\fR +configuration file is too complex to describe in detail here. A complete description is provided in the +BIND 9 Administrator Reference Manual. .SH "FILES" .TP -\fB\fI/etc/named.conf\fB\fR +\fI/etc/named.conf\fR The default configuration file. .TP -\fB\fI/var/run/named.pid\fB\fR -The default process-id file. +\fI/var/run/named.pid\fR +The default process\-id file. .SH "SEE ALSO" .PP -\fIRFC 1033\fR, -\fIRFC 1034\fR, -\fIRFC 1035\fR, +RFC 1033, +RFC 1034, +RFC 1035, \fBrndc\fR(8), \fBlwresd\fR(8), -\fIBIND 9 Administrator Reference Manual\fR. +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/named/named.conf.5 b/contrib/bind9/bin/named/named.conf.5 index 2b7387b9555..d0b690b1b5a 100644 --- a/contrib/bind9/bin/named/named.conf.5 +++ b/contrib/bind9/bin/named/named.conf.5 @@ -1,32 +1,40 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" +.\" Copyright (C) 2004, 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, +.\" 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: named.conf.5,v 1.1.4.3 2004/10/18 02:33:06 marka Exp $ +.\" $Id: named.conf.5,v 1.1.4.6 2005/10/13 02:33:47 marka Exp $ .\" -.TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "\\FINAMED.CONF\\FR" "5" "Aug 13, 2004" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" named.conf \- configuration file for named -.SH SYNOPSIS -.sp +.SH "SYNOPSIS" +.HP 11 \fBnamed.conf\fR .SH "DESCRIPTION" .PP -\fInamed.conf\fR is the configuration file for -\fBnamed\fR. Statements are enclosed -in braces and terminated with a semi-colon. Clauses in -the statements are also semi-colon terminated. The usual -comment styles are supported: +\fInamed.conf\fR +is the configuration file for +\fBnamed\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported: .PP C style: /* */ .PP @@ -37,7 +45,6 @@ Unix style: # to end of line .sp .nf acl \fIstring\fR { \fIaddress_match_element\fR; ... }; -.sp .fi .SH "KEY" .sp @@ -46,7 +53,6 @@ key \fIdomain_name\fR { algorithm \fIstring\fR; secret \fIstring\fR; }; -.sp .fi .SH "MASTERS" .sp @@ -55,7 +61,6 @@ masters \fIstring\fR [ port \fIinteger\fR ] { ( \fImasters\fR | \fIipv4_address\fR [port \fIinteger\fR] | \fIipv6_address\fR [port \fIinteger\fR] ) [ key \fIstring\fR ]; ... }; -.sp .fi .SH "SERVER" .sp @@ -63,27 +68,24 @@ masters \fIstring\fR [ port \fIinteger\fR ] { server ( \fIipv4_address\fR | \fIipv6_address\fR ) { bogus \fIboolean\fR; edns \fIboolean\fR; - provide-ixfr \fIboolean\fR; - request-ixfr \fIboolean\fR; + provide\-ixfr \fIboolean\fR; + request\-ixfr \fIboolean\fR; keys \fIserver_key\fR; transfers \fIinteger\fR; - transfer-format ( many-answers | one-answer ); - transfer-source ( \fIipv4_address\fR | * ) + transfer\-format ( many\-answers | one\-answer ); + transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - transfer-source-v6 ( \fIipv6_address\fR | * ) + transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - - support-ixfr \fIboolean\fR; // obsolete + support\-ixfr \fIboolean\fR; // obsolete }; -.sp .fi -.SH "TRUSTED-KEYS" +.SH "TRUSTED\-KEYS" .sp .nf -trusted-keys { +trusted\-keys { \fIdomain_name\fR \fIflags\fR \fIprotocol\fR \fIalgorithm\fR \fIkey\fR; ... }; -.sp .fi .SH "CONTROLS" .sp @@ -95,7 +97,6 @@ controls { [ keys { \fIstring\fR; ... } ]; unix \fIunsupported\fR; // not implemented }; -.sp .fi .SH "LOGGING" .sp @@ -107,363 +108,325 @@ logging { null; stderr; severity \fIlog_severity\fR; - print-time \fIboolean\fR; - print-severity \fIboolean\fR; - print-category \fIboolean\fR; + print\-time \fIboolean\fR; + print\-severity \fIboolean\fR; + print\-category \fIboolean\fR; }; category \fIstring\fR { \fIstring\fR; ... }; }; -.sp .fi .SH "LWRES" .sp .nf lwres { - listen-on [ port \fIinteger\fR ] { + listen\-on [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; view \fIstring\fR \fIoptional_class\fR; search { \fIstring\fR; ... }; ndots \fIinteger\fR; }; -.sp .fi .SH "OPTIONS" .sp .nf options { - avoid-v4-udp-ports { \fIport\fR; ... }; - avoid-v6-udp-ports { \fIport\fR; ... }; + avoid\-v4\-udp\-ports { \fIport\fR; ... }; + avoid\-v6\-udp\-ports { \fIport\fR; ... }; blackhole { \fIaddress_match_element\fR; ... }; coresize \fIsize\fR; datasize \fIsize\fR; directory \fIquoted_string\fR; - dump-file \fIquoted_string\fR; + dump\-file \fIquoted_string\fR; files \fIsize\fR; - heartbeat-interval \fIinteger\fR; - host-statistics \fIboolean\fR; // not implemented - host-statistics-max \fInumber\fR; // not implemented + heartbeat\-interval \fIinteger\fR; + host\-statistics \fIboolean\fR; // not implemented + host\-statistics\-max \fInumber\fR; // not implemented hostname ( \fIquoted_string\fR | none ); - interface-interval \fIinteger\fR; - listen-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; - listen-on-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; - match-mapped-addresses \fIboolean\fR; - memstatistics-file \fIquoted_string\fR; - pid-file ( \fIquoted_string\fR | none ); + interface\-interval \fIinteger\fR; + listen\-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; + listen\-on\-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... }; + match\-mapped\-addresses \fIboolean\fR; + memstatistics\-file \fIquoted_string\fR; + pid\-file ( \fIquoted_string\fR | none ); port \fIinteger\fR; querylog \fIboolean\fR; - recursing-file \fIquoted_string\fR; - random-device \fIquoted_string\fR; - recursive-clients \fIinteger\fR; - serial-query-rate \fIinteger\fR; - server-id ( \fIquoted_string\fR | none |; + recursing\-file \fIquoted_string\fR; + random\-device \fIquoted_string\fR; + recursive\-clients \fIinteger\fR; + serial\-query\-rate \fIinteger\fR; + server\-id ( \fIquoted_string\fR | none |; stacksize \fIsize\fR; - statistics-file \fIquoted_string\fR; - statistics-interval \fIinteger\fR; // not yet implemented - tcp-clients \fIinteger\fR; - tcp-listen-queue \fIinteger\fR; - tkey-dhkey \fIquoted_string\fR \fIinteger\fR; - tkey-gssapi-credential \fIquoted_string\fR; - tkey-domain \fIquoted_string\fR; - transfers-per-ns \fIinteger\fR; - transfers-in \fIinteger\fR; - transfers-out \fIinteger\fR; - use-ixfr \fIboolean\fR; + statistics\-file \fIquoted_string\fR; + statistics\-interval \fIinteger\fR; // not yet implemented + tcp\-clients \fIinteger\fR; + tcp\-listen\-queue \fIinteger\fR; + tkey\-dhkey \fIquoted_string\fR \fIinteger\fR; + tkey\-gssapi\-credential \fIquoted_string\fR; + tkey\-domain \fIquoted_string\fR; + transfers\-per\-ns \fIinteger\fR; + transfers\-in \fIinteger\fR; + transfers\-out \fIinteger\fR; + use\-ixfr \fIboolean\fR; version ( \fIquoted_string\fR | none ); - allow-recursion { \fIaddress_match_element\fR; ... }; + allow\-recursion { \fIaddress_match_element\fR; ... }; sortlist { \fIaddress_match_element\fR; ... }; topology { \fIaddress_match_element\fR; ... }; // not implemented - auth-nxdomain \fIboolean\fR; // default changed - minimal-responses \fIboolean\fR; + auth\-nxdomain \fIboolean\fR; // default changed + minimal\-responses \fIboolean\fR; recursion \fIboolean\fR; - rrset-order { + rrset\-order { [ class \fIstring\fR ] [ type \fIstring\fR ] [ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ... }; - provide-ixfr \fIboolean\fR; - request-ixfr \fIboolean\fR; - rfc2308-type1 \fIboolean\fR; // not yet implemented - additional-from-auth \fIboolean\fR; - additional-from-cache \fIboolean\fR; - query-source \fIquerysource4\fR; - query-source-v6 \fIquerysource6\fR; - cleaning-interval \fIinteger\fR; - min-roots \fIinteger\fR; // not implemented - lame-ttl \fIinteger\fR; - max-ncache-ttl \fIinteger\fR; - max-cache-ttl \fIinteger\fR; - transfer-format ( many-answers | one-answer ); - max-cache-size \fIsize_no_default\fR; - check-names ( master | slave | response ) + provide\-ixfr \fIboolean\fR; + request\-ixfr \fIboolean\fR; + rfc2308\-type1 \fIboolean\fR; // not yet implemented + additional\-from\-auth \fIboolean\fR; + additional\-from\-cache \fIboolean\fR; + query\-source \fIquerysource4\fR; + query\-source\-v6 \fIquerysource6\fR; + cleaning\-interval \fIinteger\fR; + min\-roots \fIinteger\fR; // not implemented + lame\-ttl \fIinteger\fR; + max\-ncache\-ttl \fIinteger\fR; + max\-cache\-ttl \fIinteger\fR; + transfer\-format ( many\-answers | one\-answer ); + max\-cache\-size \fIsize_no_default\fR; + check\-names ( master | slave | response ) ( fail | warn | ignore ); - cache-file \fIquoted_string\fR; - suppress-initial-notify \fIboolean\fR; // not yet implemented - preferred-glue \fIstring\fR; - dual-stack-servers [ port \fIinteger\fR ] { + cache\-file \fIquoted_string\fR; + suppress\-initial\-notify \fIboolean\fR; // not yet implemented + preferred\-glue \fIstring\fR; + dual\-stack\-servers [ port \fIinteger\fR ] { ( \fIquoted_string\fR [port \fIinteger\fR] | \fIipv4_address\fR [port \fIinteger\fR] | \fIipv6_address\fR [port \fIinteger\fR] ); ... } - edns-udp-size \fIinteger\fR; - root-delegation-only [ exclude { \fIquoted_string\fR; ... } ]; - disable-algorithms \fIstring\fR { \fIstring\fR; ... }; - dnssec-enable \fIboolean\fR; - dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR; - dnssec-must-be-secure \fIstring\fR \fIboolean\fR; - + edns\-udp\-size \fIinteger\fR; + root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ]; + disable\-algorithms \fIstring\fR { \fIstring\fR; ... }; + dnssec\-enable \fIboolean\fR; + dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR; + dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR; dialup \fIdialuptype\fR; - ixfr-from-differences \fIixfrdiff\fR; - - allow-query { \fIaddress_match_element\fR; ... }; - allow-transfer { \fIaddress_match_element\fR; ... }; - allow-update-forwarding { \fIaddress_match_element\fR; ... }; - + ixfr\-from\-differences \fIixfrdiff\fR; + allow\-query { \fIaddress_match_element\fR; ... }; + allow\-transfer { \fIaddress_match_element\fR; ... }; + allow\-update\-forwarding { \fIaddress_match_element\fR; ... }; notify \fInotifytype\fR; - notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - allow-notify { \fIaddress_match_element\fR; ... }; - + allow\-notify { \fIaddress_match_element\fR; ... }; forward ( first | only ); forwarders [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - - max-journal-size \fIsize_no_default\fR; - max-transfer-time-in \fIinteger\fR; - max-transfer-time-out \fIinteger\fR; - max-transfer-idle-in \fIinteger\fR; - max-transfer-idle-out \fIinteger\fR; - max-retry-time \fIinteger\fR; - min-retry-time \fIinteger\fR; - max-refresh-time \fIinteger\fR; - min-refresh-time \fIinteger\fR; - multi-master \fIboolean\fR; - sig-validity-interval \fIinteger\fR; - - transfer-source ( \fIipv4_address\fR | * ) + max\-journal\-size \fIsize_no_default\fR; + max\-transfer\-time\-in \fIinteger\fR; + max\-transfer\-time\-out \fIinteger\fR; + max\-transfer\-idle\-in \fIinteger\fR; + max\-transfer\-idle\-out \fIinteger\fR; + max\-retry\-time \fIinteger\fR; + min\-retry\-time \fIinteger\fR; + max\-refresh\-time \fIinteger\fR; + min\-refresh\-time \fIinteger\fR; + multi\-master \fIboolean\fR; + sig\-validity\-interval \fIinteger\fR; + transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - transfer-source-v6 ( \fIipv6_address\fR | * ) + transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - - alt-transfer-source ( \fIipv4_address\fR | * ) + alt\-transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - use-alt-transfer-source \fIboolean\fR; - - zone-statistics \fIboolean\fR; - key-directory \fIquoted_string\fR; - - allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete - deallocate-on-exit \fIboolean\fR; // obsolete - fake-iquery \fIboolean\fR; // obsolete - fetch-glue \fIboolean\fR; // obsolete - has-old-clients \fIboolean\fR; // obsolete - maintain-ixfr-base \fIboolean\fR; // obsolete - max-ixfr-log-size \fIsize\fR; // obsolete - multiple-cnames \fIboolean\fR; // obsolete - named-xfer \fIquoted_string\fR; // obsolete - serial-queries \fIinteger\fR; // obsolete - treat-cr-as-space \fIboolean\fR; // obsolete - use-id-pool \fIboolean\fR; // obsolete + use\-alt\-transfer\-source \fIboolean\fR; + zone\-statistics \fIboolean\fR; + key\-directory \fIquoted_string\fR; + allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete + deallocate\-on\-exit \fIboolean\fR; // obsolete + fake\-iquery \fIboolean\fR; // obsolete + fetch\-glue \fIboolean\fR; // obsolete + has\-old\-clients \fIboolean\fR; // obsolete + maintain\-ixfr\-base \fIboolean\fR; // obsolete + max\-ixfr\-log\-size \fIsize\fR; // obsolete + multiple\-cnames \fIboolean\fR; // obsolete + named\-xfer \fIquoted_string\fR; // obsolete + serial\-queries \fIinteger\fR; // obsolete + treat\-cr\-as\-space \fIboolean\fR; // obsolete + use\-id\-pool \fIboolean\fR; // obsolete }; -.sp .fi .SH "VIEW" .sp .nf view \fIstring\fR \fIoptional_class\fR { - match-clients { \fIaddress_match_element\fR; ... }; - match-destinations { \fIaddress_match_element\fR; ... }; - match-recursive-only \fIboolean\fR; - + match\-clients { \fIaddress_match_element\fR; ... }; + match\-destinations { \fIaddress_match_element\fR; ... }; + match\-recursive\-only \fIboolean\fR; key \fIstring\fR { algorithm \fIstring\fR; secret \fIstring\fR; }; - zone \fIstring\fR \fIoptional_class\fR { ... }; - server ( \fIipv4_address\fR | \fIipv6_address\fR ) { ... }; - - trusted-keys { + trusted\-keys { \fIstring\fR \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; ... }; - - allow-recursion { \fIaddress_match_element\fR; ... }; + allow\-recursion { \fIaddress_match_element\fR; ... }; sortlist { \fIaddress_match_element\fR; ... }; topology { \fIaddress_match_element\fR; ... }; // not implemented - auth-nxdomain \fIboolean\fR; // default changed - minimal-responses \fIboolean\fR; + auth\-nxdomain \fIboolean\fR; // default changed + minimal\-responses \fIboolean\fR; recursion \fIboolean\fR; - rrset-order { + rrset\-order { [ class \fIstring\fR ] [ type \fIstring\fR ] [ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ... }; - provide-ixfr \fIboolean\fR; - request-ixfr \fIboolean\fR; - rfc2308-type1 \fIboolean\fR; // not yet implemented - additional-from-auth \fIboolean\fR; - additional-from-cache \fIboolean\fR; - query-source \fIquerysource4\fR; - query-source-v6 \fIquerysource6\fR; - cleaning-interval \fIinteger\fR; - min-roots \fIinteger\fR; // not implemented - lame-ttl \fIinteger\fR; - max-ncache-ttl \fIinteger\fR; - max-cache-ttl \fIinteger\fR; - transfer-format ( many-answers | one-answer ); - max-cache-size \fIsize_no_default\fR; - check-names ( master | slave | response ) + provide\-ixfr \fIboolean\fR; + request\-ixfr \fIboolean\fR; + rfc2308\-type1 \fIboolean\fR; // not yet implemented + additional\-from\-auth \fIboolean\fR; + additional\-from\-cache \fIboolean\fR; + query\-source \fIquerysource4\fR; + query\-source\-v6 \fIquerysource6\fR; + cleaning\-interval \fIinteger\fR; + min\-roots \fIinteger\fR; // not implemented + lame\-ttl \fIinteger\fR; + max\-ncache\-ttl \fIinteger\fR; + max\-cache\-ttl \fIinteger\fR; + transfer\-format ( many\-answers | one\-answer ); + max\-cache\-size \fIsize_no_default\fR; + check\-names ( master | slave | response ) ( fail | warn | ignore ); - cache-file \fIquoted_string\fR; - suppress-initial-notify \fIboolean\fR; // not yet implemented - preferred-glue \fIstring\fR; - dual-stack-servers [ port \fIinteger\fR ] { + cache\-file \fIquoted_string\fR; + suppress\-initial\-notify \fIboolean\fR; // not yet implemented + preferred\-glue \fIstring\fR; + dual\-stack\-servers [ port \fIinteger\fR ] { ( \fIquoted_string\fR [port \fIinteger\fR] | \fIipv4_address\fR [port \fIinteger\fR] | \fIipv6_address\fR [port \fIinteger\fR] ); ... }; - edns-udp-size \fIinteger\fR; - root-delegation-only [ exclude { \fIquoted_string\fR; ... } ]; - disable-algorithms \fIstring\fR { \fIstring\fR; ... }; - dnssec-enable \fIboolean\fR; - dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR; - - dnssec-must-be-secure \fIstring\fR \fIboolean\fR; + edns\-udp\-size \fIinteger\fR; + root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ]; + disable\-algorithms \fIstring\fR { \fIstring\fR; ... }; + dnssec\-enable \fIboolean\fR; + dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR; + dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR; dialup \fIdialuptype\fR; - ixfr-from-differences \fIixfrdiff\fR; - - allow-query { \fIaddress_match_element\fR; ... }; - allow-transfer { \fIaddress_match_element\fR; ... }; - allow-update-forwarding { \fIaddress_match_element\fR; ... }; - + ixfr\-from\-differences \fIixfrdiff\fR; + allow\-query { \fIaddress_match_element\fR; ... }; + allow\-transfer { \fIaddress_match_element\fR; ... }; + allow\-update\-forwarding { \fIaddress_match_element\fR; ... }; notify \fInotifytype\fR; - notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - allow-notify { \fIaddress_match_element\fR; ... }; - + allow\-notify { \fIaddress_match_element\fR; ... }; forward ( first | only ); forwarders [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - - max-journal-size \fIsize_no_default\fR; - max-transfer-time-in \fIinteger\fR; - max-transfer-time-out \fIinteger\fR; - max-transfer-idle-in \fIinteger\fR; - max-transfer-idle-out \fIinteger\fR; - max-retry-time \fIinteger\fR; - min-retry-time \fIinteger\fR; - max-refresh-time \fIinteger\fR; - min-refresh-time \fIinteger\fR; - multi-master \fIboolean\fR; - sig-validity-interval \fIinteger\fR; - - transfer-source ( \fIipv4_address\fR | * ) + max\-journal\-size \fIsize_no_default\fR; + max\-transfer\-time\-in \fIinteger\fR; + max\-transfer\-time\-out \fIinteger\fR; + max\-transfer\-idle\-in \fIinteger\fR; + max\-transfer\-idle\-out \fIinteger\fR; + max\-retry\-time \fIinteger\fR; + min\-retry\-time \fIinteger\fR; + max\-refresh\-time \fIinteger\fR; + min\-refresh\-time \fIinteger\fR; + multi\-master \fIboolean\fR; + sig\-validity\-interval \fIinteger\fR; + transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - transfer-source-v6 ( \fIipv6_address\fR | * ) + transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - - alt-transfer-source ( \fIipv4_address\fR | * ) + alt\-transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - use-alt-transfer-source \fIboolean\fR; - - zone-statistics \fIboolean\fR; - key-directory \fIquoted_string\fR; - - allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete - fetch-glue \fIboolean\fR; // obsolete - maintain-ixfr-base \fIboolean\fR; // obsolete - max-ixfr-log-size \fIsize\fR; // obsolete + use\-alt\-transfer\-source \fIboolean\fR; + zone\-statistics \fIboolean\fR; + key\-directory \fIquoted_string\fR; + allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete + fetch\-glue \fIboolean\fR; // obsolete + maintain\-ixfr\-base \fIboolean\fR; // obsolete + max\-ixfr\-log\-size \fIsize\fR; // obsolete }; -.sp .fi .SH "ZONE" .sp .nf zone \fIstring\fR \fIoptional_class\fR { type ( master | slave | stub | hint | - forward | delegation-only ); + forward | delegation\-only ); file \fIquoted_string\fR; - masters [ port \fIinteger\fR ] { ( \fImasters\fR | \fIipv4_address\fR [port \fIinteger\fR] | \fIipv6_address\fR [ port \fIinteger\fR ] ) [ key \fIstring\fR ]; ... }; - database \fIstring\fR; - delegation-only \fIboolean\fR; - check-names ( fail | warn | ignore ); + delegation\-only \fIboolean\fR; + check\-names ( fail | warn | ignore ); dialup \fIdialuptype\fR; - ixfr-from-differences \fIboolean\fR; - - allow-query { \fIaddress_match_element\fR; ... }; - allow-transfer { \fIaddress_match_element\fR; ... }; - allow-update { \fIaddress_match_element\fR; ... }; - allow-update-forwarding { \fIaddress_match_element\fR; ... }; - update-policy { + ixfr\-from\-differences \fIboolean\fR; + allow\-query { \fIaddress_match_element\fR; ... }; + allow\-transfer { \fIaddress_match_element\fR; ... }; + allow\-update { \fIaddress_match_element\fR; ... }; + allow\-update\-forwarding { \fIaddress_match_element\fR; ... }; + update\-policy { ( grant | deny ) \fIstring\fR ( name | subdomain | wildcard | self ) \fIstring\fR \fIrrtypelist\fR; ... }; - notify \fInotifytype\fR; - notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) + notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; + also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - allow-notify { \fIaddress_match_element\fR; ... }; - + allow\-notify { \fIaddress_match_element\fR; ... }; forward ( first | only ); forwarders [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ... }; - - max-journal-size \fIsize_no_default\fR; - max-transfer-time-in \fIinteger\fR; - max-transfer-time-out \fIinteger\fR; - max-transfer-idle-in \fIinteger\fR; - max-transfer-idle-out \fIinteger\fR; - max-retry-time \fIinteger\fR; - min-retry-time \fIinteger\fR; - max-refresh-time \fIinteger\fR; - min-refresh-time \fIinteger\fR; - multi-master \fIboolean\fR; - sig-validity-interval \fIinteger\fR; - - transfer-source ( \fIipv4_address\fR | * ) + max\-journal\-size \fIsize_no_default\fR; + max\-transfer\-time\-in \fIinteger\fR; + max\-transfer\-time\-out \fIinteger\fR; + max\-transfer\-idle\-in \fIinteger\fR; + max\-transfer\-idle\-out \fIinteger\fR; + max\-retry\-time \fIinteger\fR; + min\-retry\-time \fIinteger\fR; + max\-refresh\-time \fIinteger\fR; + min\-refresh\-time \fIinteger\fR; + multi\-master \fIboolean\fR; + sig\-validity\-interval \fIinteger\fR; + transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - transfer-source-v6 ( \fIipv6_address\fR | * ) + transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - - alt-transfer-source ( \fIipv4_address\fR | * ) + alt\-transfer\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - alt-transfer-source-v6 ( \fIipv6_address\fR | * ) + alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ]; - use-alt-transfer-source \fIboolean\fR; - - zone-statistics \fIboolean\fR; - key-directory \fIquoted_string\fR; - - ixfr-base \fIquoted_string\fR; // obsolete - ixfr-tmp-file \fIquoted_string\fR; // obsolete - maintain-ixfr-base \fIboolean\fR; // obsolete - max-ixfr-log-size \fIsize\fR; // obsolete + use\-alt\-transfer\-source \fIboolean\fR; + zone\-statistics \fIboolean\fR; + key\-directory \fIquoted_string\fR; + ixfr\-base \fIquoted_string\fR; // obsolete + ixfr\-tmp\-file \fIquoted_string\fR; // obsolete + maintain\-ixfr\-base \fIboolean\fR; // obsolete + max\-ixfr\-log\-size \fIsize\fR; // obsolete pubkey \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; // obsolete }; -.sp .fi .SH "FILES" .PP @@ -472,4 +435,4 @@ zone \fIstring\fR \fIoptional_class\fR { .PP \fBnamed\fR(8), \fBrndc\fR(8), -\fBBIND 9 Adminstrators Reference Manual\fR. +\fBBIND 9 Adminstrators Reference Manual\fR(). diff --git a/contrib/bind9/bin/named/named.conf.docbook b/contrib/bind9/bin/named/named.conf.docbook index b5a71dcf1b3..4ba10844cc3 100644 --- a/contrib/bind9/bin/named/named.conf.docbook +++ b/contrib/bind9/bin/named/named.conf.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -28,6 +30,14 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + named.conf configuration file for named @@ -61,35 +71,35 @@ ACL - + acl string { address_match_element; ... }; - + KEY - + key domain_name { algorithm string; secret string; }; - + MASTERS - + masters string port integer { ( masters | ipv4_address port integer | ipv6_address port integer ) key string ; ... }; - + SERVER - + server ( ipv4_address | ipv6_address ) { bogus boolean; edns boolean; @@ -105,21 +115,21 @@ server ( ipv4_address | ipv6_addressboolean; // obsolete }; - + TRUSTED-KEYS - + trusted-keys { domain_name flags protocol algorithm key; ... }; - + CONTROLS - + controls { inet ( ipv4_address | ipv6_address | * ) port ( integer | * ) @@ -127,12 +137,12 @@ controls { keys { string; ... } ; unix unsupported; // not implemented }; - + LOGGING - + logging { channel string { file log_file; @@ -146,12 +156,12 @@ logging { }; category string { string; ... }; }; - + LWRES - + lwres { listen-on port integer { ( ipv4_address | ipv6_address ) port integer ; ... @@ -160,12 +170,12 @@ lwres { search { string; ... }; ndots integer; }; - + OPTIONS - + options { avoid-v4-udp-ports { port; ... }; avoid-v6-udp-ports { port; ... }; @@ -304,12 +314,12 @@ options { treat-cr-as-space boolean; // obsolete use-id-pool boolean; // obsolete }; - + VIEW - + view string optional_class { match-clients { address_match_element; ... }; match-destinations { address_match_element; ... }; @@ -423,12 +433,12 @@ view string optional_class maintain-ixfr-base boolean; // obsolete max-ixfr-log-size size; // obsolete }; - + ZONE - + zone string optional_class { type ( master | slave | stub | hint | forward | delegation-only ); @@ -500,7 +510,7 @@ zone string optional_class max-ixfr-log-size size; // obsolete pubkey integer integer integer quoted_string; // obsolete }; - + diff --git a/contrib/bind9/bin/named/named.conf.html b/contrib/bind9/bin/named/named.conf.html index 7f8bb2ec61f..8b3b517d7d7 100644 --- a/contrib/bind9/bin/named/named.conf.html +++ b/contrib/bind9/bin/named/named.conf.html @@ -1,1897 +1,500 @@ - - - - -named.conf

named.conf

Name

named.conf -- configuration file for named

Synopsis

named.conf

DESCRIPTION

named.conf is the configuration file for - named. Statements are enclosed + + + + +named.conf + + +

+
+
+

Name

+

named.conf — configuration file for named

+
+
+

Synopsis

+

named.conf

+
+
+

DESCRIPTION

+

+ named.conf is the configuration file for + named. Statements are enclosed in braces and terminated with a semi-colon. Clauses in the statements are also semi-colon terminated. The usual comment styles are supported: -

C style: /* */ -

C++ style: // to end of line -

Unix style: # to end of line -

ACL

acl string { address_match_element; ... };

KEY

key domain_name {
- algorithm string;
- secret string;
-};

MASTERS

masters string [ port integer ] {
- ( masters | ipv4_address [port integer] |
- ipv6_address [port integer] ) [ key string ]; ...
-};

SERVER

server ( ipv4_address | ipv6_address ) {
- bogus boolean;
- edns boolean;
- provide-ixfr boolean;
- request-ixfr boolean;
- keys server_key;
- transfers integer;
- transfer-format ( many-answers | one-answer );
- transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
+

+

+ C style: /* */ +

+

+ C++ style: // to end of line +

+

+ Unix style: # to end of line +

+
+
+

ACL

+


+acl string { address_match_element; ... };

- support-ixfr boolean; // obsolete
-};

TRUSTED-KEYS

trusted-keys {
- domain_name flags protocol algorithm key; ... 
-};

CONTROLS

controls {
- inet ( ipv4_address | ipv6_address | * )
- [ port ( integer | * ) ]
- allow { address_match_element; ... }
- [ keys { string; ... } ];
- unix unsupported; // not implemented
-};

LOGGING

logging {
- channel string {
- file log_file;
- syslog optional_facility;
+

+
+
+

KEY

+


+key domain_name {
+ algorithm string;
+ secret string;
+};
+

+
+
+

MASTERS

+


+masters string [ port integer ] {
+ ( masters | ipv4_address [port integer] |
+ ipv6_address [port integer] ) [ key string ]; ...
+};
+

+
+
+

SERVER

+


+server ( ipv4_address | ipv6_address ) {
+ bogus boolean;
+ edns boolean;
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ keys server_key;
+ transfers integer;
+ transfer-format ( many-answers | one-answer );
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+
+ support-ixfr boolean; // obsolete
+};
+

+
+
+

TRUSTED-KEYS

+


+trusted-keys {
+ domain_name flags protocol algorithm key; ... 
+};
+

+
+
+

CONTROLS

+


+controls {
+ inet ( ipv4_address | ipv6_address | * )
+ [ port ( integer | * ) ]
+ allow { address_match_element; ... }
+ [ keys { string; ... } ];
+ unix unsupported; // not implemented
+};
+

+
+
+

LOGGING

+


+logging {
+ channel string {
+ file log_file;
+ syslog optional_facility;
null;
stderr;
- severity log_severity;
- print-time boolean;
- print-severity boolean;
- print-category boolean;
+ severity log_severity;
+ print-time boolean;
+ print-severity boolean;
+ print-category boolean;
};
- category string { string; ... };
-};

LWRES

lwres {
- listen-on [ port integer ] {
- ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ category string { string; ... };
+};
+

+
+
+

LWRES

+


+lwres {
+ listen-on [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
};
- view string optional_class;
- search { string; ... };
- ndots integer;
-};

OPTIONS

options {
- avoid-v4-udp-ports { port; ... };
- avoid-v6-udp-ports { port; ... };
- blackhole { address_match_element; ... };
- coresize size;
- datasize size;
- directory quoted_string;
- dump-file quoted_string;
- files size;
- heartbeat-interval integer;
- host-statistics boolean; // not implemented
- host-statistics-max number; // not implemented
- hostname ( quoted_string | none );
- interface-interval integer;
- listen-on [ port integer ] { address_match_element; ... };
- listen-on-v6 [ port integer ] { address_match_element; ... };
- match-mapped-addresses boolean;
- memstatistics-file quoted_string;
- pid-file ( quoted_string | none );
- port integer;
- querylog boolean;
- recursing-file quoted_string;
- random-device quoted_string;
- recursive-clients integer;
- serial-query-rate integer;
- server-id ( quoted_string | none |;
- stacksize size;
- statistics-file quoted_string;
- statistics-interval integer; // not yet implemented
- tcp-clients integer;
- tcp-listen-queue integer;
- tkey-dhkey quoted_string integer;
- tkey-gssapi-credential quoted_string;
- tkey-domain quoted_string;
- transfers-per-ns integer;
- transfers-in integer;
- transfers-out integer;
- use-ixfr boolean;
- version ( quoted_string | none );
- allow-recursion { address_match_element; ... };
- sortlist { address_match_element; ... };
- topology { address_match_element; ... }; // not implemented
- auth-nxdomain boolean; // default changed
- minimal-responses boolean;
- recursion boolean;
- rrset-order {
- [ class string ] [ type string ]
- [ name quoted_string ] string string; ...
+ view string optional_class;
+ search { string; ... };
+ ndots integer;
+};
+

+
+
+

OPTIONS

+


+options {
+ avoid-v4-udp-ports { port; ... };
+ avoid-v6-udp-ports { port; ... };
+ blackhole { address_match_element; ... };
+ coresize size;
+ datasize size;
+ directory quoted_string;
+ dump-file quoted_string;
+ files size;
+ heartbeat-interval integer;
+ host-statistics boolean; // not implemented
+ host-statistics-max number; // not implemented
+ hostname ( quoted_string | none );
+ interface-interval integer;
+ listen-on [ port integer ] { address_match_element; ... };
+ listen-on-v6 [ port integer ] { address_match_element; ... };
+ match-mapped-addresses boolean;
+ memstatistics-file quoted_string;
+ pid-file ( quoted_string | none );
+ port integer;
+ querylog boolean;
+ recursing-file quoted_string;
+ random-device quoted_string;
+ recursive-clients integer;
+ serial-query-rate integer;
+ server-id ( quoted_string | none |;
+ stacksize size;
+ statistics-file quoted_string;
+ statistics-interval integer; // not yet implemented
+ tcp-clients integer;
+ tcp-listen-queue integer;
+ tkey-dhkey quoted_string integer;
+ tkey-gssapi-credential quoted_string;
+ tkey-domain quoted_string;
+ transfers-per-ns integer;
+ transfers-in integer;
+ transfers-out integer;
+ use-ixfr boolean;
+ version ( quoted_string | none );
+ allow-recursion { address_match_element; ... };
+ sortlist { address_match_element; ... };
+ topology { address_match_element; ... }; // not implemented
+ auth-nxdomain boolean; // default changed
+ minimal-responses boolean;
+ recursion boolean;
+ rrset-order {
+ [ class string ] [ type string ]
+ [ name quoted_string ] string string; ...
};
- provide-ixfr boolean;
- request-ixfr boolean;
- rfc2308-type1 boolean; // not yet implemented
- additional-from-auth boolean;
- additional-from-cache boolean;
- query-source querysource4;
- query-source-v6 querysource6;
- cleaning-interval integer;
- min-roots integer; // not implemented
- lame-ttl integer;
- max-ncache-ttl integer;
- max-cache-ttl integer;
- transfer-format ( many-answers | one-answer );
- max-cache-size size_no_default;
- check-names ( master | slave | response )
- ( fail | warn | ignore );
- cache-file quoted_string;
- suppress-initial-notify boolean; // not yet implemented
- preferred-glue string;
- dual-stack-servers [ port integer ] {
- ( quoted_string [port integer] |
- ipv4_address [port integer] |
- ipv6_address [port integer] ); ...
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ rfc2308-type1 boolean; // not yet implemented
+ additional-from-auth boolean;
+ additional-from-cache boolean;
+ query-source querysource4;
+ query-source-v6 querysource6;
+ cleaning-interval integer;
+ min-roots integer; // not implemented
+ lame-ttl integer;
+ max-ncache-ttl integer;
+ max-cache-ttl integer;
+ transfer-format ( many-answers | one-answer );
+ max-cache-size size_no_default;
+ check-names ( master | slave | response )
+ ( fail | warn | ignore );
+ cache-file quoted_string;
+ suppress-initial-notify boolean; // not yet implemented
+ preferred-glue string;
+ dual-stack-servers [ port integer ] {
+ ( quoted_string [port integer] |
+ ipv4_address [port integer] |
+ ipv6_address [port integer] ); ...
}
- edns-udp-size integer;
- root-delegation-only [ exclude { quoted_string; ... } ];
- disable-algorithms string { string; ... };
- dnssec-enable boolean;
- dnssec-lookaside string trust-anchor string;
- dnssec-must-be-secure string boolean;
+ edns-udp-size integer;
+ root-delegation-only [ exclude { quoted_string; ... } ];
+ disable-algorithms string { string; ... };
+ dnssec-enable boolean;
+ dnssec-lookaside string trust-anchor string;
+ dnssec-must-be-secure string boolean;

- dialup dialuptype;
- ixfr-from-differences ixfrdiff;
+ dialup dialuptype;
+ ixfr-from-differences ixfrdiff;

- allow-query { address_match_element; ... };
- allow-transfer { address_match_element; ... };
- allow-update-forwarding { address_match_element; ... };
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };

- notify notifytype;
- notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
- notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
- also-notify [ port integer ] { ( ipv4_address | ipv6_address )
- [ port integer ]; ... };
- allow-notify { address_match_element; ... };
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };

- forward ( first | only );
- forwarders [ port integer ] {
- ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
};

- max-journal-size size_no_default;
- max-transfer-time-in integer;
- max-transfer-time-out integer;
- max-transfer-idle-in integer;
- max-transfer-idle-out integer;
- max-retry-time integer;
- min-retry-time integer;
- max-refresh-time integer;
- min-refresh-time integer;
- multi-master boolean;
- sig-validity-interval integer;
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;

- transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];

- alt-transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- alt-transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
- use-alt-transfer-source boolean;
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;

- zone-statistics boolean;
- key-directory quoted_string;
+ zone-statistics boolean;
+ key-directory quoted_string;

- allow-v6-synthesis { address_match_element; ... }; // obsolete
- deallocate-on-exit boolean; // obsolete
- fake-iquery boolean; // obsolete
- fetch-glue boolean; // obsolete
- has-old-clients boolean; // obsolete
- maintain-ixfr-base boolean; // obsolete
- max-ixfr-log-size size; // obsolete
- multiple-cnames boolean; // obsolete
- named-xfer quoted_string; // obsolete
- serial-queries integer; // obsolete
- treat-cr-as-space boolean; // obsolete
- use-id-pool boolean; // obsolete
-};

VIEW

view string optional_class {
- match-clients { address_match_element; ... };
- match-destinations { address_match_element; ... };
- match-recursive-only boolean;
+ allow-v6-synthesis { address_match_element; ... }; // obsolete
+ deallocate-on-exit boolean; // obsolete
+ fake-iquery boolean; // obsolete
+ fetch-glue boolean; // obsolete
+ has-old-clients boolean; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+ multiple-cnames boolean; // obsolete
+ named-xfer quoted_string; // obsolete
+ serial-queries integer; // obsolete
+ treat-cr-as-space boolean; // obsolete
+ use-id-pool boolean; // obsolete
+};
+

+
+
+

VIEW

+


+view string optional_class {
+ match-clients { address_match_element; ... };
+ match-destinations { address_match_element; ... };
+ match-recursive-only boolean;

- key string {
- algorithm string;
- secret string;
+ key string {
+ algorithm string;
+ secret string;
};

- zone string optional_class {
+ zone string optional_class {
...
};

- server ( ipv4_address | ipv6_address ) {
+ server ( ipv4_address | ipv6_address ) {
...
};

- trusted-keys {
- string integer integer integer quoted_string; ...
+ trusted-keys {
+ string integer integer integer quoted_string; ...
};

- allow-recursion { address_match_element; ... };
- sortlist { address_match_element; ... };
- topology { address_match_element; ... }; // not implemented
- auth-nxdomain boolean; // default changed
- minimal-responses boolean;
- recursion boolean;
- rrset-order {
- [ class string ] [ type string ]
- [ name quoted_string ] string string; ...
+ allow-recursion { address_match_element; ... };
+ sortlist { address_match_element; ... };
+ topology { address_match_element; ... }; // not implemented
+ auth-nxdomain boolean; // default changed
+ minimal-responses boolean;
+ recursion boolean;
+ rrset-order {
+ [ class string ] [ type string ]
+ [ name quoted_string ] string string; ...
};
- provide-ixfr boolean;
- request-ixfr boolean;
- rfc2308-type1 boolean; // not yet implemented
- additional-from-auth boolean;
- additional-from-cache boolean;
- query-source querysource4;
- query-source-v6 querysource6;
- cleaning-interval integer;
- min-roots integer; // not implemented
- lame-ttl integer;
- max-ncache-ttl integer;
- max-cache-ttl integer;
- transfer-format ( many-answers | one-answer );
- max-cache-size size_no_default;
- check-names ( master | slave | response )
- ( fail | warn | ignore );
- cache-file quoted_string;
- suppress-initial-notify boolean; // not yet implemented
- preferred-glue string;
- dual-stack-servers [ port integer ] {
- ( quoted_string [port integer] |
- ipv4_address [port integer] |
- ipv6_address [port integer] ); ...
+ provide-ixfr boolean;
+ request-ixfr boolean;
+ rfc2308-type1 boolean; // not yet implemented
+ additional-from-auth boolean;
+ additional-from-cache boolean;
+ query-source querysource4;
+ query-source-v6 querysource6;
+ cleaning-interval integer;
+ min-roots integer; // not implemented
+ lame-ttl integer;
+ max-ncache-ttl integer;
+ max-cache-ttl integer;
+ transfer-format ( many-answers | one-answer );
+ max-cache-size size_no_default;
+ check-names ( master | slave | response )
+ ( fail | warn | ignore );
+ cache-file quoted_string;
+ suppress-initial-notify boolean; // not yet implemented
+ preferred-glue string;
+ dual-stack-servers [ port integer ] {
+ ( quoted_string [port integer] |
+ ipv4_address [port integer] |
+ ipv6_address [port integer] ); ...
};
- edns-udp-size integer;
- root-delegation-only [ exclude { quoted_string; ... } ];
- disable-algorithms string { string; ... };
- dnssec-enable boolean;
- dnssec-lookaside string trust-anchor string;
+ edns-udp-size integer;
+ root-delegation-only [ exclude { quoted_string; ... } ];
+ disable-algorithms string { string; ... };
+ dnssec-enable boolean;
+ dnssec-lookaside string trust-anchor string;

- dnssec-must-be-secure string boolean;
- dialup dialuptype;
- ixfr-from-differences ixfrdiff;
+ dnssec-must-be-secure string boolean;
+ dialup dialuptype;
+ ixfr-from-differences ixfrdiff;

- allow-query { address_match_element; ... };
- allow-transfer { address_match_element; ... };
- allow-update-forwarding { address_match_element; ... };
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };

- notify notifytype;
- notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
- notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
- also-notify [ port integer ] { ( ipv4_address | ipv6_address )
- [ port integer ]; ... };
- allow-notify { address_match_element; ... };
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };

- forward ( first | only );
- forwarders [ port integer ] {
- ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
};

- max-journal-size size_no_default;
- max-transfer-time-in integer;
- max-transfer-time-out integer;
- max-transfer-idle-in integer;
- max-transfer-idle-out integer;
- max-retry-time integer;
- min-retry-time integer;
- max-refresh-time integer;
- min-refresh-time integer;
- multi-master boolean;
- sig-validity-interval integer;
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;

- transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];

- alt-transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- alt-transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
- use-alt-transfer-source boolean;
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;

- zone-statistics boolean;
- key-directory quoted_string;
+ zone-statistics boolean;
+ key-directory quoted_string;

- allow-v6-synthesis { address_match_element; ... }; // obsolete
- fetch-glue boolean; // obsolete
- maintain-ixfr-base boolean; // obsolete
- max-ixfr-log-size size; // obsolete
-};

ZONE

zone string optional_class {
- type ( master | slave | stub | hint |
- forward | delegation-only );
- file quoted_string;
+ allow-v6-synthesis { address_match_element; ... }; // obsolete
+ fetch-glue boolean; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+};
+

+
+
+

ZONE

+


+zone string optional_class {
+ type ( master | slave | stub | hint |
+ forward | delegation-only );
+ file quoted_string;

- masters [ port integer ] {
- ( masters |
- ipv4_address [port integer] |
- ipv6_address [ port integer ] ) [ key string ]; ...
+ masters [ port integer ] {
+ ( masters |
+ ipv4_address [port integer] |
+ ipv6_address [ port integer ] ) [ key string ]; ...
};

- database string;
- delegation-only boolean;
- check-names ( fail | warn | ignore );
- dialup dialuptype;
- ixfr-from-differences boolean;
+ database string;
+ delegation-only boolean;
+ check-names ( fail | warn | ignore );
+ dialup dialuptype;
+ ixfr-from-differences boolean;

- allow-query { address_match_element; ... };
- allow-transfer { address_match_element; ... };
- allow-update { address_match_element; ... };
- allow-update-forwarding { address_match_element; ... };
- update-policy {
- ( grant | deny ) string
- ( name | subdomain | wildcard | self ) string
- rrtypelist; ...
+ allow-query { address_match_element; ... };
+ allow-transfer { address_match_element; ... };
+ allow-update { address_match_element; ... };
+ allow-update-forwarding { address_match_element; ... };
+ update-policy {
+ ( grant | deny ) string
+ ( name | subdomain | wildcard | self ) string
+ rrtypelist; ...
};

- notify notifytype;
- notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
- notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
- also-notify [ port integer ] { ( ipv4_address | ipv6_address )
- [ port integer ]; ... };
- allow-notify { address_match_element; ... };
+ notify notifytype;
+ notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
+ notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
+ also-notify [ port integer ] { ( ipv4_address | ipv6_address )
+ [ port integer ]; ... };
+ allow-notify { address_match_element; ... };

- forward ( first | only );
- forwarders [ port integer ] {
- ( ipv4_address | ipv6_address ) [ port integer ]; ...
+ forward ( first | only );
+ forwarders [ port integer ] {
+ ( ipv4_address | ipv6_address ) [ port integer ]; ...
};

- max-journal-size size_no_default;
- max-transfer-time-in integer;
- max-transfer-time-out integer;
- max-transfer-idle-in integer;
- max-transfer-idle-out integer;
- max-retry-time integer;
- min-retry-time integer;
- max-refresh-time integer;
- min-refresh-time integer;
- multi-master boolean;
- sig-validity-interval integer;
+ max-journal-size size_no_default;
+ max-transfer-time-in integer;
+ max-transfer-time-out integer;
+ max-transfer-idle-in integer;
+ max-transfer-idle-out integer;
+ max-retry-time integer;
+ min-retry-time integer;
+ max-refresh-time integer;
+ min-refresh-time integer;
+ multi-master boolean;
+ sig-validity-interval integer;

- transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
+ transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];

- alt-transfer-source ( ipv4_address | * )
- [ port ( integer | * ) ];
- alt-transfer-source-v6 ( ipv6_address | * )
- [ port ( integer | * ) ];
- use-alt-transfer-source boolean;
+ alt-transfer-source ( ipv4_address | * )
+ [ port ( integer | * ) ];
+ alt-transfer-source-v6 ( ipv6_address | * )
+ [ port ( integer | * ) ];
+ use-alt-transfer-source boolean;

- zone-statistics boolean;
- key-directory quoted_string;
+ zone-statistics boolean;
+ key-directory quoted_string;

- ixfr-base quoted_string; // obsolete
- ixfr-tmp-file quoted_string; // obsolete
- maintain-ixfr-base boolean; // obsolete
- max-ixfr-log-size size; // obsolete
- pubkey integer integer integer quoted_string; // obsolete
-};

FILES

/etc/named.conf

SEE ALSO

named(8), -rndc(8), -BIND 9 Adminstrators Reference Manual.

+ ixfr-base quoted_string; // obsolete
+ ixfr-tmp-file quoted_string; // obsolete
+ maintain-ixfr-base boolean; // obsolete
+ max-ixfr-log-size size; // obsolete
+ pubkey integer integer integer quoted_string; // obsolete
+};
+

+
+
+

FILES

+

+/etc/named.conf +

+
+
+

SEE ALSO

+

+named(8), +rndc(8), +BIND 9 Adminstrators Reference Manual. +

+
+
+ diff --git a/contrib/bind9/bin/named/named.docbook b/contrib/bind9/bin/named/named.docbook index 754f1a07c14..47ccf54b38e 100644 --- a/contrib/bind9/bin/named/named.docbook +++ b/contrib/bind9/bin/named/named.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -29,6 +31,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2003 + Internet Software Consortium. + + + named Internet domain name server diff --git a/contrib/bind9/bin/named/named.html b/contrib/bind9/bin/named/named.html index 8ee16e684f1..f266e70af55 100644 --- a/contrib/bind9/bin/named/named.html +++ b/contrib/bind9/bin/named/named.html @@ -1,625 +1,240 @@ - - - - -named

named

Name

named -- Internet domain name server

Synopsis

named [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-n #cpus] [-p port] [-s] [-t directory] [-u user] [-v] [-x cache-file]

DESCRIPTION

named is a Domain Name System (DNS) server, + + + + +named + + +

+
+
+

Name

+

named — Internet domain name server

+
+
+

Synopsis

+

named [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-n #cpus] [-p port] [-s] [-t directory] [-u user] [-v] [-x cache-file]

+
+
+

DESCRIPTION

+

+ named is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFCs 1033, 1034, and 1035. -

When invoked without arguments, named will +

+

+ When invoked without arguments, named will read the default configuration file - /etc/named.conf, read any initial + /etc/named.conf, read any initial data, and listen for queries. -

OPTIONS

-4

Use IPv4 only even if the host machine is capable of IPv6. - -4 and -6 are mutually +

+
+
+

OPTIONS

+
+
-4
+

+ Use IPv4 only even if the host machine is capable of IPv6. + -4 and -6 are mutually exclusive. -

-6

Use IPv6 only even if the host machine is capable of IPv4. - -4 and -6 are mutually +

+
-6
+

+ Use IPv6 only even if the host machine is capable of IPv4. + -4 and -6 are mutually exclusive. -

-c config-file

Use config-file as the +

+
-c config-file
+

+ Use config-file as the configuration file instead of the default, - /etc/named.conf. To + /etc/named.conf. To ensure that reloading the configuration file continues to work after the server has changed its working directory due to to a possible - directory option in the configuration - file, config-file should be + directory option in the configuration + file, config-file should be an absolute pathname. -

-d debug-level

Set the daemon's debug level to debug-level. - Debugging traces from named become +

+
-d debug-level
+

+ Set the daemon's debug level to debug-level. + Debugging traces from named become more verbose as the debug level increases. -

-f

Run the server in the foreground (i.e. do not daemonize). -

-g

Run the server in the foreground and force all logging - to stderr. -

-n #cpus

Create #cpus worker threads +

+
-f
+

+ Run the server in the foreground (i.e. do not daemonize). +

+
-g
+

+ Run the server in the foreground and force all logging + to stderr. +

+
-n #cpus
+

+ Create #cpus worker threads to take advantage of multiple CPUs. If not specified, - named will try to determine the + named will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created. -

-p port

Listen for queries on port port. If not +

+
-p port
+

+ Listen for queries on port port. If not specified, the default is port 53. -

-s

Write memory usage statistics to stdout on exit. -

Note: This option is mainly of interest to BIND 9 developers +

+
-s
+
+

+ Write memory usage statistics to stdout on exit. +

+
+

Note

+

+ This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release. -

-t directory

chroot() to directory after +

+
+ +
-t directory
+
+

+ chroot() to directory after processing the command line arguments, but before reading the configuration file. -

Warning

This option should be used in conjunction with the - -u option, as chrooting a process +

+
+

Warning

+

+ This option should be used in conjunction with the + -u option, as chrooting a process running as root doesn't enhance security on most - systems; the way chroot() is + systems; the way chroot() is defined allows a process with root privileges to escape a chroot jail. -

-u user

setuid() to user after completing +

+
+ +
-u user
+
+

+ setuid() to user after completing privileged operations, such as creating sockets that listen on privileged ports. -

Note: On Linux, named uses the kernel's +

+
+

Note

+

+ On Linux, named uses the kernel's capability mechanism to drop all root privileges - except the ability to bind() to a + except the ability to bind() to a privileged port and set process resource limits. - Unfortunately, this means that the -u - option only works when named is run + Unfortunately, this means that the -u + option only works when named is run on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since previous kernels did not allow privileges - to be retained after setuid(). -

-v

Report the version number and exit. -

-x cache-file

Load data from cache-file into the + to be retained after setuid(). +

+
+ +
-v
+

+ Report the version number and exit. +

+
-x cache-file
+
+

+ Load data from cache-file into the cache of the default view. -

Warning

This option must not be used. It is only of interest +

+
+

Warning

+

+ This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release. -

SIGNALS

In routine operation, signals should not be used to control - the nameserver; rndc should be used +

+
+ + + +
+

SIGNALS

+

+ In routine operation, signals should not be used to control + the nameserver; rndc should be used instead. -

SIGHUP

Force a reload of the server. -

SIGINT, SIGTERM

Shut down the server. -

The result of sending any other signals to the server is undefined. -

CONFIGURATION

The named configuration file is too complex +

+
+
SIGHUP
+

+ Force a reload of the server. +

+
SIGINT, SIGTERM
+

+ Shut down the server. +

+
+

+ The result of sending any other signals to the server is undefined. +

+
+
+

CONFIGURATION

+

+ The named configuration file is too complex to describe in detail here. A complete description is - provided in the BIND 9 Administrator Reference - Manual. -

FILES

/etc/named.conf

The default configuration file. -

/var/run/named.pid

The default process-id file. -

SEE ALSO

RFC 1033, - RFC 1034, - RFC 1035, - rndc(8), - lwresd(8), - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+ provided in the BIND 9 Administrator Reference + Manual. +

+ +
+

FILES

+
+
/etc/named.conf
+

+ The default configuration file. +

+
/var/run/named.pid
+

+ The default process-id file. +

+
+
+
+

SEE ALSO

+

+ RFC 1033, + RFC 1034, + RFC 1035, + rndc(8), + lwresd(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+ + diff --git a/contrib/bind9/bin/named/query.c b/contrib/bind9/bin/named/query.c index a5411af3433..75102fd1369 100644 --- a/contrib/bind9/bin/named/query.c +++ b/contrib/bind9/bin/named/query.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.198.2.13.4.30 2004/06/30 14:13:05 marka Exp $ */ +/* $Id: query.c,v 1.198.2.13.4.36 2005/08/11 05:25:20 marka Exp $ */ #include @@ -1198,17 +1198,7 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) { * recursing to add address records, which in turn can cause * recursion to add KEYs. */ - if (type == dns_rdatatype_a || type == dns_rdatatype_aaaa) { - /* - * RFC 2535 section 3.5 says that when A or AAAA records are - * retrieved as additional data, any KEY RRs for the owner name - * should be added to the additional data section. - * - * XXXRTH We should lower the priority here. Alternatively, - * we could raise the priority of glue records. - */ - eresult = query_addadditional(client, name, dns_rdatatype_dnskey); - } else if (type == dns_rdatatype_srv && trdataset != NULL) { + if (type == dns_rdatatype_srv && trdataset != NULL) { /* * If we're adding SRV records to the additional data * section, it's helpful if we add the SRV additional data @@ -1241,8 +1231,6 @@ static inline void query_addrdataset(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) { - dns_rdatatype_t type = rdataset->type; - /* * Add 'rdataset' and any pertinent additional data to * 'fname', a name in the response message for 'client'. @@ -1266,22 +1254,6 @@ query_addrdataset(ns_client_t *client, dns_name_t *fname, */ (void)dns_rdataset_additionaldata(rdataset, query_addadditional, client); - /* - * RFC 2535 section 3.5 says that when NS, SOA, A, or AAAA records - * are retrieved, any KEY RRs for the owner name should be added - * to the additional data section. We treat A6 records the same way. - * - * We don't care if query_addadditional() fails. - */ - if (type == dns_rdatatype_ns || type == dns_rdatatype_soa || - type == dns_rdatatype_a || type == dns_rdatatype_aaaa || - type == dns_rdatatype_a6) { - /* - * XXXRTH We should lower the priority here. Alternatively, - * we could raise the priority of glue records. - */ - (void)query_addadditional(client, fname, dns_rdatatype_dnskey); - } CTRACE("query_addrdataset: done"); } @@ -2116,33 +2088,37 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain, * connection was accepted (if allowed by the TCP quota). */ if (client->recursionquota == NULL) { - isc_boolean_t killoldest = ISC_FALSE; result = isc_quota_attach(&ns_g_server->recursionquota, &client->recursionquota); - if (result == ISC_R_SOFTQUOTA) { + if (result == ISC_R_SOFTQUOTA) { ns_client_log(client, NS_LOGCATEGORY_CLIENT, NS_LOGMODULE_QUERY, ISC_LOG_WARNING, - "recursive-clients limit exceeded, " + "recursive-clients soft limit exceeded, " "aborting oldest query"); - killoldest = ISC_TRUE; + ns_client_killoldestquery(client); result = ISC_R_SUCCESS; - } - if (dns_resolver_nrunning(client->view->resolver) > - (unsigned int)ns_g_server->recursionquota.max) - result = ISC_R_QUOTA; - if (result == ISC_R_SUCCESS && !client->mortal && - (client->attributes & NS_CLIENTATTR_TCP) == 0) - result = ns_client_replace(client); - if (result != ISC_R_SUCCESS) { + } else if (result == ISC_R_QUOTA) { ns_client_log(client, NS_LOGCATEGORY_CLIENT, NS_LOGMODULE_QUERY, ISC_LOG_WARNING, "no more recursive clients: %s", isc_result_totext(result)); - if (client->recursionquota != NULL) - isc_quota_detach(&client->recursionquota); - return (result); + ns_client_killoldestquery(client); } - ns_client_recursing(client, killoldest); + if (result == ISC_R_SUCCESS && !client->mortal && + (client->attributes & NS_CLIENTATTR_TCP) == 0) { + result = ns_client_replace(client); + if (result != ISC_R_SUCCESS) { + ns_client_log(client, NS_LOGCATEGORY_CLIENT, + NS_LOGMODULE_QUERY, + ISC_LOG_WARNING, + "ns_client_replace() failed: %s", + isc_result_totext(result)); + isc_quota_detach(&client->recursionquota); + } + } + if (result != ISC_R_SUCCESS) + return (result); + ns_client_recursing(client); } /* @@ -2319,6 +2295,34 @@ query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) { query_releasename(client, &fname); } +static inline void +answer_in_glue(ns_client_t *client, dns_rdatatype_t qtype) { + dns_name_t *name; + dns_message_t *msg; + dns_section_t section = DNS_SECTION_ADDITIONAL; + dns_rdataset_t *rdataset = NULL; + + msg = client->message; + for (name = ISC_LIST_HEAD(msg->sections[section]); + name != NULL; + name = ISC_LIST_NEXT(name, link)) + if (dns_name_equal(name, client->query.qname)) { + for (rdataset = ISC_LIST_HEAD(name->list); + rdataset != NULL; + rdataset = ISC_LIST_NEXT(rdataset, link)) + if (rdataset->type == qtype) + break; + break; + } + if (rdataset != NULL) { + ISC_LIST_UNLINK(msg->sections[section], name, link); + ISC_LIST_PREPEND(msg->sections[section], name, link); + ISC_LIST_UNLINK(name->list, rdataset, link); + ISC_LIST_PREPEND(name->list, rdataset, link); + rdataset->attributes |= DNS_RDATASETATTR_REQUIREDGLUE; + } +} + /* * Do the bulk of query processing for the current query of 'client'. * If 'event' is non-NULL, we are returning from recursion and 'qtype' @@ -2875,7 +2879,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) /* * Add SOA. If the query was for a SOA record force the * ttl to zero so that it is possible for clients to find - * the containing zone of a arbitary name with a stub + * the containing zone of an arbitrary name with a stub * resolver and not have it cached. */ if (qtype == dns_rdatatype_soa) @@ -3338,6 +3342,16 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype) */ setup_query_sortlist(client); + /* + * If this is a referral and the answer to the question + * is in the glue sort it to the start of the additional + * section. + */ + if (client->message->counts[DNS_SECTION_ANSWER] == 0 && + client->message->rcode == dns_rcode_noerror && + (qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa)) + answer_in_glue(client, qtype); + if (client->message->rcode == dns_rcode_nxdomain && client->view->auth_nxdomain == ISC_TRUE) client->message->flags |= DNS_MESSAGEFLAG_AA; diff --git a/contrib/bind9/bin/named/server.c b/contrib/bind9/bin/named/server.c index d0b6afc0e59..b9d30d02f64 100644 --- a/contrib/bind9/bin/named/server.c +++ b/contrib/bind9/bin/named/server.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.339.2.15.2.59 2004/11/10 22:13:56 marka Exp $ */ +/* $Id: server.c,v 1.339.2.15.2.65 2005/07/27 02:53:15 marka Exp $ */ #include @@ -81,6 +81,10 @@ #include #include #include +#ifdef HAVE_LIBSCF +#include +#include +#endif /* * Check an operation for failure. Assumes that the function @@ -1798,7 +1802,7 @@ configure_server_quota(cfg_obj_t **maps, const char *name, isc_quota_t *quota) result = ns_config_get(maps, name, &obj); INSIST(result == ISC_R_SUCCESS); - quota->max = cfg_obj_asuint32(obj); + isc_quota_max(quota, cfg_obj_asuint32(obj)); } /* @@ -1937,9 +1941,13 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) { * At this point the zone list may contain a stale zone * just removed from the configuration. To see the validity, * check if the corresponding view is in our current view list. + * There may also be old zones that are still in the process + * of shutting down and have detached from their old view + * (zoneview == NULL). */ zoneview = dns_zone_getview(zone); - INSIST(zoneview != NULL); + if (zoneview == NULL) + continue; for (view = ISC_LIST_HEAD(server->viewlist); view != NULL && view != zoneview; view = ISC_LIST_NEXT(view, link)) @@ -2221,6 +2229,11 @@ load_configuration(const char *filename, ns_server_t *server, configure_server_quota(maps, "tcp-clients", &server->tcpquota); configure_server_quota(maps, "recursive-clients", &server->recursionquota); + if (server->recursionquota.max > 1000) + isc_quota_soft(&server->recursionquota, + server->recursionquota.max - 100); + else + isc_quota_soft(&server->recursionquota, 0); CHECK(configure_view_acl(NULL, config, "blackhole", &aclconfctx, ns_g_mctx, &server->blackholeacl)); @@ -2948,7 +2961,6 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) { RUNTIME_CHECK(result == ISC_R_SUCCESS); result = isc_quota_init(&server->recursionquota, 100); RUNTIME_CHECK(result == ISC_R_SUCCESS); - isc_quota_soft(&server->recursionquota, ISC_FALSE); result = dns_aclenv_init(mctx, &server->aclenv); RUNTIME_CHECK(result == ISC_R_SUCCESS); @@ -3637,6 +3649,15 @@ add_view_tolist(struct dumpcontext *dctx, dns_view_t *view) { struct viewlistentry *vle; isc_result_t result = ISC_R_SUCCESS; + /* + * Prevent duplicate views. + */ + for (vle = ISC_LIST_HEAD(dctx->viewlist); + vle != NULL; + vle = ISC_LIST_NEXT(vle, link)) + if (vle->view == view) + return (ISC_R_SUCCESS); + vle = isc_mem_get(dctx->mctx, sizeof *vle); if (vle == NULL) return (ISC_R_NOMEMORY); @@ -3700,9 +3721,11 @@ dumpdone(void *arg, isc_result_t result) { if (dctx->view == NULL) goto done; INSIST(dctx->zone == NULL); - } + } else + goto resume; nextview: fprintf(dctx->fp, ";\n; Start view %s\n;\n", dctx->view->view->name); + resume: if (dctx->zone == NULL && dctx->cache == NULL && dctx->dumpcache) { style = &dns_master_style_cache; /* start cache dump */ @@ -3763,9 +3786,12 @@ dumpdone(void *arg, isc_result_t result) { &dctx->mdctx); if (result == DNS_R_CONTINUE) return; - if (result == ISC_R_NOTIMPLEMENTED) + if (result == ISC_R_NOTIMPLEMENTED) { fprintf(dctx->fp, "; %s\n", dns_result_totext(result)); + result = ISC_R_SUCCESS; + goto nextzone; + } if (result != ISC_R_SUCCESS) goto cleanup; } @@ -3789,7 +3815,6 @@ dumpdone(void *arg, isc_result_t result) { dumpcontext_destroy(dctx); } - isc_result_t ns_server_dumpdb(ns_server_t *server, char *args) { struct dumpcontext *dctx = NULL; @@ -3845,6 +3870,7 @@ ns_server_dumpdb(ns_server_t *server, char *args) { ptr = next_token(&args, " \t"); } + nextview: for (view = ISC_LIST_HEAD(server->viewlist); view != NULL; view = ISC_LIST_NEXT(view, link)) @@ -3853,6 +3879,11 @@ ns_server_dumpdb(ns_server_t *server, char *args) { continue; CHECK(add_view_tolist(dctx, view)); } + if (ptr != NULL) { + ptr = next_token(&args, " \t"); + if (ptr != NULL) + goto nextview; + } dumpdone(dctx, ISC_R_SUCCESS); return (ISC_R_SUCCESS); @@ -4101,3 +4132,22 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) { dns_zone_detach(&zone); return (result); } + +#ifdef HAVE_LIBSCF +/* + * This function adds a message for rndc to echo if named + * is managed by smf and is also running chroot. + */ +isc_result_t +ns_smf_add_message(isc_buffer_t *text) { + unsigned int n; + + n = snprintf((char *)isc_buffer_used(text), + isc_buffer_availablelength(text), + "use svcadm(1M) to manage named"); + if (n >= isc_buffer_availablelength(text)) + return (ISC_R_NOSPACE); + isc_buffer_add(text, n); + return (ISC_R_SUCCESS); +} +#endif /* HAVE_LIBSCF */ diff --git a/contrib/bind9/bin/named/unix/os.c b/contrib/bind9/bin/named/unix/os.c index 797754948de..f306f146225 100644 --- a/contrib/bind9/bin/named/unix/os.c +++ b/contrib/bind9/bin/named/unix/os.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: os.c,v 1.46.2.4.8.19 2004/10/07 02:34:20 marka Exp $ */ +/* $Id: os.c,v 1.46.2.4.8.22 2005/05/20 01:37:19 marka Exp $ */ #include #include @@ -46,6 +46,9 @@ #include #include +#ifdef HAVE_LIBSCF +#include +#endif static char *pidfile = NULL; static int devnullfd = -1; @@ -159,7 +162,7 @@ linux_setcaps(unsigned int caps) { memset(&cap, 0, sizeof(cap)); cap.effective = caps; cap.permitted = caps; - cap.inheritable = caps; + cap.inheritable = 0; if (syscall(SYS_capset, &caphead, &cap) < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); ns_main_earlyfatal("capset failed: %s:" @@ -417,6 +420,9 @@ all_digits(const char *s) { void ns_os_chroot(const char *root) { char strbuf[ISC_STRERRORSIZE]; +#ifdef HAVE_LIBSCF + ns_smf_chroot = 0; +#endif if (root != NULL) { if (chroot(root) < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); @@ -426,6 +432,10 @@ ns_os_chroot(const char *root) { isc__strerror(errno, strbuf, sizeof(strbuf)); ns_main_earlyfatal("chdir(/): %s", strbuf); } +#ifdef HAVE_LIBSCF + /* Set ns_smf_chroot flag on successful chroot. */ + ns_smf_chroot = 1; +#endif } } diff --git a/contrib/bind9/bin/named/update.c b/contrib/bind9/bin/named/update.c index 325381a85be..6c2d7597f79 100644 --- a/contrib/bind9/bin/named/update.c +++ b/contrib/bind9/bin/named/update.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.88.2.5.2.25 2004/10/21 01:40:22 marka Exp $ */ +/* $Id: update.c,v 1.88.2.5.2.27 2005/10/08 00:21:06 marka Exp $ */ #include @@ -2723,8 +2723,8 @@ updatedone_action(isc_task_t *task, isc_event_t *event) { INSIST(client->nupdates > 0); client->nupdates--; respond(client, uev->result); - ns_client_detach(&client); isc_event_free(&event); + ns_client_detach(&client); } /* @@ -2740,8 +2740,8 @@ forward_fail(isc_task_t *task, isc_event_t *event) { INSIST(client->nupdates > 0); client->nupdates--; respond(client, DNS_R_SERVFAIL); - ns_client_detach(&client); isc_event_free(&event); + ns_client_detach(&client); } diff --git a/contrib/bind9/bin/named/xfrout.c b/contrib/bind9/bin/named/xfrout.c index 9fb2697a45d..687c287f4bd 100644 --- a/contrib/bind9/bin/named/xfrout.c +++ b/contrib/bind9/bin/named/xfrout.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: xfrout.c,v 1.101.2.5.2.10 2004/04/02 06:08:17 marka Exp $ */ +/* $Id: xfrout.c,v 1.101.2.5.2.12 2005/10/14 02:13:05 marka Exp $ */ #include @@ -868,7 +868,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename, const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6); static void -xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) +xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...) ISC_FORMAT_PRINTF(3, 4); /**************************************************************************/ @@ -1710,7 +1710,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename, * Logging function for use when there is a xfrout_ctx_t. */ static void -xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) { +xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...) { va_list ap; va_start(ap, fmt); xfrout_logv(xfr->client, xfr->qname, xfr->qclass, level, fmt, ap); diff --git a/contrib/bind9/bin/named/zoneconf.c b/contrib/bind9/bin/named/zoneconf.c index afafa534d2b..41ce69d6a62 100644 --- a/contrib/bind9/bin/named/zoneconf.c +++ b/contrib/bind9/bin/named/zoneconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zoneconf.c,v 1.87.2.4.10.13 2004/04/20 14:12:09 marka Exp $ */ +/* $Id: zoneconf.c,v 1.87.2.4.10.15 2005/09/06 02:12:39 marka Exp $ */ #include @@ -375,17 +375,30 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig, obj = NULL; result = cfg_map_get(zoptions, "database", &obj); if (result == ISC_R_SUCCESS) - cpval = cfg_obj_asstring(obj); + cpval = isc_mem_strdup(mctx, cfg_obj_asstring(obj)); else cpval = default_dbtype; - RETERR(strtoargv(mctx, cpval, &dbargc, &dbargv)); + + if (cpval == NULL) + return(ISC_R_NOMEMORY); + + result = strtoargv(mctx, cpval, &dbargc, &dbargv); + if (result != ISC_R_SUCCESS && cpval != default_dbtype) { + isc_mem_free(mctx, cpval); + return (result); + } + /* * ANSI C is strange here. There is no logical reason why (char **) * cannot be promoted automatically to (const char * const *) by the * compiler w/o generating a warning. */ - RETERR(dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv)); + result = dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv); isc_mem_put(mctx, dbargv, dbargc * sizeof(*dbargv)); + if (cpval != default_dbtype) + isc_mem_free(mctx, cpval); + if (result != ISC_R_SUCCESS) + return (result); obj = NULL; result = cfg_map_get(zoptions, "file", &obj); diff --git a/contrib/bind9/bin/nsupdate/nsupdate.8 b/contrib/bind9/bin/nsupdate/nsupdate.8 index 7828db23a8b..602a55b1831 100644 --- a/contrib/bind9/bin/nsupdate/nsupdate.8 +++ b/contrib/bind9/bin/nsupdate/nsupdate.8 @@ -1,294 +1,239 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000-2003 Internet Software Consortium. -.\" +.\" 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, +.\" 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: nsupdate.8,v 1.24.2.2.2.5 2004/03/08 09:04:15 marka Exp $ +.\" $Id: nsupdate.8,v 1.24.2.2.2.8 2005/10/13 02:33:48 marka Exp $ .\" -.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" nsupdate \- Dynamic DNS update utility -.SH SYNOPSIS -.sp -\fBnsupdate\fR [ \fB-d\fR ] [ \fB [ -y \fIkeyname:secret\fB ] [ -k \fIkeyfile\fB ] \fR ] [ \fB-t \fItimeout\fB\fR ] [ \fB-u \fIudptimeout\fB\fR ] [ \fB-r \fIudpretries\fB\fR ] [ \fB-v\fR ] [ \fBfilename\fR ] +.SH "SYNOPSIS" +.HP 9 +\fBnsupdate\fR [\fB\-d\fR] [[\fB\-y\ \fR\fB\fIkeyname:secret\fR\fR] [\fB\-k\ \fR\fB\fIkeyfile\fR\fR]] [\fB\-t\ \fR\fB\fItimeout\fR\fR] [\fB\-u\ \fR\fB\fIudptimeout\fR\fR] [\fB\-r\ \fR\fB\fIudpretries\fR\fR] [\fB\-v\fR] [filename] .SH "DESCRIPTION" .PP \fBnsupdate\fR -is used to submit Dynamic DNS Update requests as defined in RFC2136 -to a name server. -This allows resource records to be added or removed from a zone -without manually editing the zone file. -A single update request can contain requests to add or remove more than one -resource record. +is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. This allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or remove more than one resource record. .PP Zones that are under dynamic control via \fBnsupdate\fR -or a DHCP server should not be edited by hand. -Manual edits could -conflict with dynamic updates and cause data to be lost. +or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause data to be lost. .PP The resource records that are dynamically added or removed with \fBnsupdate\fR -have to be in the same zone. -Requests are sent to the zone's master server. -This is identified by the MNAME field of the zone's SOA record. +have to be in the same zone. Requests are sent to the zone's master server. This is identified by the MNAME field of the zone's SOA record. .PP The -\fB-d\fR +\fB\-d\fR option makes \fBnsupdate\fR -operate in debug mode. -This provides tracing information about the update requests that are -made and the replies received from the name server. +operate in debug mode. This provides tracing information about the update requests that are made and the replies received from the name server. .PP -Transaction signatures can be used to authenticate the Dynamic DNS -updates. -These use the TSIG resource record type described in RFC2845 or the -SIG(0) record described in RFC3535 and RFC2931. -TSIG relies on a shared secret that should only be known to -\fBnsupdate\fR and the name server. -Currently, the only supported encryption algorithm for TSIG is -HMAC-MD5, which is defined in RFC 2104. -Once other algorithms are defined for TSIG, applications will need to -ensure they select the appropriate algorithm as well as the key when -authenticating each other. -For instance suitable +Transaction signatures can be used to authenticate the Dynamic DNS updates. These use the TSIG resource record type described in RFC2845 or the SIG(0) record described in RFC3535 and RFC2931. TSIG relies on a shared secret that should only be known to +\fBnsupdate\fR +and the name server. Currently, the only supported encryption algorithm for TSIG is HMAC\-MD5, which is defined in RFC 2104. Once other algorithms are defined for TSIG, applications will need to ensure they select the appropriate algorithm as well as the key when authenticating each other. For instance suitable \fBkey\fR and \fBserver\fR statements would be added to \fI/etc/named.conf\fR -so that the name server can associate the appropriate secret key -and algorithm with the IP address of the -client application that will be using TSIG authentication. -SIG(0) uses public key cryptography. To use a SIG(0) key, the public -key must be stored in a KEY record in a zone served by the name server. +so that the name server can associate the appropriate secret key and algorithm with the IP address of the client application that will be using TSIG authentication. SIG(0) uses public key cryptography. To use a SIG(0) key, the public key must be stored in a KEY record in a zone served by the name server. \fBnsupdate\fR does not read \fI/etc/named.conf\fR. .PP \fBnsupdate\fR uses the -\fB-y\fR +\fB\-y\fR or -\fB-k\fR -option (with an HMAC-MD5 key) to provide the shared secret needed to generate -a TSIG record for authenticating Dynamic DNS update requests. -These options are mutually exclusive. -With the -\fB-k\fR +\fB\-k\fR +option (with an HMAC\-MD5 key) to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the +\fB\-k\fR option, \fBnsupdate\fR reads the shared secret from the file -\fIkeyfile\fR, -whose name is of the form -\fIK{name}.+157.+{random}.private\fR. -For historical -reasons, the file +\fIkeyfile\fR, whose name is of the form +\fIK{name}.+157.+{random}.private\fR. For historical reasons, the file \fIK{name}.+157.+{random}.key\fR must also be present. When the -\fB-y\fR +\fB\-y\fR option is used, a signature is generated from -\fIkeyname:secret.\fR -\fIkeyname\fR -is the name of the key, -and +\fIkeyname:secret.\fR\fIkeyname\fR +is the name of the key, and \fIsecret\fR -is the base64 encoded shared secret. -Use of the -\fB-y\fR -option is discouraged because the shared secret is supplied as a command -line argument in clear text. -This may be visible in the output from -\fBps\fR(1) +is the base64 encoded shared secret. Use of the +\fB\-y\fR +option is discouraged because the shared secret is supplied as a command line argument in clear text. This may be visible in the output from +\fBps\fR(1 ) or in a history file maintained by the user's shell. .PP -The \fB-k\fR may also be used to specify a SIG(0) key used -to authenticate Dynamic DNS update requests. In this case, the key -specified is not an HMAC-MD5 key. +The +\fB\-k\fR +may also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the key specified is not an HMAC\-MD5 key. .PP By default \fBnsupdate\fR -uses UDP to send update requests to the name server unless they are too -large to fit in a UDP request in which case TCP will be used. -The -\fB-v\fR +uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. The +\fB\-v\fR option makes \fBnsupdate\fR -use a TCP connection. -This may be preferable when a batch of update requests is made. +use a TCP connection. This may be preferable when a batch of update requests is made. .PP -The \fB-t\fR option sets the maximum time a update request can -take before it is aborted. The default is 300 seconds. Zero can be used -to disable the timeout. +The +\fB\-t\fR +option sets the maximum time a update request can take before it is aborted. The default is 300 seconds. Zero can be used to disable the timeout. .PP -The \fB-u\fR option sets the UDP retry interval. The default is -3 seconds. If zero the interval will be computed from the timeout interval -and number of UDP retries. +The +\fB\-u\fR +option sets the UDP retry interval. The default is 3 seconds. If zero the interval will be computed from the timeout interval and number of UDP retries. .PP -The \fB-r\fR option sets the number of UDP retries. The default is -3. If zero only one update request will be made. +The +\fB\-r\fR +option sets the number of UDP retries. The default is 3. If zero only one update request will be made. .SH "INPUT FORMAT" .PP \fBnsupdate\fR reads input from \fIfilename\fR -or standard input. -Each command is supplied on exactly one line of input. -Some commands are for administrative purposes. -The others are either update instructions or prerequisite checks on the -contents of the zone. -These checks set conditions that some name or set of -resource records (RRset) either exists or is absent from the zone. -These conditions must be met if the entire update request is to succeed. -Updates will be rejected if the tests for the prerequisite conditions fail. +or standard input. Each command is supplied on exactly one line of input. Some commands are for administrative purposes. The others are either update instructions or prerequisite checks on the contents of the zone. These checks set conditions that some name or set of resource records (RRset) either exists or is absent from the zone. These conditions must be met if the entire update request is to succeed. Updates will be rejected if the tests for the prerequisite conditions fail. .PP -Every update request consists of zero or more prerequisites -and zero or more updates. -This allows a suitably authenticated update request to proceed if some -specified resource records are present or missing from the zone. -A blank input line (or the \fBsend\fR command) causes the -accumulated commands to be sent as one Dynamic DNS update request to the -name server. +Every update request consists of zero or more prerequisites and zero or more updates. This allows a suitably authenticated update request to proceed if some specified resource records are present or missing from the zone. A blank input line (or the +\fBsend\fR +command) causes the accumulated commands to be sent as one Dynamic DNS update request to the name server. .PP The command formats and their meaning are as follows: .TP -\fBserver servername [ port ]\fR +.HP 7 \fBserver\fR {servername} [port] Sends all dynamic update requests to the name server -\fIservername\fR. -When no server statement is provided, +\fIservername\fR. When no server statement is provided, \fBnsupdate\fR -will send updates to the master server of the correct zone. -The MNAME field of that zone's SOA record will identify the master -server for that zone. +will send updates to the master server of the correct zone. The MNAME field of that zone's SOA record will identify the master server for that zone. \fIport\fR is the port number on \fIservername\fR -where the dynamic update requests get sent. -If no port number is specified, the default DNS port number of 53 is -used. +where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is used. .TP -\fBlocal address [ port ]\fR +.HP 6 \fBlocal\fR {address} [port] Sends all dynamic update requests using the local -\fIaddress\fR. -When no local statement is provided, +\fIaddress\fR. When no local statement is provided, \fBnsupdate\fR will send updates using an address and port chosen by the system. \fIport\fR -can additionally be used to make requests come from a specific port. -If no port number is specified, the system will assign one. +can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one. .TP -\fBzone zonename\fR +.HP 5 \fBzone\fR {zonename} Specifies that all updates are to be made to the zone -\fIzonename\fR. -If no +\fIzonename\fR. If no \fIzone\fR statement is provided, \fBnsupdate\fR will attempt determine the correct zone to update based on the rest of the input. .TP -\fBclass classname\fR -Specify the default class. -If no \fIclass\fR is specified the default class is +.HP 6 \fBclass\fR {classname} +Specify the default class. If no +\fIclass\fR +is specified the default class is \fIIN\fR. .TP -\fBkey name secret\fR +.HP 4 \fBkey\fR {name} {secret} Specifies that all updates are to be TSIG signed using the -\fIkeyname\fR \fIkeysecret\fR pair. -The \fBkey\fR command -overrides any key specified on the command line via -\fB-y\fR or \fB-k\fR. +\fIkeyname\fR\fIkeysecret\fR +pair. The +\fBkey\fR +command overrides any key specified on the command line via +\fB\-y\fR +or +\fB\-k\fR. .TP -\fBprereq nxdomain domain-name\fR +.HP 16 \fBprereq nxdomain\fR {domain\-name} Requires that no resource record of any type exists with name -\fIdomain-name\fR. +\fIdomain\-name\fR. .TP -\fBprereq yxdomain domain-name\fR +.HP 16 \fBprereq yxdomain\fR {domain\-name} Requires that -\fIdomain-name\fR +\fIdomain\-name\fR exists (has as at least one resource record, of any type). .TP -\fBprereq nxrrset domain-name [ class ] type\fR +.HP 15 \fBprereq nxrrset\fR {domain\-name} [class] {type} Requires that no resource record exists of the specified \fItype\fR, \fIclass\fR and -\fIdomain-name\fR. -If +\fIdomain\-name\fR. If \fIclass\fR is omitted, IN (internet) is assumed. .TP -\fBprereq yxrrset domain-name [ class ] type\fR +.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type} This requires that a resource record of the specified \fItype\fR, \fIclass\fR and -\fIdomain-name\fR -must exist. -If +\fIdomain\-name\fR +must exist. If \fIclass\fR is omitted, IN (internet) is assumed. .TP -\fBprereq yxrrset domain-name [ class ] type data\fI...\fB\fR +.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type} {data...} The \fIdata\fR -from each set of prerequisites of this form -sharing a common +from each set of prerequisites of this form sharing a common \fItype\fR, -\fIclass\fR, -and -\fIdomain-name\fR -are combined to form a set of RRs. This set of RRs must -exactly match the set of RRs existing in the zone at the -given +\fIclass\fR, and +\fIdomain\-name\fR +are combined to form a set of RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given \fItype\fR, -\fIclass\fR, -and -\fIdomain-name\fR. -The +\fIclass\fR, and +\fIdomain\-name\fR. The \fIdata\fR -are written in the standard text representation of the resource record's -RDATA. +are written in the standard text representation of the resource record's RDATA. .TP -\fBupdate delete domain-name [ ttl ] [ class ] [ type [ data\fI...\fB ] ]\fR +.HP 14 \fBupdate delete\fR {domain\-name} [ttl] [class] [type\ [data...]] Deletes any resource records named -\fIdomain-name\fR. -If +\fIdomain\-name\fR. If \fItype\fR and \fIdata\fR -is provided, only matching resource records will be removed. -The internet class is assumed if +is provided, only matching resource records will be removed. The internet class is assumed if \fIclass\fR is not supplied. The \fIttl\fR is ignored, and is only allowed for compatibility. .TP -\fBupdate add domain-name ttl [ class ] type data\fI...\fB\fR +.HP 11 \fBupdate add\fR {domain\-name} {ttl} [class] {type} {data...} Adds a new resource record with the specified \fIttl\fR, \fIclass\fR and \fIdata\fR. .TP -\fBshow\fR -Displays the current message, containing all of the prerequisites and -updates specified since the last send. +.HP 5 \fBshow\fR +Displays the current message, containing all of the prerequisites and updates specified since the last send. .TP -\fBsend\fR +.HP 5 \fBsend\fR Sends the current message. This is equivalent to entering a blank line. .TP -\fBanswer\fR +.HP 7 \fBanswer\fR Displays the answer. .PP Lines beginning with a semicolon are comments and are ignored. @@ -298,10 +243,7 @@ The examples below show how \fBnsupdate\fR could be used to insert and delete resource records from the \fBexample.com\fR -zone. -Notice that the input in each example contains a trailing blank line so that -a group of commands are sent as one dynamic update request to the -master name server for +zone. Notice that the input in each example contains a trailing blank line so that a group of commands are sent as one dynamic update request to the master name server for \fBexample.com\fR. .sp .nf @@ -309,61 +251,48 @@ master name server for > update delete oldhost.example.com A > update add newhost.example.com 86400 A 172.16.1.1 > send -.sp .fi +.sp .PP Any A records for \fBoldhost.example.com\fR -are deleted. -and an A record for +are deleted. and an A record for \fBnewhost.example.com\fR -it IP address 172.16.1.1 is added. -The newly-added record has a 1 day TTL (86400 seconds) +it IP address 172.16.1.1 is added. The newly\-added record has a 1 day TTL (86400 seconds) .sp .nf # nsupdate > prereq nxdomain nickname.example.com > update add nickname.example.com 86400 CNAME somehost.example.com > send -.sp .fi +.sp .PP -The prerequisite condition gets the name server to check that there -are no resource records of any type for -\fBnickname.example.com\fR. -If there are, the update request fails. -If this name does not exist, a CNAME for it is added. -This ensures that when the CNAME is added, it cannot conflict with the -long-standing rule in RFC1034 that a name must not exist as any other -record type if it exists as a CNAME. -(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have -RRSIG, DNSKEY and NSEC records.) +The prerequisite condition gets the name server to check that there are no resource records of any type for +\fBnickname.example.com\fR. If there are, the update request fails. If this name does not exist, a CNAME for it is added. This ensures that when the CNAME is added, it cannot conflict with the long\-standing rule in RFC1034 that a name must not exist as any other record type if it exists as a CNAME. (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have RRSIG, DNSKEY and NSEC records.) .SH "FILES" .TP \fB/etc/resolv.conf\fR used to identify default name server .TP \fBK{name}.+157.+{random}.key\fR -base-64 encoding of HMAC-MD5 key created by -\fBdnssec-keygen\fR(8). +base\-64 encoding of HMAC\-MD5 key created by +\fBdnssec\-keygen\fR(8). .TP \fBK{name}.+157.+{random}.private\fR -base-64 encoding of HMAC-MD5 key created by -\fBdnssec-keygen\fR(8). +base\-64 encoding of HMAC\-MD5 key created by +\fBdnssec\-keygen\fR(8). .SH "SEE ALSO" .PP -\fBRFC2136\fR, -\fBRFC3007\fR, -\fBRFC2104\fR, -\fBRFC2845\fR, -\fBRFC1034\fR, -\fBRFC2535\fR, -\fBRFC2931\fR, +\fBRFC2136\fR(), +\fBRFC3007\fR(), +\fBRFC2104\fR(), +\fBRFC2845\fR(), +\fBRFC1034\fR(), +\fBRFC2535\fR(), +\fBRFC2931\fR(), \fBnamed\fR(8), -\fBdnssec-keygen\fR(8). +\fBdnssec\-keygen\fR(8). .SH "BUGS" .PP -The TSIG key is redundantly stored in two separate files. -This is a consequence of nsupdate using the DST library -for its cryptographic operations, and may change in future -releases. +The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may change in future releases. diff --git a/contrib/bind9/bin/nsupdate/nsupdate.c b/contrib/bind9/bin/nsupdate/nsupdate.c index 3304a3c0e64..7c728b6db95 100644 --- a/contrib/bind9/bin/nsupdate/nsupdate.c +++ b/contrib/bind9/bin/nsupdate/nsupdate.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nsupdate.c,v 1.103.2.15.2.18 2004/09/16 02:12:18 marka Exp $ */ +/* $Id: nsupdate.c,v 1.103.2.15.2.20 2005/03/17 03:58:26 marka Exp $ */ #include @@ -1634,6 +1634,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) { ddebug("Destroying request [%p]", request); dns_request_destroy(&request); dns_message_renderreset(soaquery); + dns_message_settsigkey(soaquery, NULL); sendrequest(localaddr, &servers[ns_inuse], soaquery, &request); isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t)); isc_event_free(&event); @@ -1813,6 +1814,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) { dns_name_clone(&tname, name); dns_request_destroy(&request); dns_message_renderreset(soaquery); + dns_message_settsigkey(soaquery, NULL); if (userserver != NULL) sendrequest(localaddr, userserver, soaquery, &request); else diff --git a/contrib/bind9/bin/nsupdate/nsupdate.docbook b/contrib/bind9/bin/nsupdate/nsupdate.docbook index 7d23333c864..7a2b4cfb7dd 100644 --- a/contrib/bind9/bin/nsupdate/nsupdate.docbook +++ b/contrib/bind9/bin/nsupdate/nsupdate.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -27,6 +29,22 @@ 8 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + + nsupdate Dynamic DNS update utility @@ -229,6 +247,8 @@ where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is used. + + @@ -248,6 +268,9 @@ will send updates using an address and port chosen by the system. port can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one. + + + @@ -482,6 +505,7 @@ updates specified since the last send. Sends the current message. This is equivalent to entering a blank line. + @@ -493,8 +517,10 @@ Sends the current message. This is equivalent to entering a blank line. Displays the answer. + + Lines beginning with a semicolon are comments and are ignored. @@ -562,6 +588,7 @@ RRSIG, DNSKEY and NSEC records.) used to identify default name server + K{name}.+157.+{random}.key @@ -572,6 +599,7 @@ base-64 encoding of HMAC-MD5 key created by . + K{name}.+157.+{random}.private @@ -582,6 +610,7 @@ base-64 encoding of HMAC-MD5 key created by . + @@ -615,7 +644,7 @@ base-64 encoding of HMAC-MD5 key created by dnssec-keygen8 . - + BUGS diff --git a/contrib/bind9/bin/nsupdate/nsupdate.html b/contrib/bind9/bin/nsupdate/nsupdate.html index f9cb98cc35f..74ba2fbe277 100644 --- a/contrib/bind9/bin/nsupdate/nsupdate.html +++ b/contrib/bind9/bin/nsupdate/nsupdate.html @@ -1,339 +1,170 @@ - - - - -nsupdate

nsupdate

Name

nsupdate -- Dynamic DNS update utility

Synopsis

nsupdate [-d] [-y keyname:secret | -k keyfile] [-t timeout] [-u udptimeout] [-r udpretries] [-v] [filename]

DESCRIPTION

nsupdate + + + + +nsupdate + + +

+
+
+

Name

+

nsupdate — Dynamic DNS update utility

+
+
+

Synopsis

+

nsupdate [-d] [[-y keyname:secret] | [-k keyfile]] [-t timeout] [-u udptimeout] [-r udpretries] [-v] [filename]

+
+
+

DESCRIPTION

+

+nsupdate is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. This allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or remove more than one -resource record.

Zones that are under dynamic control via -nsupdate +resource record. +

+

+Zones that are under dynamic control via +nsupdate or a DHCP server should not be edited by hand. Manual edits could -conflict with dynamic updates and cause data to be lost.

The resource records that are dynamically added or removed with -nsupdate +conflict with dynamic updates and cause data to be lost. +

+

+The resource records that are dynamically added or removed with +nsupdate have to be in the same zone. Requests are sent to the zone's master server. -This is identified by the MNAME field of the zone's SOA record.

The --d +This is identified by the MNAME field of the zone's SOA record. +

+

+The +-d option makes -nsupdate +nsupdate operate in debug mode. This provides tracing information about the update requests that are -made and the replies received from the name server.

Transaction signatures can be used to authenticate the Dynamic DNS +made and the replies received from the name server. +

+

+Transaction signatures can be used to authenticate the Dynamic DNS updates. These use the TSIG resource record type described in RFC2845 or the SIG(0) record described in RFC3535 and RFC2931. TSIG relies on a shared secret that should only be known to -nsupdate and the name server. +nsupdate and the name server. Currently, the only supported encryption algorithm for TSIG is HMAC-MD5, which is defined in RFC 2104. Once other algorithms are defined for TSIG, applications will need to ensure they select the appropriate algorithm as well as the key when authenticating each other. For instance suitable -key +key and -server +server statements would be added to -/etc/named.conf +/etc/named.conf so that the name server can associate the appropriate secret key and algorithm with the IP address of the client application that will be using TSIG authentication. SIG(0) uses public key cryptography. To use a SIG(0) key, the public key must be stored in a KEY record in a zone served by the name server. -nsupdate +nsupdate does not read -/etc/named.conf.

nsupdate +/etc/named.conf. +

+

+nsupdate uses the --y +-y or --k +-k option (with an HMAC-MD5 key) to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the --k +-k option, -nsupdate +nsupdate reads the shared secret from the file -keyfile, +keyfile, whose name is of the form -K{name}.+157.+{random}.private. +K{name}.+157.+{random}.private. For historical reasons, the file -K{name}.+157.+{random}.key +K{name}.+157.+{random}.key must also be present. When the --y +-y option is used, a signature is generated from -keyname:secret. -keyname +keyname:secret. +keyname is the name of the key, and -secret +secret is the base64 encoded shared secret. Use of the --y +-y option is discouraged because the shared secret is supplied as a command line argument in clear text. This may be visible in the output from -ps(1) -or in a history file maintained by the user's shell.

The -k may also be used to specify a SIG(0) key used +ps(1 +) +or in a history file maintained by the user's shell. +

+

+The -k may also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the key -specified is not an HMAC-MD5 key.

By default -nsupdate +specified is not an HMAC-MD5 key. +

+

+By default +nsupdate uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. The --v +-v option makes -nsupdate +nsupdate use a TCP connection. -This may be preferable when a batch of update requests is made.

The -t option sets the maximum time a update request can +This may be preferable when a batch of update requests is made. +

+

The -t option sets the maximum time a update request can take before it is aborted. The default is 300 seconds. Zero can be used -to disable the timeout.

The -u option sets the UDP retry interval. The default is +to disable the timeout. +

+

The -u option sets the UDP retry interval. The default is 3 seconds. If zero the interval will be computed from the timeout interval -and number of UDP retries.

The -r option sets the number of UDP retries. The default is -3. If zero only one update request will be made.

INPUT FORMAT

nsupdate +and number of UDP retries. +

+

The -r option sets the number of UDP retries. The default is +3. If zero only one update request will be made. +

+
+
+

INPUT FORMAT

+

+nsupdate reads input from -filename +filename or standard input. Each command is supplied on exactly one line of input. Some commands are for administrative purposes. @@ -342,471 +173,245 @@ contents of the zone. These checks set conditions that some name or set of resource records (RRset) either exists or is absent from the zone. These conditions must be met if the entire update request is to succeed. -Updates will be rejected if the tests for the prerequisite conditions fail.

Every update request consists of zero or more prerequisites +Updates will be rejected if the tests for the prerequisite conditions fail. +

+

+Every update request consists of zero or more prerequisites and zero or more updates. This allows a suitably authenticated update request to proceed if some specified resource records are present or missing from the zone. -A blank input line (or the send command) causes the +A blank input line (or the send command) causes the accumulated commands to be sent as one Dynamic DNS update request to the -name server.

The command formats and their meaning are as follows: -

server {servername} [port]

Sends all dynamic update requests to the name server -servername. +name server. +

+

+The command formats and their meaning are as follows: +

+
+
+

server {servername} [port]

+
+

+Sends all dynamic update requests to the name server +servername. When no server statement is provided, -nsupdate +nsupdate will send updates to the master server of the correct zone. The MNAME field of that zone's SOA record will identify the master server for that zone. -port +port is the port number on -servername +servername where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is -used.

local {address} [port]

Sends all dynamic update requests using the local -address. +used. +

+
+

local {address} [port]

+
+

+Sends all dynamic update requests using the local +address. When no local statement is provided, -nsupdate +nsupdate will send updates using an address and port chosen by the system. -port +port can additionally be used to make requests come from a specific port. -If no port number is specified, the system will assign one.

zone {zonename}

Specifies that all updates are to be made to the zone -zonename. +If no port number is specified, the system will assign one. +

+
+

zone {zonename}

+
+

+Specifies that all updates are to be made to the zone +zonename. If no -zone +zone statement is provided, -nsupdate -will attempt determine the correct zone to update based on the rest of the input.

class {classname}

Specify the default class. -If no class is specified the default class is -IN.

key {name} {secret}

Specifies that all updates are to be TSIG signed using the -keyname keysecret pair. -The key command +nsupdate +will attempt determine the correct zone to update based on the rest of the input. +

+
+

class {classname}

+
+

+Specify the default class. +If no class is specified the default class is +IN. +

+
+

key {name} {secret}

+
+

+Specifies that all updates are to be TSIG signed using the +keyname keysecret pair. +The key command overrides any key specified on the command line via --y or -k.

prereq nxdomain {domain-name}

Requires that no resource record of any type exists with name -domain-name.

prereq yxdomain {domain-name}

Requires that -domain-name -exists (has as at least one resource record, of any type).

prereq nxrrset {domain-name} [class] {type}

Requires that no resource record exists of the specified -type, -class +-y or -k. +

+
+

prereq nxdomain {domain-name}

+
+

+Requires that no resource record of any type exists with name +domain-name. +

+
+

prereq yxdomain {domain-name}

+
+

+Requires that +domain-name +exists (has as at least one resource record, of any type). +

+
+

prereq nxrrset {domain-name} [class] {type}

+
+

+Requires that no resource record exists of the specified +type, +class and -domain-name. +domain-name. If -class -is omitted, IN (internet) is assumed.

prereq yxrrset {domain-name} [class] {type}

This requires that a resource record of the specified -type, -class +class +is omitted, IN (internet) is assumed. +

+
+

prereq yxrrset {domain-name} [class] {type}

+
+

+This requires that a resource record of the specified +type, +class and -domain-name +domain-name must exist. If -class -is omitted, IN (internet) is assumed.

prereq yxrrset {domain-name} [class] {type} {data...}

The -data +class +is omitted, IN (internet) is assumed. +

+
+

prereq yxrrset {domain-name} [class] {type} {data...}

+
+

+The +data from each set of prerequisites of this form sharing a common -type, -class, +type, +class, and -domain-name +domain-name are combined to form a set of RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given -type, -class, +type, +class, and -domain-name. +domain-name. The -data +data are written in the standard text representation of the resource record's -RDATA.

update delete {domain-name} [ttl] [class] [type [data...]]

Deletes any resource records named -domain-name. +RDATA. +

+
+

update delete {domain-name} [ttl] [class] [type [data...]]

+
+

+Deletes any resource records named +domain-name. If -type +type and -data +data is provided, only matching resource records will be removed. The internet class is assumed if -class +class is not supplied. The -ttl -is ignored, and is only allowed for compatibility.

update add {domain-name} {ttl} [class] {type} {data...}

Adds a new resource record with the specified -ttl, -class +ttl +is ignored, and is only allowed for compatibility. +

+
+

update add {domain-name} {ttl} [class] {type} {data...}

+
+

+Adds a new resource record with the specified +ttl, +class and -data.

show

Displays the current message, containing all of the prerequisites and -updates specified since the last send.

send

Sends the current message. This is equivalent to entering a blank line.

answer

Displays the answer.

Lines beginning with a semicolon are comments and are ignored.

EXAMPLES

The examples below show how -nsupdate +data. +

+
+

show

+
+

+Displays the current message, containing all of the prerequisites and +updates specified since the last send. +

+
+

send

+
+

+Sends the current message. This is equivalent to entering a blank line. +

+
+

answer

+
+

+Displays the answer. +

+
+

+

+

+Lines beginning with a semicolon are comments and are ignored. +

+
+
+

EXAMPLES

+

+The examples below show how +nsupdate could be used to insert and delete resource records from the -example.com +example.com zone. Notice that the input in each example contains a trailing blank line so that a group of commands are sent as one dynamic update request to the master name server for -example.com. +example.com. -

# nsupdate
-> update delete oldhost.example.com A
-> update add newhost.example.com 86400 A 172.16.1.1
-> send

Any A records for -oldhost.example.com +

+
+# nsupdate
+> update delete oldhost.example.com A
+> update add newhost.example.com 86400 A 172.16.1.1
+> send
+
+

+

+

+Any A records for +oldhost.example.com are deleted. and an A record for -newhost.example.com +newhost.example.com it IP address 172.16.1.1 is added. The newly-added record has a 1 day TTL (86400 seconds) -

# nsupdate
-> prereq nxdomain nickname.example.com
-> update add nickname.example.com 86400 CNAME somehost.example.com
-> send

The prerequisite condition gets the name server to check that there +

+
+# nsupdate
+> prereq nxdomain nickname.example.com
+> update add nickname.example.com 86400 CNAME somehost.example.com
+> send
+
+

+

+

+The prerequisite condition gets the name server to check that there are no resource records of any type for -nickname.example.com. +nickname.example.com. If there are, the update request fails. If this name does not exist, a CNAME for it is added. @@ -814,149 +419,50 @@ This ensures that when the CNAME is added, it cannot conflict with the long-standing rule in RFC1034 that a name must not exist as any other record type if it exists as a CNAME. (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have -RRSIG, DNSKEY and NSEC records.)

FILES

/etc/resolv.conf

used to identify default name server

K{name}.+157.+{random}.key

base-64 encoding of HMAC-MD5 key created by -dnssec-keygen(8).

K{name}.+157.+{random}.private

base-64 encoding of HMAC-MD5 key created by -dnssec-keygen(8).

SEE ALSO

RFC2136, -RFC3007, -RFC2104, -RFC2845, -RFC1034, -RFC2535, -RFC2931, -named(8), -dnssec-keygen(8).

BUGS

The TSIG key is redundantly stored in two separate files. +RRSIG, DNSKEY and NSEC records.) +

+
+
+

FILES

+
+
/etc/resolv.conf
+

+used to identify default name server +

+
K{name}.+157.+{random}.key
+

+base-64 encoding of HMAC-MD5 key created by +dnssec-keygen(8). +

+
K{name}.+157.+{random}.private
+

+base-64 encoding of HMAC-MD5 key created by +dnssec-keygen(8). +

+
+
+
+

SEE ALSO

+

+RFC2136, +RFC3007, +RFC2104, +RFC2845, +RFC1034, +RFC2535, +RFC2931, +named(8), +dnssec-keygen(8). +

+
+
+

BUGS

+

+The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may change in future -releases.

+releases. +

+
+
+ diff --git a/contrib/bind9/bin/rndc/rndc-confgen.8 b/contrib/bind9/bin/rndc/rndc-confgen.8 index b12e90cc569..b29f0095cc0 100644 --- a/contrib/bind9/bin/rndc/rndc-confgen.8 +++ b/contrib/bind9/bin/rndc/rndc-confgen.8 @@ -1,140 +1,183 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2001-2003 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2001, 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, +.\" 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: rndc-confgen.8,v 1.3.2.5.2.3 2004/06/03 05:35:48 marka Exp $ +.\" $Id: rndc-confgen.8,v 1.3.2.5.2.7 2005/10/13 02:33:50 marka Exp $ .\" -.TH "RNDC-CONFGEN" "8" "Aug 27, 2001" "BIND9" "" -.SH NAME -rndc-confgen \- rndc key generation tool -.SH SYNOPSIS -.sp -\fBrndc-confgen\fR [ \fB-a\fR ] [ \fB-b \fIkeysize\fB\fR ] [ \fB-c \fIkeyfile\fB\fR ] [ \fB-h\fR ] [ \fB-k \fIkeyname\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-r \fIrandomfile\fB\fR ] [ \fB-s \fIaddress\fB\fR ] [ \fB-t \fIchrootdir\fB\fR ] [ \fB-u \fIuser\fB\fR ] +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "RNDC\-CONFGEN" "8" "Aug 27, 2001" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +rndc\-confgen \- rndc key generation tool +.SH "SYNOPSIS" +.HP 13 +\fBrndc\-confgen\fR [\fB\-a\fR] [\fB\-b\ \fR\fB\fIkeysize\fR\fR] [\fB\-c\ \fR\fB\fIkeyfile\fR\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkeyname\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-r\ \fR\fB\fIrandomfile\fR\fR] [\fB\-s\ \fR\fB\fIaddress\fR\fR] [\fB\-t\ \fR\fB\fIchrootdir\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] .SH "DESCRIPTION" .PP -\fBrndc-confgen\fR generates configuration files -for \fBrndc\fR. It can be used as a -convenient alternative to writing the -\fIrndc.conf\fR file -and the corresponding \fBcontrols\fR -and \fBkey\fR -statements in \fInamed.conf\fR by hand. -Alternatively, it can be run with the \fB-a\fR -option to set up a \fIrndc.key\fR file and -avoid the need for a \fIrndc.conf\fR file -and a \fBcontrols\fR statement altogether. +\fBrndc\-confgen\fR +generates configuration files for +\fBrndc\fR. It can be used as a convenient alternative to writing the +\fIrndc.conf\fR +file and the corresponding +\fBcontrols\fR +and +\fBkey\fR +statements in +\fInamed.conf\fR +by hand. Alternatively, it can be run with the +\fB\-a\fR +option to set up a +\fIrndc.key\fR +file and avoid the need for a +\fIrndc.conf\fR +file and a +\fBcontrols\fR +statement altogether. .SH "OPTIONS" .TP -\fB-a\fR -Do automatic \fBrndc\fR configuration. -This creates a file \fIrndc.key\fR -in \fI/etc\fR (or whatever -sysconfdir -was specified as when BIND was built) -that is read by both \fBrndc\fR -and \fBnamed\fR on startup. The -\fIrndc.key\fR file defines a default -command channel and authentication key allowing -\fBrndc\fR to communicate with -\fBnamed\fR on the local host -with no further configuration. - -Running \fBrndc-confgen -a\fR allows -BIND 9 and \fBrndc\fR to be used as drop-in -replacements for BIND 8 and \fBndc\fR, -with no changes to the existing BIND 8 -\fInamed.conf\fR file. - -If a more elaborate configuration than that -generated by \fBrndc-confgen -a\fR -is required, for example if rndc is to be used remotely, -you should run \fBrndc-confgen\fR without the -\fB-a\fR option and set up a -\fIrndc.conf\fR and +\-a +Do automatic +\fBrndc\fR +configuration. This creates a file +\fIrndc.key\fR +in +\fI/etc\fR +(or whatever +\fIsysconfdir\fR +was specified as when +BIND +was built) that is read by both +\fBrndc\fR +and +\fBnamed\fR +on startup. The +\fIrndc.key\fR +file defines a default command channel and authentication key allowing +\fBrndc\fR +to communicate with +\fBnamed\fR +on the local host with no further configuration. +.sp +Running +\fBrndc\-confgen \-a\fR +allows BIND 9 and +\fBrndc\fR +to be used as drop\-in replacements for BIND 8 and +\fBndc\fR, with no changes to the existing BIND 8 +\fInamed.conf\fR +file. +.sp +If a more elaborate configuration than that generated by +\fBrndc\-confgen \-a\fR +is required, for example if rndc is to be used remotely, you should run +\fBrndc\-confgen\fR +without the +\fB\-a\fR +option and set up a +\fIrndc.conf\fR +and \fInamed.conf\fR as directed. .TP -\fB-b \fIkeysize\fB\fR -Specifies the size of the authentication key in bits. -Must be between 1 and 512 bits; the default is 128. +\-b \fIkeysize\fR +Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128. .TP -\fB-c \fIkeyfile\fB\fR -Used with the \fB-a\fR option to specify -an alternate location for \fIrndc.key\fR. +\-c \fIkeyfile\fR +Used with the +\fB\-a\fR +option to specify an alternate location for +\fIrndc.key\fR. .TP -\fB-h\fR +\-h Prints a short summary of the options and arguments to -\fBrndc-confgen\fR. +\fBrndc\-confgen\fR. .TP -\fB-k \fIkeyname\fB\fR -Specifies the key name of the rndc authentication key. -This must be a valid domain name. -The default is rndc-key. +\-k \fIkeyname\fR +Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is +\fBrndc\-key\fR. .TP -\fB-p \fIport\fB\fR -Specifies the command channel port where \fBnamed\fR -listens for connections from \fBrndc\fR. -The default is 953. +\-p \fIport\fR +Specifies the command channel port where +\fBnamed\fR +listens for connections from +\fBrndc\fR. The default is 953. .TP -\fB-r \fIrandomfile\fB\fR -Specifies a source of random data for generating the -authorization. If the operating -system does not provide a \fI/dev/random\fR -or equivalent device, the default source of randomness -is keyboard input. \fIrandomdev\fR specifies -the name of a character device or file containing random -data to be used instead of the default. The special value -\fIkeyboard\fR indicates that keyboard -input should be used. +\-r \fIrandomfile\fR +Specifies a source of random data for generating the authorization. If the operating system does not provide a +\fI/dev/random\fR +or equivalent device, the default source of randomness is keyboard input. +\fIrandomdev\fR +specifies the name of a character device or file containing random data to be used instead of the default. The special value +\fIkeyboard\fR +indicates that keyboard input should be used. .TP -\fB-s \fIaddress\fB\fR -Specifies the IP address where \fBnamed\fR +\-s \fIaddress\fR +Specifies the IP address where +\fBnamed\fR listens for command channel connections from -\fBrndc\fR. The default is the loopback -address 127.0.0.1. +\fBrndc\fR. The default is the loopback address 127.0.0.1. .TP -\fB-t \fIchrootdir\fB\fR -Used with the \fB-a\fR option to specify -a directory where \fBnamed\fR will run -chrooted. An additional copy of the \fIrndc.key\fR -will be written relative to this directory so that -it will be found by the chrooted \fBnamed\fR. +\-t \fIchrootdir\fR +Used with the +\fB\-a\fR +option to specify a directory where +\fBnamed\fR +will run chrooted. An additional copy of the +\fIrndc.key\fR +will be written relative to this directory so that it will be found by the chrooted +\fBnamed\fR. .TP -\fB-u \fIuser\fB\fR -Used with the \fB-a\fR option to set the owner -of the \fIrndc.key\fR file generated. If -\fB-t\fR is also specified only the file in -the chroot area has its owner changed. +\-u \fIuser\fR +Used with the +\fB\-a\fR +option to set the owner of the +\fIrndc.key\fR +file generated. If +\fB\-t\fR +is also specified only the file in the chroot area has its owner changed. .SH "EXAMPLES" .PP -To allow \fBrndc\fR to be used with -no manual configuration, run +To allow +\fBrndc\fR +to be used with no manual configuration, run .PP -\fBrndc-confgen -a\fR +\fBrndc\-confgen \-a\fR .PP -To print a sample \fIrndc.conf\fR file and -corresponding \fBcontrols\fR and \fBkey\fR -statements to be manually inserted into \fInamed.conf\fR, -run +To print a sample +\fIrndc.conf\fR +file and corresponding +\fBcontrols\fR +and +\fBkey\fR +statements to be manually inserted into +\fInamed.conf\fR, run .PP -\fBrndc-confgen\fR +\fBrndc\-confgen\fR .SH "SEE ALSO" .PP \fBrndc\fR(8), \fBrndc.conf\fR(5), \fBnamed\fR(8), -\fIBIND 9 Administrator Reference Manual\fR. +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc-confgen.docbook b/contrib/bind9/bin/rndc/rndc-confgen.docbook index 272de459c19..e0c5a68cf6f 100644 --- a/contrib/bind9/bin/rndc/rndc-confgen.docbook +++ b/contrib/bind9/bin/rndc/rndc-confgen.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -29,6 +31,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2001 + 2003 + Internet Software Consortium. + + + rndc-confgen rndc key generation tool diff --git a/contrib/bind9/bin/rndc/rndc-confgen.html b/contrib/bind9/bin/rndc/rndc-confgen.html index 7292be2f99d..ca754008419 100644 --- a/contrib/bind9/bin/rndc/rndc-confgen.html +++ b/contrib/bind9/bin/rndc/rndc-confgen.html @@ -1,538 +1,185 @@ - - - - -rndc-confgen

rndc-confgen

Name

rndc-confgen -- rndc key generation tool

Synopsis

rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user]

DESCRIPTION

rndc-confgen generates configuration files - for rndc. It can be used as a + + + + +rndc-confgen + + +

+
+
+

Name

+

rndc-confgen — rndc key generation tool

+
+
+

Synopsis

+

rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user]

+
+
+

DESCRIPTION

+

+ rndc-confgen generates configuration files + for rndc. It can be used as a convenient alternative to writing the - rndc.conf file - and the corresponding controls - and key - statements in named.conf by hand. - Alternatively, it can be run with the -a - option to set up a rndc.key file and - avoid the need for a rndc.conf file - and a controls statement altogether. -

OPTIONS

-a

Do automatic rndc configuration. - This creates a file rndc.key - in /etc (or whatever - sysconfdir - was specified as when BIND was built) - that is read by both rndc - and named on startup. The - rndc.key file defines a default + rndc.conf file + and the corresponding controls + and key + statements in named.conf by hand. + Alternatively, it can be run with the -a + option to set up a rndc.key file and + avoid the need for a rndc.conf file + and a controls statement altogether. +

+
+
+

OPTIONS

+
+
-a
+
+

+ Do automatic rndc configuration. + This creates a file rndc.key + in /etc (or whatever + sysconfdir + was specified as when BIND was built) + that is read by both rndc + and named on startup. The + rndc.key file defines a default command channel and authentication key allowing - rndc to communicate with - named on the local host + rndc to communicate with + named on the local host with no further configuration. -

Running rndc-confgen -a allows - BIND 9 and rndc to be used as drop-in - replacements for BIND 8 and ndc, +

+

+ Running rndc-confgen -a allows + BIND 9 and rndc to be used as drop-in + replacements for BIND 8 and ndc, with no changes to the existing BIND 8 - named.conf file. -

If a more elaborate configuration than that - generated by rndc-confgen -a + named.conf file. +

+

+ If a more elaborate configuration than that + generated by rndc-confgen -a is required, for example if rndc is to be used remotely, - you should run rndc-confgen without the - -a option and set up a - rndc.conf and - named.conf + you should run rndc-confgen without the + -a option and set up a + rndc.conf and + named.conf as directed. -

-b keysize

Specifies the size of the authentication key in bits. +

+
+
-b keysize
+

+ Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128. -

-c keyfile

Used with the -a option to specify - an alternate location for rndc.key. -

-h

Prints a short summary of the options and arguments to - rndc-confgen. -

-k keyname

Specifies the key name of the rndc authentication key. +

+
-c keyfile
+

+ Used with the -a option to specify + an alternate location for rndc.key. +

+
-h
+

+ Prints a short summary of the options and arguments to + rndc-confgen. +

+
-k keyname
+

+ Specifies the key name of the rndc authentication key. This must be a valid domain name. - The default is rndc-key. -

-p port

Specifies the command channel port where named - listens for connections from rndc. + The default is rndc-key. +

+
-p port
+

+ Specifies the command channel port where named + listens for connections from rndc. The default is 953. -

-r randomfile

Specifies a source of random data for generating the +

+
-r randomfile
+

+ Specifies a source of random data for generating the authorization. If the operating - system does not provide a /dev/random + system does not provide a /dev/random or equivalent device, the default source of randomness - is keyboard input. randomdev specifies + is keyboard input. randomdev specifies the name of a character device or file containing random data to be used instead of the default. The special value - keyboard indicates that keyboard + keyboard indicates that keyboard input should be used. -

-s address

Specifies the IP address where named +

+
-s address
+

+ Specifies the IP address where named listens for command channel connections from - rndc. The default is the loopback + rndc. The default is the loopback address 127.0.0.1. -

-t chrootdir

Used with the -a option to specify - a directory where named will run - chrooted. An additional copy of the rndc.key +

+
-t chrootdir
+

+ Used with the -a option to specify + a directory where named will run + chrooted. An additional copy of the rndc.key will be written relative to this directory so that - it will be found by the chrooted named. -

-u user

Used with the -a option to set the owner - of the rndc.key file generated. If - -t is also specified only the file in + it will be found by the chrooted named. +

+
-u user
+

+ Used with the -a option to set the owner + of the rndc.key file generated. If + -t is also specified only the file in the chroot area has its owner changed. -

EXAMPLES

To allow rndc to be used with +

+
+
+
+

EXAMPLES

+

+ To allow rndc to be used with no manual configuration, run -

rndc-confgen -a -

To print a sample rndc.conf file and - corresponding controls and key - statements to be manually inserted into named.conf, +

+

+ rndc-confgen -a +

+

+ To print a sample rndc.conf file and + corresponding controls and key + statements to be manually inserted into named.conf, run -

rndc-confgen -

SEE ALSO

rndc(8), - rndc.conf(5), - named(8), - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+

+

+ rndc-confgen +

+
+
+

SEE ALSO

+

+ rndc(8), + rndc.conf(5), + named(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/bin/rndc/rndc.8 b/contrib/bind9/bin/rndc/rndc.8 index 356883bc414..fba5529e405 100644 --- a/contrib/bind9/bin/rndc/rndc.8 +++ b/contrib/bind9/bin/rndc/rndc.8 @@ -1,118 +1,118 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: rndc.8,v 1.24.206.2 2004/06/03 05:35:49 marka Exp $ +.\" $Id: rndc.8,v 1.24.206.5 2005/10/13 02:33:49 marka Exp $ .\" -.TH "RNDC" "8" "June 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "RNDC" "8" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" rndc \- name server control utility -.SH SYNOPSIS -.sp -\fBrndc\fR [ \fB-c \fIconfig-file\fB\fR ] [ \fB-k \fIkey-file\fB\fR ] [ \fB-s \fIserver\fB\fR ] [ \fB-p \fIport\fB\fR ] [ \fB-V\fR ] [ \fB-y \fIkey_id\fB\fR ] \fBcommand\fR +.SH "SYNOPSIS" +.HP 5 +\fBrndc\fR [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-k\ \fR\fB\fIkey\-file\fR\fR] [\fB\-s\ \fR\fB\fIserver\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-V\fR] [\fB\-y\ \fR\fB\fIkey_id\fR\fR] {command} .SH "DESCRIPTION" .PP -\fBrndc\fR controls the operation of a name -server. It supersedes the \fBndc\fR utility -that was provided in old BIND releases. If -\fBrndc\fR is invoked with no command line -options or arguments, it prints a short summary of the -supported commands and the available options and their -arguments. +\fBrndc\fR +controls the operation of a name server. It supersedes the +\fBndc\fR +utility that was provided in old BIND releases. If +\fBrndc\fR +is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments. .PP -\fBrndc\fR communicates with the name server -over a TCP connection, sending commands authenticated with -digital signatures. In the current versions of -\fBrndc\fR and \fBnamed\fR named -the only supported authentication algorithm is HMAC-MD5, -which uses a shared secret on each end of the connection. -This provides TSIG-style authentication for the command -request and the name server's response. All commands sent -over the channel must be signed by a key_id known to the -server. +\fBrndc\fR +communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of +\fBrndc\fR +and +\fBnamed\fR +named the only supported authentication algorithm is HMAC\-MD5, which uses a shared secret on each end of the connection. This provides TSIG\-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server. .PP -\fBrndc\fR reads a configuration file to -determine how to contact the name server and decide what -algorithm and key it should use. +\fBrndc\fR +reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use. .SH "OPTIONS" .TP -\fB-c \fIconfig-file\fB\fR -Use \fIconfig-file\fR +\-c \fIconfig\-file\fR +Use +\fIconfig\-file\fR as the configuration file instead of the default, \fI/etc/rndc.conf\fR. .TP -\fB-k \fIkey-file\fB\fR -Use \fIkey-file\fR +\-k \fIkey\-file\fR +Use +\fIkey\-file\fR as the key file instead of the default, \fI/etc/rndc.key\fR. The key in -\fI/etc/rndc.key\fR will be used to authenticate -commands sent to the server if the \fIconfig-file\fR +\fI/etc/rndc.key\fR +will be used to authenticate commands sent to the server if the +\fIconfig\-file\fR does not exist. .TP -\fB-s \fIserver\fB\fR -\fIserver\fR is -the name or address of the server which matches a -server statement in the configuration file for -\fBrndc\fR. If no server is supplied on the -command line, the host named by the default-server clause -in the option statement of the configuration file will be -used. +\-s \fIserver\fR +\fIserver\fR +is the name or address of the server which matches a server statement in the configuration file for +\fBrndc\fR. If no server is supplied on the command line, the host named by the default\-server clause in the option statement of the configuration file will be used. .TP -\fB-p \fIport\fB\fR +\-p \fIport\fR Send commands to TCP port -\fIport\fR instead -of BIND 9's default control channel port, 953. +\fIport\fR +instead of BIND 9's default control channel port, 953. .TP -\fB-V\fR +\-V Enable verbose logging. .TP -\fB-y \fIkeyid\fB\fR -Use the key \fIkeyid\fR +\-y \fIkeyid\fR +Use the key +\fIkeyid\fR from the configuration file. -\fIkeyid\fR must be -known by named with the same algorithm and secret string -in order for control message validation to succeed. -If no \fIkeyid\fR -is specified, \fBrndc\fR will first look -for a key clause in the server statement of the server -being used, or if no server statement is present for that -host, then the default-key clause of the options statement. -Note that the configuration file contains shared secrets -which are used to send authenticated control commands -to name servers. It should therefore not have general read -or write access. -.PP -For the complete set of commands supported by \fBrndc\fR, -see the BIND 9 Administrator Reference Manual or run -\fBrndc\fR without arguments to see its help message. +\fIkeyid\fR +must be known by named with the same algorithm and secret string in order for control message validation to succeed. If no +\fIkeyid\fR +is specified, +\fBrndc\fR +will first look for a key clause in the server statement of the server being used, or if no server statement is present for that host, then the default\-key clause of the options statement. Note that the configuration file contains shared secrets which are used to send authenticated control commands to name servers. It should therefore not have general read or write access. .PP +For the complete set of commands supported by +\fBrndc\fR, see the BIND 9 Administrator Reference Manual or run +\fBrndc\fR +without arguments to see its help message. .SH "LIMITATIONS" .PP -\fBrndc\fR does not yet support all the commands of -the BIND 8 \fBndc\fR utility. +\fBrndc\fR +does not yet support all the commands of the BIND 8 +\fBndc\fR +utility. .PP There is currently no way to provide the shared secret for a -\fBkey_id\fR without using the configuration file. +\fBkey_id\fR +without using the configuration file. .PP Several error messages could be clearer. .SH "SEE ALSO" .PP \fBrndc.conf\fR(5), \fBnamed\fR(8), -\fBnamed.conf\fR(5) -\fBndc\fR(8), -\fIBIND 9 Administrator Reference Manual\fR. +\fBnamed.conf\fR(5)\fBndc\fR(8), +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc.c b/contrib/bind9/bin/rndc/rndc.c index c74828ce7c8..63e8f23b9ff 100644 --- a/contrib/bind9/bin/rndc/rndc.c +++ b/contrib/bind9/bin/rndc/rndc.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rndc.c,v 1.77.2.5.2.13 2004/09/03 03:43:32 marka Exp $ */ +/* $Id: rndc.c,v 1.77.2.5.2.15 2005/03/17 03:58:27 marka Exp $ */ /* * Principal Author: DCL @@ -104,7 +104,8 @@ command is one of the following:\n\ reconfig Reload configuration file and new zones only.\n\ stats Write server statistics to the statistics file.\n\ querylog Toggle query logging.\n\ - dumpdb Dump cache(s) to the dump file (named_dump.db).\n\ + dumpdb [-all|-cache|-zones] [view ...]\n\ + Dump cache(s) to the dump file (named_dump.db).\n\ stop Save pending updates to master files and stop the server.\n\ stop -p Save pending updates to master files and stop the server\n\ reporting process id.\n\ diff --git a/contrib/bind9/bin/rndc/rndc.conf.5 b/contrib/bind9/bin/rndc/rndc.conf.5 index 5b61cfb00c1..1c21e363d61 100644 --- a/contrib/bind9/bin/rndc/rndc.conf.5 +++ b/contrib/bind9/bin/rndc/rndc.conf.5 @@ -1,35 +1,42 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: rndc.conf.5,v 1.21.206.2 2004/06/03 05:35:50 marka Exp $ +.\" $Id: rndc.conf.5,v 1.21.206.5 2005/10/13 02:33:50 marka Exp $ .\" -.TH "RNDC.CONF" "5" "June 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "\\FIRNDC.CONF\\FR" "5" "June 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" rndc.conf \- rndc configuration file -.SH SYNOPSIS -.sp +.SH "SYNOPSIS" +.HP 10 \fBrndc.conf\fR .SH "DESCRIPTION" .PP -\fIrndc.conf\fR is the configuration file -for \fBrndc\fR, the BIND 9 name server control -utility. This file has a similar structure and syntax to -\fInamed.conf\fR. Statements are enclosed -in braces and terminated with a semi-colon. Clauses in -the statements are also semi-colon terminated. The usual -comment styles are supported: +\fIrndc.conf\fR +is the configuration file for +\fBrndc\fR, the BIND 9 name server control utility. This file has a similar structure and syntax to +\fInamed.conf\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported: .PP C style: /* */ .PP @@ -37,106 +44,111 @@ C++ style: // to end of line .PP Unix style: # to end of line .PP -\fIrndc.conf\fR is much simpler than -\fInamed.conf\fR. The file uses three -statements: an options statement, a server statement -and a key statement. +\fIrndc.conf\fR +is much simpler than +\fInamed.conf\fR. The file uses three statements: an options statement, a server statement and a key statement. .PP -The \fBoptions\fR statement contains three clauses. -The \fBdefault-server\fR clause is followed by the -name or address of a name server. This host will be used when -no name server is given as an argument to -\fBrndc\fR. The \fBdefault-key\fR -clause is followed by the name of a key which is identified by -a \fBkey\fR statement. If no -\fBkeyid\fR is provided on the rndc command line, -and no \fBkey\fR clause is found in a matching -\fBserver\fR statement, this default key will be -used to authenticate the server's commands and responses. The -\fBdefault-port\fR clause is followed by the port -to connect to on the remote name server. If no -\fBport\fR option is provided on the rndc command -line, and no \fBport\fR clause is found in a -matching \fBserver\fR statement, this default port -will be used to connect. +The +\fBoptions\fR +statement contains three clauses. The +\fBdefault\-server\fR +clause is followed by the name or address of a name server. This host will be used when no name server is given as an argument to +\fBrndc\fR. The +\fBdefault\-key\fR +clause is followed by the name of a key which is identified by a +\fBkey\fR +statement. If no +\fBkeyid\fR +is provided on the rndc command line, and no +\fBkey\fR +clause is found in a matching +\fBserver\fR +statement, this default key will be used to authenticate the server's commands and responses. The +\fBdefault\-port\fR +clause is followed by the port to connect to on the remote name server. If no +\fBport\fR +option is provided on the rndc command line, and no +\fBport\fR +clause is found in a matching +\fBserver\fR +statement, this default port will be used to connect. .PP -After the \fBserver\fR keyword, the server statement -includes a string which is the hostname or address for a name -server. The statement has two possible clauses: -\fBkey\fR and \fBport\fR. The key name must -match the name of a key statement in the file. The port number -specifies the port to connect to. +After the +\fBserver\fR +keyword, the server statement includes a string which is the hostname or address for a name server. The statement has two possible clauses: +\fBkey\fR +and +\fBport\fR. The key name must match the name of a key statement in the file. The port number specifies the port to connect to. .PP -The \fBkey\fR statement begins with an identifying -string, the name of the key. The statement has two clauses. -\fBalgorithm\fR identifies the encryption algorithm -for \fBrndc\fR to use; currently only HMAC-MD5 is -supported. This is followed by a secret clause which contains -the base-64 encoding of the algorithm's encryption key. The -base-64 string is enclosed in double quotes. +The +\fBkey\fR +statement begins with an identifying string, the name of the key. The statement has two clauses. +\fBalgorithm\fR +identifies the encryption algorithm for +\fBrndc\fR +to use; currently only HMAC\-MD5 is supported. This is followed by a secret clause which contains the base\-64 encoding of the algorithm's encryption key. The base\-64 string is enclosed in double quotes. .PP -There are two common ways to generate the base-64 string for the -secret. The BIND 9 program \fBrndc-confgen\fR can -be used to generate a random key, or the -\fBmmencode\fR program, also known as -\fBmimencode\fR, can be used to generate a base-64 -string from known input. \fBmmencode\fR does not -ship with BIND 9 but is available on many systems. See the -EXAMPLE section for sample command lines for each. +There are two common ways to generate the base\-64 string for the secret. The BIND 9 program +\fBrndc\-confgen\fR +can be used to generate a random key, or the +\fBmmencode\fR +program, also known as +\fBmimencode\fR, can be used to generate a base\-64 string from known input. +\fBmmencode\fR +does not ship with BIND 9 but is available on many systems. See the EXAMPLE section for sample command lines for each. .SH "EXAMPLE" .sp .nf options { - default-server localhost; - default-key samplekey; + default\-server localhost; + default\-key samplekey; }; - server localhost { key samplekey; }; - key samplekey { - algorithm hmac-md5; + algorithm hmac\-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; - -.sp .fi .PP -In the above example, \fBrndc\fR will by default use -the server at localhost (127.0.0.1) and the key called samplekey. -Commands to the localhost server will use the samplekey key, which -must also be defined in the server's configuration file with the -same name and secret. The key statement indicates that samplekey -uses the HMAC-MD5 algorithm and its secret clause contains the -base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. +In the above example, +\fBrndc\fR +will by default use the server at localhost (127.0.0.1) and the key called samplekey. Commands to the localhost server will use the samplekey key, which must also be defined in the server's configuration file with the same name and secret. The key statement indicates that samplekey uses the HMAC\-MD5 algorithm and its secret clause contains the base\-64 encoding of the HMAC\-MD5 secret enclosed in double quotes. .PP -To generate a random secret with \fBrndc-confgen\fR: +To generate a random secret with +\fBrndc\-confgen\fR: .PP -\fBrndc-confgen\fR +\fBrndc\-confgen\fR .PP -A complete \fIrndc.conf\fR file, including the -randomly generated key, will be written to the standard -output. Commented out \fBkey\fR and -\fBcontrols\fR statements for -\fInamed.conf\fR are also printed. +A complete +\fIrndc.conf\fR +file, including the randomly generated key, will be written to the standard output. Commented out +\fBkey\fR +and +\fBcontrols\fR +statements for +\fInamed.conf\fR +are also printed. .PP -To generate a base-64 secret with \fBmmencode\fR: +To generate a base\-64 secret with +\fBmmencode\fR: .PP \fBecho "known plaintext for a secret" | mmencode\fR .SH "NAME SERVER CONFIGURATION" .PP -The name server must be configured to accept rndc connections and -to recognize the key specified in the \fIrndc.conf\fR -file, using the controls statement in \fInamed.conf\fR. -See the sections on the \fBcontrols\fR statement in the -BIND 9 Administrator Reference Manual for details. +The name server must be configured to accept rndc connections and to recognize the key specified in the +\fIrndc.conf\fR +file, using the controls statement in +\fInamed.conf\fR. See the sections on the +\fBcontrols\fR +statement in the BIND 9 Administrator Reference Manual for details. .SH "SEE ALSO" .PP \fBrndc\fR(8), -\fBrndc-confgen\fR(8), +\fBrndc\-confgen\fR(8), \fBmmencode\fR(1), -\fIBIND 9 Administrator Reference Manual\fR. +BIND 9 Administrator Reference Manual. .SH "AUTHOR" .PP Internet Systems Consortium diff --git a/contrib/bind9/bin/rndc/rndc.conf.docbook b/contrib/bind9/bin/rndc/rndc.conf.docbook index 95f158b7602..16b9caf43cb 100644 --- a/contrib/bind9/bin/rndc/rndc.conf.docbook +++ b/contrib/bind9/bin/rndc/rndc.conf.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + rndc.conf rndc configuration file diff --git a/contrib/bind9/bin/rndc/rndc.conf.html b/contrib/bind9/bin/rndc/rndc.conf.html index ea087c8be60..05db0eca644 100644 --- a/contrib/bind9/bin/rndc/rndc.conf.html +++ b/contrib/bind9/bin/rndc/rndc.conf.html @@ -1,238 +1,113 @@ - - - - -rndc.conf

rndc.conf

Name

rndc.conf -- rndc configuration file

Synopsis

rndc.conf

DESCRIPTION

rndc.conf is the configuration file - for rndc, the BIND 9 name server control + + + + +rndc.conf + + +

+
+
+

Name

+

rndc.conf — rndc configuration file

+
+
+

Synopsis

+

rndc.conf

+
+
+

DESCRIPTION

+

+ rndc.conf is the configuration file + for rndc, the BIND 9 name server control utility. This file has a similar structure and syntax to - named.conf. Statements are enclosed + named.conf. Statements are enclosed in braces and terminated with a semi-colon. Clauses in the statements are also semi-colon terminated. The usual comment styles are supported: -

C style: /* */ -

C++ style: // to end of line -

Unix style: # to end of line -

rndc.conf is much simpler than - named.conf. The file uses three +

+

+ C style: /* */ +

+

+ C++ style: // to end of line +

+

+ Unix style: # to end of line +

+

+ rndc.conf is much simpler than + named.conf. The file uses three statements: an options statement, a server statement and a key statement. -

The options statement contains three clauses. - The default-server clause is followed by the +

+

+ The options statement contains three clauses. + The default-server clause is followed by the name or address of a name server. This host will be used when no name server is given as an argument to - rndc. The default-key + rndc. The default-key clause is followed by the name of a key which is identified by - a key statement. If no - keyid is provided on the rndc command line, - and no key clause is found in a matching - server statement, this default key will be + a key statement. If no + keyid is provided on the rndc command line, + and no key clause is found in a matching + server statement, this default key will be used to authenticate the server's commands and responses. The - default-port clause is followed by the port + default-port clause is followed by the port to connect to on the remote name server. If no - port option is provided on the rndc command - line, and no port clause is found in a - matching server statement, this default port + port option is provided on the rndc command + line, and no port clause is found in a + matching server statement, this default port will be used to connect. -

After the server keyword, the server statement +

+

+ After the server keyword, the server statement includes a string which is the hostname or address for a name server. The statement has two possible clauses: - key and port. The key name must + key and port. The key name must match the name of a key statement in the file. The port number specifies the port to connect to. -

The key statement begins with an identifying +

+

+ The key statement begins with an identifying string, the name of the key. The statement has two clauses. - algorithm identifies the encryption algorithm - for rndc to use; currently only HMAC-MD5 is + algorithm identifies the encryption algorithm + for rndc to use; currently only HMAC-MD5 is supported. This is followed by a secret clause which contains the base-64 encoding of the algorithm's encryption key. The base-64 string is enclosed in double quotes. -

There are two common ways to generate the base-64 string for the - secret. The BIND 9 program rndc-confgen can +

+

+ There are two common ways to generate the base-64 string for the + secret. The BIND 9 program rndc-confgen can be used to generate a random key, or the - mmencode program, also known as - mimencode, can be used to generate a base-64 - string from known input. mmencode does not + mmencode program, also known as + mimencode, can be used to generate a base-64 + string from known input. mmencode does not ship with BIND 9 but is available on many systems. See the EXAMPLE section for sample command lines for each. -

EXAMPLE

    options {
+    

+
+
+

EXAMPLE

+
+    options {
         default-server  localhost;
         default-key     samplekey;
       };
@@ -245,133 +120,60 @@ CLASS="PROGRAMLISTING"
         algorithm       hmac-md5;
         secret          "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
       };
-

In the above example, rndc will by default use + +

+ In the above example, rndc will by default use the server at localhost (127.0.0.1) and the key called samplekey. Commands to the localhost server will use the samplekey key, which must also be defined in the server's configuration file with the same name and secret. The key statement indicates that samplekey uses the HMAC-MD5 algorithm and its secret clause contains the base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. -

To generate a random secret with rndc-confgen: -

rndc-confgen -

A complete rndc.conf file, including the +

+

+ To generate a random secret with rndc-confgen: +

+

+ rndc-confgen +

+

+ A complete rndc.conf file, including the randomly generated key, will be written to the standard - output. Commented out key and - controls statements for - named.conf are also printed. -

To generate a base-64 secret with mmencode: -

echo "known plaintext for a secret" | mmencode -

NAME SERVER CONFIGURATION

The name server must be configured to accept rndc connections and - to recognize the key specified in the rndc.conf - file, using the controls statement in named.conf. - See the sections on the controls statement in the + output. Commented out key and + controls statements for + named.conf are also printed. +

+

+ To generate a base-64 secret with mmencode: +

+

+ echo "known plaintext for a secret" | mmencode +

+
+
+

NAME SERVER CONFIGURATION

+

+ The name server must be configured to accept rndc connections and + to recognize the key specified in the rndc.conf + file, using the controls statement in named.conf. + See the sections on the controls statement in the BIND 9 Administrator Reference Manual for details. -

SEE ALSO

rndc(8), - rndc-confgen(8), - mmencode(1), - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+

+
+
+

SEE ALSO

+

+ rndc(8), + rndc-confgen(8), + mmencode(1), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/bin/rndc/rndc.docbook b/contrib/bind9/bin/rndc/rndc.docbook index d4529ccfa6e..afb88f5f6ea 100644 --- a/contrib/bind9/bin/rndc/rndc.docbook +++ b/contrib/bind9/bin/rndc/rndc.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + rndc name server control utility diff --git a/contrib/bind9/bin/rndc/rndc.html b/contrib/bind9/bin/rndc/rndc.html index 56f1aa1dba1..d23f4682c01 100644 --- a/contrib/bind9/bin/rndc/rndc.html +++ b/contrib/bind9/bin/rndc/rndc.html @@ -1,284 +1,112 @@ - - - - -rndc

rndc

Name

rndc -- name server control utility

Synopsis

rndc [-c config-file] [-k key-file] [-s server] [-p port] [-V] [-y key_id] {command}

DESCRIPTION

rndc controls the operation of a name - server. It supersedes the ndc utility + + + + +rndc + + +

+
+
+

Name

+

rndc — name server control utility

+
+
+

Synopsis

+

rndc [-c config-file] [-k key-file] [-s server] [-p port] [-V] [-y key_id] {command}

+
+
+

DESCRIPTION

+

+ rndc controls the operation of a name + server. It supersedes the ndc utility that was provided in old BIND releases. If - rndc is invoked with no command line + rndc is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments. -

rndc communicates with the name server +

+

+ rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of - rndc and named named + rndc and named named the only supported authentication algorithm is HMAC-MD5, which uses a shared secret on each end of the connection. This provides TSIG-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server. -

rndc reads a configuration file to +

+

+ rndc reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use. -

OPTIONS

-c config-file

Use config-file +

+
+
+

OPTIONS

+
+
-c config-file
+

+ Use config-file as the configuration file instead of the default, - /etc/rndc.conf. -

-k key-file

Use key-file + /etc/rndc.conf. +

+
-k key-file
+

+ Use key-file as the key file instead of the default, - /etc/rndc.key. The key in - /etc/rndc.key will be used to authenticate - commands sent to the server if the config-file + /etc/rndc.key. The key in + /etc/rndc.key will be used to authenticate + commands sent to the server if the config-file does not exist. -

-s server

server is +

+
-s server
+

+ server is the name or address of the server which matches a server statement in the configuration file for - rndc. If no server is supplied on the + rndc. If no server is supplied on the command line, the host named by the default-server clause in the option statement of the configuration file will be used. -

-p port

Send commands to TCP port - port instead +

+
-p port
+

+ Send commands to TCP port + port instead of BIND 9's default control channel port, 953. -

-V

Enable verbose logging. -

-y keyid

Use the key keyid +

+
-V
+

+ Enable verbose logging. +

+
-y keyid
+

+ Use the key keyid from the configuration file. - keyid must be + keyid must be known by named with the same algorithm and secret string in order for control message validation to succeed. - If no keyid - is specified, rndc will first look + If no keyid + is specified, rndc will first look for a key clause in the server statement of the server being used, or if no server statement is present for that host, then the default-key clause of the options statement. @@ -286,103 +114,43 @@ CLASS="COMMAND" which are used to send authenticated control commands to name servers. It should therefore not have general read or write access. -

For the complete set of commands supported by rndc, +

+
+

+ For the complete set of commands supported by rndc, see the BIND 9 Administrator Reference Manual or run - rndc without arguments to see its help message. -

LIMITATIONS

rndc does not yet support all the commands of - the BIND 8 ndc utility. -

There is currently no way to provide the shared secret for a - key_id without using the configuration file. -

Several error messages could be clearer. -

SEE ALSO

rndc.conf(5), - named(8), - named.conf(5) - ndc(8), - BIND 9 Administrator Reference Manual. -

AUTHOR

Internet Systems Consortium -

+ rndc without arguments to see its help message. +

+
+
+

LIMITATIONS

+

+ rndc does not yet support all the commands of + the BIND 8 ndc utility. +

+

+ There is currently no way to provide the shared secret for a + key_id without using the configuration file. +

+

+ Several error messages could be clearer. +

+
+
+

SEE ALSO

+

+ rndc.conf(5), + named(8), + named.conf(5) + ndc(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

+ Internet Systems Consortium +

+
+
+ diff --git a/contrib/bind9/config.threads.in b/contrib/bind9/config.threads.in new file mode 100644 index 00000000000..f2816c447fb --- /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/configure.in b/contrib/bind9/configure.in index 9aff151668c..b14b489bb2b 100644 --- a/contrib/bind9/configure.in +++ b/contrib/bind9/configure.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.294.2.23.2.39 $) +AC_REVISION($Revision: 1.294.2.23.2.51 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -261,6 +261,7 @@ AC_TRY_COMPILE(, [ AC_TYPE_SIZE_T AC_CHECK_TYPE(ssize_t, int) +AC_CHECK_TYPE(uintptr_t,unsigned long) AC_CHECK_TYPE(socklen_t, [AC_DEFINE(ISC_SOCKADDR_LEN_T, socklen_t)], [ @@ -608,158 +609,7 @@ esac # AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM)) -# -# 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 +sinclude(config.threads.in)dnl if $use_threads then @@ -790,7 +640,11 @@ then *-freebsd*) AC_CHECK_LIB(c_r, sigwait, AC_DEFINE(HAVE_SIGWAIT),) case $host in - *-freebsd5.3|*-freebsd5.3.*) + *-freebsd5.[[012]]|*-freebsd5.[[012]].*);; + *-freebsd5.[[3456789]]|*-freebsd5.[[3456789]].*) + AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM) + ;; + *-freebsd6.*) AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM) ;; esac @@ -884,7 +738,6 @@ fi AC_SUBST(ALWAYS_DEFINES) AC_SUBST(ISC_PLATFORM_USETHREADS) - ISC_THREAD_DIR=$thread_dir AC_SUBST(ISC_THREAD_DIR) @@ -939,7 +792,7 @@ if test "X$GCC" = "Xyes"; then STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat" case "$host" in *-hp-hpux*) - LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS" + LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS" ;; esac else @@ -961,11 +814,11 @@ else ;; *) # Turn off the pointlessly noisy warnings. - STD_CWARNINGS="+w1 +W 474,530" + STD_CWARNINGS="+w1 +W 474,530,2193,2236" ;; esac CCOPT="$CCOPT -Ae -z" - LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS" + LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS" MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>>$TMP' ;; *-sgi-irix*) @@ -1414,6 +1267,10 @@ char a[16],b[64]; return(inet_ntop(AF_INET6, a, b, sizeof(b)) == (char*)0);}], [AC_MSG_RESULT(no) ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O" ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c" + ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"], + [AC_MSG_RESULT(assuming inet_ntop needed) + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O" + ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c" ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"]) @@ -1437,7 +1294,13 @@ main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 : ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c" ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"], [AC_MSG_RESULT(assuming target platform has working inet_pton) - ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"]) + ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"], + [AC_MSG_RESULT(assuming inet_pton needed) + ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_pton.$O" + ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c" + ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"], + [AC_MSG_RESULT(assuming target platform has working inet_pton) + ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"]) AC_MSG_CHECKING([for inet_aton]) AC_TRY_LINK([ @@ -1703,9 +1566,15 @@ AC_CHECK_FUNC(memmove, AC_SUBST(ISC_PLATFORM_NEEDMEMMOVE) AC_CHECK_FUNC(strtoul, - [ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"], - [ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"]) + [ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL" + LWRES_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL" + GENRANDOMLIB=""], + [ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1" + LWRES_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1" + "GENRANDOMLIB=${ISCLIBS}"]) AC_SUBST(ISC_PLATFORM_NEEDSTRTOUL) +AC_SUBST(LWRES_PLATFORM_NEEDSTRTOUL) +AC_SUBST(GENRANDOMLIB) AC_CHECK_FUNC(strlcpy, [ISC_PLATFORM_NEEDSTRLCPY="#undef ISC_PLATFORM_NEEDSTRLCPY"], @@ -1760,6 +1629,9 @@ AC_SUBST(ISC_EXTRA_SRCS) # will produce a inconsistant result in the later case. If the compiler # fails due to seeing "%lld" we fall back to "l". # +# Digital Unix 4.0 (gcc?) (long long) is 64 bits as is its long. It uses +# %ld even for (long long)/ +# # Win32 uses "%I64d", but that's defined elsewhere since we don't use # configure on Win32. # @@ -1776,12 +1648,16 @@ main() { } ], [AC_MSG_RESULT(ll) - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'], + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' + LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"'], [AC_MSG_RESULT(l) - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'], + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"' + LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "l"'], [AC_MSG_RESULT(assuming target platform uses ll) - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"']) + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' + LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"']) AC_SUBST(ISC_PLATFORM_QUADFORMAT) +AC_SUBST(LWRES_PLATFORM_QUADFORMAT) # # Security Stuff @@ -1803,6 +1679,15 @@ AC_CHECK_HEADERS(sys/prctl.h) # AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET)) +AC_MSG_CHECKING(for optarg decarartion) +AC_TRY_COMPILE([ +#include +], +[optarg = 0;], +[AC_MSG_RESULT(yes)], +[AC_MSG_RESULT(no) +AC_DEFINE(NEED_OPTARG, 1, [Defined if extern char *optarg is not declared.])]) + # # BSD/OS, and perhaps some others, don't define rlim_t. # @@ -1843,7 +1728,9 @@ ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"], [AC_MSG_ERROR([unable to determine sizeof rlim_cur]) ],[AC_MSG_ERROR(this cannot happen)]) ],[AC_MSG_ERROR(this cannot happen)]) -],[AC_MSG_ERROR(cannot determine type of rlim_cur when cross compiling - define rlim_t)]) +],[ +ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int" +AC_MSG_RESULT(cannot determine type of rlim_cur when cross compiling - assuming long long int)]) ]) AC_SUBST(ISC_PLATFORM_RLIMITTYPE) @@ -1957,31 +1844,51 @@ yes) esac AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX) +# +# The following sets up how non-blocking i/o is established. +# Sunos, cygwin and solaris 2.x (x<5) require special handling. +# +case "$host" in +*-sunos*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);; +*-cygwin*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);; +*-solaris2.[[01234]]) + AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK) + AC_DEFINE(USE_FIONBIO_IOCTL, 1, + [Defined if you need to use ioctl(FIONBIO) instead a fcntl call to make non-blocking.]) + ;; +*) AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK, + [Sets which flag to pass to open/fcntl to make non-blocking (O_NDELAY/O_NONBLOCK).]) + ;; +esac # # The following sections deal with tools used for formatting # the documentation. They are all optional, unless you are # a developer editing the documentation source. # -# Directory trees where SGML files are commonly found. -sgmltrees="/usr/pkg/share/sgml /usr/local/share/sgml /usr/share/sgml" - -# -# Look for openjade. Plain jade is no longer supported. -# - -AC_PATH_PROGS(OPENJADE, openjade, openjade) -AC_SUBST(OPENJADE) - # # Look for TeX. # -AC_PATH_PROGS(JADETEX, jadetex, jadetex) -AC_SUBST(JADETEX) +AC_PATH_PROGS(LATEX, latex, latex) +AC_SUBST(LATEX) -AC_PATH_PROGS(PDFJADETEX, pdfjadetex, pdfjadetex) -AC_SUBST(PDFJADETEX) +AC_PATH_PROGS(PDFLATEX, pdflatex, pdflatex) +AC_SUBST(PDFLATEX) + +# +# Look for xsltproc (libxslt) +# + +AC_PATH_PROG(XSLTPROC, xsltproc, xsltproc) +AC_SUBST(XSLTPROC) + +# +# Look for xmllint (libxml2) +# + +AC_PATH_PROG(XMLLINT, xmllint, xmllint) +AC_SUBST(XMLLINT) # # Subroutine for searching for an ordinary file (e.g., a stylesheet) @@ -2018,74 +1925,60 @@ AC_SUBST($1) ]) # -# Look for the SGML catalog. -# Its location varies, so far we have seen: +# Look for Docbook-XSL stylesheets. Location probably varies by +# system. Guessing where it might be found, based on where SGML stuff +# lives on some systems. FreeBSD is the only one I'm sure of at the +# moment. # -# NetBSD /usr/pkg/share/sgml/docbook/catalog -# FreeBSD /usr/local/share/sgml/docbook/catalog -# Linux /usr/local/share/dsssl/docbook/catalog -# /usr/share/sgml/docbook/dsssl-stylesheets/catalog + +docbook_xsl_trees="/usr/pkg/share/xsl /usr/local/share/xsl /usr/share/xsl" + # -catalogpath="" -for d in $sgmltrees +# Look for stylesheets we need. +# + +NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_HTML, docbook/html/docbook.xsl, $docbook_xsl_trees) +NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_XHTML, docbook/xhtml/docbook.xsl, $docbook_xsl_trees) +NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_MAN, docbook/manpages/docbook.xsl, $docbook_xsl_trees) +NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_HTML, docbook/html/chunk.xsl, $docbook_xsl_trees) +NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_XHTML, docbook/xhtml/chunk.xsl, $docbook_xsl_trees) + +# +# Same dance for db2latex +# +# No idea where this lives except on FreeBSD. +# + +db2latex_xsl_trees="/usr/local/share" + +# +# Look for stylesheets we need. +# + +NOM_PATH_FILE(XSLT_DB2LATEX_STYLE, db2latex/xsl/docbook.xsl, $db2latex_xsl_trees) + +# +# Look for "admonition" image directory. Can't use NOM_PATH_FILE() +# because it's a directory, so just do the same things, inline. +# + +AC_MSG_CHECKING(for db2latex/xsl/figures) +for d in $db2latex_xsl_trees do - catalogpath="$catalogpath $d" - for s in docbook/dsssl-stylesheets - do - catalogpath="$catalogpath $d/$s" - done + dd=$d/db2latex/xsl/figures + if test -d $dd + then + XSLT_DB2LATEX_ADMONITIONS=$dd + AC_MSG_RESULT($dd) + break + fi done -NOM_PATH_FILE(SGMLCATALOG, catalog, $catalogpath) - -# -# Look for the HTML stylesheet html/docbook.dsl, used for -# formatting man pages in HTML. Its location varies, -# so far we have seen: -# -# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/ -# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/ -# Linux /usr/local/share/dsssl/docbook/ -# /usr/share/sgml/docbook/dsssl-stylesheets/ -# -# Ditto for the print stylesheet print/docbook.dsl. -# - -stylepath="" -for d in $sgmltrees -do - for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets - do - stylepath="$stylepath $d/$s" - done -done -NOM_PATH_FILE(HTMLSTYLE, html/docbook.dsl, $stylepath) -NOM_PATH_FILE(PRINTSTYLE, print/docbook.dsl, $stylepath) - -# -# Look for XML declarations. -# Its location varies, so far we have seen: -# -# NetBSD /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/ -# FreeBSD /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/ -# Linux /usr/local/share/dsssl/docbook/dtds/decls/ -# /usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/ -# - -xmlpath="" -for d in $sgmltrees -do - for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets - do - xmlpath="$xmlpath $d/$s" - done -done -NOM_PATH_FILE(XMLDCL, dtds/decls/xml.dcl, $xmlpath) - -# -# Look for docbook2man-spec.pl -# - -NOM_PATH_FILE(DOCBOOK2MANSPEC, docbook2X/docbook2man-spec.pl, $sgmltrees) +if test "X$XSLT_DB2LATEX_ADMONITIONS" = "X" +then + AC_MSG_RESULT(not found) + XSLT_DB2LATEX_ADMONITIONS=db2latex/xsl/figures +fi +AC_SUBST(XSLT_DB2LATEX_ADMONITIONS) # # Substitutions @@ -2213,12 +2106,13 @@ AC_OUTPUT( bin/dnssec/Makefile doc/Makefile doc/arm/Makefile - doc/arm/nominum-docbook-html.dsl - doc/arm/nominum-docbook-print.dsl - doc/arm/validate.sh doc/misc/Makefile - docutil/docbook2man-wrapper.sh + doc/xsl/Makefile isc-config.sh + doc/xsl/isc-docbook-chunk.xsl + doc/xsl/isc-docbook-html.xsl + doc/xsl/isc-docbook-latex.xsl + doc/xsl/isc-manpage.xsl ) chmod a+x isc-config.sh diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in index e7dd9ca35ef..1e69dabdbab 100644 --- a/contrib/bind9/doc/Makefile.in +++ b/contrib/bind9/doc/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2000, 2001 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.4.206.1 2004/03/06 13:16:14 marka Exp $ +# $Id: Makefile.in,v 1.4.206.3 2005/09/13 00:34:54 marka Exp $ # This Makefile is a placeholder. It exists merely to make # sure that its directory gets created in the object directory @@ -23,7 +23,7 @@ srcdir = @srcdir@ VPATH = @srcdir@ top_srcdir = @top_srcdir@ -SUBDIRS = arm misc +SUBDIRS = arm misc xsl TARGETS = @BIND9_MAKE_RULES@ diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml index 01cab15ce17..28ccb360afe 100644 --- a/contrib/bind9/doc/arm/Bv9ARM-book.xml +++ b/contrib/bind9/doc/arm/Bv9ARM-book.xml @@ -1,24 +1,44 @@ - + "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" + []> + - + BIND 9 Administrator Reference Manual - - -2004 -Internet Systems Consortium, Inc. ("ISC") - - -2000-2003 -Internet Software Consortium - - + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + - + Introduction The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical @@ -368,7 +388,7 @@ be placed inside a firewall. -<acronym>BIND</acronym> Resource Requirements +<acronym>BIND</acronym> Resource Requirements Hardware requirements @@ -419,7 +439,7 @@ of the BIND 9 source distribution. - + Name Server Configuration In this section we provide some suggested configurations along with guidelines for their use. We also address the topic of reasonable @@ -667,6 +687,7 @@ of a server. checks the syntax of a named.conf file. named-checkconf + -jvz -t directory filename @@ -734,25 +755,32 @@ of a server. Retransfer the given zone from the master. - freeze zone + freeze zone class - view - Suspend updates to a dynamic zone. This allows manual + view + Suspend updates to a dynamic zone. If no zone is specified + then all zones are suspended. This allows manual edits to be made to a zone normally updated by dynamic update. It also causes changes in the journal file to be synced into the master and the journal file to be removed. All dynamic update attempts will be refused while the zone is frozen. - unfreeze zone + thaw zone class - view - Enable updates to a frozen dynamic zone. This causes + view + Enable updates to a frozen dynamic zone. If no zone is + specified then all frozen zones are enabled. This causes the server to reload the zone from disk, and re-enables dynamic updates - after the load has completed. After a zone is unfrozen, dynamic updates + after the load has completed. After a zone is thawed, dynamic updates will no longer be refused. + notify zone + class + view + Resend NOTIFY messages for the zone + reconfig Reload the configuration file and load new zones, but do not reload existing zone files even if they have changed. @@ -773,20 +801,21 @@ of a server. logging section of named.conf. - dumpdb - Dump the server's caches to the dump file. + dumpdb -all|-cache|-zone view ... + Dump the server's caches (default) and / or zones to the + dump file for the specified views. If no view is specified all + views are dumped. - stop - Stop the server, - making sure any recent changes + stop -p + Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files - of the updated zones. + of the updated zones. If -p is specified named's process id is returned. - halt + halt -p Stop the server immediately. Recent changes made through dynamic update or IXFR are not saved to the master files, but will be rolled forward from the journal files when the server - is restarted. + is restarted. If -p is specified named's process id is returned. trace Increment the servers debugging level by one. @@ -801,12 +830,20 @@ of a server. flush Flushes the server's cache. + flushname name + Flushes the given name from the server's cache. + status Display status of the server. Note the number of zones includes the internal bind/CH zone and the default ./IN hint zone if there is not a explicit root zone configured. + recursing + Dump the list of queries named is currently recursing + on. + + In BIND 9.2, rndc @@ -957,7 +994,7 @@ reload the database. - + Advanced DNS Features @@ -1004,7 +1041,7 @@ protocol is specified in RFC 1996. All changes made to a zone using dynamic update are stored in the zone's journal file. This file is automatically created by the - server when when the first dynamic update takes place. The name of + server when the first dynamic update takes place. The name of the journal file is formed by appending the extension .jnl to the name of the corresponding zone file. The journal file is in a @@ -1123,7 +1160,7 @@ to those internal hosts. With the wildcard records, the mail will be delivered to the bastion host, which can then forward it on to internal hosts. Here's an example of a wildcard MX record: -* IN MX 10 external1.example.com. +* IN MX 10 external1.example.com. Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on @@ -1620,7 +1657,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. - The <acronym>BIND</acronym> 9 Lightweight Resolver + The <acronym>BIND</acronym> 9 Lightweight Resolver The Lightweight Resolver Library Traditionally applications have been linked with a stub resolver library that sends recursive DNS queries to a local caching name @@ -1666,7 +1703,7 @@ be configured to act as a lightweight resolver daemon using the -<acronym>BIND</acronym> 9 Configuration Reference +<acronym>BIND</acronym> 9 Configuration Reference BIND 9 configuration is broadly similar to BIND 8; however, there are a few new areas @@ -1831,7 +1868,7 @@ which constitute an address match list can be any of the following: a key ID, as defined by the key statement - the name of an address match list previously defined with + the name of an address match list defined with the acl statement a nested address match list enclosed in braces @@ -2181,7 +2218,7 @@ installed. To disable the command channel, use an empty controls -statement: controls { };. +statement: controls { };. @@ -2591,9 +2628,10 @@ The query log entry reports the client's IP address and port number. The query name, class and type. It also reports whether the Recursion Desired flag was set (+ if set, - if not set), EDNS was in use (E) or if the query was signed (S). -client 127.0.0.1#62536: query: www.example.com IN AAAA +SE -client ::1#62537: query: www.example.net IN AAAA -SE - +client 127.0.0.1#62536: query: www.example.com IN AAAA +SE + +client ::1#62537: query: www.example.net IN AAAA -SE + @@ -2724,7 +2762,7 @@ statement in the named.conf file: dnssec-lookaside domain trust-anchor domain; dnssec-must-be-secure domain yes_or_no; forward ( only | first ); - forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + forwarders { ip_addr port ip_port ; ... }; dual-stack-servers port ip_port { ( domain_name port ip_port | ip_addr port ip_port ) ; ... }; check-names ( master | slave | response )( warn | fail | ignore ); allow-notify { address_match_list }; @@ -2958,7 +2996,7 @@ record does) the DNSKEY RRset is deemed to be trusted. dnssec-must-be-secure -Specify heirachies which must / may not be secure (signed and validated). +Specify heirarchies which must / may not be secure (signed and validated). If yes then named will only accept answers if they are secure. If no then normal dnssec validation applies @@ -3714,11 +3752,25 @@ in the configuration file. except zone transfers are performed using IPv6. -alt-transfer-source -An alternate transfer source if the one listed in -transfer-source fails and -use-alt-transfer-source is set. - + + alt-transfer-source + + + An alternate transfer source if the one listed in + transfer-source fails and + use-alt-transfer-source is + set. + + + If you do not wish the alternate transfer source + to be used you should set + use-alt-transfer-source + appropriately and you should not depend upon + getting a answer back to the first refresh + query. + + + alt-transfer-source-v6 An alternate transfer source if the one listed in @@ -4553,7 +4605,7 @@ Statement Grammar delegation-only yes_or_no ; file string ; forward (only|first) ; - forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + forwarders { ip_addr port ip_port ; ... }; ixfr-base string ; ixfr-tmp-file string ; maintain-ixfr-base yes_or_no ; @@ -5539,10 +5591,10 @@ be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN <zone-name>. The current $ORIGIN is appended to the domain specified in the $ORIGIN argument if it is not absolute. -$ORIGIN example.com. -WWW CNAME MAIN-SERVER +$ORIGIN example.com. +WWW CNAME MAIN-SERVER is equivalent to -WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. +WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. The <command>$INCLUDE</command> Directive Syntax: $INCLUDE filename @@ -5576,17 +5628,17 @@ resource records that only differ from each other by an iterator. $GENE be used to easily generate the sets of records required to support sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA delegation. -$ORIGIN 0.0.192.IN-ADDR.ARPA. +$ORIGIN 0.0.192.IN-ADDR.ARPA. $GENERATE 1-2 0 NS SERVER$.EXAMPLE. -$GENERATE 1-127 $ CNAME $.0 +$GENERATE 1-127 $ CNAME $.0 is equivalent to -0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. +0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. 1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA. 2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. ... 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. - + @@ -5655,7 +5707,7 @@ and not part of the standard zone file format. -<acronym>BIND</acronym> 9 Security Considerations +<acronym>BIND</acronym> 9 Security Considerations Access Control Lists Access Control Lists (ACLs), are address match lists that you can set up and nickname for future use in allow-notify, @@ -5778,7 +5830,7 @@ all. - + Troubleshooting Common Problems @@ -5837,7 +5889,7 @@ all. to read more. - + Appendices Acknowledgments diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html index 5b3659e6101..37f1eec39ab 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch01.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch01.html @@ -1,1131 +1,412 @@ - -Introduction
BIND 9 Administrator Reference Manual
PrevNext

Chapter 1. Introduction

The Internet Domain Name System (DNS) consists of the syntax + + + + + +Chapter 1. Introduction + + + + + + + +

+ + + + + + + +
Chapter 1. Introduction
+Prev   Next +
+
+
+
+

+Chapter 1. Introduction

+
+

Table of Contents

+
+
Scope of Document
+
Organization of This Document
+
Conventions Used in This Document
+
The Domain Name System (DNS)
+
+
DNS Fundamentals
+
Domains and Domain Names
+
Zones
+
Authoritative Name Servers
+
Caching Name Servers
+
Name Servers in Multiple Roles
+
+
+
+

The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actually maps names to Internet - addresses. DNS data is maintained in a group of distributed - hierarchical databases.

1.1. Scope of Document

The Berkeley Internet Name Domain (BIND) implements an + addresses. DNS data is maintained in a group of distributed + hierarchical databases.

+
+

+Scope of Document

+

The Berkeley Internet Name Domain (BIND) implements an domain name server for a number of operating systems. This document provides basic information about the installation and - care of the Internet Software Consortium (ISC) - BIND version 9 software package for system - administrators.

This version of the manual corresponds to BIND version 9.3.

1.2. Organization of This Document

In this document, Section 1 introduces - the basic DNS and BIND concepts. Section 2 - describes resource requirements for running BIND in various - environments. Information in Section 3 is - task-oriented in its presentation and is + care of the Internet Software Consortium (ISC) + BIND version 9 software package for system + administrators.

+

This version of the manual corresponds to BIND version 9.3.

+
+
+

+Organization of This Document

+

In this document, Section 1 introduces + the basic DNS and BIND concepts. Section 2 + describes resource requirements for running BIND in various + environments. Information in Section 3 is + task-oriented in its presentation and is organized functionally, to aid in the process of installing the - BIND 9 software. The task-oriented section is followed by - Section 4, which contains more advanced + BIND 9 software. The task-oriented section is followed by + Section 4, which contains more advanced concepts that the system administrator may need for implementing - certain options. Section 5 - describes the BIND 9 lightweight - resolver. The contents of Section 6 are + certain options. Section 5 + describes the BIND 9 lightweight + resolver. The contents of Section 6 are organized as in a reference manual to aid in the ongoing - maintenance of the software. Section 7 - addresses security considerations, and - Section 8 contains troubleshooting help. The + maintenance of the software. Section 7 + addresses security considerations, and + Section 8 contains troubleshooting help. The main body of the document is followed by several - Appendices which contain useful reference - information, such as a Bibliography and - historic information related to BIND and the Domain Name - System.

1.3. Conventions Used in This Document

In this document, we use the following general typographic - conventions:

To -describe:

We use the style:

a pathname, filename, URL, hostname, -mailing list name, or new term or concept

Fixed width

literal user -input

Fixed Width Bold

program output

Fixed Width

The following conventions are used in descriptions of the -BIND configuration file:

To -describe:

We use the style:

keywords

Fixed Width

variables

Fixed Width

Optional input

[Text is enclosed in square brackets]

1.4. The Domain Name System (DNS)

The purpose of this document is to explain the installation -and upkeep of the BIND software package, and we + Appendices which contain useful reference + information, such as a Bibliography and + historic information related to BIND and the Domain Name + System.

+
+
+

+Conventions Used in This Document

+

In this document, we use the following general typographic + conventions:

+
++++ + + + + + + + + + + + + + + + + + + +
+

To +describe:

+		 +

We use the style:

+
+

a pathname, filename, URL, hostname, +mailing list name, or new term or concept

+

Fixed width

literal user +input

Fixed Width Bold

program output

Fixed Width

+

The following conventions are used in descriptions of the +BIND configuration file:

+
++++ + + + + + + + + + + + + + + + + + + +

To +describe:

We use the style:

keywords

Fixed Width

variables

Fixed Width

Optional input

[Text is enclosed in square brackets]

+
+
+

+The Domain Name System (DNS)

+

The purpose of this document is to explain the installation +and upkeep of the BIND software package, and we begin by reviewing the fundamentals of the Domain Name System -(DNS) as they relate to BIND. -

1.4.1. DNS Fundamentals

The Domain Name System (DNS) is the hierarchical, distributed +(DNS) as they relate to BIND. +

+
+

+DNS Fundamentals

+

The Domain Name System (DNS) is the hierarchical, distributed database. It stores information for mapping Internet host names to IP addresses and vice versa, mail routing information, and other data -used by Internet applications.

Clients look up information in the DNS by calling a -resolver library, which sends queries to one or -more name servers and interprets the responses. -The BIND 9 software distribution contains a -name server, named, and two resolver -libraries, liblwres and libbind. -

1.4.2. Domains and Domain Names

The data stored in the DNS is identified by domain -names that are organized as a tree according to +used by Internet applications.

+

Clients look up information in the DNS by calling a +resolver library, which sends queries to one or +more name servers and interprets the responses. +The BIND 9 software distribution contains a +name server, named, and two resolver +libraries, liblwres and libbind. +

+
+
+

+Domains and Domain Names

+

The data stored in the DNS is identified by domain +names that are organized as a tree according to organizational or administrative boundaries. Each node of the tree, -called a domain, is given a label. The domain name of the +called a domain, is given a label. The domain name of the node is the concatenation of all the labels on the path from the -node to the root node. This is represented +node to the root node. This is represented in written form as a string of labels listed from right to left and separated by dots. A label need only be unique within its parent -domain.

For example, a domain name for a host at the -company Example, Inc. could be -mail.example.com, -where com is the +domain.

+

For example, a domain name for a host at the +company Example, Inc. could be +mail.example.com, +where com is the top level domain to which -ourhost.example.com belongs, -example is -a subdomain of com, and -ourhost is the -name of the host.

For administrative purposes, the name space is partitioned into -areas called zones, each starting at a node and +ourhost.example.com belongs, +example is +a subdomain of com, and +ourhost is the +name of the host.

+

For administrative purposes, the name space is partitioned into +areas called zones, each starting at a node and extending down to the leaf nodes or to nodes where other zones start. -The data for each zone is stored in a name -server, which answers queries about the zone using the -DNS protocol. -

The data associated with each domain name is stored in the -form of resource records (RRs). +The data for each zone is stored in a name +server, which answers queries about the zone using the +DNS protocol. +

+

The data associated with each domain name is stored in the +form of resource records (RRs). Some of the supported resource record types are described in -Section 6.3.1.

For more detailed information about the design of the DNS and +the section called “Types of Resource Records and When to Use Them”.

+

For more detailed information about the design of the DNS and the DNS protocol, please refer to the standards documents listed in -Section A.3.1.

1.4.3. Zones

To properly operate a name server, it is important to understand -the difference between a zone -and a domain.

As we stated previously, a zone is a point of delegation in -the DNS tree. A zone consists of +the section called “Request for Comments (RFCs)”.

+
+
+

+Zones

+

To properly operate a name server, it is important to understand +the difference between a zone +and a domain.

+

As we stated previously, a zone is a point of delegation in +the DNS tree. A zone consists of those contiguous parts of the domain tree for which a name server has complete information and over which it has authority. It contains all domain names from a certain point downward in the domain tree except those which are delegated to other zones. A delegation point is marked by one or more -NS records in the +NS records in the parent zone, which should be matched by equivalent NS records at -the root of the delegated zone.

For instance, consider the example.com +the root of the delegated zone.

+

For instance, consider the example.com domain which includes names -such as host.aaa.example.com and -host.bbb.example.com even though -the example.com zone includes -only delegations for the aaa.example.com and -bbb.example.com zones. A zone can map +such as host.aaa.example.com and +host.bbb.example.com even though +the example.com zone includes +only delegations for the aaa.example.com and +bbb.example.com zones. A zone can map exactly to a single domain, but could also include only part of a domain, the rest of which could be delegated to other -name servers. Every name in the DNS tree is a -domain, even if it is -terminal, that is, has no -subdomains. Every subdomain is a domain and +name servers. Every name in the DNS tree is a +domain, even if it is +terminal, that is, has no +subdomains. Every subdomain is a domain and every domain except the root is also a subdomain. The terminology is not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to gain a complete understanding of this difficult and subtle -topic.

Though BIND is called a "domain name server", +topic.

+

Though BIND is called a "domain name server", it deals primarily in terms of zones. The master and slave -declarations in the named.conf file specify +declarations in the named.conf file specify zones, not domains. When you ask some other site if it is willing to -be a slave server for your domain, you are -actually asking for slave service for some collection of zones.

1.4.4. Authoritative Name Servers

Each zone is served by at least -one authoritative name server, +be a slave server for your domain, you are +actually asking for slave service for some collection of zones.

+
+
+

+Authoritative Name Servers

+

Each zone is served by at least +one authoritative name server, which contains the complete data for the zone. To make the DNS tolerant of server and network failures, most zones have two or more authoritative servers. -

Responses from authoritative servers have the "authoritative +

+

Responses from authoritative servers have the "authoritative answer" (AA) bit set in the response packets. This makes them easy to identify when debugging DNS configurations using tools like -dig (Section 3.3.1.1).

1.4.4.1. The Primary Master

The authoritative server where the master copy of the zone data is maintained is -called the primary master server, or simply the -primary. It loads the zone contents from some +dig (the section called “Diagnostic Tools”).

+
+

+The Primary Master

+

+The authoritative server where the master copy of the zone data is maintained is +called the primary master server, or simply the +primary. It loads the zone contents from some local file edited by humans or perhaps generated mechanically from some other local file which is edited by humans. This file is called -the zone file or master file.

1.4.4.2. Slave Servers

The other authoritative servers, the slave -servers (also known as secondary servers) load +the zone file or master file.

+
+
+

+Slave Servers

+

The other authoritative servers, the slave +servers (also known as secondary servers) load the zone contents from another server using a replication process -known as a zone transfer. Typically the data are +known as a zone transfer. Typically the data are transferred directly from the primary master, but it is also possible to transfer it from another slave. In other words, a slave server -may itself act as a master to a subordinate slave server.

1.4.4.3. Stealth Servers

Usually all of the zone's authoritative servers are listed in +may itself act as a master to a subordinate slave server.

+
+
+

+Stealth Servers

+

Usually all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute -a delegation of the zone from the parent. +a delegation of the zone from the parent. The authoritative servers are also listed in the zone file itself, -at the top level or apex +at the top level or apex of the zone. You can list servers in the zone's top-level NS records that are not in the parent's NS delegation, but you cannot list servers in the parent's delegation that are not present at -the zone's top level.

A stealth server is a server that is +the zone's top level.

+

A stealth server is a server that is authoritative for a zone but is not listed in that zone's NS records. Stealth servers can be used for keeping a local copy of a zone to speed up access to the zone's records or to make sure that the zone is available even if all the "official" servers for the zone are -inaccessible.

A configuration where the primary master server itself is a +inaccessible.

+

A configuration where the primary master server itself is a stealth server is often referred to as a "hidden primary" configuration. One use for this configuration is when the primary master is behind a firewall and therefore unable to communicate directly -with the outside world.

1.4.5. Caching Name Servers

The resolver libraries provided by most operating systems are -stub resolvers, meaning that they are not capable of +with the outside world.

+
+
+
+

+Caching Name Servers

+

The resolver libraries provided by most operating systems are +stub resolvers, meaning that they are not capable of performing the full DNS resolution process by themselves by talking directly to the authoritative servers. Instead, they rely on a local name server to perform the resolution on their behalf. Such a server -is called a recursive name server; it performs -recursive lookups for local clients.

To improve performance, recursive servers cache the results of +is called a recursive name server; it performs +recursive lookups for local clients.

+

To improve performance, recursive servers cache the results of the lookups they perform. Since the processes of recursion and caching are intimately connected, the terms -recursive server and -caching server are often used synonymously.

The length of time for which a record may be retained in +recursive server and +caching server are often used synonymously.

+

The length of time for which a record may be retained in in the cache of a caching name server is controlled by the Time To Live (TTL) field associated with each resource record. -

1.4.5.1. Forwarding

Even a caching name server does not necessarily perform +

+
+

+Forwarding

+

Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can -forward some or all of the queries +forward some or all of the queries that it cannot satisfy from its cache to another caching name server, -commonly referred to as a forwarder. -

There may be one or more forwarders, +commonly referred to as a forwarder. +

+

There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found. Forwarders are typically used when you do not wish all the servers at a given site to interact directly with the rest of the Internet servers. A typical scenario would involve a number -of internal DNS servers and an Internet firewall. Servers unable +of internal DNS servers and an Internet firewall. Servers unable to pass packets through the firewall would forward to the server -that can do it, and that server would query the Internet DNS servers +that can do it, and that server would query the Internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the clients can take advantage -of.

1.4.6. Name Servers in Multiple Roles

The BIND name server can simultaneously act as +of.

+
+
+
+

+Name Servers in Multiple Roles

+

The BIND name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching -(recursive) server for a set of local clients.

However, since the functions of authoritative name service +(recursive) server for a set of local clients.

+

However, since the functions of authoritative name service and caching/recursive name service are logically separate, it is often advantageous to run them on separate server machines. A server that only provides authoritative name service -(an authoritative-only server) can run with +(an authoritative-only server) can run with recursion disabled, improving reliability and security. A server that is not authoritative for any zones and only provides recursive service to local -clients (a caching-only server) +clients (a caching-only server) does not need to be reachable from the Internet at large and can -be placed inside a firewall.

PrevHomeNext
BIND 9 Administrator Reference Manual BIND Resource Requirements
\ No newline at end of file +be placed inside a firewall.

+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
BIND 9 Administrator Reference Manual Home Chapter 2. BIND Resource Requirements
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html index 0b293c7edfd..d3e946ad770 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch02.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch02.html @@ -1,198 +1,95 @@ - -BIND Resource Requirements
BIND 9 Administrator Reference Manual
PrevNext

Chapter 2. BIND Resource Requirements

2.1. Hardware requirements

DNS hardware requirements have traditionally been quite modest. + + + + + +Chapter 2. BIND Resource Requirements + + + + + + + +

+ + + + + + + +
Chapter 2. BIND Resource Requirements
+Prev   Next +
+
+
+
+

+Chapter 2. BIND Resource Requirements

+
+

Table of Contents

+
+
Hardware requirements
+
CPU Requirements
+
Memory Requirements
+
Name Server Intensive Environment Issues
+
Supported Operating Systems
+
+
+
+

+Hardware requirements

+

DNS hardware requirements have traditionally been quite modest. For many installations, servers that have been pensioned off from -active duty have performed admirably as DNS servers.

The DNSSEC and IPv6 features of BIND 9 may prove to be quite +active duty have performed admirably as DNS servers.

+

The DNSSEC and IPv6 features of BIND 9 may prove to be quite CPU intensive however, so organizations that make heavy use of these features may wish to consider larger systems for these applications. -BIND 9 is fully multithreaded, allowing full utilization of -multiprocessor systems for installations that need it.

2.2. CPU Requirements

CPU requirements for BIND 9 range from i486-class machines +BIND 9 is fully multithreaded, allowing full utilization of +multiprocessor systems for installations that need it.

+
+
+

+CPU Requirements

+

CPU requirements for BIND 9 range from i486-class machines for serving of static zones without caching, to enterprise-class machines if you intend to process many dynamic updates and DNSSEC -signed zones, serving many thousands of queries per second.

2.3. Memory Requirements

The memory of the server has to be large enough to fit the -cache and zones loaded off disk. The max-cache-size +signed zones, serving many thousands of queries per second.

+
+
+

+Memory Requirements

+

The memory of the server has to be large enough to fit the +cache and zones loaded off disk. The max-cache-size option can be used to limit the amount of memory used by the cache, -at the expense of reducing cache hit rates and causing more DNS +at the expense of reducing cache hit rates and causing more DNS traffic. It is still good practice to have enough memory to load all zone and cache data into memory — unfortunately, the best way to determine this for a given installation is to watch the name server in operation. After a few weeks the server process should reach a relatively stable size where entries are expiring from the cache as -fast as they are being inserted.

2.4. Name Server Intensive Environment Issues

For name server intensive environments, there are two alternative +fast as they are being inserted.

+
+
+

+Name Server Intensive Environment Issues

+

For name server intensive environments, there are two alternative configurations that may be used. The first is where clients and any second-level internal name servers query a main name server, which has enough memory to build a large cache. This approach minimizes @@ -201,84 +98,33 @@ is to set up second-level internal name servers to make queries independently. In this configuration, none of the individual machines needs to have as much memory or CPU power as in the first alternative, but this has the disadvantage of making many more external queries, -as none of the name servers share their cached data.

2.5. Supported Operating Systems

ISC BIND 9 compiles and runs on a large number +as none of the name servers share their cached data.

+
+
+

+Supported Operating Systems

+

ISC BIND 9 compiles and runs on a large number of Unix-like operating system and on Windows NT / 2000. For an up-to-date list of supported systems, see the README file in the top level directory -of the BIND 9 source distribution.

PrevHomeNext
Introduction Name Server Configuration
\ No newline at end of file +of the BIND 9 source distribution.

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 1. Introduction  Home Chapter 3. Name Server Configuration
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html index 37362d5daef..4d6d93be1f1 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch03.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch03.html @@ -1,133 +1,79 @@ - -Name Server Configuration
BIND 9 Administrator Reference Manual
PrevNext

Chapter 3. Name Server Configuration

In this section we provide some suggested configurations along + + + + + +Chapter 3. Name Server Configuration + + + + + + + +

+ + + + + + + +
Chapter 3. Name Server Configuration
+Prev   Next +
+
+
+
+

+Chapter 3. Name Server Configuration

+
+

Table of Contents

+
+
Sample Configurations
+
+
A Caching-only Name Server
+
An Authoritative-only Name Server
+
+
Load Balancing
+
Name Server Operations
+
+
Tools for Use With the Name Server Daemon
+
Signals
+
+
+
+

In this section we provide some suggested configurations along with guidelines for their use. We also address the topic of reasonable -option setting.

3.1. Sample Configurations

3.1.1. A Caching-only Name Server

The following sample configuration is appropriate for a caching-only +option setting.

+
+

+Sample Configurations

+
+

+A Caching-only Name Server

+

The following sample configuration is appropriate for a caching-only name server for use by clients internal to a corporation. All queries -from outside clients are refused using the allow-query +from outside clients are refused using the allow-query option. Alternatively, the same effect could be achieved using suitable -firewall rules.


// Two corporate subnets we wish to allow queries from.
+firewall rules.

+
+// Two corporate subnets we wish to allow queries from.
 acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
 options {
      directory "/etc/namedb";           // Working directory
@@ -139,29 +85,16 @@ zone "0.0.127.in-addr.arpa" {
      file "localhost.rev";
      notify no;
 };
-

3.1.2. An Authoritative-only Name Server

This sample configuration is for an authoritative-only server -that is the master server for "example.com" -and a slave for the subdomain "eng.example.com".


options {
+
+
+
+

+An Authoritative-only Name Server

+

This sample configuration is for an authoritative-only server +that is the master server for "example.com" +and a slave for the subdomain "eng.example.com".

+
+options {
      directory "/etc/namedb";           // Working directory
      allow-query { any; };              // This is the default
      recursion no;                      // Do not provide recursive service
@@ -190,1070 +123,321 @@ zone "eng.example.com" {
      // IP address of eng.example.com master server
      masters { 192.168.4.12; };
 };
-

3.2. Load Balancing

A primitive form of load balancing can be achieved in -the DNS by using multiple A records for one name.

For example, if you have three WWW servers with network addresses + +

+
+
+

+Load Balancing

+

A primitive form of load balancing can be achieved in +the DNS by using multiple A records for one name.

+

For example, if you have three WWW servers with network addresses of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the following means that clients will connect to each machine one third -of the time:

Name

TTL

CLASS

TYPE

Resource Record (RR) Data

www

600

IN

A

10.0.0.1

600

IN

A

10.0.0.2

600

IN

A

10.0.0.3

When a resolver queries for these records, BIND will rotate +of the time:

+
+++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

TTL

CLASS

TYPE

Resource Record (RR) Data

www

600

IN

A

10.0.0.1

600

IN

A

10.0.0.2

600

IN

A

10.0.0.3

+

When a resolver queries for these records, BIND will rotate them and respond to the query with the records in a different order. In the example above, clients will randomly receive records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients - will use the first record returned and discard the rest.

For more detail on ordering responses, check the - rrset-order substatement in the - options statement, see - RRset Ordering. + will use the first record returned and discard the rest.

+

For more detail on ordering responses, check the + rrset-order substatement in the + options statement, see + RRset Ordering. This substatement is not supported in - BIND 9, and only the ordering scheme described above is - available.

3.3. Name Server Operations

3.3.1. Tools for Use With the Name Server Daemon

There are several indispensable diagnostic, administrative + BIND 9, and only the ordering scheme described above is + available.

+
+
+

+Name Server Operations

+
+

+Tools for Use With the Name Server Daemon

+

There are several indispensable diagnostic, administrative and monitoring tools available to the system administrator for controlling and debugging the name server daemon. We describe several in this -section

3.3.1.1. Diagnostic Tools

The dig, host, and -nslookup programs are all command line tools +section

+
+

+Diagnostic Tools

+

The dig, host, and +nslookup programs are all command line tools for manually querying name servers. They differ in style and output format. -

dig

The domain information groper (dig) +

+
+
dig
+
+

The domain information groper (dig) is the most versatile and complete of these lookup tools. It has two modes: simple interactive mode for a single query, and batch mode which executes a query for each in a list of several query lines. All query options are accessible -from the command line.

dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%comment]

The usual simple use of dig will take the form

dig @server domain query-type query-class

For more information and a list of available commands and -options, see the dig man page.

host

The host utility emphasizes simplicity +from the command line.

+

dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%comment]

+

The usual simple use of dig will take the form

+

dig @server domain query-type query-class

+

For more information and a list of available commands and +options, see the dig man page.

+
+
host
+
+

The host utility emphasizes simplicity and ease of use. By default, it converts between host names and Internet addresses, but its functionality -can be extended with the use of options.

host [-aCdlrTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] hostname [server]

For more information and a list of available commands and -options, see the host man page.

nslookup

nslookup has two modes: interactive +can be extended with the use of options.

+

host [-aCdlrTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] hostname [server]

+

For more information and a list of available commands and +options, see the host man page.

+
+
nslookup
+
+

nslookup has two modes: interactive and non-interactive. Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain. Non-interactive mode is used to print just -the name and requested information for a host or domain.

nslookup [-option...] [host-to-find | - [server]]

Interactive mode is entered when no arguments are given (the +the name and requested information for a host or domain.

+

nslookup [-option...] [[host-to-find] | [- [server]]]

+

Interactive mode is entered when no arguments are given (the default name server will be used) or when the first argument is a hyphen (`-') and the second argument is the host name or Internet address -of a name server.

Non-interactive mode is used when the name or Internet address +of a name server.

+

Non-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument. The -optional second argument specifies the host name or address of a name server.

Due to its arcane user interface and frequently inconsistent -behavior, we do not recommend the use of nslookup. -Use dig instead.

3.3.1.2. Administrative Tools

Administrative tools play an integral part in the management -of a server.

named-checkconf

The named-checkconf program - checks the syntax of a named.conf file.

named-checkconf [-t directory] [filename]

named-checkzone

The named-checkzone program checks a master file for - syntax and consistency.

named-checkzone [-djqvD] [-c class] [-o output] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] zone [filename]

rndc

The remote name daemon control - (rndc) program allows the system +optional second argument specifies the host name or address of a name server.

+

Due to its arcane user interface and frequently inconsistent +behavior, we do not recommend the use of nslookup. +Use dig instead.

+
+
+
+
+

+Administrative Tools

+

Administrative tools play an integral part in the management +of a server.

+
+
+named-checkconf +
+
+

The named-checkconf program + checks the syntax of a named.conf file.

+

named-checkconf [-jvz] [-t directory] [filename]

+
+
+named-checkzone +
+
+

The named-checkzone program checks a master file for + syntax and consistency.

+

named-checkzone [-djqvD] [-c class] [-o output] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] zone [filename]

+
+
+rndc +
+
+

The remote name daemon control + (rndc) program allows the system administrator to control the operation of a name server. - If you run rndc without any options - it will display a usage message as follows:

rndc [-c config] [-s server] [-p port] [-y key] command [command...]

command is one of the following:

reload

Reload configuration file and zones.

reload zone - [class - [view]]

Reload the given zone.

refresh zone - [class - [view]]

Schedule zone maintenance for the given zone.

retransfer zone - [class - [view]]

Retransfer the given zone from the master.

freeze zone - [class - [view]]

Suspend updates to a dynamic zone. This allows manual + If you run rndc without any options + it will display a usage message as follows:

+

rndc [-c config] [-s server] [-p port] [-y key] command [command...]

+

command is one of the following:

+
+
reload
+

Reload configuration file and zones.

+
reload zone + [class + [view]]
+

Reload the given zone.

+
refresh zone + [class + [view]]
+

Schedule zone maintenance for the given zone.

+
retransfer zone + [class + [view]]
+

Retransfer the given zone from the master.

+
freeze [zone + [class + [view]]]
+

Suspend updates to a dynamic zone. If no zone is specified + then all zones are suspended. This allows manual edits to be made to a zone normally updated by dynamic update. It also causes changes in the journal file to be synced into the master and the journal file to be removed. All dynamic update attempts will - be refused while the zone is frozen.

unfreeze zone - [class - [view]]

Enable updates to a frozen dynamic zone. This causes + be refused while the zone is frozen.

+
thaw [zone + [class + [view]]]
+

Enable updates to a frozen dynamic zone. If no zone is + specified then all frozen zones are enabled. This causes the server to reload the zone from disk, and re-enables dynamic updates - after the load has completed. After a zone is unfrozen, dynamic updates - will no longer be refused.

reconfig

Reload the configuration file and load new zones, + after the load has completed. After a zone is thawed, dynamic updates + will no longer be refused.

+
notify zone + [class + [view]]
+

Resend NOTIFY messages for the zone

+
reconfig
+

Reload the configuration file and load new zones, but do not reload existing zone files even if they have changed. - This is faster than a full reload when there + This is faster than a full reload when there is a large number of zones because it avoids the need to examine the modification times of the zones files. -

stats

Write server statistics to the statistics file.

querylog

Toggle query logging. Query logging can also be enabled - by explicitly directing the queries - category to a channel in the - logging section of - named.conf.

dumpdb

Dump the server's caches to the dump file.

stop

Stop the server, - making sure any recent changes +

+
stats
+

Write server statistics to the statistics file.

+
querylog
+

Toggle query logging. Query logging can also be enabled + by explicitly directing the queries + category to a channel in the + logging section of + named.conf.

+
dumpdb [-all|-cache|-zone] [view ...]
+

Dump the server's caches (default) and / or zones to the + dump file for the specified views. If no view is specified all + views are dumped.

+
stop [-p]
+

Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files - of the updated zones.

halt

Stop the server immediately. Recent changes + of the updated zones. If -p is specified named's process id is returned.

+
halt [-p]
+

Stop the server immediately. Recent changes made through dynamic update or IXFR are not saved to the master files, but will be rolled forward from the journal files when the server - is restarted.

trace

Increment the servers debugging level by one.

trace level

Sets the server's debugging level to an explicit - value.

notrace

Sets the server's debugging level to 0.

flush

Flushes the server's cache.

status

Display status of the server. -Note the number of zones includes the internal bind/CH zone -and the default ./IN hint zone if there is not a -explicit root zone configured.

In BIND 9.2, rndc -supports all the commands of the BIND 8 ndc -utility except ndc start and -ndc restart, which were also -not supported in ndc's channel mode.

A configuration file is required, since all + is restarted. If -p is specified named's process id is returned.

+
trace
+

Increment the servers debugging level by one.

+
trace level
+

Sets the server's debugging level to an explicit + value.

+
notrace
+

Sets the server's debugging level to 0.

+
flush
+

Flushes the server's cache.

+
flushname name
+

Flushes the given name from the server's cache.

+
status
+

Display status of the server. +Note the number of zones includes the internal bind/CH zone +and the default ./IN hint zone if there is not a +explicit root zone configured.

+
recursing
+

Dump the list of queries named is currently recursing + on. +

+
+

In BIND 9.2, rndc +supports all the commands of the BIND 8 ndc +utility except ndc start and +ndc restart, which were also +not supported in ndc's channel mode.

+

A configuration file is required, since all communication with the server is authenticated with digital signatures that rely on a shared secret, and there is no way to provide that secret other than with a configuration file. The default location for the -rndc configuration file is -/etc/rndc.conf, but an alternate -location can be specified with the -c +rndc configuration file is +/etc/rndc.conf, but an alternate +location can be specified with the -c option. If the configuration file is not found, -rndc will also look in -/etc/rndc.key (or whatever -sysconfdir was defined when -the BIND build was configured). -The rndc.key file is generated by -running rndc-confgen -a as described in -Section 6.2.4.

The format of the configuration file is similar to -that of named.conf, but limited to -only four statements, the options, -key, server and -include +rndc will also look in +/etc/rndc.key (or whatever +sysconfdir was defined when +the BIND build was configured). +The rndc.key file is generated by +running rndc-confgen -a as described in +the section called “controls Statement Definition and Usage”.

+

The format of the configuration file is similar to +that of named.conf, but limited to +only four statements, the options, +key, server and +include statements. These statements are what associate the secret keys to the servers with which they are meant to be shared. The order of statements is not -significant.

The options statement has three clauses: -default-server, default-key, -and default-port. -default-server takes a +significant.

+

The options statement has three clauses: +default-server, default-key, +and default-port. +default-server takes a host name or address argument and represents the server that will -be contacted if no -s +be contacted if no -s option is provided on the command line. -default-key takes -the name of a key as its argument, as defined by a key statement. -default-port specifies the port to which -rndc should connect if no +default-key takes +the name of a key as its argument, as defined by a key statement. +default-port specifies the port to which +rndc should connect if no port is given on the command line or in a -server statement.

The key statement defines an key to be used -by rndc when authenticating with -named. Its syntax is identical to the -key statement in named.conf. -The keyword key is +server statement.

+

The key statement defines an key to be used +by rndc when authenticating with +named. Its syntax is identical to the +key statement in named.conf. +The keyword key is followed by a key name, which must be a valid domain name, though it need not actually be hierarchical; thus, -a string like "rndc_key" is a valid name. -The key statement has two clauses: -algorithm and secret. +a string like "rndc_key" is a valid name. +The key statement has two clauses: +algorithm and secret. While the configuration parser will accept any string as the argument -to algorithm, currently only the string "hmac-md5" -has any meaning. The secret is a base-64 encoded string.

The server statement associates a key -defined using the key statement with a server. -The keyword server is followed by a -host name or address. The server statement -has two clauses: key and port. -The key clause specifies the name of the key +to algorithm, currently only the string "hmac-md5" +has any meaning. The secret is a base-64 encoded string.

+

The server statement associates a key +defined using the key statement with a server. +The keyword server is followed by a +host name or address. The server statement +has two clauses: key and port. +The key clause specifies the name of the key to be used when communicating with this server, and the -port clause can be used to -specify the port rndc should connect -to on the server.

A sample minimal configuration file is as follows:


key rndc_key {
+port clause can be used to
+specify the port rndc should connect
+to on the server.

+
A sample minimal configuration file is as follows:

+
+key rndc_key {
      algorithm "hmac-md5";
      secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
 };
@@ -1261,213 +445,81 @@ options {
      default-server 127.0.0.1;
      default-key    rndc_key;
 };
-
This file, if installed as /etc/rndc.conf,
-would allow the command:
$ rndc reload
to connect to 127.0.0.1 port 953 and cause the name server
+
+

This file, if installed as /etc/rndc.conf, +would allow the command:

+

$ rndc reload

+

to connect to 127.0.0.1 port 953 and cause the name server to reload, if a name server on the local machine were running with -following controls statements:


controls {
+following controls statements:

+
+controls {
         inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
 };
-
and it had an identical key statement for
-rndc_key.
Running the rndc-confgen program will
-conveniently create a rndc.conf
+
+

and it had an identical key statement for +rndc_key.

+

Running the rndc-confgen program will +conveniently create a rndc.conf file for you, and also display the -corresponding controls statement that you need to -add to named.conf. Alternatively, -you can run rndc-confgen -a to set up -a rndc.key file and not modify -named.conf at all. -

3.3.2. Signals

Certain UNIX signals cause the name server to take specific +corresponding controls statement that you need to +add to named.conf. Alternatively, +you can run rndc-confgen -a to set up +a rndc.key file and not modify +named.conf at all. +

+ +
+
+
+
+

+Signals

+

Certain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can -be sent using the kill command.

SIGHUP

Causes the server to read named.conf and -reload the database.

SIGTERM

Causes the server to clean up and exit.

SIGINT

-

Causes the server to clean up and exit.

PrevHomeNext
BIND Resource Requirements Advanced DNS Features
\ No newline at end of file +be sent using the kill command.

+
++++ + + + + + + + + + + + + + + +

SIGHUP

Causes the server to read named.conf and +reload the database.

SIGTERM

Causes the server to clean up and exit.

+

SIGINT

+

Causes the server to clean up and exit.

+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 2. BIND Resource Requirements Home Chapter 4. Advanced DNS Features
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html index 8a4ab28875c..8165dbba967 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch04.html @@ -1,618 +1,273 @@ - -Advanced DNS Features
BIND 9 Administrator Reference Manual
PrevNext

Chapter 4. Advanced DNS Features

4.1. Notify

DNS NOTIFY is a mechanism that allows master + + + + + +Chapter 4. Advanced DNS Features + + + + + + + +

+ + + + + + + +
Chapter 4. Advanced DNS Features
+Prev   Next +
+
+
+
+

+Chapter 4. Advanced DNS Features

+
+

Table of Contents

+
+
Notify
+
Dynamic Update
+
The journal file
+
Incremental Zone Transfers (IXFR)
+
Split DNS
+
TSIG
+
+
Generate Shared Keys for Each Pair of Hosts
+
Copying the Shared Secret to Both Machines
+
Informing the Servers of the Key's Existence
+
Instructing the Server to Use the Key
+
TSIG Key Based Access Control
+
Errors
+
+
TKEY
+
SIG(0)
+
DNSSEC
+
+
Generating Keys
+
Signing the Zone
+
Configuring Servers
+
+
IPv6 Support in BIND 9
+
+
Address Lookups Using AAAA Records
+
Address to Name Lookups Using Nibble Format
+
+
+
+
+

+Notify

+

DNS NOTIFY is a mechanism that allows master servers to notify their slave servers of changes to a zone's data. In -response to a NOTIFY from a master server, the +response to a NOTIFY from a master server, the slave will check to see that its version of the zone is the -current version and, if not, initiate a zone transfer.

DNS +current version and, if not, initiate a zone transfer.

+

DNS For more information about -NOTIFY, see the description of the -notify option in Section 6.2.16.1 and -the description of the zone option also-notify in -Section 6.2.16.7. The NOTIFY +NOTIFY, see the description of the +notify option in the section called “Boolean Options” and +the description of the zone option also-notify in +the section called “Zone Transfers”. The NOTIFY protocol is specified in RFC 1996. -

4.2. Dynamic Update

Dynamic Update is a method for adding, replacing or deleting +

+
+
+

+Dynamic Update

+

Dynamic Update is a method for adding, replacing or deleting records in a master server by sending it a special form of DNS messages. The format and meaning of these messages is specified - in RFC 2136.

Dynamic update is enabled on a zone-by-zone basis, by - including an allow-update or - update-policy clause in the - zone statement.

Updating of secure zones (zones using DNSSEC) follows + in RFC 2136.

+

Dynamic update is enabled on a zone-by-zone basis, by + including an allow-update or + update-policy clause in the + zone statement.

+

Updating of secure zones (zones using DNSSEC) follows RFC 3007: RRSIG and NSEC records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based - on transaction signatures and an explicit server policy.

4.2.1. The journal file

All changes made to a zone using dynamic update are stored in the + on transaction signatures and an explicit server policy.

+
+

+The journal file

+

All changes made to a zone using dynamic update are stored in the zone's journal file. This file is automatically created by the - server when when the first dynamic update takes place. The name of + server when the first dynamic update takes place. The name of the journal file is formed by appending the - extension .jnl to the + extension .jnl to the name of the corresponding zone file. The journal file is in a - binary format and should not be edited manually.

The server will also occasionally write ("dump") + binary format and should not be edited manually.

+

The server will also occasionally write ("dump") the complete contents of the updated zone to its zone file. This is not done immediately after each dynamic update, because that would be too slow when a large zone is updated frequently. Instead, the dump is delayed by - up to 15 minutes, allowing additional updates to take place.

When a server is restarted after a shutdown or crash, it will replay + up to 15 minutes, allowing additional updates to take place.

+

When a server is restarted after a shutdown or crash, it will replay the journal file to incorporate into the zone any updates that took - place after the last zone dump.

Changes that result from incoming incremental zone transfers are also - journalled in a similar way.

The zone files of dynamic zones cannot normally be edited by + place after the last zone dump.

+

Changes that result from incoming incremental zone transfers are also + journalled in a similar way.

+

The zone files of dynamic zones cannot normally be edited by hand because they are not guaranteed to contain the most recent dynamic changes - those are only in the journal file. The only way to ensure that the zone file of a dynamic zone - is up to date is to run rndc stop.

If you have to make changes to a dynamic zone + is up to date is to run rndc stop.

+

If you have to make changes to a dynamic zone manually, the following procedure will work: Disable dynamic updates to the zone using - rndc freeze zone. - This will also remove the zone's .jnl file + rndc freeze zone. + This will also remove the zone's .jnl file and update the master file. Edit the zone file. Run - rndc unfreeze zone - to reload the changed zone and re-enable dynamic updates.

4.3. Incremental Zone Transfers (IXFR)

The incremental zone transfer (IXFR) protocol is a way for + rndc unfreeze zone + to reload the changed zone and re-enable dynamic updates.

+
+
+
+

+Incremental Zone Transfers (IXFR)

+

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data, instead of having to transfer the entire zone. The IXFR protocol is specified in RFC -1995. See Proposed Standards.

When acting as a master, BIND 9 +1995. See Proposed Standards.

+

When acting as a master, BIND 9 supports IXFR for those zones where the necessary change history information is available. These include master zones maintained by dynamic update and slave zones whose data was obtained by IXFR. For manually maintained master zones, and for slave zones obtained by performing a full zone transfer (AXFR), IXFR is supported only if the option -ixfr-from-differences is set -to yes. -

When acting as a slave, BIND 9 will +ixfr-from-differences is set +to yes. +

+

When acting as a slave, BIND 9 will attempt to use IXFR unless it is explicitly disabled. For more information about disabling -IXFR, see the description of the request-ixfr clause -of the server statement.

4.4. Split DNS

Setting up different views, or visibility, of the DNS space to -internal and external resolvers is usually referred to as a Split -DNS setup. There are several reasons an organization -would want to set up its DNS this way.

One common reason for setting up a DNS system this way is +IXFR, see the description of the request-ixfr clause +of the server statement.

+
+
+

+Split DNS

+

Setting up different views, or visibility, of the DNS space to +internal and external resolvers is usually referred to as a Split +DNS setup. There are several reasons an organization +would want to set up its DNS this way.

+

One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy "attackers" can find the information -they need using other means.

Another common reason for setting up a Split DNS system is +they need using other means.

+

Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside -back in to the internal network.

Here is an example of a split DNS setup:

Let's say a company named Example, Inc. -(example.com) +back in to the internal network.

+

Here is an example of a split DNS setup:

+

Let's say a company named Example, Inc. +(example.com) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), -or "outside" section of a network, that is available to the public.

Example, Inc. wants its internal clients +or "outside" section of a network, that is available to the public.

+

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. The company also wants its internal resolvers to have access to certain internal-only zones that are not available -at all outside of the internal network.

In order to accomplish this, the company will set up two sets +at all outside of the internal network.

+

In order to accomplish this, the company will set up two sets of name servers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy" -hosts that can talk to both sides of its network, in the DMZ.

The internal servers will be configured to forward all queries, -except queries for site1.internal, site2.internal, site1.example.com, -and site2.example.com, to the servers in the +hosts that can talk to both sides of its network, in the DMZ.

+

The internal servers will be configured to forward all queries, +except queries for site1.internal, site2.internal, site1.example.com, +and site2.example.com, to the servers in the DMZ. These internal servers will have complete sets of information -for site1.example.com, site2.example.com, site1.internal, -and site2.internal.

To protect the site1.internal and site2.internal domains, +for site1.example.com, site2.example.com, site1.internal, +and site2.internal.

+

To protect the site1.internal and site2.internal domains, the internal name servers must be configured to disallow all queries to these domains from any external hosts, including the bastion -hosts.

The external servers, which are on the bastion hosts, will -be configured to serve the "public" version of the site1 and site2.example.com zones. +hosts.

+

The external servers, which are on the bastion hosts, will +be configured to serve the "public" version of the site1 and site2.example.com zones. This could include things such as the host records for public servers -(www.example.com and ftp.example.com), -and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).

In addition, the public site1 and site2.example.com zones +(www.example.com and ftp.example.com), +and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).

+

In addition, the public site1 and site2.example.com zones should have special MX records that contain wildcard (`*') records pointing to the bastion hosts. This is needed because external mail servers do not have any other way of looking up how to deliver mail to those internal hosts. With the wildcard records, the mail will be delivered to the bastion host, which can then forward it on to -internal hosts.

Here's an example of a wildcard MX record:

*   IN MX 10 external1.example.com.

Now that they accept mail on behalf of anything in the internal +internal hosts.

+

Here's an example of a wildcard MX record:

+
*   IN MX 10 external1.example.com.
+

Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on the bastion hosts will need to be configured to point to the internal -name servers for DNS resolution.

Queries for internal hostnames will be answered by the internal +name servers for DNS resolution.

+

Queries for internal hostnames will be answered by the internal servers, and queries for external hostnames will be forwarded back -out to the DNS servers on the bastion hosts.

In order for all this to work properly, internal clients will -need to be configured to query only the internal +out to the DNS servers on the bastion hosts.

+

In order for all this to work properly, internal clients will +need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective -filtering on the network.

If everything has been set properly, Example, Inc.'s -internal clients will now be able to:

  • Look up any hostnames in the site1 and -site2.example.com zones.

  • Look up any hostnames in the site1.internal and -site2.internal domains.

  • Look up any hostnames on the Internet.

  • Exchange mail with internal AND external people.

Hosts on the Internet will be able to:

  • Look up any hostnames in the site1 and -site2.example.com zones.

  • Exchange mail with anyone in the site1 and -site2.example.com zones.

Here is an example configuration for the setup we just +filtering on the network.

+

If everything has been set properly, Example, Inc.'s +internal clients will now be able to:

+
    +
  • Look up any hostnames in the site1 and +site2.example.com zones.
    • +
  • Look up any hostnames in the site1.internal and +site2.internal domains.
    • +
  • Look up any hostnames on the Internet.
    • +
  • Exchange mail with internal AND external people.
    • +
+

Hosts on the Internet will be able to:

+
    +
  • Look up any hostnames in the site1 and +site2.example.com zones.
    • +
  • Exchange mail with anyone in the site1 and +site2.example.com zones.
    • +
+

Here is an example configuration for the setup we just described above. Note that this is only configuration information; - for information on how to configure your zone files, see Section 3.1

Internal DNS server config:


+    for information on how to configure your zone files, see the section called “Sample Configurations”

+
Internal DNS server config:

+
+
 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 
-acl externals { bastion-ips-go-here; };
+acl externals { bastion-ips-go-here; };
 
 options {
     ...
     ...
     forward only;
     forwarders {                                // forward to external servers
-        bastion-ips-go-here; 
+        bastion-ips-go-here; 
     };
     allow-transfer { none; };                   // sample allow-transfer (no one)
     allow-query { internals; externals; };      // restrict query access
@@ -655,12 +310,10 @@ zone "site2.internal" {
   allow-query { internals };
   allow-transfer { internals; }
 };
-
External (bastion host) DNS server config:

acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+

+
External (bastion host) DNS server config:

+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 
 acl externals { bastion-ips-go-here; };
 
@@ -688,367 +341,147 @@ zone "site2.example.com" {
   allow-query { any; };
   allow-transfer { internals; externals; }
 };
-
In the resolv.conf (or equivalent) on
-the bastion host(s):

search ...
+

+
In the resolv.conf (or equivalent) on
+the bastion host(s):

+
+search ...
 nameserver 172.16.72.2
 nameserver 172.16.72.3
 nameserver 172.16.72.4
-

4.5. TSIG

This is a short guide to setting up Transaction SIGnatures -(TSIG) based transaction security in BIND. It describes changes + +

+
+

+TSIG

+

This is a short guide to setting up Transaction SIGnatures +(TSIG) based transaction security in BIND. It describes changes to the configuration file as well as what changes are required for different features, including the process of creating transaction -keys and using transaction signatures with BIND.

BIND primarily supports TSIG for server to server communication. +keys and using transaction signatures with BIND.

+

BIND primarily supports TSIG for server to server communication. This includes zone transfer, notify, and recursive query messages. -Resolvers based on newer versions of BIND 8 have limited support -for TSIG.

TSIG might be most useful for dynamic update. A primary +Resolvers based on newer versions of BIND 8 have limited support +for TSIG.

+

TSIG might be most useful for dynamic update. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient. The cryptographic access control provided by TSIG - is far superior. The nsupdate - program supports TSIG via the -k and - -y command line options.

4.5.1. Generate Shared Keys for Each Pair of Hosts

A shared secret is generated to be shared between host1 and host2. + is far superior. The nsupdate + program supports TSIG via the -k and + -y command line options.

+
+

+Generate Shared Keys for Each Pair of Hosts

+

A shared secret is generated to be shared between host1 and host2. An arbitrary key name is chosen: "host1-host2.". The key name must -be the same on both hosts.

4.5.1.1. Automatic Generation

The following command will generate a 128 bit (16 byte) HMAC-MD5 +be the same on both hosts.

+
+

+Automatic Generation

+

The following command will generate a 128 bit (16 byte) HMAC-MD5 key as described above. Longer keys are better, but shorter keys are easier to read. Note that the maximum key length is 512 bits; keys longer than that will be digested with MD5 to produce a 128 -bit key.

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.

The key is in the file Khost1-host2.+157+00000.private. +bit key.

+

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.

+

The key is in the file Khost1-host2.+157+00000.private. Nothing directly uses this file, but the base-64 encoded string -following "Key:" -can be extracted from the file and used as a shared secret:

Key: La/E5CjG9O+os1jq0a2jdA==

The string "La/E5CjG9O+os1jq0a2jdA==" can -be used as the shared secret.

4.5.1.2. Manual Generation

The shared secret is simply a random sequence of bits, encoded +following "Key:" +can be extracted from the file and used as a shared secret:

+
Key: La/E5CjG9O+os1jq0a2jdA==
+

The string "La/E5CjG9O+os1jq0a2jdA==" can +be used as the shared secret.

+
+
+

+Manual Generation

+

The shared secret is simply a random sequence of bits, encoded in base-64. Most ASCII strings are valid base-64 strings (assuming the length is a multiple of 4 and only valid characters are used), -so the shared secret can be manually generated.

Also, a known string can be run through mmencode or -a similar program to generate base-64 encoded data.

4.5.2. Copying the Shared Secret to Both Machines

This is beyond the scope of DNS. A secure transport mechanism -should be used. This could be secure FTP, ssh, telephone, etc.

4.5.3. Informing the Servers of the Key's Existence

Imagine host1 and host 2 are -both servers. The following is added to each server's named.conf file:


key host1-host2. {
+so the shared secret can be manually generated.

+
Also, a known string can be run through mmencode or
+a similar program to generate base-64 encoded data.

+
+
+
+

+Copying the Shared Secret to Both Machines

+

This is beyond the scope of DNS. A secure transport mechanism +should be used. This could be secure FTP, ssh, telephone, etc.

+
+
+

+Informing the Servers of the Key's Existence

+

Imagine host1 and host 2 are +both servers. The following is added to each server's named.conf file:

+
+key host1-host2. {
   algorithm hmac-md5;
   secret "La/E5CjG9O+os1jq0a2jdA==";
 };
-

The algorithm, hmac-md5, is the only one supported by BIND. + +

The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it -is recommended that either named.conf be non-world +is recommended that either named.conf be non-world readable, or the key directive be added to a non-world readable -file that is included by named.conf.

At this point, the key is recognized. This means that if the +file that is included by named.conf.

+

At this point, the key is recognized. This means that if the server receives a message signed by this key, it can verify the signature. If the signature is successfully verified, the -response is signed by the same key.

4.5.4. Instructing the Server to Use the Key

Since keys are shared between two hosts only, the server must -be told when keys are to be used. The following is added to the named.conf file -for host1, if the IP address of host2 is -10.1.2.3:


server 10.1.2.3 {
+response is signed by the same key.

+
+
+

+Instructing the Server to Use the Key

+

Since keys are shared between two hosts only, the server must +be told when keys are to be used. The following is added to the named.conf file +for host1, if the IP address of host2 is +10.1.2.3:

+
+server 10.1.2.3 {
   keys { host1-host2. ;};
 };
-

Multiple keys may be present, but only the first is used. + +

Multiple keys may be present, but only the first is used. This directive does not contain any secrets, so it may be in a world-readable -file.

If host1 sends a message that is a request -to that address, the message will be signed with the specified key. host1 will +file.

+

If host1 sends a message that is a request +to that address, the message will be signed with the specified key. host1 will expect any responses to signed messages to be signed with the same -key.

A similar statement must be present in host2's -configuration file (with host1's address) for host2 to -sign request messages to host1.

4.5.5. TSIG Key Based Access Control

BIND allows IP addresses and ranges to be specified in ACL +key.

+

A similar statement must be present in host2's +configuration file (with host1's address) for host2 to +sign request messages to host1.

+
+
+

+TSIG Key Based Access Control

+

BIND allows IP addresses and ranges to be specified in ACL definitions and -allow-{ query | transfer | update } directives. +allow-{ query | transfer | update } directives. This has been extended to allow TSIG keys also. The above key would -be denoted key host1-host2.

An example of an allow-update directive would be:


allow-update { key host1-host2. ;};
-

This allows dynamic updates to succeed only if the request +be denoted key host1-host2.

+

An example of an allow-update directive would be:

+
+allow-update { key host1-host2. ;};
+
+

This allows dynamic updates to succeed only if the request was signed by a key named - "host1-host2.".

You may want to read about the more - powerful update-policy statement in Section 6.2.24.4.

4.5.6. Errors

The processing of TSIG signed messages can result in + "host1-host2.".

+

You may want to read about the more + powerful update-policy statement in the section called “Dynamic Update Policies”.

+
+
+

+Errors

+

The processing of TSIG signed messages can result in several errors. If a signed message is sent to a non-TSIG aware server, a FORMERR will be returned, since the server will not understand the record. This is a result of misconfiguration, since the server must be explicitly configured to send a TSIG - signed message to a specific server.

If a TSIG aware server receives a message signed by an + signed message to a specific server.

+

If a TSIG aware server receives a message signed by an unknown key, the response will be unsigned with the TSIG extended error code set to BADKEY. If a TSIG aware server receives a message with a signature that does not validate, the @@ -1058,545 +491,226 @@ NAME="AEN923" the TSIG extended error code set to BADTIME, and the time values will be adjusted so that the response can be successfully verified. In any of these cases, the message's rcode is set to - NOTAUTH.

4.6. TKEY

TKEY is a mechanism for automatically + NOTAUTH.

+
+
+
+

+TKEY

+

TKEY is a mechanism for automatically generating a shared secret between two hosts. There are several - "modes" of TKEY that specify how the key is - generated or assigned. BIND 9 + "modes" of TKEY that specify how the key is + generated or assigned. BIND 9 implements only one of these modes, the Diffie-Hellman key exchange. Both hosts are required to have a Diffie-Hellman KEY record (although this record is not required - to be present in a zone). The TKEY process + to be present in a zone). The TKEY process must use signed messages, signed either by TSIG or SIG(0). The - result of TKEY is a shared secret that can be - used to sign messages with TSIG. TKEY can also + result of TKEY is a shared secret that can be + used to sign messages with TSIG. TKEY can also be used to delete shared secrets that it had previously - generated.

The TKEY process is initiated by a client - or server by sending a signed TKEY query + generated.

+

The TKEY process is initiated by a client + or server by sending a signed TKEY query (including any appropriate KEYs) to a TKEY-aware server. The server response, if it indicates success, will contain a - TKEY record and any appropriate keys. After + TKEY record and any appropriate keys. After this exchange, both participants have enough information to determine the shared secret; the exact process depends on the - TKEY mode. When using the Diffie-Hellman - TKEY mode, Diffie-Hellman keys are exchanged, - and the shared secret is derived by both participants.

4.7. SIG(0)

BIND 9 partially supports DNSSEC SIG(0) + TKEY mode. When using the Diffie-Hellman + TKEY mode, Diffie-Hellman keys are exchanged, + and the shared secret is derived by both participants.

+
+
+

+SIG(0)

+

BIND 9 partially supports DNSSEC SIG(0) transaction signatures as specified in RFC 2535 and RFC2931. SIG(0) uses public/private keys to authenticate messages. Access control is performed in the same manner as TSIG keys; privileges can be - granted or denied based on the key name.

When a SIG(0) signed message is received, it will only be + granted or denied based on the key name.

+

When a SIG(0) signed message is received, it will only be verified if the key is known and trusted by the server; the server - will not attempt to locate and/or validate the key.

SIG(0) signing of multiple-message TCP streams is not - supported.

The only tool shipped with BIND 9 that - generates SIG(0) signed messages is nsupdate.

4.8. DNSSEC

Cryptographic authentication of DNS information is possible - through the DNS Security (DNSSEC-bis) extensions, - defined in RFC <TBA>. This section describes the creation and use - of DNSSEC signed zones.

In order to set up a DNSSEC secure zone, there are a series - of steps which must be followed. BIND 9 ships + will not attempt to locate and/or validate the key.

+

SIG(0) signing of multiple-message TCP streams is not + supported.

+

The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate.

+
+
+

+DNSSEC

+

Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC <TBA>. This section describes the creation and use + of DNSSEC signed zones.

+

In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND 9 ships with several tools that are used in this process, which are explained in more detail - below. In all cases, the -h option prints a + below. In all cases, the -h option prints a full list of parameters. Note that the DNSSEC tools require the keyset files to be in the working directory or the - directory specified by the -h option, and + directory specified by the -h option, and that the tools shipped with BIND 9.2.x and earlier are not compatible - with the current ones.

There must also be communication with the administrators of + with the current ones.

+

There must also be communication with the administrators of the parent and/or child zone to transmit keys. A zone's security status must be indicated by the parent zone for a DNSSEC capable resolver to trust its data. This is done through the presense - or absence of a DS record at the delegation - point.

For other servers to trust data in this zone, they must + or absence of a DS record at the delegation + point.

+

For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the - zone key of another zone above this one in the DNS tree.

4.8.1. Generating Keys

The dnssec-keygen program is used to - generate keys.

A secure zone must contain one or more zone keys. The + zone key of another zone above this one in the DNS tree.

+
+

+Generating Keys

+

The dnssec-keygen program is used to + generate keys.

+

A secure zone must contain one or more zone keys. The zone keys will sign all other records in the zone, as well as the zone keys of any secure delegated zones. Zone keys must have the same name as the zone, a name type of - ZONE, and must be usable for authentication. + ZONE, and must be usable for authentication. It is recommended that zone keys use a cryptographic algorithm designated as "mandatory to implement" by the IETF; currently - the only one is RSASHA1.

The following command will generate a 768 bit RSASHA1 key for - the child.example zone:

dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.

Two output files will be produced: - Kchild.example.+005+12345.key and - Kchild.example.+005+12345.private (where + the only one is RSASHA1.

+

The following command will generate a 768 bit RSASHA1 key for + the child.example zone:

+

dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.

+

Two output files will be produced: + Kchild.example.+005+12345.key and + Kchild.example.+005+12345.private (where 12345 is an example of a key tag). The key file names contain - the key name (child.example.), algorithm (3 + the key name (child.example.), algorithm (3 is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case). - The private key (in the .private file) is + The private key (in the .private file) is used to generate signatures, and the public key (in the - .key file) is used for signature - verification.

To generate another key with the same properties (but with - a different key tag), repeat the above command.

The public keys should be inserted into the zone file by - including the .key files using - $INCLUDE statements. -

4.8.2. Signing the Zone

The dnssec-signzone program is used to - sign a zone.

Any keyset files corresponding + .key file) is used for signature + verification.

+

To generate another key with the same properties (but with + a different key tag), repeat the above command.

+

The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. +

+
+
+

+Signing the Zone

+

The dnssec-signzone program is used to + sign a zone.

+

Any keyset files corresponding to secure subzones should be present. The zone signer will - generate NSEC and RRSIG - records for the zone, as well as DS for - the child zones if '-d' is specified. - If '-d' is not specified then DS RRsets for - the secure child zones need to be added manually.

The following command signs the zone, assuming it is in a - file called zone.child.example. By + generate NSEC and RRSIG + records for the zone, as well as DS for + the child zones if '-d' is specified. + If '-d' is not specified then DS RRsets for + the secure child zones need to be added manually.

+

The following command signs the zone, assuming it is in a + file called zone.child.example. By default, all zone keys which have an available private key are - used to generate signatures.

dnssec-signzone -o child.example zone.child.example

One output file is produced: - zone.child.example.signed. This file - should be referenced by named.conf as the - input file for the zone.

dnssec-signzone will also produce a + used to generate signatures.

+

dnssec-signzone -o child.example zone.child.example

+

One output file is produced: + zone.child.example.signed. This file + should be referenced by named.conf as the + input file for the zone.

+

dnssec-signzone will also produce a keyset and dsset files and optionally a dlvset file. These are used to provide the parent zone administators with the - DNSKEYs (or their corresponding DS - records) that are the secure entry point to the zone.

4.8.3. Configuring Servers

Unlike BIND 8, -BIND 9 does not verify signatures on load, + DNSKEYs (or their corresponding DS + records) that are the secure entry point to the zone.

+
+
+

+Configuring Servers

+

Unlike BIND 8, +BIND 9 does not verify signatures on load, so zone keys for authoritative zones do not need to be specified -in the configuration file.

The public key for any security root must be present in -the configuration file's trusted-keys -statement, as described later in this document.

4.9. IPv6 Support in BIND 9

BIND 9 fully supports all currently defined forms of IPv6 +in the configuration file.

+

The public key for any security root must be present in +the configuration file's trusted-keys +statement, as described later in this document.

+
+
+
+

+IPv6 Support in BIND 9

+

BIND 9 fully supports all currently defined forms of IPv6 name to address and address to name lookups. It will also use IPv6 addresses to make queries when running on an IPv6 capable - system.

For forward lookups, BIND 9 supports only AAAA + system.

+

For forward lookups, BIND 9 supports only AAAA records. The use of A6 records is deprecated by RFC 3363, and the - support for forward lookups in BIND 9 is + support for forward lookups in BIND 9 is removed accordingly. - However, authoritative BIND 9 name servers still + However, authoritative BIND 9 name servers still load zone files containing A6 records correctly, answer queries for A6 records, and accept zone transfer for a zone containing A6 - records.

For IPv6 reverse lookups, BIND 9 supports + records.

+

For IPv6 reverse lookups, BIND 9 supports the traditional "nibble" format used in the - ip6.arpa domain, as well as the older, deprecated - ip6.int domain. - BIND 9 formerly + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + BIND 9 formerly supported the "binary label" (also known as "bitstring") format. The support of binary labels, however, is now completely removed according to the changes in RFC 3363. - Any applications in BIND 9 do not understand + Any applications in BIND 9 do not understand the format any more, and will return an error if given. - In particular, an authoritative BIND 9 name - server rejects to load a zone file containing binary labels.

For an overview of the format and structure of IPv6 addresses, - see Section A.2.1.

4.9.1. Address Lookups Using AAAA Records

The AAAA record is a parallel to the IPv4 A record. It + In particular, an authoritative BIND 9 name + server rejects to load a zone file containing binary labels.

+

For an overview of the format and structure of IPv6 addresses, + see the section called “IPv6 addresses (AAAA)”.

+
+

+Address Lookups Using AAAA Records

+

The AAAA record is a parallel to the IPv4 A record. It specifies the entire address in a single record. For - example,


$ORIGIN example.com.
+      example,

+
+$ORIGIN example.com.
 host            3600    IN      AAAA    2001:db8::1
-
It is recommended that IPv4-in-IPv6 mapped addresses not
+
+

It is recommended that IPv4-in-IPv6 mapped addresses not be used. If a host has an IPv4 address, use an A record, not - a AAAA, with ::ffff:192.168.42.1 as the - address.

4.9.2. Address to Name Lookups Using Nibble Format

When looking up an address in nibble format, the address + a AAAA, with ::ffff:192.168.42.1 as the + address.

+
+
+

+Address to Name Lookups Using Nibble Format

+

When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and - ip6.arpa. is appended to the resulting name. + ip6.arpa. is appended to the resulting name. For example, the following would provide reverse name lookup for a host with address - 2001:db8::1.


$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+      2001:db8::1.

+
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
-
PrevHomeNext
Name Server Configuration The BIND 9 Lightweight Resolver
\ No newline at end of file + +
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 3. Name Server Configuration Home Chapter 5. The BIND 9 Lightweight Resolver
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html index dd59488d938..1720660b65a 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch05.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch05.html @@ -1,265 +1,115 @@ - -The BIND 9 Lightweight Resolver
BIND 9 Administrator Reference Manual
PrevNext

Chapter 5. The BIND 9 Lightweight Resolver

5.1. The Lightweight Resolver Library

Traditionally applications have been linked with a stub resolver + + + + + +Chapter 5. The BIND 9 Lightweight Resolver + + + + + + + +

+ + + + + + + +
Chapter 5. The BIND 9 Lightweight Resolver
+Prev   Next +
+
+
+
+

+Chapter 5. The BIND 9 Lightweight Resolver

+
+

Table of Contents

+
+
The Lightweight Resolver Library
+
Running a Resolver Daemon
+
+
+
+

+The Lightweight Resolver Library

+

Traditionally applications have been linked with a stub resolver library that sends recursive DNS queries to a local caching name -server.

IPv6 once introduced new complexity into the resolution process, +server.

+

IPv6 once introduced new complexity into the resolution process, such as following A6 chains and DNAME records, and simultaneous lookup of IPv4 and IPv6 addresses. Though most of the complexity was then removed, these are hard or impossible -to implement in a traditional stub resolver.

Instead, BIND 9 provides resolution services to local clients +to implement in a traditional stub resolver.

+

Instead, BIND 9 provides resolution services to local clients using a combination of a lightweight resolver library and a resolver daemon process running on the local host. These communicate using a simple UDP-based protocol, the "lightweight resolver protocol" -that is distinct from and simpler than the full DNS protocol.

5.2. Running a Resolver Daemon

To use the lightweight resolver interface, the system must -run the resolver daemon lwresd or a local -name server configured with a lwres statement.

By default, applications using the lightweight resolver library will make +that is distinct from and simpler than the full DNS protocol.

+
+
+

+Running a Resolver Daemon

+

To use the lightweight resolver interface, the system must +run the resolver daemon lwresd or a local +name server configured with a lwres statement.

+

By default, applications using the lightweight resolver library will make UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The -address can be overridden by lwserver lines in -/etc/resolv.conf.

The daemon currently only looks in the DNS, but in the future -it may use other sources such as /etc/hosts, -NIS, etc.

The lwresd daemon is essentially a +address can be overridden by lwserver lines in +/etc/resolv.conf.

+

The daemon currently only looks in the DNS, but in the future +it may use other sources such as /etc/hosts, +NIS, etc.

+

The lwresd daemon is essentially a caching-only name server that responds to requests using the lightweight resolver protocol rather than the DNS protocol. Because it needs to run on each host, it is designed to require no or minimal configuration. Unless configured otherwise, it uses the name servers listed on -nameserver lines in /etc/resolv.conf +nameserver lines in /etc/resolv.conf as forwarders, but is also capable of doing the resolution autonomously if -none are specified.

The lwresd daemon may also be configured with a -named.conf style configuration file, in -/etc/lwresd.conf by default. A name server may also +none are specified.

+

The lwresd daemon may also be configured with a +named.conf style configuration file, in +/etc/lwresd.conf by default. A name server may also be configured to act as a lightweight resolver daemon using the -lwres statement in named.conf.

PrevHomeNext
Advanced DNS Features BIND 9 Configuration Reference
\ No newline at end of file +lwres statement in named.conf.

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 4. Advanced DNS Features Home Chapter 6. BIND 9 Configuration Reference
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html index 8cd4c7022db..4b5300069d1 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch06.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch06.html @@ -1,286 +1,148 @@ - -BIND 9 Configuration Reference
BIND 9 Administrator Reference Manual
PrevNext

Chapter 6. BIND 9 Configuration Reference

BIND 9 configuration is broadly similar -to BIND 8; however, there are a few new areas -of configuration, such as views. BIND -8 configuration files should work with few alterations in BIND + + + + + +Chapter 6. BIND 9 Configuration Reference + + + + + + + +

+ + + + + + + +
Chapter 6. BIND 9 Configuration Reference
+Prev   Next +
+
+
+
+

+Chapter 6. BIND 9 Configuration Reference

+
+

Table of Contents

+
+
Configuration File Elements
+
+
Address Match Lists
+
Comment Syntax
+
+
Configuration File Grammar
+
+
acl Statement Grammar
+
acl Statement Definition and +Usage
+
controls Statement Grammar
+
controls Statement Definition and Usage
+
include Statement Grammar
+
include Statement Definition and Usage
+
key Statement Grammar
+
key Statement Definition and Usage
+
logging Statement Grammar
+
logging Statement Definition and Usage
+
lwres Statement Grammar
+
lwres Statement Definition and Usage
+
masters Statement Grammar
+
masters Statement Definition and Usage
+
options Statement Grammar
+
options Statement Definition and Usage
+
server Statement Grammar
+
server Statement Definition and Usage
+
trusted-keys Statement Grammar
+
trusted-keys Statement Definition +and Usage
+
view Statement Grammar
+
view Statement Definition and Usage
+
zone +Statement Grammar
+
zone Statement Definition and Usage
+
+
Zone File
+
+
Types of Resource Records and When to Use Them
+
Discussion of MX Records
+
Setting TTLs
+
Inverse Mapping in IPv4
+
Other Zone File Directives
+
BIND Master File Extension: the $GENERATE Directive
+
+
+
+

BIND 9 configuration is broadly similar +to BIND 8; however, there are a few new areas +of configuration, such as views. BIND +8 configuration files should work with few alterations in BIND 9, although more complex configurations should be reviewed to check if they can be more efficiently implemented using the new features -found in BIND 9.

BIND 4 configuration files can be converted to the new format +found in BIND 9.

+

BIND 4 configuration files can be converted to the new format using the shell script -contrib/named-bootconf/named-bootconf.sh.

6.1. Configuration File Elements

Following is a list of elements used throughout the BIND configuration -file documentation:

+ + + + + + + + + + +

acl_name

The name of an address_match_list as -defined by the acl statement.

address_match_list

A list of one or more ip_addr, -ip_prefix, key_id, -or acl_name elements, see -Section 6.1.1.

domain_name

A quoted string which will be used as -a DNS name, for example "my.test.domain".

dotted_decimal

One to four integers valued 0 through -255 separated by dots (`.'), such as 123, -45.67 or 89.123.45.67.

ip4_addr

An IPv4 address with exactly four elements -in dotted_decimal notation.

ip6_addr

An IPv6 address, such as 2001:db8::1234. +contrib/named-bootconf/named-bootconf.sh.

+
+

+Configuration File Elements

+

Following is a list of elements used throughout the BIND configuration +file documentation:

+
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

acl_name

The name of an address_match_list as +defined by the acl statement.

address_match_list

A list of one or more ip_addr, +ip_prefix, key_id, +or acl_name elements, see +the section called “Address Match Lists”.

domain_name

A quoted string which will be used as +a DNS name, for example "my.test.domain".

dotted_decimal

One to four integers valued 0 through +255 separated by dots (`.'), such as 123, +45.67 or 89.123.45.67.

ip4_addr

An IPv4 address with exactly four elements +in dotted_decimal notation.

ip6_addr

An IPv6 address, such as 2001:db8::1234. IPv6 scoped addresses that have ambiguity on their scope zones must be disambiguated by an appropriate zone ID with the percent character (`%') as delimiter. @@ -290,2043 +152,677 @@ configuration changes. However, since there is no standard mapping for such names and identifier values, currently only interface names as link identifiers are supported, assuming one-to-one mapping between interfaces and links. -For example, a link-local address fe80::1 on the -link attached to the interface ne0 -can be specified as fe80::1%ne0. +For example, a link-local address fe80::1 on the +link attached to the interface ne0 +can be specified as fe80::1%ne0. Note that on most systems link-local addresses always have the -ambiguity, and need to be disambiguated.

ip_addr

An ip4_addr or ip6_addr.

ip_port

An IP port number. -number is limited to 0 through 65535, with values +ambiguity, and need to be disambiguated.

ip_addr

An ip4_addr or ip6_addr.

ip_port

An IP port number. +number is limited to 0 through 65535, with values below 1024 typically restricted to use by processes running as root. In some cases an asterisk (`*') character can be used as a placeholder to -select a random high-numbered port.

ip_prefix

An IP network specified as an ip_addr, +select a random high-numbered port.

ip_prefix

An IP network specified as an ip_addr, followed by a slash (`/') and then the number of bits in the netmask. -Trailing zeros in a ip_addr may omitted. -For example, 127/8 is the network 127.0.0.0 with -netmask 255.0.0.0 and 1.2.3.0/28 is -network 1.2.3.0 with netmask 255.255.255.240.

key_id

A domain_name representing -the name of a shared key, to be used for transaction security.

key_list

A list of one or more key_ids, -separated by semicolons and ending with a semicolon.

number

A non-negative 32 bit integer +Trailing zeros in a ip_addr may omitted. +For example, 127/8 is the network 127.0.0.0 with +netmask 255.0.0.0 and 1.2.3.0/28 is +network 1.2.3.0 with netmask 255.255.255.240.

key_id

A domain_name representing +the name of a shared key, to be used for transaction security.

key_list

A list of one or more key_ids, +separated by semicolons and ending with a semicolon.

number

A non-negative 32 bit integer (i.e., a number between 0 and 4294967295, inclusive). Its acceptable value might further -be limited by the context in which it is used.

path_name

A quoted string which will be used as -a pathname, such as zones/master/my.test.domain.

size_spec

A number, the word unlimited, -or the word default.

An unlimited size_spec requests unlimited -use, or the maximum available amount. A default size_spec uses -the limit that was in force when the server was started.

A number can -optionally be followed by a scaling factor: K or k for -kilobytes, M or m for -megabytes, and G or g for gigabytes, -which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.

-

The value must be representable as a 64-bit unsigned integer +be limited by the context in which it is used.

path_name

A quoted string which will be used as +a pathname, such as zones/master/my.test.domain.

size_spec

 +

A number, the word unlimited, +or the word default.

+

+An unlimited size_spec requests unlimited +use, or the maximum available amount. A default size_spec uses +the limit that was in force when the server was started.

+

A number can +optionally be followed by a scaling factor: K or k for +kilobytes, M or m for +megabytes, and G or g for gigabytes, +which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.

+

The value must be representable as a 64-bit unsigned integer (0 to 18446744073709551615, inclusive). -Using unlimited is the best way -to safely set a really large number.

yes_or_no

Either yes or no. -The words true and false are -also accepted, as are the numbers 1 and 0.

dialup_option

One of yes, -no, notify, -notify-passive, refresh or -passive. -When used in a zone, notify-passive, -refresh, and passive -are restricted to slave and stub zones.

6.1.1. Address Match Lists

6.1.1.1. Syntax

address_match_list = address_match_list_element ;
-  [ address_match_list_element; ... ]
-address_match_list_element = [ ! ] (ip_address [/length] |
+Using unlimited is the best way
+to safely set a really large number.

+

yes_or_no

Either yes or no. +The words true and false are +also accepted, as are the numbers 1 and 0.

dialup_option

One of yes, +no, notify, +notify-passive, refresh or +passive. +When used in a zone, notify-passive, +refresh, and passive +are restricted to slave and stub zones.

+
+

+Address Match Lists

+
+

+Syntax

+
address_match_list = address_match_list_element ;
+  [ address_match_list_element; ... ]
+address_match_list_element = [ ! ] (ip_address [/length] |
    key key_id | acl_name | { address_match_list } )
-

6.1.1.2. Definition and Usage

Address match lists are primarily used to determine access + +

+
+

+Definition and Usage

+

Address match lists are primarily used to determine access control for various server operations. They are also used in -the listen-on and sortlist +the listen-on and sortlist statements. The elements -which constitute an address match list can be any of the following:

  • an IP address (IPv4 or IPv6)

  • an IP prefix (in `/' notation)

  • a key ID, as defined by the key statement

  • the name of an address match list previously defined with -the acl statement

  • a nested address match list enclosed in braces

Elements can be negated with a leading exclamation mark (`!'), +which constitute an address match list can be any of the following:

+
    +
  • an IP address (IPv4 or IPv6)
    • +
  • an IP prefix (in `/' notation)
    • +
  • a key ID, as defined by the key statement
    • +
  • the name of an address match list defined with +the acl statement
    • +
  • a nested address match list enclosed in braces
    • +
+

Elements can be negated with a leading exclamation mark (`!'), and the match list names "any", "none", "localhost", and "localnets" are predefined. More information on those names can be found in -the description of the acl statement.

The addition of the key clause made the name of this syntactic +the description of the acl statement.

+

The addition of the key clause made the name of this syntactic element something of a misnomer, since security keys can be used to validate access without regard to a host or network address. Nonetheless, -the term "address match list" is still used throughout the documentation.

When a given IP address or prefix is compared to an address +the term "address match list" is still used throughout the documentation.

+

When a given IP address or prefix is compared to an address match list, the list is traversed in order until an element matches. The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports, or in a sortlist, -and whether the element was negated.

When used as an access control list, a non-negated match allows +and whether the element was negated.

+

When used as an access control list, a non-negated match allows access and a negated match denies access. If there is no match, -access is denied. The clauses allow-notify, -allow-query, allow-transfer, -allow-update, allow-update-forwarding, -and blackhole all +access is denied. The clauses allow-notify, +allow-query, allow-transfer, +allow-update, allow-update-forwarding, +and blackhole all use address match lists this. Similarly, the listen-on option will cause the server to not accept queries on any of the machine's addresses -which do not match the list.

Because of the first-match aspect of the algorithm, an element +which do not match the list.

+

Because of the first-match aspect of the algorithm, an element that defines a subset of another element in the list should come before the broader element, regardless of whether either is negated. For example, in -1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is +1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is completely useless because the algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 element. -Using ! 1.2.3.13; 1.2.3/24 fixes +Using ! 1.2.3.13; 1.2.3/24 fixes that problem by having 1.2.3.13 blocked by the negation but all -other 1.2.3.* hosts fall through.

6.1.2. Comment Syntax

The BIND 9 comment syntax allows for comments to appear -anywhere that white space may appear in a BIND configuration +other 1.2.3.* hosts fall through.

+
+
+
+

+Comment Syntax

+

The BIND 9 comment syntax allows for comments to appear +anywhere that white space may appear in a BIND configuration file. To appeal to programmers of all kinds, they can be written -in the C, C++, or shell/perl style.

6.1.2.1. Syntax

/* This is a BIND comment as in C */
-
// This is a BIND comment as in C++
-
# This is a BIND comment as in common UNIX shells and perl
-

6.1.2.2. Definition and Usage

Comments may appear anywhere that whitespace may appear in -a BIND configuration file.

C-style comments start with the two characters /* (slash, +in the C, C++, or shell/perl style.

+
+

+Syntax

+
/* This is a BIND comment as in C */
+

+

+
// This is a BIND comment as in C++
+

+

+
# This is a BIND comment as in common UNIX shells and perl
+

+

+
+
+

+Definition and Usage

+

Comments may appear anywhere that whitespace may appear in +a BIND configuration file.

+

C-style comments start with the two characters /* (slash, star) and end with */ (star, slash). Because they are completely delimited with these characters, they can be used to comment only -a portion of a line or to span multiple lines.

C-style comments cannot be nested. For example, the following -is not valid because the entire comment ends with the first */:

/* This is the start of a comment.
+a portion of a line or to span multiple lines.

+
C-style comments cannot be nested. For example, the following
+is not valid because the entire comment ends with the first */:

+
/* This is the start of a comment.
    This is still part of the comment.
 /* This is an incorrect attempt at nesting a comment. */
    This is no longer in any comment. */
-
C++-style comments start with the two characters // (slash,
+
+

C++-style comments start with the two characters // (slash, slash) and continue to the end of the physical line. They cannot be continued across multiple physical lines; to have one logical -comment span multiple lines, each line must use the // pair.

For example:

// This is the start of a comment.  The next line
+comment span multiple lines, each line must use the // pair.

+
For example:

+
// This is the start of a comment.  The next line
 // is a new comment, even though it is logically
 // part of the previous comment.
-
Shell-style (or perl-style, if you prefer) comments start
-with the character # (number sign) and continue to the end of the
-physical line, as in C++ comments.
For example:
# This is the start of a comment.  The next line
+

+
Shell-style (or perl-style, if you prefer) comments start
+with the character # (number sign) and continue to the end of the
+physical line, as in C++ comments.

+
For example:

+
# This is the start of a comment.  The next line
 # is a new comment, even though it is logically
 # part of the previous comment.
-

-
Warning
You cannot use the semicolon (`;') character
+
+

+

+

+
Warning

+
You cannot use the semicolon (`;') character
    to start a comment such as you would in a zone file. The
    semicolon indicates the end of a configuration
-   statement.

6.2. Configuration File Grammar

A BIND 9 configuration consists of statements and comments. + statement.

+
+
+
+ +
+

+Configuration File Grammar

+

A BIND 9 configuration consists of statements and comments. Statements end with a semicolon. Statements and comments are the only elements that can appear without enclosing braces. Many statements contain a block of sub-statements, which are also - terminated with a semicolon.

The following statements are supported:

acl

defines a named IP address -matching list, for access control and other uses.

controls

declares control channels to be used -by the rndc utility.

include

includes a file.

key

specifies key information for use in -authentication and authorization using TSIG.

logging

specifies what the server logs, and where -the log messages are sent.

lwres

configures named to -also act as a light weight resolver daemon (lwresd).

masters

defines a named masters list for -inclusion in stub and slave zone masters clauses.

options

controls global server configuration -options and sets defaults for other statements.

server

sets certain configuration options on -a per-server basis.

trusted-keys

defines trusted DNSSEC keys.

view

defines a view.

zone

defines a zone.

The logging and - options statements may only occur once per - configuration.

6.2.1. acl Statement Grammar

acl acl-name { 
+    terminated with a semicolon.

+
The following statements are supported:

+

++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+




acl
defines a named IP address
+matching list, for access control and other uses.
controls
declares control channels to be used
+by the rndc utility.
include
includes a file.
key
specifies key information for use in
+authentication and authorization using TSIG.
logging
specifies what the server logs, and where
+the log messages are sent.
lwres
configures named to
+also act as a light weight resolver daemon (lwresd).
masters
defines a named masters list for
+inclusion in stub and slave zone masters clauses.
options
controls global server configuration
+options and sets defaults for other statements.
server
sets certain configuration options on
+a per-server basis.
trusted-keys
defines trusted DNSSEC keys.
view
defines a view.
zone
defines a zone.

+
The logging and
+    options statements may only occur once per
+    configuration.

+

+

+acl Statement Grammar

+
acl acl-name { 
     address_match_list 
 };
-
6.2.2. acl Statement Definition and
-Usage
The acl statement assigns a symbolic
+
+
+
+

+acl Statement Definition and +Usage

+

The acl statement assigns a symbolic name to an address match list. It gets its name from a primary - use of address match lists: Access Control Lists (ACLs).

Note that an address match list's name must be defined - with acl before it can be used elsewhere; no - forward references are allowed.

The following ACLs are built-in:

+ + +

any

Matches all hosts.

none

Matches no hosts.

localhost

Matches the IPv4 and IPv6 addresses of all network -interfaces on the system.

localnets

Matches any host on an IPv4 or IPv6 network + use of address match lists: Access Control Lists (ACLs).

+

Note that an address match list's name must be defined + with acl before it can be used elsewhere; no + forward references are allowed.

+

The following ACLs are built-in:

+
++++ + + + + + + + + + + + + + + + +

any

Matches all hosts.

none

Matches no hosts.

localhost

Matches the IPv4 and IPv6 addresses of all network +interfaces on the system.

localnets

Matches any host on an IPv4 or IPv6 network for which the system has an interface. Some systems do not provide a way to determine the prefix lengths of local IPv6 addresses. -In such a case, localnets only matches the local -IPv6 addresses, just like localhost. -

6.2.3. controls Statement Grammar

controls {
-   inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
-                keys {  key_list  };
-   [ inet ...; ]
+In such a case, localnets only matches the local
+IPv6 addresses, just like localhost.
+
+
+
+

+controls Statement Grammar

+
controls {
+   inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
+                keys {  key_list  };
+   [ inet ...; ]
 };
-

6.2.4. controls Statement Definition and Usage

The controls statement declares control + +

+
+

+controls Statement Definition and Usage

+

The controls statement declares control channels to be used by system administrators to control the operation of the name server. These control channels are - used by the rndc utility to send commands to - and retrieve non-DNS results from a name server.

An inet control channel is a TCP + used by the rndc utility to send commands to + and retrieve non-DNS results from a name server.

+

An inet control channel is a TCP socket listening at the specified - ip_port on the specified - ip_addr, which can be an IPv4 or IPv6 - address. An ip_addr - of * is interpreted as the IPv4 wildcard + ip_port on the specified + ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr + of * is interpreted as the IPv4 wildcard address; connections will be accepted on any of the system's IPv4 addresses. To listen on the IPv6 wildcard address, - use an ip_addr of ::. - If you will only use rndc on the local host, - using the loopback address (127.0.0.1 - or ::1) is recommended for maximum + use an ip_addr of ::. + If you will only use rndc on the local host, + using the loopback address (127.0.0.1 + or ::1) is recommended for maximum security. -

If no port is specified, port 953 - is used. "*" cannot be used for - ip_port.

The ability to issue commands over the control channel is - restricted by the allow and - keys clauses. Connections to the control +

+

+ If no port is specified, port 953 + is used. "*" cannot be used for + ip_port.

+

The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. Connections to the control channel are permitted based on the - address_match_list. This is for simple - IP address based filtering only; any key_id - elements of the address_match_list are + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list are ignored. -

The primary authorization mechanism of the command - channel is the key_list, which contains - a list of key_ids. - Each key_id in - the key_list is authorized to execute +

+

The primary authorization mechanism of the command + channel is the key_list, which contains + a list of key_ids. + Each key_id in + the key_list is authorized to execute commands over the control channel. - See Remote Name Daemon Control application in - Section 3.3.1.2) for information about - configuring keys in rndc.

If no controls statement is present, -named will set up a default + See Remote Name Daemon Control application in + the section called “Administrative Tools”) for information about + configuring keys in rndc.

+

+If no controls statement is present, +named will set up a default control channel listening on the loopback address 127.0.0.1 and its IPv6 counterpart ::1. -In this case, and also when the controls statement -is present but does not have a keys clause, -named will attempt to load the command channel key -from the file rndc.key in -/etc (or whatever sysconfdir -was specified as when BIND was built). -To create a rndc.key file, run -rndc-confgen -a. -

The rndc.key feature was created to - ease the transition of systems from BIND 8, +In this case, and also when the controls statement +is present but does not have a keys clause, +named will attempt to load the command channel key +from the file rndc.key in +/etc (or whatever sysconfdir +was specified as when BIND was built). +To create a rndc.key file, run +rndc-confgen -a. +

+

The rndc.key feature was created to + ease the transition of systems from BIND 8, which did not have digital signatures on its command channel messages - and thus did not have a keys clause. + and thus did not have a keys clause. -It makes it possible to use an existing BIND 8 -configuration file in BIND 9 unchanged, -and still have rndc work the same way -ndc worked in BIND 8, simply by executing the -command rndc-confgen -a after BIND 9 is +It makes it possible to use an existing BIND 8 +configuration file in BIND 9 unchanged, +and still have rndc work the same way +ndc worked in BIND 8, simply by executing the +command rndc-confgen -a after BIND 9 is installed. -

Since the rndc.key feature +

+

+ Since the rndc.key feature is only intended to allow the backward-compatible usage of - BIND 8 configuration files, this feature does not + BIND 8 configuration files, this feature does not have a high degree of configurability. You cannot easily change the key name or the size of the secret, so you should make a - rndc.conf with your own key if you wish to change - those things. The rndc.key file also has its + rndc.conf with your own key if you wish to change + those things. The rndc.key file also has its permissions set such that only the owner of the file (the user that - named is running as) can access it. If you + named is running as) can access it. If you desire greater flexibility in allowing other users to access - rndc commands then you need to create an - rndc.conf and make it group readable by a group - that contains the users who should have access.

The UNIX control channel type of BIND 8 is not supported - in BIND 9, and is not expected to be added in future + rndc commands then you need to create an + rndc.conf and make it group readable by a group + that contains the users who should have access.

+

The UNIX control channel type of BIND 8 is not supported + in BIND 9, and is not expected to be added in future releases. If it is present in the controls statement from a - BIND 8 configuration file, it is ignored - and a warning is logged.

To disable the command channel, use an empty controls -statement: controls { };. -

6.2.6. include Statement Definition and Usage

The include statement inserts the - specified file at the point where the include - statement is encountered. The include + BIND 8 configuration file, it is ignored + and a warning is logged.

+

+To disable the command channel, use an empty controls +statement: controls { };. +

+
+
+

+include Statement Grammar

+
include filename;
+
+
+

+include Statement Definition and Usage

+

The include statement inserts the + specified file at the point where the include + statement is encountered. The include statement facilitates the administration of configuration files by permitting the reading or writing of some things but not others. For example, the statement could include private keys - that are readable only by the name server.

6.2.7. key Statement Grammar

key key_id {
-    algorithm string;
-    secret string;
+      that are readable only by the name server.

+
+
+

+key Statement Grammar

+
key key_id {
+    algorithm string;
+    secret string;
 };
-

6.2.8. key Statement Definition and Usage

The key statement defines a shared -secret key for use with TSIG (see Section 4.5) + +

+
+

+key Statement Definition and Usage

+

The key statement defines a shared +secret key for use with TSIG (see the section called “TSIG”) or the command channel -(see Section 6.2.4). -

The key statement can occur at the top level -of the configuration file or inside a view -statement. Keys defined in top-level key +(see the section called “controls Statement Definition and Usage”). +

+

+The key statement can occur at the top level +of the configuration file or inside a view +statement. Keys defined in top-level key statements can be used in all views. Keys intended for use in -a controls statement -(see Section 6.2.4) +a controls statement +(see the section called “controls Statement Definition and Usage”) must be defined at the top level. -

The key_id, also known as the +

+

The key_id, also known as the key name, is a domain name uniquely identifying the key. It can -be used in a server +be used in a server statement to cause requests sent to that server to be signed with this key, or in address match lists to verify that incoming requests have been signed with a key -matching this name, algorithm, and secret.

The algorithm_id is a string +matching this name, algorithm, and secret.

+

The algorithm_id is a string that specifies a security/authentication algorithm. The only algorithm currently supported with TSIG authentication is -hmac-md5. The -secret_string is the secret to be +hmac-md5. The +secret_string is the secret to be used by the algorithm, and is treated as a base-64 encoded -string.

6.2.9. logging Statement Grammar

logging {
-   [ channel channel_name {
-     ( file path name
-         [ versions ( number | unlimited ) ]
-         [ size size spec ]
-       | syslog syslog_facility
-       | stderr
-       | null );
-     [ severity (critical | error | warning | notice |
-                 info | debug [ level ] | dynamic ); ]
-     [ print-category yes or no; ]
-     [ print-severity yes or no; ]
-     [ print-time yes or no; ]
+string.

+
+
+

+logging Statement Grammar

+
logging {
+   [ channel channel_name {
+     ( file path name
+         [ versions ( number | unlimited ) ]
+         [ size size spec ]
+       | syslog syslog_facility
+       | stderr
+       | null );
+     [ severity (critical | error | warning | notice |
+                 info | debug [ level ] | dynamic ); ]
+     [ print-category yes or no; ]
+     [ print-severity yes or no; ]
+     [ print-time yes or no; ]
    }; ]
-   [ category category_name {
-     channel_name ; [ channel_name ; ... ]
+   [ category category_name {
+     channel_name ; [ channel_name ; ... ]
    }; ]
    ...
 };
-

6.2.10. logging Statement Definition and Usage

The logging statement configures a wide -variety of logging options for the name server. Its channel phrase + +

+
+

+logging Statement Definition and Usage

+

The logging statement configures a wide +variety of logging options for the name server. Its channel phrase associates output methods, format options and severity levels with -a name that can then be used with the category phrase -to select how various classes of messages are logged.

Only one logging statement is used to define -as many channels and categories as are wanted. If there is no logging statement, -the logging configuration will be:

logging {
+a name that can then be used with the category phrase
+to select how various classes of messages are logged.

+
Only one logging statement is used to define
+as many channels and categories as are wanted. If there is no logging statement,
+the logging configuration will be:

+
logging {
      category default { default_syslog; default_debug; };
      category unmatched { null; };
 };
-
In BIND 9, the logging configuration is only established when
-the entire configuration file has been parsed.  In BIND 8, it was
-established as soon as the logging statement
+
+

In BIND 9, the logging configuration is only established when +the entire configuration file has been parsed. In BIND 8, it was +established as soon as the logging statement was parsed. When the server is starting up, all logging messages regarding syntax errors in the configuration file go to the default -channels, or to standard error if the "-g" option -was specified.

6.2.10.1. The channel Phrase

All log output goes to one or more channels; -you can make as many of them as you want.

Every channel definition must include a destination clause that +channels, or to standard error if the "-g" option +was specified.

+
+

+The channel Phrase

+

All log output goes to one or more channels; +you can make as many of them as you want.

+

Every channel definition must include a destination clause that says whether messages selected for the channel go to a file, to a particular syslog facility, to the standard error stream, or are discarded. It can optionally also limit the message severity level that will be accepted by the channel (the default is -info), and whether to include a -named-generated time stamp, the category name -and/or severity level (the default is not to include any).

The null destination clause +info), and whether to include a +named-generated time stamp, the category name +and/or severity level (the default is not to include any).

+

The null destination clause causes all messages sent to the channel to be discarded; -in that case, other options for the channel are meaningless.

The file destination clause directs the channel +in that case, other options for the channel are meaningless.

+

The file destination clause directs the channel to a disk file. It can include limitations both on how large the file is allowed to become, and how many versions -of the file will be saved each time the file is opened.

If you use the versions log file option, then -named will retain that many backup versions of the file by +of the file will be saved each time the file is opened.

+

If you use the versions log file option, then +named will retain that many backup versions of the file by renaming them when opening. For example, if you choose to keep 3 old versions -of the file lamers.log then just before it is opened -lamers.log.1 is renamed to -lamers.log.2, lamers.log.0 is renamed -to lamers.log.1, and lamers.log is -renamed to lamers.log.0. -You can say versions unlimited to not limit +of the file lamers.log then just before it is opened +lamers.log.1 is renamed to +lamers.log.2, lamers.log.0 is renamed +to lamers.log.1, and lamers.log is +renamed to lamers.log.0. +You can say versions unlimited to not limit the number of versions. -If a size option is associated with the log file, +If a size option is associated with the log file, then renaming is only done when the file being opened exceeds the indicated size. No backup versions are kept by default; any existing -log file is simply appended.

The size option for files is used to limit log -growth. If the file ever exceeds the size, then named will -stop writing to the file unless it has a versions option +log file is simply appended.

+

The size option for files is used to limit log +growth. If the file ever exceeds the size, then named will +stop writing to the file unless it has a versions option associated with it. If backup versions are kept, the files are rolled as described above and a new one begun. If there is no -versions option, no more data will be written to the log +versions option, no more data will be written to the log until some out-of-band mechanism removes or truncates the log to less than the maximum size. The default behavior is not to limit the size of the -file.

Example usage of the size and -versions options:

channel an_example_channel {
+file.

+
Example usage of the size and
+versions options:

+
channel an_example_channel {
     file "example.log" versions 3 size 20m;
     print-time yes;
     print-category yes;
 };
-
The syslog destination clause directs the
+
+

The syslog destination clause directs the channel to the system log. Its argument is a -syslog facility as described in the syslog man -page. Known facilities are kern, user, -mail, daemon, auth, -syslog, lpr, news, -uucp, cron, authpriv, -ftp, local0, local1, -local2, local3, local4, -local5, local6 and -local7, however not all facilities are supported on +syslog facility as described in the syslog man +page. Known facilities are kern, user, +mail, daemon, auth, +syslog, lpr, news, +uucp, cron, authpriv, +ftp, local0, local1, +local2, local3, local4, +local5, local6 and +local7, however not all facilities are supported on all operating systems. -How syslog will handle messages sent to -this facility is described in the syslog.conf man -page. If you have a system which uses a very old version of syslog that -only uses two arguments to the openlog() function, -then this clause is silently ignored.

The severity clause works like syslog's +How syslog will handle messages sent to +this facility is described in the syslog.conf man +page. If you have a system which uses a very old version of syslog that +only uses two arguments to the openlog() function, +then this clause is silently ignored.

+

The severity clause works like syslog's "priorities", except that they can also be used if you are writing -straight to a file rather than using syslog. +straight to a file rather than using syslog. Messages which are not at least of the severity level given will not be selected for the channel; messages of higher severity levels -will be accepted.

If you are using syslog, then the syslog.conf priorities +will be accepted.

+

If you are using syslog, then the syslog.conf priorities will also determine what eventually passes through. For example, -defining a channel facility and severity as daemon and debug but -only logging daemon.warning via syslog.conf will -cause messages of severity info and notice to -be dropped. If the situation were reversed, with named writing -messages of only warning or higher, then syslogd would -print all messages it received from the channel.

The stderr destination clause directs the +defining a channel facility and severity as daemon and debug but +only logging daemon.warning via syslog.conf will +cause messages of severity info and notice to +be dropped. If the situation were reversed, with named writing +messages of only warning or higher, then syslogd would +print all messages it received from the channel.

+

The stderr destination clause directs the channel to the server's standard error stream. This is intended for use when the server is running as a foreground process, for example -when debugging a configuration.

The server can supply extensive debugging information when +when debugging a configuration.

+

The server can supply extensive debugging information when it is in debugging mode. If the server's global debug level is greater than zero, then debugging mode will be active. The global debug -level is set either by starting the named server -with the -d flag followed by a positive integer, -or by running rndc trace. +level is set either by starting the named server +with the -d flag followed by a positive integer, +or by running rndc trace. The global debug level -can be set to zero, and debugging mode turned off, by running ndc -notrace. All debugging messages in the server have a debug +can be set to zero, and debugging mode turned off, by running ndc +notrace. All debugging messages in the server have a debug level, and higher debug levels give more detailed output. Channels -that specify a specific debug severity, for example:

channel specific_debug_level {
+that specify a specific debug severity, for example:

+
channel specific_debug_level {
     file "foo";
     severity debug 3;
 };
-
will get debugging output of level 3 or less any time the
+
+

will get debugging output of level 3 or less any time the server is in debugging mode, regardless of the global debugging -level. Channels with dynamic severity use the -server's global debug level to determine what messages to print.

If print-time has been turned on, then -the date and time will be logged. print-time may -be specified for a syslog channel, but is usually -pointless since syslog also prints the date and -time. If print-category is requested, then the -category of the message will be logged as well. Finally, if print-severity is -on, then the severity level of the message will be logged. The print- options may +level. Channels with dynamic severity use the +server's global debug level to determine what messages to print.

+

If print-time has been turned on, then +the date and time will be logged. print-time may +be specified for a syslog channel, but is usually +pointless since syslog also prints the date and +time. If print-category is requested, then the +category of the message will be logged as well. Finally, if print-severity is +on, then the severity level of the message will be logged. The print- options may be used in any combination, and will always be printed in the following -order: time, category, severity. Here is an example where all three print- options -are on:

28-Feb-2000 15:05:32.863 general: notice: running

There are four predefined channels that are used for -named's default logging as follows. How they are -used is described in Section 6.2.10.2. -

channel default_syslog {
+order: time, category, severity. Here is an example where all three print- options
+are on:

+
28-Feb-2000 15:05:32.863 general: notice: running

+
There are four predefined channels that are used for
+named's default logging as follows. How they are
+used is described in the section called “The category Phrase”.
+

+
channel default_syslog {
     syslog daemon;                      // send to syslog's daemon
                                         // facility
     severity info;                      // only send priority info
@@ -2354,78 +850,37 @@ channel null {
    null;                                // toss anything sent to
                                         // this channel
 };
-
The default_debug channel has the special
+
+

The default_debug channel has the special property that it only produces output when the server's debug level is -nonzero. It normally writes to a file named.run -in the server's working directory.

For security reasons, when the "-u" -command line option is used, the named.run file -is created only after named has changed to the -new UID, and any debug output generated while named is +nonzero. It normally writes to a file named.run +in the server's working directory.

+

For security reasons, when the "-u" +command line option is used, the named.run file +is created only after named has changed to the +new UID, and any debug output generated while named is starting up and still running as root is discarded. If you need -to capture this output, you must run the server with the "-g" -option and redirect standard error to a file.

Once a channel is defined, it cannot be redefined. Thus you +to capture this output, you must run the server with the "-g" +option and redirect standard error to a file.

+

Once a channel is defined, it cannot be redefined. Thus you cannot alter the built-in channels directly, but you can modify -the default logging by pointing categories at channels you have defined.

6.2.10.2. The category Phrase

There are many categories, so you can send the logs you want +the default logging by pointing categories at channels you have defined.

+
+
+

+The category Phrase

+

There are many categories, so you can send the logs you want to see wherever you want, without seeing logs you don't want. If you don't specify a list of channels for a category, then log messages -in that category will be sent to the default category +in that category will be sent to the default category instead. If you don't specify a default category, the following -"default default" is used:

category default { default_syslog; default_debug; };
-

As an example, let's say you want to log security events to +"default default" is used:

+
category default { default_syslog; default_debug; };
+
+

As an example, let's say you want to log security events to a file, but you also want keep the default logging behavior. You'd -specify the following:

channel my_security_channel {
+specify the following:

+
channel my_security_channel {
     file "my_security_file";
     severity info;
 };
@@ -2433,2691 +888,690 @@ category security {
     my_security_channel;
     default_syslog;
     default_debug;
-};
To discard all messages in a category, specify the null channel:
category xfer-out { null; };
+};

+
To discard all messages in a category, specify the null channel:

+
category xfer-out { null; };
 category notify { null; };
-
Following are the available categories and brief descriptions
+
+

Following are the available categories and brief descriptions of the types of log information they contain. More -categories may be added in future BIND releases.

+ + +

default

The default category defines the logging +categories may be added in future BIND releases.

+
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

default

The default category defines the logging options for those categories where no specific configuration has been -defined.

general

The catch-all. Many things still aren't -classified into categories, and they all end up here.

database

Messages relating to the databases used -internally by the name server to store zone and cache data.

security

Approval and denial of requests.

config

Configuration file parsing and processing.

resolver

DNS resolution, such as the recursive -lookups performed on behalf of clients by a caching name server.

xfer-in

Zone transfers the server is receiving.

xfer-out

Zone transfers the server is sending.

notify

The NOTIFY protocol.

client

Processing of client requests.

unmatched

Messages that named was unable to determine the -class of or for which there was no matching view. -A one line summary is also logged to the client category. +defined.

general

The catch-all. Many things still aren't +classified into categories, and they all end up here.

database

Messages relating to the databases used +internally by the name server to store zone and cache data.

security

Approval and denial of requests.

config

Configuration file parsing and processing.

resolver

DNS resolution, such as the recursive +lookups performed on behalf of clients by a caching name server.

xfer-in

Zone transfers the server is receiving.

xfer-out

Zone transfers the server is sending.

notify

The NOTIFY protocol.

client

Processing of client requests.

unmatched

Messages that named was unable to determine the +class of or for which there was no matching view. +A one line summary is also logged to the client category. This category is best sent to a file or stderr, by default it is sent to -the null channel.

network

Network operations.

update

Dynamic updates.

update-security

Approval and denial of update requests.

queries

Specify where queries should be logged to.

-

At startup, specifing the category queries will also -enable query logging unless querylog option has been +the null channel.

network

Network operations.

update

Dynamic updates.

update-security

Approval and denial of update requests.

queries

 +

Specify where queries should be logged to.

+

+At startup, specifing the category queries will also +enable query logging unless querylog option has been specified. -

-

The query log entry reports the client's IP address and port number. The +

+

+The query log entry reports the client's IP address and port number. The query name, class and type. It also reports whether the Recursion Desired flag was set (+ if set, - if not set), EDNS was in use (E) or if the -query was signed (S).

-
client 127.0.0.1#62536: query: www.example.com IN AAAA +SE
-client ::1#62537: query: www.example.net IN AAAA -SE
-
-

dispatch

Dispatching of incoming packets to the +query was signed (S).

+

client 127.0.0.1#62536: query: www.example.com IN AAAA +SE +

+

client ::1#62537: query: www.example.net IN AAAA -SE +

+

dispatch

Dispatching of incoming packets to the server modules where they are to be processed. -

dnssec

DNSSEC and TSIG protocol processing. -

lame-servers

Lame servers. These are misconfigurations +

dnssec

DNSSEC and TSIG protocol processing. +

lame-servers

Lame servers. These are misconfigurations in remote servers, discovered by BIND 9 when trying to query those servers during resolution. -

delegation-only

Delegation only. Logs queries that have have +

delegation-only

Delegation only. Logs queries that have have been forced to NXDOMAIN as the result of a delegation-only zone or -a delegation-only in a hint or stub zone declaration. -

6.2.11. lwres Statement Grammar

This is the grammar of the lwres -statement in the named.conf file:

lwres {
-    [ listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
-    [ view view_name; ]
-    [ search { domain_name ; [ domain_name ; ... ] }; ]
-    [ ndots number; ]
+a delegation-only in a hint or stub zone declaration.
+
+
+
+
+

+lwres Statement Grammar

+

This is the grammar of the lwres +statement in the named.conf file:

+
lwres {
+    [ listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ view view_name; ]
+    [ search { domain_name ; [ domain_name ; ... ] }; ]
+    [ ndots number; ]
 };
-

6.2.12. lwres Statement Definition and Usage

The lwres statement configures the name + +

+
+

+lwres Statement Definition and Usage

+

The lwres statement configures the name server to also act as a lightweight resolver server, see -Section 5.2. There may be be multiple -lwres statements configuring -lightweight resolver servers with different properties.

The listen-on statement specifies a list of +the section called “Running a Resolver Daemon”. There may be be multiple +lwres statements configuring +lightweight resolver servers with different properties.

+

The listen-on statement specifies a list of addresses (and ports) that this instance of a lightweight resolver daemon should accept requests on. If no port is specified, port 921 is used. If this statement is omitted, requests will be accepted on 127.0.0.1, -port 921.

The view statement binds this instance of a +port 921.

+

The view statement binds this instance of a lightweight resolver daemon to a view in the DNS namespace, so that the response will be constructed in the same manner as a normal DNS query matching this view. If this statement is omitted, the default view is -used, and if there is no default view, an error is triggered.

The search statement is equivalent to the -search statement in -/etc/resolv.conf. It provides a list of domains -which are appended to relative names in queries.

The ndots statement is equivalent to the -ndots statement in -/etc/resolv.conf. It indicates the minimum +used, and if there is no default view, an error is triggered.

+

The search statement is equivalent to the +search statement in +/etc/resolv.conf. It provides a list of domains +which are appended to relative names in queries.

+

The ndots statement is equivalent to the +ndots statement in +/etc/resolv.conf. It indicates the minimum number of dots in a relative domain name that should result in an -exact match lookup before search path elements are appended.

6.2.13. masters Statement Grammar


masters name [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; 
-

6.2.14. masters Statement Definition and Usage

masters lists allow for a common set of masters -to be easily used by multiple stub and slave zones.

6.2.15. options Statement Grammar

This is the grammar of the options -statement in the named.conf file:

options {
-    [ version version_string; ]
-    [ hostname hostname_string; ]
-    [ server-id server_id_string; ]
-    [ directory path_name; ]
-    [ key-directory path_name; ]
-    [ named-xfer path_name; ]
-    [ tkey-domain domainname; ]
-    [ tkey-dhkey key_name key_tag; ]
-    [ dump-file path_name; ]
-    [ memstatistics-file path_name; ]
-    [ pid-file path_name; ]
-    [ statistics-file path_name; ]
-    [ zone-statistics yes_or_no; ]
-    [ auth-nxdomain yes_or_no; ]
-    [ deallocate-on-exit yes_or_no; ]
-    [ dialup dialup_option; ]
-    [ fake-iquery yes_or_no; ]
-    [ fetch-glue yes_or_no; ]
-    [ flush-zones-on-shutdown yes_or_no; ]
-    [ has-old-clients yes_or_no; ]
-    [ host-statistics yes_or_no; ]
-    [ host-statistics-max number; ]
-    [ minimal-responses yes_or_no; ]
-    [ multiple-cnames yes_or_no; ]
-    [ notify yes_or_no | explicit; ]
-    [ recursion yes_or_no; ]
-    [ rfc2308-type1 yes_or_no; ]
-    [ use-id-pool yes_or_no; ]
-    [ maintain-ixfr-base yes_or_no; ]
-    [ dnssec-enable yes_or_no; ]
-    [ dnssec-lookaside domain trust-anchor domain; ]
-    [ dnssec-must-be-secure domain yes_or_no; ]
-    [ forward ( only | first ); ]
-    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
-    [ dual-stack-servers [port ip_port] { ( domain_name [port ip_port] | ip_addr [port ip_port] ) ; ... }; ]
-    [ check-names ( master | slave | response )( warn | fail | ignore ); ]
-    [ allow-notify { address_match_list }; ]
-    [ allow-query { address_match_list }; ]
-    [ allow-transfer { address_match_list }; ]
-    [ allow-recursion { address_match_list }; ]
-    [ allow-update-forwarding { address_match_list }; ]
-    [ allow-v6-synthesis { address_match_list }; ]
-    [ blackhole { address_match_list }; ]
-    [ avoid-v4-udp-ports { port_list }; ]
-    [ avoid-v6-udp-ports { port_list }; ]
-    [ listen-on [ port ip_port ] { address_match_list }; ]
-    [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
-    [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
-    [ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
-    [ max-transfer-time-in number; ]
-    [ max-transfer-time-out number; ]
-    [ max-transfer-idle-in number; ]
-    [ max-transfer-idle-out number; ]
-    [ tcp-clients number; ]
-    [ recursive-clients number; ]
-    [ serial-query-rate number; ]
-    [ serial-queries number; ]
-    [ tcp-listen-queue number; ]
-    [ transfer-format ( one-answer | many-answers ); ]
-    [ transfers-in  number; ]
-    [ transfers-out number; ]
-    [ transfers-per-ns number; ]
-    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
-    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
-    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ use-alt-transfer-source yes_or_no; ]
-    [ notify-source (ip4_addr | *) [port ip_port] ; ]
-    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
-    [ max-ixfr-log-size number; ]
-    [ max-journal-size size_spec; ]
-    [ coresize size_spec ; ]
-    [ datasize size_spec ; ]
-    [ files size_spec ; ]
-    [ stacksize size_spec ; ]
-    [ cleaning-interval number; ]
-    [ heartbeat-interval number; ]
-    [ interface-interval number; ]
-    [ statistics-interval number; ]
-    [ topology { address_match_list }];
-    [ sortlist { address_match_list }];
-    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
-    [ lame-ttl number; ]
-    [ max-ncache-ttl number; ]
-    [ max-cache-ttl number; ]
-    [ sig-validity-interval number ; ]
-    [ min-roots number; ]
-    [ use-ixfr yes_or_no ; ]
-    [ provide-ixfr yes_or_no; ]
-    [ request-ixfr yes_or_no; ]
-    [ treat-cr-as-space yes_or_no ; ]
-    [ min-refresh-time number ; ]
-    [ max-refresh-time number ; ]
-    [ min-retry-time number ; ]
-    [ max-retry-time number ; ]
-    [ port ip_port; ]
-    [ additional-from-auth yes_or_no ; ]
-    [ additional-from-cache yes_or_no ; ]
-    [ random-device path_name ; ]
-    [ max-cache-size size_spec ; ]
-    [ match-mapped-addresses yes_or_no; ]
-    [ preferred-glue ( A | AAAA | NONE ); ]
-    [ edns-udp-size number; ]
-    [ root-delegation-only [ exclude { namelist } ] ; ]
-    [ querylog yes_or_no ; ]
-    [ disable-algorithms domain { algorithm; [ algorithm; ] }; ]
+exact match lookup before search path elements are appended.

+
+
+

+masters Statement Grammar

+
+masters name [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; 
+
+
+
+

+masters Statement Definition and Usage

+

masters lists allow for a common set of masters +to be easily used by multiple stub and slave zones.

+
+
+

+options Statement Grammar

+

This is the grammar of the options +statement in the named.conf file:

+
options {
+    [ version version_string; ]
+    [ hostname hostname_string; ]
+    [ server-id server_id_string; ]
+    [ directory path_name; ]
+    [ key-directory path_name; ]
+    [ named-xfer path_name; ]
+    [ tkey-domain domainname; ]
+    [ tkey-dhkey key_name key_tag; ]
+    [ dump-file path_name; ]
+    [ memstatistics-file path_name; ]
+    [ pid-file path_name; ]
+    [ statistics-file path_name; ]
+    [ zone-statistics yes_or_no; ]
+    [ auth-nxdomain yes_or_no; ]
+    [ deallocate-on-exit yes_or_no; ]
+    [ dialup dialup_option; ]
+    [ fake-iquery yes_or_no; ]
+    [ fetch-glue yes_or_no; ]
+    [ flush-zones-on-shutdown yes_or_no; ]
+    [ has-old-clients yes_or_no; ]
+    [ host-statistics yes_or_no; ]
+    [ host-statistics-max number; ]
+    [ minimal-responses yes_or_no; ]
+    [ multiple-cnames yes_or_no; ]
+    [ notify yes_or_no | explicit; ]
+    [ recursion yes_or_no; ]
+    [ rfc2308-type1 yes_or_no; ]
+    [ use-id-pool yes_or_no; ]
+    [ maintain-ixfr-base yes_or_no; ]
+    [ dnssec-enable yes_or_no; ]
+    [ dnssec-lookaside domain trust-anchor domain; ]
+    [ dnssec-must-be-secure domain yes_or_no; ]
+    [ forward ( only | first ); ]
+    [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
+    [ dual-stack-servers [port ip_port] { ( domain_name [port ip_port] | ip_addr [port ip_port] ) ; ... }; ]
+    [ check-names ( master | slave | response )( warn | fail | ignore ); ]
+    [ allow-notify { address_match_list }; ]
+    [ allow-query { address_match_list }; ]
+    [ allow-transfer { address_match_list }; ]
+    [ allow-recursion { address_match_list }; ]
+    [ allow-update-forwarding { address_match_list }; ]
+    [ allow-v6-synthesis { address_match_list }; ]
+    [ blackhole { address_match_list }; ]
+    [ avoid-v4-udp-ports { port_list }; ]
+    [ avoid-v6-udp-ports { port_list }; ]
+    [ listen-on [ port ip_port ] { address_match_list }; ]
+    [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
+    [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ max-transfer-time-in number; ]
+    [ max-transfer-time-out number; ]
+    [ max-transfer-idle-in number; ]
+    [ max-transfer-idle-out number; ]
+    [ tcp-clients number; ]
+    [ recursive-clients number; ]
+    [ serial-query-rate number; ]
+    [ serial-queries number; ]
+    [ tcp-listen-queue number; ]
+    [ transfer-format ( one-answer | many-answers ); ]
+    [ transfers-in  number; ]
+    [ transfers-out number; ]
+    [ transfers-per-ns number; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ max-ixfr-log-size number; ]
+    [ max-journal-size size_spec; ]
+    [ coresize size_spec ; ]
+    [ datasize size_spec ; ]
+    [ files size_spec ; ]
+    [ stacksize size_spec ; ]
+    [ cleaning-interval number; ]
+    [ heartbeat-interval number; ]
+    [ interface-interval number; ]
+    [ statistics-interval number; ]
+    [ topology { address_match_list }];
+    [ sortlist { address_match_list }];
+    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
+    [ lame-ttl number; ]
+    [ max-ncache-ttl number; ]
+    [ max-cache-ttl number; ]
+    [ sig-validity-interval number ; ]
+    [ min-roots number; ]
+    [ use-ixfr yes_or_no ; ]
+    [ provide-ixfr yes_or_no; ]
+    [ request-ixfr yes_or_no; ]
+    [ treat-cr-as-space yes_or_no ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ port ip_port; ]
+    [ additional-from-auth yes_or_no ; ]
+    [ additional-from-cache yes_or_no ; ]
+    [ random-device path_name ; ]
+    [ max-cache-size size_spec ; ]
+    [ match-mapped-addresses yes_or_no; ]
+    [ preferred-glue ( A | AAAA | NONE ); ]
+    [ edns-udp-size number; ]
+    [ root-delegation-only [ exclude { namelist } ] ; ]
+    [ querylog yes_or_no ; ]
+    [ disable-algorithms domain { algorithm; [ algorithm; ] }; ]
 };
-

6.2.16. options Statement Definition and Usage

The options statement sets up global options -to be used by BIND. This statement may appear only -once in a configuration file. If there is no options + +

+
+

+options Statement Definition and Usage

+

The options statement sets up global options +to be used by BIND. This statement may appear only +once in a configuration file. If there is no options statement, an options block with each option set to its default will -be used.

directory

The working directory of the server. +be used.

+
+
directory
+

The working directory of the server. Any non-absolute pathnames in the configuration file will be taken as relative to this directory. The default location for most server -output files (e.g. named.run) is this directory. +output files (e.g. named.run) is this directory. If a directory is not specified, the working directory defaults -to `.', the directory from which the server -was started. The directory specified should be an absolute path.

key-directory

When performing dynamic update of secure zones, the +to `.', the directory from which the server +was started. The directory specified should be an absolute path.

+
key-directory
+

When performing dynamic update of secure zones, the directory where the public and private key files should be found, if different than the current working directory. The directory specified -must be an absolute path.

named-xfer

This option is obsolete. -It was used in BIND 8 to -specify the pathname to the named-xfer program. -In BIND 9, no separate named-xfer program is -needed; its functionality is built into the name server.

tkey-domain

The domain appended to the names of all -shared keys generated with TKEY. When a client -requests a TKEY exchange, it may or may not specify +must be an absolute path.

+
named-xfer
+

This option is obsolete. +It was used in BIND 8 to +specify the pathname to the named-xfer program. +In BIND 9, no separate named-xfer program is +needed; its functionality is built into the name server.

+
tkey-domain
+

The domain appended to the names of all +shared keys generated with TKEY. When a client +requests a TKEY exchange, it may or may not specify the desired name for the key. If present, the name of the shared -key will be "client specified part" + -"tkey-domain". -Otherwise, the name of the shared key will be "random hex -digits" + "tkey-domain". In most cases, -the domainname should be the server's domain -name.

tkey-dhkey

The Diffie-Hellman key used by the server +key will be "client specified part" + +"tkey-domain". +Otherwise, the name of the shared key will be "random hex +digits" + "tkey-domain". In most cases, +the domainname should be the server's domain +name.

+
tkey-dhkey
+

The Diffie-Hellman key used by the server to generate shared keys with clients using the Diffie-Hellman mode -of TKEY. The server must be able to load the +of TKEY. The server must be able to load the public and private keys from files in the working directory. In -most cases, the keyname should be the server's host name.

dump-file

The pathname of the file the server dumps +most cases, the keyname should be the server's host name.

+
dump-file
+

The pathname of the file the server dumps the database to when instructed to do so with -rndc dumpdb. -If not specified, the default is named_dump.db.

memstatistics-file

The pathname of the file the server writes memory +rndc dumpdb. +If not specified, the default is named_dump.db.

+
memstatistics-file
+

The pathname of the file the server writes memory usage statistics to on exit. If not specified, -the default is named.memstats.

pid-file

The pathname of the file the server writes its process ID -in. If not specified, the default is /var/run/named.pid. +the default is named.memstats.

+
pid-file
+

The pathname of the file the server writes its process ID +in. If not specified, the default is /var/run/named.pid. The pid-file is used by programs that want to send signals to the running -name server. Specifying pid-file none disables the +name server. Specifying pid-file none disables the use of a PID file — no file will be written and any -existing one will be removed. Note that none +existing one will be removed. Note that none is a keyword, not a file name, and therefore is not enclosed in -double quotes.

statistics-file

The pathname of the file the server appends statistics -to when instructed to do so using rndc stats. -If not specified, the default is named.stats in the +double quotes.

+
statistics-file
+

The pathname of the file the server appends statistics +to when instructed to do so using rndc stats. +If not specified, the default is named.stats in the server's current directory. The format of the file is described -in Section 6.2.16.17

port

The UDP/TCP port number the server uses for +in the section called “The Statistics File”

+
port
+

+The UDP/TCP port number the server uses for receiving and sending DNS protocol traffic. The default is 53. This option is mainly intended for server testing; a server using a port other than 53 will not be able to communicate with the global DNS. -

random-device

The source of entropy to be used by the server. Entropy is primarily needed +

+
random-device
+

+The source of entropy to be used by the server. Entropy is primarily needed for DNSSEC operations, such as TKEY transactions and dynamic update of signed zones. This options specifies the device (or file) from which to read entropy. If this is a file, operations requiring entropy will fail when the file has been exhausted. If not specified, the default value is -/dev/random +/dev/random (or equivalent) when present, and none otherwise. The -random-device option takes effect during +random-device option takes effect during the initial configuration load at server startup time and -is ignored on subsequent reloads.

preferred-glue

If specified the listed type (A or AAAA) will be emitted before other glue +is ignored on subsequent reloads.

+
preferred-glue
+

+If specified the listed type (A or AAAA) will be emitted before other glue in the additional section of a query response. The default is not to preference any type (NONE). -

root-delegation-only

Turn on enforcement of delegation-only in TLDs and root zones with an optional +

+
root-delegation-only
+
+

+Turn on enforcement of delegation-only in TLDs and root zones with an optional exclude list. -

Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). -


options {
+

+

+Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
+

+
+options {
 	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
 };
-
disable-algorithms

Disable the specified DNSSEC algorithms at and below the specified name. -Multiple disable-algorithms statements are allowed. + +

+
disable-algorithms
+

+Disable the specified DNSSEC algorithms at and below the specified name. +Multiple disable-algorithms statements are allowed. Only the most specific will be applied. -

dnssec-lookaside

When set dnssec-lookaside provides the +

+
dnssec-lookaside
+

+When set dnssec-lookaside provides the validator with an alternate method to validate DNSKEY records at the top of a zone. When a DNSKEY is at or below a domain specified by the -deepest dnssec-lookaside, and the normal dnssec validation +deepest dnssec-lookaside, and the normal dnssec validation has left the key untrusted, the trust-anchor will be append to the key name and a DLV record will be looked up to see if it can validate the key. If the DLV record validates a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted. -

dnssec-must-be-secure

Specify heirachies which must / may not be secure (signed and validated). -If yes then named will only accept answers if they +

+
dnssec-must-be-secure
+

+Specify heirarchies which must / may not be secure (signed and validated). +If yes then named will only accept answers if they are secure. -If no then normal dnssec validation applies +If no then normal dnssec validation applies allowing for insecure answers to be accepted. -The specified domain must be under a trusted-key or -dnssec-lookaside must be active. -

6.2.16.1. Boolean Options

auth-nxdomain

If yes, then the AA bit +The specified domain must be under a trusted-key or +dnssec-lookaside must be active. +

+
+
+

+Boolean Options

+
+
auth-nxdomain
+

If yes, then the AA bit is always set on NXDOMAIN responses, even if the server is not actually -authoritative. The default is no; this is -a change from BIND 8. If you are using very old DNS software, you -may need to set it to yes.

deallocate-on-exit

This option was used in BIND 8 to enable checking -for memory leaks on exit. BIND 9 ignores the option and always performs -the checks.

dialup

If yes, then the +authoritative. The default is no; this is +a change from BIND 8. If you are using very old DNS software, you +may need to set it to yes.

+
deallocate-on-exit
+

This option was used in BIND 8 to enable checking +for memory leaks on exit. BIND 9 ignores the option and always performs +the checks.

+
dialup
+
+

If yes, then the server treats all zones as if they are doing zone transfers across a dial on demand dialup link, which can be brought up by traffic originating from this server. This has different effects according to zone type and concentrates the zone maintenance so that it all -happens in a short interval, once every heartbeat-interval and +happens in a short interval, once every heartbeat-interval and hopefully during the one call. It also suppresses some of the normal -zone maintenance traffic. The default is no.

The dialup option -may also be specified in the view and -zone statements, -in which case it overrides the global dialup -option.

If the zone is a master zone then the server will send out a NOTIFY +zone maintenance traffic. The default is no.

+

The dialup option +may also be specified in the view and +zone statements, +in which case it overrides the global dialup +option.

+

If the zone is a master zone then the server will send out a NOTIFY request to all the slaves (default). This should trigger the zone serial number check in the slave (providing it supports NOTIFY) allowing the slave to verify the zone while the connection is active. The set of servers to which NOTIFY is sent can be controlled by -notify and also-notify.

If the +notify and also-notify.

+

If the zone is a slave or stub zone, then the server will suppress the regular "zone up to date" (refresh) queries and only perform them when the -heartbeat-interval expires in addition to sending -NOTIFY requests.

Finer control can be achieved by using -notify which only sends NOTIFY messages, -notify-passive which sends NOTIFY messages and -suppresses the normal refresh queries, refresh +heartbeat-interval expires in addition to sending +NOTIFY requests.

+

Finer control can be achieved by using +notify which only sends NOTIFY messages, +notify-passive which sends NOTIFY messages and +suppresses the normal refresh queries, refresh which suppresses normal refresh processing and sends refresh queries -when the heartbeat-interval expires, and -passive which just disables normal refresh -processing.

dialup mode

normal refresh

heart-beat refresh

heart-beat notify

no (default)

yes

no

no

yes

no

yes

yes

notify

yes

no

yes

refresh

no

yes

no

passive

no

no

no

notify-passive

no

no

yes

Note that normal NOTIFY processing is not affected by -dialup.

fake-iquery

In BIND 8, this option +when the heartbeat-interval expires, and +passive which just disables normal refresh +processing.

+
++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

dialup mode

normal refresh

heart-beat refresh

heart-beat notify

no (default)

yes

no

no

yes

no

yes

yes

notify

yes

no

yes

refresh

no

yes

no

passive

no

no

no

notify-passive

no

no

yes

+

Note that normal NOTIFY processing is not affected by +dialup.

+
+
fake-iquery
+

In BIND 8, this option enabled simulating the obsolete DNS query type -IQUERY. BIND 9 never does IQUERY simulation. -

fetch-glue

This option is obsolete. -In BIND 8, fetch-glue yes +IQUERY. BIND 9 never does IQUERY simulation. +

+
fetch-glue
+

This option is obsolete. +In BIND 8, fetch-glue yes caused the server to attempt to fetch glue resource records it didn't have when constructing the additional data section of a response. This is now considered a bad idea -and BIND 9 never does it.

flush-zones-on-shutdown

When the nameserver exits due receiving SIGTERM, +and BIND 9 never does it.

+
flush-zones-on-shutdown
+

When the nameserver exits due receiving SIGTERM, flush / do not flush any pending zone writes. The default is -flush-zones-on-shutdown no. -

has-old-clients

This option was incorrectly implemented -in BIND 8, and is ignored by BIND 9. +flush-zones-on-shutdown no. +

+
has-old-clients
+

This option was incorrectly implemented +in BIND 8, and is ignored by BIND 9. To achieve the intended effect of -has-old-clients yes, specify -the two separate options auth-nxdomain yes -and rfc2308-type1 no instead. -

host-statistics

In BIND 8, this enables keeping of +has-old-clients yes, specify +the two separate options auth-nxdomain yes +and rfc2308-type1 no instead. +

+
host-statistics
+

In BIND 8, this enables keeping of statistics for every host that the name server interacts with. Not implemented in BIND 9. -

maintain-ixfr-base

This option is obsolete. - It was used in BIND 8 to determine whether a transaction log was -kept for Incremental Zone Transfer. BIND 9 maintains a transaction +

+
maintain-ixfr-base
+

This option is obsolete. + It was used in BIND 8 to determine whether a transaction log was +kept for Incremental Zone Transfer. BIND 9 maintains a transaction log whenever possible. If you need to disable outgoing incremental zone -transfers, use provide-ixfr no. -

minimal-responses

If yes, then when generating +transfers, use provide-ixfr no. +

+
minimal-responses
+

If yes, then when generating responses the server will only add records to the authority and additional data sections when they are required (e.g. delegations, negative responses). This may improve the performance of the server. -The default is no. -

multiple-cnames

This option was used in BIND 8 to allow +The default is no. +

+
multiple-cnames
+

This option was used in BIND 8 to allow a domain name to have multiple CNAME records in violation of the -DNS standards. BIND 9.2 always strictly +DNS standards. BIND 9.2 always strictly enforces the CNAME rules both in master files and dynamic updates. -

notify

If yes (the default), +

+
notify
+
+

If yes (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for -changes, see Section 4.1. The messages are sent to the +changes, see the section called “Notify”. The messages are sent to the servers listed in the zone's NS records (except the master server identified in the SOA MNAME field), and to any servers listed in the -also-notify option. -

If explicit, notifies are sent only to -servers explicitly listed using also-notify. -If no, no notifies are sent. -

The notify option may also be -specified in the zone statement, -in which case it overrides the options notify statement. +also-notify option. +

+

+If explicit, notifies are sent only to +servers explicitly listed using also-notify. +If no, no notifies are sent. +

+

+The notify option may also be +specified in the zone statement, +in which case it overrides the options notify statement. It would only be necessary to turn off this option if it caused slaves -to crash.

recursion

If yes, and a +to crash.

+
+
recursion
+

If yes, and a DNS query requests recursion, then the server will attempt to do all the work required to answer the query. If recursion is off and the server does not already know the answer, it will return a -referral response. The default is yes. -Note that setting recursion no does not prevent +referral response. The default is yes. +Note that setting recursion no does not prevent clients from getting data from the server's cache; it only prevents new data from being cached as an effect of client queries. Caching may still occur as an effect the server's internal operation, such as NOTIFY address lookups. -See also fetch-glue above. -

rfc2308-type1

Setting this to yes will +See also fetch-glue above. +

+
rfc2308-type1
+
+

Setting this to yes will cause the server to send NS records along with the SOA record for negative -answers. The default is no.

Note: Not yet implemented in BIND 9.

use-id-pool

This option is obsolete. -BIND 9 always allocates query IDs from a pool. -

zone-statistics

If yes, the server will collect +answers. The default is no.

+
+

Note

+

Not yet implemented in BIND 9.

+
+
+
use-id-pool
+

This option is obsolete. +BIND 9 always allocates query IDs from a pool. +

+
zone-statistics
+

If yes, the server will collect statistical data on all zones (unless specifically turned off -on a per-zone basis by specifying zone-statistics no -in the zone statement). These statistics may be accessed -using rndc stats, which will dump them to the file listed -in the statistics-file. See also Section 6.2.16.17. -

use-ixfr

This option is obsolete. +on a per-zone basis by specifying zone-statistics no +in the zone statement). These statistics may be accessed +using rndc stats, which will dump them to the file listed +in the statistics-file. See also the section called “The Statistics File”. +

+
use-ixfr
+

This option is obsolete. If you need to disable IXFR to a particular server or servers see -the information on the provide-ixfr option -in Section 6.2.18. See also -Section 4.3. -

provide-ixfr

See the description of -provide-ixfr in -Section 6.2.18 -

request-ixfr

See the description of -request-ixfr in -Section 6.2.18 -

treat-cr-as-space

This option was used in BIND 8 to make -the server treat carriage return ("\r") characters the same way +the information on the provide-ixfr option +in the section called “server Statement Definition and Usage”. See also +the section called “Incremental Zone Transfers (IXFR)”. +

+
provide-ixfr
+

+See the description of +provide-ixfr in +the section called “server Statement Definition and Usage” +

+
request-ixfr
+

+See the description of +request-ixfr in +the section called “server Statement Definition and Usage” +

+
treat-cr-as-space
+

This option was used in BIND 8 to make +the server treat carriage return ("\r") characters the same way as a space or tab character, to facilitate loading of zone files on a UNIX system that were generated -on an NT or DOS machine. In BIND 9, both UNIX "\n" -and NT/DOS "\r\n" newlines are always accepted, -and the option is ignored.

additional-from-auth, additional-from-cache

These options control the behavior of an authoritative server when +on an NT or DOS machine. In BIND 9, both UNIX "\n" +and NT/DOS "\r\n" newlines are always accepted, +and the option is ignored.

+
+additional-from-auth, additional-from-cache +
+
+

+These options control the behavior of an authoritative server when answering queries which have additional data, or when following CNAME and DNAME chains. -

When both of these options are set to yes +

+

+When both of these options are set to yes (the default) and a query is being answered from authoritative data (a zone configured into the server), the additional data section of the @@ -5129,76 +1583,43 @@ untrusted third parties. Also, avoiding the search for this additional data will speed up server operations at the possible expense of additional queries to resolve what would otherwise be provided in the additional section. -

For example, if a query asks for an MX record for host foo.example.com, -and the record found is "MX 10 mail.example.net", normally the address -records (A and AAAA) for mail.example.net will be provided as well, +

+

+For example, if a query asks for an MX record for host foo.example.com, +and the record found is "MX 10 mail.example.net", normally the address +records (A and AAAA) for mail.example.net will be provided as well, if known, even though they are not in the example.com zone. -Setting these options to no disables this behavior and makes +Setting these options to no disables this behavior and makes the server only search for additional data in the zone it answers from. -

These options are intended for use in authoritative-only +

+

+These options are intended for use in authoritative-only servers, or in authoritative-only views. Attempts to set -them to no without also specifying -recursion no will cause the server to +them to no without also specifying +recursion no will cause the server to ignore the options and log a warning message. -

Specifying additional-from-cache no actually +

+

+Specifying additional-from-cache no actually disables the use of the cache not only for additional data lookups but also when looking up the answer. This is usually the desired behavior in an authoritative-only server where the correctness of the cached data is an issue. -

When a name server is non-recursively queried for a name that is not +

+

+When a name server is non-recursively queried for a name that is not below the apex of any served zone, it normally answers with an "upwards referral" to the root servers or the servers of some other known parent of the query name. Since the data in an upwards referral comes from the cache, the server will not be able to provide upwards -referrals when additional-from-cache no +referrals when additional-from-cache no has been specified. Instead, it will respond to such queries with REFUSED. This should not cause any problems since upwards referrals are not required for the resolution process. -

match-mapped-addresses

If yes, then an +

+
+
match-mapped-addresses
+

If yes, then an IPv4-mapped IPv6 address will match any address match list entries that match the corresponding IPv4 address. Enabling this option is sometimes useful on IPv6-enabled Linux @@ -5207,25 +1628,20 @@ TCP connections such as zone transfers to be accepted on an IPv6 socket using mapped addresses, causing address match lists designed for IPv4 to fail to match. The use of this option for any other purpose is discouraged. -

ixfr-from-differences

When 'yes' and the server loads a new version of a master +

+
ixfr-from-differences
+
+

+When 'yes' and the server loads a new version of a master zone from its zone file or receives a new version of a slave file by a non-incremental zone transfer, it will compare the new version to the previous one and calculate a set of differences. The differences are then logged in the zone's journal file such that the changes can be transmitted to downstream slaves as an incremental zone transfer. -

By allowing incremental zone transfers to be used for +

+

+By allowing incremental zone transfers to be used for non-dynamic zones, this option saves bandwidth at the expense of increased CPU and memory consumption at the master. In particular, if the new version of a zone is completely @@ -5234,1096 +1650,422 @@ will be of a size comparable to the combined size of the old and new zone version, and the server will need to temporarily allocate memory to hold this complete difference set. -

multi-master

This should be set when you have multiple masters for a zone and the +

+
+
multi-master
+

+This should be set when you have multiple masters for a zone and the addresses refer to different machines. If 'yes' named will not log when the serial number on the master is less than what named currently -has. The default is no. -

dnssec-enable

Enable DNSSEC support in named. Unless set to yes +has. The default is no. +

+
dnssec-enable
+

+Enable DNSSEC support in named. Unless set to yes named behaves as if it does not support DNSSEC. -The default is no. -

querylog

Specify whether query logging should be started when named start. -If querylog is not specified then the query logging -is determined by the presence of the logging category queries. -

check-names

This option is used to restrict the character set and syntax of +The default is no. +

+
querylog
+

+Specify whether query logging should be started when named start. +If querylog is not specified then the query logging +is determined by the presence of the logging category queries. +

+
check-names
+
+

+This option is used to restrict the character set and syntax of certain domain names in master files and/or DNS responses received from the network. The default varies according to usage area. For -master zones the default is fail. -For slave zones the default is warn. -For answer received from the network (response) -the default is ignore. -

The rules for legal hostnames / mail domains are derived from RFC 952 +master zones the default is fail. +For slave zones the default is warn. +For answer received from the network (response) +the default is ignore. +

+

The rules for legal hostnames / mail domains are derived from RFC 952 and RFC 821 as modified by RFC 1123. -

check-names applies to the owner names of A, AAA and +

+

check-names applies to the owner names of A, AAA and MX records. It also applies to the domain names in the RDATA of NS, SOA and MX records. It also applies to the RDATA of PTR records where the owner name indicated that it is a reverse lookup of a hostname (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, IP6.INT). -

6.2.16.2. Forwarding

The forwarding facility can be used to create a large site-wide +

+
+
+
+
+

+Forwarding

+

The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external name servers. It can also be used to allow queries by servers that do not have direct access to the Internet, but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in -its cache.

forward

This option is only meaningful if the -forwarders list is not empty. A value of first, +its cache.

+
+
forward
+

This option is only meaningful if the +forwarders list is not empty. A value of first, the default, causes the server to query the forwarders first, and if that doesn't answer the question the server will then look for -the answer itself. If only is specified, the +the answer itself. If only is specified, the server will only query the forwarders. -

forwarders

Specifies the IP addresses to be used +

+
forwarders
+

Specifies the IP addresses to be used for forwarding. The default is the empty list (no forwarding). -

Forwarding can also be configured on a per-domain basis, allowing +

+
+

Forwarding can also be configured on a per-domain basis, allowing for the global forwarding options to be overridden in a variety of ways. You can set particular domains to use different forwarders, -or have a different forward only/first behavior, -or not forward at all, see Section 6.2.23.

6.2.16.3. Dual-stack Servers

Dual-stack servers are used as servers of last resort to work around +or have a different forward only/first behavior, +or not forward at all, see the section called “zone +Statement Grammar”.

+
+
+

+Dual-stack Servers

+

Dual-stack servers are used as servers of last resort to work around problems in reachability due the lack of support for either IPv4 or IPv6 -on the host machine.

dual-stack-servers

Specifies host names / addresses of machines with access to +on the host machine.

+
+
dual-stack-servers
+

Specifies host names / addresses of machines with access to both IPv4 and IPv6 transports. If a hostname is used the server must be able to resolve the name using only the transport it has. If the machine is dual -stacked then the dual-stack-servers have no effect unless +stacked then the dual-stack-servers have no effect unless access to a transport has been disabled on the command line -(e.g. named -4).

6.2.16.4. Access Control

Access to the server can be restricted based on the IP address -of the requesting system. See Section 6.1.1 for -details on how to specify IP address lists.

allow-notify

Specifies which hosts are allowed to +(e.g. named -4).

+
+
+
+

+Access Control

+

Access to the server can be restricted based on the IP address +of the requesting system. See the section called “Address Match Lists” for +details on how to specify IP address lists.

+
+
allow-notify
+

Specifies which hosts are allowed to notify this server, a slave, of zone changes in addition to the zone masters. -allow-notify may also be specified in the -zone statement, in which case it overrides the -options allow-notify statement. It is only meaningful +allow-notify may also be specified in the +zone statement, in which case it overrides the +options allow-notify statement. It is only meaningful for a slave zone. If not specified, the default is to process notify messages -only from a zone's master.

allow-query

Specifies which hosts are allowed to -ask ordinary DNS questions. allow-query may also -be specified in the zone statement, in which -case it overrides the options allow-query statement. If -not specified, the default is to allow queries from all hosts.

allow-recursion

Specifies which hosts are allowed to +only from a zone's master.

+
allow-query
+

Specifies which hosts are allowed to +ask ordinary DNS questions. allow-query may also +be specified in the zone statement, in which +case it overrides the options allow-query statement. If +not specified, the default is to allow queries from all hosts.

+
allow-recursion
+

Specifies which hosts are allowed to make recursive queries through this server. If not specified, the default is to allow recursive queries from all hosts. Note that disallowing recursive queries for a host does not prevent the host from retrieving data that is already in the server's cache. -

allow-update-forwarding

Specifies which hosts are allowed to +

+
allow-update-forwarding
+
+

Specifies which hosts are allowed to submit Dynamic DNS updates to slave zones to be forwarded to the -master. The default is { none; }, which +master. The default is { none; }, which means that no update forwarding will be performed. To enable update forwarding, specify -allow-update-forwarding { any; };. -Specifying values other than { none; } or -{ any; } is usually counterproductive, since +allow-update-forwarding { any; };. +Specifying values other than { none; } or +{ any; } is usually counterproductive, since the responsibility for update access control should rest with the -master server, not the slaves.

Note that enabling the update forwarding feature on a slave server +master server, not the slaves.

+

Note that enabling the update forwarding feature on a slave server may expose master servers relying on insecure IP address based -access control to attacks; see Section 7.3 -for more details.

allow-v6-synthesis

This option was introduced for the smooth transition from AAAA +access control to attacks; see the section called “Dynamic Update Security” +for more details.

+
+
allow-v6-synthesis
+

This option was introduced for the smooth transition from AAAA to A6 and from "nibble labels" to binary labels. However, since both A6 and binary labels were then deprecated, this option was also deprecated. It is now ignored with some warning messages. -

allow-transfer

Specifies which hosts are allowed to -receive zone transfers from the server. allow-transfer may -also be specified in the zone statement, in which -case it overrides the options allow-transfer statement. -If not specified, the default is to allow transfers to all hosts.

blackhole

Specifies a list of addresses that the +

+
allow-transfer
+

Specifies which hosts are allowed to +receive zone transfers from the server. allow-transfer may +also be specified in the zone statement, in which +case it overrides the options allow-transfer statement. +If not specified, the default is to allow transfers to all hosts.

+
blackhole
+

Specifies a list of addresses that the server will not accept queries from or use to resolve a query. Queries -from these addresses will not be responded to. The default is none.

6.2.16.5. Interfaces

The interfaces and ports that the server will answer queries -from may be specified using the listen-on option. listen-on takes -an optional port, and an address_match_list. +from these addresses will not be responded to. The default is none.

+
+
+
+

+Interfaces

+

The interfaces and ports that the server will answer queries +from may be specified using the listen-on option. listen-on takes +an optional port, and an address_match_list. The server will listen on all interfaces allowed by the address -match list. If a port is not specified, port 53 will be used.

Multiple listen-on statements are allowed. -For example,

listen-on { 5.6.7.8; };
+match list. If a port is not specified, port 53 will be used.

+
Multiple listen-on statements are allowed.
+For example,

+
listen-on { 5.6.7.8; };
 listen-on port 1234 { !1.2.3.4; 1.2/16; };
-
will enable the name server on port 53 for the IP address
+
+

will enable the name server on port 53 for the IP address 5.6.7.8, and on port 1234 of an address on the machine in net -1.2 that is not 1.2.3.4.

If no listen-on is specified, the -server will listen on port 53 on all interfaces.

The listen-on-v6 option is used to +1.2 that is not 1.2.3.4.

+

If no listen-on is specified, the +server will listen on port 53 on all interfaces.

+

The listen-on-v6 option is used to specify the interfaces and the ports on which the server will listen -for incoming queries sent using IPv6.

When 

{ any; }
is specified -as the address_match_list for the -listen-on-v6 option, +for incoming queries sent using IPv6.

+

When

+
{ any; }
+

is specified +as the address_match_list for the +listen-on-v6 option, the server does not bind a separate socket to each IPv6 interface address as it does for IPv4 if the operating system has enough API support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542). Instead, it listens on the IPv6 wildcard address. If the system only has incomplete API support for IPv6, however, -the behavior is the same as that for IPv4.

A list of particular IPv6 addresses can also be specified, in which case +the behavior is the same as that for IPv4.

+

A list of particular IPv6 addresses can also be specified, in which case the server listens on a separate socket for each specified address, -regardless of whether the desired API is supported by the system.

Multiple listen-on-v6 options can be used. -For example,

listen-on-v6 { any; };
+regardless of whether the desired API is supported by the system.

+
Multiple listen-on-v6 options can be used.
+For example,

+
listen-on-v6 { any; };
 listen-on-v6 port 1234 { !2001:db8::/32; any; };
-
will enable the name server on port 53 for any IPv6 addresses
+
+

will enable the name server on port 53 for any IPv6 addresses (with a single wildcard socket), and on port 1234 of IPv6 addresses that is not in the prefix -2001:db8::/32 (with separate sockets for each matched address.)

To make the server not listen on any IPv6 address, use

listen-on-v6 { none; };
-

If no listen-on-v6 option is specified, -the server will not listen on any IPv6 address.

6.2.16.6. Query Address

If the server doesn't know the answer to a question, it will -query other name servers. query-source specifies +2001:db8::/32 (with separate sockets for each matched address.)

+

To make the server not listen on any IPv6 address, use

+
listen-on-v6 { none; };
+
+

If no listen-on-v6 option is specified, +the server will not listen on any IPv6 address.

+
+
+

+Query Address

+

If the server doesn't know the answer to a question, it will +query other name servers. query-source specifies the address and port used for such queries. For queries sent over -IPv6, there is a separate query-source-v6 option. -If address is * or is omitted, -a wildcard IP address (INADDR_ANY) will be used. -If port is * or is omitted, -a random unprivileged port will be used, avoid-v4-udp-ports -and avoid-v6-udp-ports can be used to prevent named -from selecting certain ports. The defaults are

query-source address * port *;
+IPv6, there is a separate query-source-v6 option.
+If address is * or is omitted,
+a wildcard IP address (INADDR_ANY) will be used.
+If port is * or is omitted,
+a random unprivileged port will be used, avoid-v4-udp-ports
+and avoid-v6-udp-ports can be used to prevent named
+from selecting certain ports. The defaults are

+
query-source address * port *;
 query-source-v6 address * port *;
-
Note: The address specified in the query-source option
+
+
+

Note

+

The address specified in the query-source option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random -unprivileged port.

Note: See also transfer-source and -notify-source.

6.2.16.7. Zone Transfers

BIND has mechanisms in place to facilitate zone transfers +unprivileged port.

+
+
+

Note

+

See also transfer-source and +notify-source.

+
+
+
+

+Zone Transfers

+

BIND has mechanisms in place to facilitate zone transfers and set limits on the amount of load that transfers place on the -system. The following options apply to zone transfers.

also-notify

Defines a global list of IP addresses of name servers +system. The following options apply to zone transfers.

+
+
also-notify
+

Defines a global list of IP addresses of name servers that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded, in addition to the servers listed in the zone's NS records. This helps to ensure that copies of the zones will -quickly converge on stealth servers. If an also-notify list -is given in a zone statement, it will override -the options also-notify statement. When a zone notify statement -is set to no, the IP addresses in the global also-notify list will +quickly converge on stealth servers. If an also-notify list +is given in a zone statement, it will override +the options also-notify statement. When a zone notify statement +is set to no, the IP addresses in the global also-notify list will not be sent NOTIFY messages for that zone. The default is the empty -list (no global notification list).

max-transfer-time-in

Inbound zone transfers running longer than +list (no global notification list).

+
max-transfer-time-in
+

Inbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes -(2 hours). The maximum value is 28 days (40320 minutes).

max-transfer-idle-in

Inbound zone transfers making no progress +(2 hours). The maximum value is 28 days (40320 minutes).

+
max-transfer-idle-in
+

Inbound zone transfers making no progress in this many minutes will be terminated. The default is 60 minutes -(1 hour). The maximum value is 28 days (40320 minutes).

max-transfer-time-out

Outbound zone transfers running longer than +(1 hour). The maximum value is 28 days (40320 minutes).

+
max-transfer-time-out
+

Outbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes -(2 hours). The maximum value is 28 days (40320 minutes).

max-transfer-idle-out

Outbound zone transfers making no progress +(2 hours). The maximum value is 28 days (40320 minutes).

+
max-transfer-idle-out
+

Outbound zone transfers making no progress in this many minutes will be terminated. The default is 60 minutes (1 -hour). The maximum value is 28 days (40320 minutes).

serial-query-rate

Slave servers will periodically query master servers +hour). The maximum value is 28 days (40320 minutes).

+
serial-query-rate
+

Slave servers will periodically query master servers to find out if zone serial numbers have changed. Each such query uses a minute amount of the slave server's network bandwidth. To limit the amount of bandwidth used, BIND 9 limits the rate at which queries are -sent. The value of the serial-query-rate option, +sent. The value of the serial-query-rate option, an integer, is the maximum number of queries sent per second. The default is 20. -

serial-queries

In BIND 8, the serial-queries option +

+
serial-queries
+

In BIND 8, the serial-queries option set the maximum number of concurrent serial number queries allowed to be outstanding at any given time. BIND 9 does not limit the number of outstanding -serial queries and ignores the serial-queries option. +serial queries and ignores the serial-queries option. Instead, it limits the rate at which the queries are sent -as defined using the serial-query-rate option. -

transfer-format

Zone transfers can be sent using two different formats, -one-answer and many-answers. -The transfer-format option is used +as defined using the serial-query-rate option. +

+
transfer-format
+

+Zone transfers can be sent using two different formats, +one-answer and many-answers. +The transfer-format option is used on the master server to determine which format it sends. -one-answer uses one DNS message per +one-answer uses one DNS message per resource record transferred. -many-answers packs as many resource records as -possible into a message. many-answers is more +many-answers packs as many resource records as +possible into a message. many-answers is more efficient, but is only supported by relatively new slave servers, -such as BIND 9, BIND 8.x and patched -versions of BIND 4.9.5. The default is -many-answers. transfer-format +such as BIND 9, BIND 8.x and patched +versions of BIND 4.9.5. The default is +many-answers. transfer-format may be overridden on a per-server basis by using the -server statement. -

transfers-in

The maximum number of inbound zone transfers -that can be running concurrently. The default value is 10. -Increasing transfers-in may speed up the convergence -of slave zones, but it also may increase the load on the local system.

transfers-out

The maximum number of outbound zone transfers +server statement. +

+
transfers-in
+

The maximum number of inbound zone transfers +that can be running concurrently. The default value is 10. +Increasing transfers-in may speed up the convergence +of slave zones, but it also may increase the load on the local system.

+
transfers-out
+

The maximum number of outbound zone transfers that can be running concurrently. Zone transfer requests in excess -of the limit will be refused. The default value is 10.

transfers-per-ns

The maximum number of inbound zone transfers +of the limit will be refused. The default value is 10.

+
transfers-per-ns
+

The maximum number of inbound zone transfers that can be concurrently transferring from a given remote name server. -The default value is 2. Increasing transfers-per-ns may +The default value is 2. Increasing transfers-per-ns may speed up the convergence of slave zones, but it also may increase -the load on the remote name server. transfers-per-ns may -be overridden on a per-server basis by using the transfers phrase -of the server statement.

transfer-source

transfer-source determines +the load on the remote name server. transfers-per-ns may +be overridden on a per-server basis by using the transfers phrase +of the server statement.

+
transfer-source
+

transfer-source determines which local address will be bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. It also determines the source IPv4 address, and optionally the UDP port, used for the refresh queries and forwarded dynamic updates. If not set, it defaults to a system controlled value which will usually be the address of the interface "closest to" the remote end. This address must appear -in the remote end's allow-transfer option for +in the remote end's allow-transfer option for the zone being transferred, if one is specified. This statement -sets the transfer-source for all zones, but can +sets the transfer-source for all zones, but can be overridden on a per-view or per-zone basis by including a -transfer-source statement within the -view or zone block -in the configuration file.

transfer-source-v6

The same as transfer-source, -except zone transfers are performed using IPv6.

alt-transfer-source

An alternate transfer source if the one listed in -transfer-source fails and -use-alt-transfer-source is set.

alt-transfer-source-v6

An alternate transfer source if the one listed in -transfer-source-v6 fails and -use-alt-transfer-source is set.

use-alt-transfer-source

Use the alternate transfer sources or not. If views are -specified this defaults to no otherwise it defaults to -yes (for BIND 8 compatibility).

notify-source

notify-source determines +transfer-source statement within the +view or zone block +in the configuration file.

+
transfer-source-v6
+

The same as transfer-source, +except zone transfers are performed using IPv6.

+
alt-transfer-source
+
+

+ An alternate transfer source if the one listed in + transfer-source fails and + use-alt-transfer-source is + set. +

+
+

Note

+ If you do not wish the alternate transfer source + to be used you should set + use-alt-transfer-source + appropriately and you should not depend upon + getting a answer back to the first refresh + query. +
+
+
alt-transfer-source-v6
+

An alternate transfer source if the one listed in +transfer-source-v6 fails and +use-alt-transfer-source is set.

+
use-alt-transfer-source
+

Use the alternate transfer sources or not. If views are +specified this defaults to no otherwise it defaults to +yes (for BIND 8 compatibility).

+
notify-source
+

notify-source determines which local source address, and optionally UDP port, will be used to send NOTIFY messages. -This address must appear in the slave server's masters -zone clause or in an allow-notify clause. -This statement sets the notify-source for all zones, +This address must appear in the slave server's masters +zone clause or in an allow-notify clause. +This statement sets the notify-source for all zones, but can be overridden on a per-zone / per-view basis by including a -notify-source statement within the zone -or view block in the configuration file.

notify-source-v6

Like notify-source, -but applies to notify messages sent to IPv6 addresses.

6.2.16.8. Bad UDP Port Lists

avoid-v4-udp-ports and avoid-v6-udp-ports +notify-source statement within the zone +or view block in the configuration file.

+
notify-source-v6
+

Like notify-source, +but applies to notify messages sent to IPv6 addresses.

+
+
+
+

+Bad UDP Port Lists

+

+avoid-v4-udp-ports and avoid-v6-udp-ports specify a list of IPv4 and IPv6 UDP ports that will not be used as system assigned source ports for UDP sockets. These lists prevent named from choosing as its random source port a port that is blocked by your firewall. If a query went out with such a source port, the answer would not get by the firewall and the name server would have to query again. -

6.2.16.9. Operating System Resource Limits

The server's usage of many system resources can be limited. +

+
+
+

+Operating System Resource Limits

+

The server's usage of many system resources can be limited. Scaled values are allowed when specifying resource limits. For -example, 1G can be used instead of -1073741824 to specify a limit of one -gigabyte. unlimited requests unlimited use, or the -maximum available amount. default uses the limit +example, 1G can be used instead of +1073741824 to specify a limit of one +gigabyte. unlimited requests unlimited use, or the +maximum available amount. default uses the limit that was in force when the server was started. See the description of -size_spec in Section 6.1.

The following options set operating system resource limits for +size_spec in the section called “Configuration File Elements”.

+

The following options set operating system resource limits for the name server process. Some operating systems don't support some or any of the limits. On such systems, a warning will be issued if the -unsupported limit is used.

coresize

The maximum size of a core dump. The default -is default.

datasize

The maximum amount of data memory the server -may use. The default is default. +unsupported limit is used.

+
+
coresize
+

The maximum size of a core dump. The default +is default.

+
datasize
+

The maximum amount of data memory the server +may use. The default is default. This is a hard limit on server memory usage. If the server attempts to allocate memory in excess of this limit, the allocation will fail, which may in turn leave @@ -6333,299 +2075,118 @@ amount of memory used by the server, but it can be used to raise an operating system data size limit that is too small by default. If you wish to limit the amount of memory used by the server, use the -max-cache-size and -recursive-clients +max-cache-size and +recursive-clients options instead. -

files

The maximum number of files the server -may have open concurrently. The default is unlimited. -

stacksize

The maximum amount of stack memory the server -may use. The default is default.

6.2.16.10. Server Resource Limits

The following options set limits on the server's +

+
files
+

The maximum number of files the server +may have open concurrently. The default is unlimited. +

+
stacksize
+

The maximum amount of stack memory the server +may use. The default is default.

+
+
+
+

+Server Resource Limits

+

The following options set limits on the server's resource consumption that are enforced internally by the -server rather than the operating system.

max-ixfr-log-size

This option is obsolete; it is accepted +server rather than the operating system.

+
+
max-ixfr-log-size
+

This option is obsolete; it is accepted and ignored for BIND 8 compatibility. The option -max-journal-size performs a similar +max-journal-size performs a similar function in BIND 8. -

max-journal-size

Sets a maximum size for each journal file -(Section 4.2.1). When the journal file approaches +

+
max-journal-size
+

Sets a maximum size for each journal file +(the section called “The journal file”). When the journal file approaches the specified size, some of the oldest transactions in the journal will be automatically removed. The default is -unlimited.

host-statistics-max

In BIND 8, specifies the maximum number of host statistic +unlimited.

+
host-statistics-max
+

In BIND 8, specifies the maximum number of host statistic entries to be kept. Not implemented in BIND 9. -

recursive-clients

The maximum number of simultaneous recursive lookups +

+
recursive-clients
+

The maximum number of simultaneous recursive lookups the server will perform on behalf of clients. The default is -1000. Because each recursing client uses a fair +1000. Because each recursing client uses a fair bit of memory, on the order of 20 kilobytes, the value of the -recursive-clients option may have to be decreased +recursive-clients option may have to be decreased on hosts with limited memory. -

tcp-clients

The maximum number of simultaneous client TCP +

+
tcp-clients
+

The maximum number of simultaneous client TCP connections that the server will accept. -The default is 100.

max-cache-size

The maximum amount of memory to use for the +The default is 100.

+
max-cache-size
+

The maximum amount of memory to use for the server's cache, in bytes. When the amount of data in the cache reaches this limit, the server will cause records to expire prematurely so that the limit is not exceeded. In a server with multiple views, the limit applies separately to the cache of each -view. The default is unlimited, meaning that +view. The default is unlimited, meaning that records are purged from the cache only when their TTLs expire. -

tcp-listen-queue

The listen queue depth. The default and minimum is 3. +

+
tcp-listen-queue
+

The listen queue depth. The default and minimum is 3. If the kernel supports the accept filter "dataready" this also controls how many TCP connections that will be queued in kernel space waiting for some data before being passed to accept. Values less than 3 will be silently raised. -

6.2.16.11. Periodic Task Intervals

cleaning-interval

The server will remove expired resource records -from the cache every cleaning-interval minutes. +

+
+
+
+

+Periodic Task Intervals

+
+
cleaning-interval
+

The server will remove expired resource records +from the cache every cleaning-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). -If set to 0, no periodic cleaning will occur.

heartbeat-interval

The server will perform zone maintenance tasks -for all zones marked as dialup whenever this +If set to 0, no periodic cleaning will occur.

+
heartbeat-interval
+

The server will perform zone maintenance tasks +for all zones marked as dialup whenever this interval expires. The default is 60 minutes. Reasonable values are up to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). -If set to 0, no zone maintenance for these zones will occur.

interface-interval

The server will scan the network interface list -every interface-interval minutes. The default +If set to 0, no zone maintenance for these zones will occur.

+
interface-interval
+

The server will scan the network interface list +every interface-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). If set to 0, interface scanning will only occur when the configuration file is loaded. After the scan, the server will begin listening for queries on any newly discovered interfaces (provided they are allowed by the -listen-on configuration), and will -stop listening on interfaces that have gone away.

statistics-interval

Name server statistics will be logged -every statistics-interval minutes. The default is +listen-on configuration), and will +stop listening on interfaces that have gone away.

+
statistics-interval
+
+

Name server statistics will be logged +every statistics-interval minutes. The default is 60. The maximum value is 28 days (40320 minutes). -If set to 0, no statistics will be logged.

Note: Not yet implemented in BIND9.

6.2.16.12. Topology

All other things being equal, when the server chooses a name server +If set to 0, no statistics will be logged.

+
+

Note

+

Not yet implemented in BIND9.

+
+ +
+
+
+

+Topology

+

All other things being equal, when the server chooses a name server to query from a list of name servers, it prefers the one that is -topologically closest to itself. The topology statement -takes an address_match_list and interprets it +topologically closest to itself. The topology statement +takes an address_match_list and interprets it in a special way. Each top-level list element is assigned a distance. Non-negated elements get a distance based on their position in the list, where the closer the match is to the start of the list, the @@ -6633,124 +2194,61 @@ shorter the distance is between it and the server. A negated match will be assigned the maximum distance from the server. If there is no match, the address will get a distance which is further than any non-negated list element, and closer than any negated element. -For example,

topology {
+For example,

+
topology {
     10/8;
     !1.2.3/24;
     { 1.2/16; 3/8; };
-};
will prefer servers on network 10 the most, followed by hosts
+};
+

will prefer servers on network 10 the most, followed by hosts on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception of hosts on network 1.2.3 (netmask 255.255.255.0), which -is preferred least of all.

The default topology is

    topology { localhost; localnets; };
-

Note: The topology option -is not implemented in BIND 9. -

6.2.16.13. The sortlist Statement

The response to a DNS query may consist of multiple resource +is preferred least of all.

+

The default topology is

+
    topology { localhost; localnets; };
+
+
+

Note

+

The topology option +is not implemented in BIND 9. +

+
+
+
+

+The sortlist Statement

+

The response to a DNS query may consist of multiple resource records (RRs) forming a resource records set (RRset). The name server will normally return the RRs within the RRset in an indeterminate order -(but see the rrset-order -statement in Section 6.2.16.14). +(but see the rrset-order +statement in the section called “RRset Ordering”). The client resolver code should rearrange the RRs as appropriate, that is, using any addresses on the local net in preference to other addresses. However, not all resolvers can do this or are correctly configured. When a client is using a local server the sorting can be performed in the server, based on the client's address. This only requires -configuring the name servers, not all the clients.

The sortlist statement (see below) takes -an address_match_list and interprets it even -more specifically than the topology statement -does (Section 6.2.16.12). -Each top level statement in the sortlist must -itself be an explicit address_match_list with +configuring the name servers, not all the clients.

+

The sortlist statement (see below) takes +an address_match_list and interprets it even +more specifically than the topology statement +does (the section called “Topology”). +Each top level statement in the sortlist must +itself be an explicit address_match_list with one or two elements. The first element (which may be an IP address, -an IP prefix, an ACL name or a nested address_match_list) +an IP prefix, an ACL name or a nested address_match_list) of each top level list is checked against the source address of -the query until a match is found.

Once the source address of the query has been matched, if +the query until a match is found.

+

Once the source address of the query has been matched, if the top level statement contains only one element, the actual primitive element that matched the source address is used to select the address in the response to move to the beginning of the response. If the statement is a list of two elements, then the second element is -treated the same as the address_match_list in -a topology statement. Each top level element +treated the same as the address_match_list in +a topology statement. Each top level element is assigned a distance and the address in the response with the minimum -distance is moved to the beginning of the response.

In the following example, any queries received from any of +distance is moved to the beginning of the response.

+

In the following example, any queries received from any of the addresses of the host itself will get responses preferring addresses on any of the locally connected networks. Next most preferred are addresses on the 192.168.1/24 network, and after that either the 192.168.2/24 @@ -6761,10 +2259,8 @@ will prefer other addresses on that network to the 192.168.2/24 and 192.168.3/24 networks. Queries received from a host on the 192.168.4/24 or the 192.168.5/24 network will only prefer other addresses on -their directly connected networks.

sortlist {
+their directly connected networks.

+
sortlist {
     { localhost;                                   // IF   the local host
         { localnets;                               // THEN first fit on the
             192.168.1/24;                          //   following nets
@@ -6780,1331 +2276,446 @@ CLASS="programlisting"
             { 192.168.1/24; 192.168.2/24; }; }; };
     { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
     };
-};
The following example will give reasonable behavior for the
+};
+

The following example will give reasonable behavior for the local host and hosts on directly connected networks. It is similar -to the behavior of the address sort in BIND 4.9.x. Responses sent +to the behavior of the address sort in BIND 4.9.x. Responses sent to queries from the local host will favor any of the directly connected networks. Responses sent to queries from any other hosts on a directly connected network will prefer addresses on that same network. Responses -to other queries will not be sorted.

sortlist {
+to other queries will not be sorted.

+
sortlist {
            { localhost; localnets; };
            { localnets; };
 };
-

6.2.16.14. RRset Ordering

When multiple records are returned in an answer it may be + +

+
+

+RRset Ordering

+

When multiple records are returned in an answer it may be useful to configure the order of the records placed into the response. -The rrset-order statement permits configuration +The rrset-order statement permits configuration of the ordering of the records in a multiple record response. -See also the sortlist statement, -Section 6.2.16.13. -

An order_spec is defined as follows:

[ class class_name ][ type type_name ][ name "domain_name"]
-      order ordering
-

If no class is specified, the default is ANY. -If no type is specified, the default is ANY. -If no name is specified, the default is "*".

The legal values for ordering are:

fixed

Records are returned in the order they -are defined in the zone file.

random

Records are returned in some random order.

cyclic

Records are returned in a round-robin -order.

For example:

rrset-order {
+See also the sortlist statement,
+the section called “The sortlist Statement”.
+

+
An order_spec is defined as follows:

+
[ class class_name ][ type type_name ][ name "domain_name"]
+      order ordering
+

+
If no class is specified, the default is ANY.
+If no type is specified, the default is ANY.
+If no name is specified, the default is "*".

+
The legal values for ordering are:

+

++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+




fixed
Records are returned in the order they
+are defined in the zone file.
random
Records are returned in some random order.
cyclic
Records are returned in a round-robin
+order.

+
For example:

+
rrset-order {
    class IN type A name "host.example.com" order random;
    order cyclic;
 };
-
will cause any responses for type A records in class IN that
-have "host.example.com" as a suffix, to always be returned
-in random order. All other records are returned in cyclic order.
If multiple rrset-order statements appear,
-they are not combined — the last one applies.
Note: The rrset-order statement
-is not yet fully implemented in BIND 9.
+
+

will cause any responses for type A records in class IN that +have "host.example.com" as a suffix, to always be returned +in random order. All other records are returned in cyclic order.

+

If multiple rrset-order statements appear, +they are not combined — the last one applies.

+
+

Note

+

The rrset-order statement +is not yet fully implemented in BIND 9. BIND 9 currently does not support "fixed" ordering. -

6.2.16.15. Tuning

lame-ttl

Sets the number of seconds to cache a +

+
+
+
+

+Tuning

+
+
lame-ttl
+

Sets the number of seconds to cache a lame server indication. 0 disables caching. (This is -NOT recommended.) -Default is 600 (10 minutes). Maximum value is -1800 (30 minutes).

max-ncache-ttl

To reduce network traffic and increase performance -the server stores negative answers. max-ncache-ttl is +NOT recommended.) +Default is 600 (10 minutes). Maximum value is +1800 (30 minutes).

+
max-ncache-ttl
+

To reduce network traffic and increase performance +the server stores negative answers. max-ncache-ttl is used to set a maximum retention time for these answers in the server in seconds. The default -max-ncache-ttl is 10800 seconds (3 hours). -max-ncache-ttl cannot exceed 7 days and will -be silently truncated to 7 days if set to a greater value.

max-cache-ttl

max-cache-ttl sets +max-ncache-ttl is 10800 seconds (3 hours). +max-ncache-ttl cannot exceed 7 days and will +be silently truncated to 7 days if set to a greater value.

+
max-cache-ttl
+

max-cache-ttl sets the maximum time for which the server will cache ordinary (positive) -answers. The default is one week (7 days).

min-roots

The minimum number of root servers that +answers. The default is one week (7 days).

+
min-roots
+
+

The minimum number of root servers that is required for a request for the root servers to be accepted. Default -is 2.

Note: Not implemented in BIND9.

sig-validity-interval

Specifies the number of days into the +is 2.

+
+

Note

+

Not implemented in BIND9.

+
+
+
sig-validity-interval
+

Specifies the number of days into the future when DNSSEC signatures automatically generated as a result -of dynamic updates (Section 4.2) -will expire. The default is 30 days. +of dynamic updates (the section called “Dynamic Update”) +will expire. The default is 30 days. The maximum value is 10 years (3660 days). The signature inception time is unconditionally set to one hour before the current time -to allow for a limited amount of clock skew.

min-refresh-time, max-refresh-time, min-retry-time, max-retry-time

These options control the server's behavior on refreshing a zone +to allow for a limited amount of clock skew.

+
+min-refresh-time, max-refresh-time, min-retry-time, max-retry-time +
+
+

+These options control the server's behavior on refreshing a zone (querying for SOA changes) or retrying failed transfers. Usually the SOA values for the zone are used, but these values are set by the master, giving slave server administrators little control over their contents. -

These options allow the administrator to set a minimum and maximum +

+

+These options allow the administrator to set a minimum and maximum refresh and retry time either per-zone, per-view, or globally. These options are valid for slave and stub zones, and clamp the SOA refresh and retry times to the specified values. -

edns-udp-size

edns-udp-size sets the advertised EDNS UDP buffer +

+
+
edns-udp-size
+

+edns-udp-size sets the advertised EDNS UDP buffer size. Valid values are 512 to 4096 (values outside this range will be silently adjusted). The default value is 4096. The usual reason for setting edns-udp-size to a non default value it to get UDP answers to pass through broken firewalls that block fragmented packets and/or block UDP packets that are greater than 512 bytes. -

6.2.16.16. Built-in server information zones

The server provides some helpful diagnostic information +

+
+
+
+

+Built-in server information zones

+

The server provides some helpful diagnostic information through a number of built-in zones under the -pseudo-top-level-domain bind in the -CHAOS class. These zones are part of a -built-in view (see Section 6.2.21) of class -CHAOS which is separate from the default view of -class IN; therefore, any global server options -such as allow-query do not apply the these zones. +pseudo-top-level-domain bind in the +CHAOS class. These zones are part of a +built-in view (see the section called “view Statement Grammar”) of class +CHAOS which is separate from the default view of +class IN; therefore, any global server options +such as allow-query do not apply the these zones. If you feel the need to disable these zones, use the options -below, or hide the built-in CHAOS view by -defining an explicit view of class CHAOS -that matches all clients.

version

The version the server should report -via a query of the name version.bind -with type TXT, class CHAOS. +below, or hide the built-in CHAOS view by +defining an explicit view of class CHAOS +that matches all clients.

+
+
version
+

The version the server should report +via a query of the name version.bind +with type TXT, class CHAOS. The default is the real version number of this server. -Specifying version none -disables processing of the queries.

hostname

The hostname the server should report via a query of -the name hostname.bind -with type TXT, class CHAOS. +Specifying version none +disables processing of the queries.

+
hostname
+

The hostname the server should report via a query of +the name hostname.bind +with type TXT, class CHAOS. This defaults to the hostname of the machine hosting the name server as found by gethostname(). The primary purpose of such queries is to identify which of a group of anycast servers is actually -answering your queries. Specifying hostname none; -disables processing of the queries.

server-id

The ID of the server should report via a query of -the name ID.SERVER -with type TXT, class CHAOS. +answering your queries. Specifying hostname none; +disables processing of the queries.

+
server-id
+

The ID of the server should report via a query of +the name ID.SERVER +with type TXT, class CHAOS. The primary purpose of such queries is to identify which of a group of anycast servers is actually -answering your queries. Specifying server-id none; +answering your queries. Specifying server-id none; disables processing of the queries. -Specifying server-id hostname; will cause named to +Specifying server-id hostname; will cause named to use the hostname as found by gethostname(). -The default server-id is none. -

6.2.16.17. The Statistics File

The statistics file generated by BIND 9 +The default server-id is none. +

+
+
+
+

+The Statistics File

+

The statistics file generated by BIND 9 is similar, but not identical, to that -generated by BIND 8. -

The statistics dump begins with the line +++ Statistics Dump -+++ (973798949), where the number in parentheses is a standard +generated by BIND 8. +

+

The statistics dump begins with the line +++ Statistics Dump ++++ (973798949), where the number in parentheses is a standard Unix-style timestamp, measured as seconds since January 1, 1970. Following that line are a series of lines containing a counter type, the value of the counter, optionally a zone name, and optionally a view name. The lines without view and zone listed are global statistics for the entire server. Lines with a zone and view name for the given view and zone (the view name is omitted for the default view). The statistics dump ends -with the line --- Statistics Dump --- (973798949), where the -number is identical to the number in the beginning line.

The following statistics counters are maintained:

+ + + + + + + + + + + + + + + + + + + + + + +

success

The number of +with the line --- Statistics Dump --- (973798949), where the +number is identical to the number in the beginning line.

+

The following statistics counters are maintained:

+
++++ + + + +

success

The number of successful queries made to the server or zone. A successful query is defined as query which returns a NOERROR response with at least -one answer RR.

referral

The number of queries which resulted -in referral responses.

nxrrset

The number of queries which resulted in -NOERROR responses with no data.

nxdomain

The number -of queries which resulted in NXDOMAIN responses.

failure

The number of queries which resulted in a -failure response other than those above.

recursion

The number of queries which caused the server -to perform recursion in order to find the final answer.

Each query received by the server will cause exactly one of -success, -referral, -nxrrset, -nxdomain, or -failure +one answer RR.

referral

The number of queries which resulted +in referral responses.

nxrrset

The number of queries which resulted in +NOERROR responses with no data.

nxdomain

The number +of queries which resulted in NXDOMAIN responses.

failure

The number of queries which resulted in a +failure response other than those above.

recursion

The number of queries which caused the server +to perform recursion in order to find the final answer.

+

+Each query received by the server will cause exactly one of +success, +referral, +nxrrset, +nxdomain, or +failure to be incremented, and may additionally cause the -recursion counter to be incremented. -

6.2.17. server Statement Grammar

server ip_addr {
-    [ bogus yes_or_no ; ]
-    [ provide-ixfr yes_or_no ; ]
-    [ request-ixfr yes_or_no ; ]
-    [ edns yes_or_no ; ]
-    [ transfers number ; ]
-    [ transfer-format ( one-answer | many-answers ) ; ]]
-    [ keys { string ; [ string ; [...]] } ; ]
-    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
-    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+recursion counter to be incremented.
+

+
+ +
+

+server Statement Grammar

+
server ip_addr {
+    [ bogus yes_or_no ; ]
+    [ provide-ixfr yes_or_no ; ]
+    [ request-ixfr yes_or_no ; ]
+    [ edns yes_or_no ; ]
+    [ transfers number ; ]
+    [ transfer-format ( one-answer | many-answers ) ; ]]
+    [ keys { string ; [ string ; [...]] } ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
 };
-

6.2.18. server Statement Definition and Usage

The server statement defines characteristics -to be associated with a remote name server.

The server statement can occur at the top level of the -configuration file or inside a view statement. -If a view statement contains -one or more server statements, only those + +

+
+

+server Statement Definition and Usage

+

The server statement defines characteristics +to be associated with a remote name server.

+

+The server statement can occur at the top level of the +configuration file or inside a view statement. +If a view statement contains +one or more server statements, only those apply to the view and any top-level ones are ignored. -If a view contains no server statements, -any top-level server statements are used as +If a view contains no server statements, +any top-level server statements are used as defaults. -

If you discover that a remote server is giving out bad data, +

+

If you discover that a remote server is giving out bad data, marking it as bogus will prevent further queries to it. The default -value of bogus is no.

The provide-ixfr clause determines whether +value of bogus is no.

+

The provide-ixfr clause determines whether the local server, acting as master, will respond with an incremental zone transfer when the given remote server, a slave, requests it. -If set to yes, incremental transfer will be provided -whenever possible. If set to no, all transfers +If set to yes, incremental transfer will be provided +whenever possible. If set to no, all transfers to the remote server will be non-incremental. If not set, the value -of the provide-ixfr option in the view or -global options block is used as a default.

The request-ixfr clause determines whether +of the provide-ixfr option in the view or +global options block is used as a default.

+

The request-ixfr clause determines whether the local server, acting as a slave, will request incremental zone transfers from the given remote server, a master. If not set, the -value of the request-ixfr option in the view or -global options block is used as a default.

IXFR requests to servers that do not support IXFR will automatically +value of the request-ixfr option in the view or +global options block is used as a default.

+

IXFR requests to servers that do not support IXFR will automatically fall back to AXFR. Therefore, there is no need to manually list which servers support IXFR and which ones do not; the global default -of yes should always work. -The purpose of the provide-ixfr and -request-ixfr clauses is +of yes should always work. +The purpose of the provide-ixfr and +request-ixfr clauses is to make it possible to disable the use of IXFR even when both master and slave claim to support it, for example if one of the servers -is buggy and crashes or corrupts data when IXFR is used.

The edns clause determines whether the local server +is buggy and crashes or corrupts data when IXFR is used.

+

The edns clause determines whether the local server will attempt to use EDNS when communicating with the remote server. The -default is yes.

The server supports two zone transfer methods. The first, one-answer, -uses one DNS message per resource record transferred. many-answers packs -as many resource records as possible into a message. many-answers is -more efficient, but is only known to be understood by BIND 9, BIND -8.x, and patched versions of BIND 4.9.5. You can specify which method -to use for a server with the transfer-format option. -If transfer-format is not specified, the transfer-format specified -by the options statement will be used.

transfers is used to limit the number of +default is yes.

+

The server supports two zone transfer methods. The first, one-answer, +uses one DNS message per resource record transferred. many-answers packs +as many resource records as possible into a message. many-answers is +more efficient, but is only known to be understood by BIND 9, BIND +8.x, and patched versions of BIND 4.9.5. You can specify which method +to use for a server with the transfer-format option. +If transfer-format is not specified, the transfer-format specified +by the options statement will be used.

+

transfers is used to limit the number of concurrent inbound zone transfers from the specified server. If -no transfers clause is specified, the limit is -set according to the transfers-per-ns option.

The keys clause identifies a -key_id defined by the key statement, -to be used for transaction security (TSIG, Section 4.5) +no transfers clause is specified, the limit is +set according to the transfers-per-ns option.

+

The keys clause identifies a +key_id defined by the key statement, +to be used for transaction security (TSIG, the section called “TSIG”) when talking to the remote server. When a request is sent to the remote server, a request signature will be generated using the key specified here and appended to the message. A request originating from the remote server is not required -to be signed by this key.

Although the grammar of the keys clause +to be signed by this key.

+

Although the grammar of the keys clause allows for multiple keys, only a single key per server is currently -supported.

The transfer-source and -transfer-source-v6 clauses specify the IPv4 and IPv6 source +supported.

+

The transfer-source and +transfer-source-v6 clauses specify the IPv4 and IPv6 source address to be used for zone transfer with the remote server, respectively. -For an IPv4 remote server, only transfer-source can +For an IPv4 remote server, only transfer-source can be specified. Similarly, for an IPv6 remote server, only -transfer-source-v6 can be specified. +transfer-source-v6 can be specified. Form more details, see the description of -transfer-source and -transfer-source-v6 in -Section 6.2.16.7.

6.2.19. trusted-keys Statement Grammar

trusted-keys {
-    string number number number string ;
-    [ string number number number string ; [...]]
+transfer-source and
+transfer-source-v6 in
+the section called “Zone Transfers”.

+
+
+

+trusted-keys Statement Grammar

+
trusted-keys {
+    string number number number string ;
+    [ string number number number string ; [...]]
 };
-

6.2.20. trusted-keys Statement Definition -and Usage

The trusted-keys statement defines DNSSEC -security roots. DNSSEC is described in Section 4.8. A security root is defined when the public key for a non-authoritative + +

+
+

+trusted-keys Statement Definition +and Usage

+

The trusted-keys statement defines DNSSEC +security roots. DNSSEC is described in the section called “DNSSEC”. A security root is defined when the public key for a non-authoritative zone is known, but cannot be securely obtained through DNS, either because it is the DNS root zone or because its parent zone is unsigned. Once a key has been configured as a trusted key, it is treated as if it had been validated and proven secure. The resolver attempts -DNSSEC validation on all DNS data in subdomains of a security root.

The trusted-keys statement can contain +DNSSEC validation on all DNS data in subdomains of a security root.

+

The trusted-keys statement can contain multiple key entries, each consisting of the key's domain name, flags, protocol, algorithm, and the base-64 representation of the -key data.

6.2.21. view Statement Grammar

view view_name 
-      [class] {
-      match-clients { address_match_list } ;
-      match-destinations { address_match_list } ;
-      match-recursive-only yes_or_no ;
-      [ view_option; ...]
-      [ zone_statement; ...]
+key data.

+
+
+

+view Statement Grammar

+
view view_name 
+      [class] {
+      match-clients { address_match_list } ;
+      match-destinations { address_match_list } ;
+      match-recursive-only yes_or_no ;
+      [ view_option; ...]
+      [ zone_statement; ...]
 };
-

6.2.22. view Statement Definition and Usage

The view statement is a powerful new feature -of BIND 9 that lets a name server answer a DNS query differently + +

+
+

+view Statement Definition and Usage

+

The view statement is a powerful new feature +of BIND 9 that lets a name server answer a DNS query differently depending on who is asking. It is particularly useful for implementing -split DNS setups without having to run multiple servers.

Each view statement defines a view of the +split DNS setups without having to run multiple servers.

+

Each view statement defines a view of the DNS namespace that will be seen by a subset of clients. A client matches a view if its source IP address matches the -address_match_list of the view's -match-clients clause and its destination IP address matches -the address_match_list of the view's -match-destinations clause. If not specified, both -match-clients and match-destinations +address_match_list of the view's +match-clients clause and its destination IP address matches +the address_match_list of the view's +match-destinations clause. If not specified, both +match-clients and match-destinations default to matching all addresses. In addition to checking IP addresses -match-clients and match-destinations -can also take keys which provide an mechanism for the +match-clients and match-destinations +can also take keys which provide an mechanism for the client to select the view. A view can also be specified -as match-recursive-only, which means that only recursive +as match-recursive-only, which means that only recursive requests from matching clients will match that view. -The order of the view statements is significant — +The order of the view statements is significant — a client request will be resolved in the context of the first -view that it matches.

Zones defined within a view statement will -be only be accessible to clients that match the view. +view that it matches.

+

Zones defined within a view statement will +be only be accessible to clients that match the view. By defining a zone of the same name in multiple views, different zone data can be given to different clients, for example, "internal" -and "external" clients in a split DNS setup.

Many of the options given in the options statement -can also be used within a view statement, and then +and "external" clients in a split DNS setup.

+

Many of the options given in the options statement +can also be used within a view statement, and then apply only when resolving queries with that view. When no view-specific -value is given, the value in the options statement +value is given, the value in the options statement is used as a default. Also, zone options can have default values specified -in the view statement; these view-specific defaults -take precedence over those in the options statement.

Views are class specific. If no class is given, class IN +in the view statement; these view-specific defaults +take precedence over those in the options statement.

+

Views are class specific. If no class is given, class IN is assumed. Note that all non-IN views must contain a hint zone, -since only the IN class has compiled-in default hints.

If there are no view statements in the config +since only the IN class has compiled-in default hints.

+

If there are no view statements in the config file, a default view that matches any client is automatically created -in class IN. Any zone statements specified on +in class IN. Any zone statements specified on the top level of the configuration file are considered to be part of -this default view, and the options statement will -apply to the default view. If any explicit view -statements are present, all zone statements must -occur inside view statements.

Here is an example of a typical split DNS setup implemented -using view statements.

view "internal" {
+this default view, and the options statement will
+apply to the default view. If any explicit view
+statements are present, all zone statements must
+occur inside view statements.

+
Here is an example of a typical split DNS setup implemented
+using view statements.

+
view "internal" {
       // This should match our internal networks.
       match-clients { 10.0.0.0/8; };
 
@@ -8133,519 +2744,80 @@ view "external" {
            file "example-external.db";
       };
 };
-

6.2.23. zone -Statement Grammar

zone zone_name [class] [{ 
+
+
+
+

+zone +Statement Grammar

+
zone zone_name [class] [{ 
     type ( master | slave | hint | stub | forward | delegation-only ) ;
-    [ allow-notify { address_match_list } ; ]
-    [ allow-query { address_match_list } ; ]
-    [ allow-transfer { address_match_list } ; ]
-    [ allow-update { address_match_list } ; ]
-    [ update-policy { update_policy_rule [...] } ; ]
-    [ allow-update-forwarding { address_match_list } ; ]
-    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
-    [ check-names (warn|fail|ignore) ; ]
-    [ dialup dialup_option ; ]
-    [ delegation-only yes_or_no ; ]
-    [ file string ; ]
-    [ forward (only|first) ; ]
-    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
-    [ ixfr-base string ; ]
-    [ ixfr-tmp-file string ; ]
-    [ maintain-ixfr-base yes_or_no ; ]
-    [ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; ]
-    [ max-ixfr-log-size number ; ]
-    [ max-transfer-idle-in number ; ]
-    [ max-transfer-idle-out number ; ]
-    [ max-transfer-time-in number ; ]
-    [ max-transfer-time-out number ; ]
-    [ notify yes_or_no | explicit ; ]
-    [ pubkey number number number string ; ]
-    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
-    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
-    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ use-alt-transfer-source yes_or_no; ]
-    [ notify-source (ip4_addr | *) [port ip_port] ; ]
-    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
-    [ zone-statistics yes_or_no ; ]
-    [ sig-validity-interval number ; ]
-    [ database string ; ]
-    [ min-refresh-time number ; ]
-    [ max-refresh-time number ; ]
-    [ min-retry-time number ; ]
-    [ max-retry-time number ; ]
-    [ multi-master yes_or_no ; ]
-    [ key-directory path_name; ]
+    [ allow-notify { address_match_list } ; ]
+    [ allow-query { address_match_list } ; ]
+    [ allow-transfer { address_match_list } ; ]
+    [ allow-update { address_match_list } ; ]
+    [ update-policy { update_policy_rule [...] } ; ]
+    [ allow-update-forwarding { address_match_list } ; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ dialup dialup_option ; ]
+    [ delegation-only yes_or_no ; ]
+    [ file string ; ]
+    [ forward (only|first) ; ]
+    [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
+    [ ixfr-base string ; ]
+    [ ixfr-tmp-file string ; ]
+    [ maintain-ixfr-base yes_or_no ; ]
+    [ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] } ; ]
+    [ max-ixfr-log-size number ; ]
+    [ max-transfer-idle-in number ; ]
+    [ max-transfer-idle-out number ; ]
+    [ max-transfer-time-in number ; ]
+    [ max-transfer-time-out number ; ]
+    [ notify yes_or_no | explicit ; ]
+    [ pubkey number number number string ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ zone-statistics yes_or_no ; ]
+    [ sig-validity-interval number ; ]
+    [ database string ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ multi-master yes_or_no ; ]
+    [ key-directory path_name; ]
 
-}];
-

6.2.24. zone Statement Definition and Usage

6.2.24.1. Zone Types

+ + +

master

The server has a master copy of the data +}]; + + +

+

+zone Statement Definition and Usage

+
+

+Zone Types

+
++++ + + + + + + + + + + + + + + + + + + + + + + + +

master

The server has a master copy of the data for the zone and will be able to provide authoritative answers for -it.

slave

A slave zone is a replica of a master -zone. The masters list specifies one or more IP addresses +it.

slave

A slave zone is a replica of a master +zone. The masters list specifies one or more IP addresses of master servers that the slave contacts to update its copy of the zone. Masters list elements can also be names of other masters lists. By default, transfers are made from port 53 on the servers; this can @@ -8659,1640 +2831,605 @@ recommended, since it often speeds server start-up and eliminates a needless waste of bandwidth. Note that for large numbers (in the tens or hundreds of thousands) of zones per server, it is best to use a two level naming scheme for zone file names. For example, -a slave server for the zone example.com might place +a slave server for the zone example.com might place the zone contents into a file called -ex/example.com where ex/ is +ex/example.com where ex/ is just the first two letters of the zone name. (Most operating systems behave very slowly if you put 100 000 files into -a single directory.)

stub

A stub zone is similar to a slave zone, +a single directory.)

stub

 +

A stub zone is similar to a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone. Stub zones are not a standard part of the DNS; -they are a feature specific to the BIND implementation. -

+they are a feature specific to the BIND implementation. +

-

Stub zones can be used to eliminate the need for glue NS record +

Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and -a set of name server addresses in named.conf. +a set of name server addresses in named.conf. This usage is not recommended for new configurations, and BIND 9 supports it only in a limited way. -In BIND 4/8, zone transfers of a parent zone +In BIND 4/8, zone transfers of a parent zone included the NS records from stub children of that zone. This meant that, in some cases, users could get away with configuring child stubs -only in the master server for the parent zone. BIND +only in the master server for the parent zone. BIND 9 never mixes together zone data from different zones in this -way. Therefore, if a BIND 9 master serving a parent +way. Therefore, if a BIND 9 master serving a parent zone has child stub zones configured, all the slave servers for the parent zone also need to have the same child stub zones -configured.

+configured.

-

Stub zones can also be used as a way of forcing the resolution +

Stub zones can also be used as a way of forcing the resolution of a given domain to use a particular set of authoritative servers. For example, the caching name servers on a private network using RFC1981 addressing may be configured with stub zones for -10.in-addr.arpa +10.in-addr.arpa to use a set of internal name servers as the authoritative -servers for that domain.

-

forward

A "forward zone" is a way to configure -forwarding on a per-domain basis. A zone statement -of type forward can contain a forward and/or forwarders statement, +servers for that domain.

+

forward

 +

A "forward zone" is a way to configure +forwarding on a per-domain basis. A zone statement +of type forward can contain a forward and/or forwarders statement, which will apply to queries within the domain given by the zone -name. If no forwarders statement is present or -an empty list for forwarders is given, then no +name. If no forwarders statement is present or +an empty list for forwarders is given, then no forwarding will be done for the domain, canceling the effects of -any forwarders in the options statement. Thus +any forwarders in the options statement. Thus if you want to use this type of zone to change the behavior of the -global forward option (that is, "forward first +global forward option (that is, "forward first to", then "forward only", or vice versa, but want to use the same -servers as set globally) you need to re-specify the global forwarders.

-

hint

The initial set of root name servers is +servers as set globally) you need to re-specify the global forwarders.

+

hint

The initial set of root name servers is specified using a "hint zone". When the server starts up, it uses the root hints to find a root name server and get the most recent list of root name servers. If no hint zone is specified for class IN, the server uses a compiled-in default set of root servers hints. -Classes other than IN have no built-in defaults hints.

delegation-only

This is used to enforce the delegation only +Classes other than IN have no built-in defaults hints.

delegation-only

 +

This is used to enforce the delegation only status of infrastructure zones (e.g. COM, NET, ORG). Any answer that is received without a explicit or implicit delegation in the authority section will be treated as NXDOMAIN. This does not apply to the zone -apex. This SHOULD NOT be applied to leaf zones.

-

delegation-only has no effect on answers received -from forwarders.

6.2.24.2. Class

The zone's name may optionally be followed by a class. If -a class is not specified, class IN (for Internet), -is assumed. This is correct for the vast majority of cases.

The hesiod class is +apex. This SHOULD NOT be applied to leaf zones.

+

delegation-only has no effect on answers received +from forwarders.

+
+
+
+

+Class

+

The zone's name may optionally be followed by a class. If +a class is not specified, class IN (for Internet), +is assumed. This is correct for the vast majority of cases.

+

The hesiod class is named for an information service from MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers and so on. The keyword -HS is -a synonym for hesiod.

Another MIT development is CHAOSnet, a LAN protocol created -in the mid-1970s. Zone data for it can be specified with the CHAOS class.

6.2.24.3. Zone Options

allow-notify

See the description of -allow-notify in Section 6.2.16.4

allow-query

See the description of -allow-query in Section 6.2.16.4

allow-transfer

See the description of allow-transfer -in Section 6.2.16.4.

allow-update

Specifies which hosts are allowed to +HS is +a synonym for hesiod.

+

Another MIT development is CHAOSnet, a LAN protocol created +in the mid-1970s. Zone data for it can be specified with the CHAOS class.

+
+
+

+Zone Options

+
+
allow-notify
+

See the description of +allow-notify in the section called “Access Control”

+
allow-query
+

See the description of +allow-query in the section called “Access Control”

+
allow-transfer
+

See the description of allow-transfer +in the section called “Access Control”.

+
allow-update
+

Specifies which hosts are allowed to submit Dynamic DNS updates for master zones. The default is to deny updates from all hosts. Note that allowing updates based on the requestor's IP address is insecure; see -Section 7.3 for details. -

update-policy

Specifies a "Simple Secure Update" policy. See -Section 6.2.24.4.

allow-update-forwarding

See the description of allow-update-forwarding -in Section 6.2.16.4.

also-notify

Only meaningful if notify is +the section called “Dynamic Update Security” for details. +

+
update-policy
+

Specifies a "Simple Secure Update" policy. See +the section called “Dynamic Update Policies”.

+
allow-update-forwarding
+

See the description of allow-update-forwarding +in the section called “Access Control”.

+
also-notify
+

Only meaningful if notify is active for this zone. The set of machines that will receive a -DNS NOTIFY message +DNS NOTIFY message for this zone is made up of all the listed name servers (other than the primary master) for the zone plus any IP addresses specified -with also-notify. A port may be specified -with each also-notify address to send the notify +with also-notify. A port may be specified +with each also-notify address to send the notify messages to a port other than the default of 53. -also-notify is not meaningful for stub zones. -The default is the empty list.

check-names

This option is used to restrict the character set and syntax of +also-notify is not meaningful for stub zones. +The default is the empty list.

+
check-names
+

+This option is used to restrict the character set and syntax of certain domain names in master files and/or DNS responses received from the -network. The default varies according to zone type. For master zones the default is fail. For slave -zones the default is warn. -

database

Specify the type of database to be used for storing the -zone data. The string following the database keyword +network. The default varies according to zone type. For master zones the default is fail. For slave +zones the default is warn. +

+
database
+
+

Specify the type of database to be used for storing the +zone data. The string following the database keyword is interpreted as a list of whitespace-delimited words. The first word identifies the database type, and any subsequent words are passed as arguments to the database to be interpreted in a way specific -to the database type.

The default is "rbt", BIND 9's native in-memory -red-black-tree database. This database does not take arguments.

Other values are possible if additional database drivers +to the database type.

+

The default is "rbt", BIND 9's native in-memory +red-black-tree database. This database does not take arguments.

+

Other values are possible if additional database drivers have been linked into the server. Some sample drivers are included -with the distribution but none are linked in by default.

dialup

See the description of -dialup in Section 6.2.16.1.

delegation-only

The flag only applies to hint and stub zones. If set -to yes then the zone will also be treated as if it +with the distribution but none are linked in by default.

+
+
dialup
+

See the description of +dialup in the section called “Boolean Options”.

+
delegation-only
+

The flag only applies to hint and stub zones. If set +to yes then the zone will also be treated as if it is also a delegation-only type zone. -

forward

Only meaningful if the zone has a forwarders -list. The only value causes the lookup to fail -after trying the forwarders and getting no answer, while first would -allow a normal lookup to be tried.

forwarders

Used to override the list of global forwarders. -If it is not specified in a zone of type forward, -no forwarding is done for the zone; the global options are not used.

ixfr-base

Was used in BIND 8 to specify the name +

+
forward
+

Only meaningful if the zone has a forwarders +list. The only value causes the lookup to fail +after trying the forwarders and getting no answer, while first would +allow a normal lookup to be tried.

+
forwarders
+

Used to override the list of global forwarders. +If it is not specified in a zone of type forward, +no forwarding is done for the zone; the global options are not used.

+
ixfr-base
+

Was used in BIND 8 to specify the name of the transaction log (journal) file for dynamic update and IXFR. -BIND 9 ignores the option and constructs the name of the journal -file by appending ".jnl" to the name of the -zone file.

ixfr-tmp-file

Was an undocumented option in BIND 8. -Ignored in BIND 9.

max-transfer-time-in

See the description of -max-transfer-time-in in Section 6.2.16.7.

max-transfer-idle-in

See the description of -max-transfer-idle-in in Section 6.2.16.7.

max-transfer-time-out

See the description of -max-transfer-time-out in Section 6.2.16.7.

max-transfer-idle-out

See the description of -max-transfer-idle-out in Section 6.2.16.7.

notify

See the description of -notify in Section 6.2.16.1.

pubkey

In BIND 8, this option was intended for specifying +BIND 9 ignores the option and constructs the name of the journal +file by appending ".jnl" to the name of the +zone file.

+
ixfr-tmp-file
+

Was an undocumented option in BIND 8. +Ignored in BIND 9.

+
max-transfer-time-in
+

See the description of +max-transfer-time-in in the section called “Zone Transfers”.

+
max-transfer-idle-in
+

See the description of +max-transfer-idle-in in the section called “Zone Transfers”.

+
max-transfer-time-out
+

See the description of +max-transfer-time-out in the section called “Zone Transfers”.

+
max-transfer-idle-out
+

See the description of +max-transfer-idle-out in the section called “Zone Transfers”.

+
notify
+

See the description of +notify in the section called “Boolean Options”.

+
pubkey
+

In BIND 8, this option was intended for specifying a public zone key for verification of signatures in DNSSEC signed -zones when they are loaded from disk. BIND 9 does not verify signatures -on load and ignores the option.

zone-statistics

If yes, the server will keep statistical +zones when they are loaded from disk. BIND 9 does not verify signatures +on load and ignores the option.

+
zone-statistics
+

If yes, the server will keep statistical information for this zone, which can be dumped to the -statistics-file defined in the server options.

sig-validity-interval

See the description of -sig-validity-interval in Section 6.2.16.15.

transfer-source

See the description of -transfer-source in Section 6.2.16.7 -

transfer-source-v6

See the description of -transfer-source-v6 in Section 6.2.16.7 -

alt-transfer-source

See the description of -alt-transfer-source in Section 6.2.16.7 -

alt-transfer-source-v6

See the description of -alt-transfer-source-v6 in Section 6.2.16.7 -

use-alt-transfer-source

See the description of -use-alt-transfer-source in Section 6.2.16.7 -

notify-source

See the description of -notify-source in Section 6.2.16.7 -

notify-source-v6

See the description of -notify-source-v6 in Section 6.2.16.7. -

min-refresh-time, max-refresh-time, min-retry-time, max-retry-time

See the description in Section 6.2.16.15. -

ixfr-from-differences

See the description of -ixfr-from-differences in Section 6.2.16.1.

key-directory

See the description of -key-directory in Section 6.2.16

multi-master

See the description of -multi-master in Section 6.2.16.1.

6.2.24.4. Dynamic Update Policies

BIND 9 supports two alternative methods of granting clients +statistics-file defined in the server options.

+
sig-validity-interval
+

See the description of +sig-validity-interval in the section called “Tuning”.

+
transfer-source
+

See the description of +transfer-source in the section called “Zone Transfers” +

+
transfer-source-v6
+

See the description of +transfer-source-v6 in the section called “Zone Transfers” +

+
alt-transfer-source
+

See the description of +alt-transfer-source in the section called “Zone Transfers” +

+
alt-transfer-source-v6
+

See the description of +alt-transfer-source-v6 in the section called “Zone Transfers” +

+
use-alt-transfer-source
+

See the description of +use-alt-transfer-source in the section called “Zone Transfers” +

+
notify-source
+

See the description of +notify-source in the section called “Zone Transfers” +

+
notify-source-v6
+

See the description of +notify-source-v6 in the section called “Zone Transfers”. +

+
+min-refresh-time, max-refresh-time, min-retry-time, max-retry-time +
+

+See the description in the section called “Tuning”. +

+
ixfr-from-differences
+

See the description of +ixfr-from-differences in the section called “Boolean Options”.

+
key-directory
+

See the description of +key-directory in the section called “options Statement Definition and Usage”

+
multi-master
+

See the description of +multi-master in the section called “Boolean Options”.

+
+
+
+

+Dynamic Update Policies

+

BIND 9 supports two alternative methods of granting clients the right to perform dynamic updates to a zone, -configured by the allow-update and -update-policy option, respectively.

The allow-update clause works the same -way as in previous versions of BIND. It grants given clients the -permission to update any record of any name in the zone.

The update-policy clause is new in BIND +configured by the allow-update and +update-policy option, respectively.

+

The allow-update clause works the same +way as in previous versions of BIND. It grants given clients the +permission to update any record of any name in the zone.

+

The update-policy clause is new in BIND 9 and allows more fine-grained control over what updates are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or more names to be updated by one or more identities. If the dynamic update request message is signed (that is, it includes either a TSIG or SIG(0) record), the identity of the signer can -be determined.

Rules are specified in the update-policy zone -option, and are only meaningful for master zones. When the update-policy statement -is present, it is a configuration error for the allow-update statement -to be present. The update-policy statement only -examines the signer of a message; the source address is not relevant.

This is how a rule definition looks:


( grant | deny ) identity nametype name [ types ]
-

Each rule grants or denies privileges. Once a message has +be determined.

+

Rules are specified in the update-policy zone +option, and are only meaningful for master zones. When the update-policy statement +is present, it is a configuration error for the allow-update statement +to be present. The update-policy statement only +examines the signer of a message; the source address is not relevant.

+

This is how a rule definition looks:

+
+( grant | deny ) identity nametype name [ types ]
+
+

Each rule grants or denies privileges. Once a message has successfully matched a rule, the operation is immediately granted or denied and no further rules are examined. A rule is matched when the signer matches the identity field, the name matches the name field in accordance with the nametype field, and the type matches -the types specified in the type field.

The identity field specifies a name or a wildcard name. Normally, this +the types specified in the type field.

+

The identity field specifies a name or a wildcard name. Normally, this is the name of the TSIG or SIG(0) key used to sign the update request. When a TKEY exchange has been used to create a shared secret, the identity of the shared secret is the same as the identity of the key used to authenticate the -TKEY exchange. When the identity field specifies a +TKEY exchange. When the identity field specifies a wildcard name, it is subject to DNS wildcard expansion, so the rule will apply -to multiple identities. The identity field must -contain a fully qualified domain name.

The nametype field has 4 values: -name, subdomain, -wildcard, and self. -

+ + +

name

Exact-match semantics. This rule matches when the +to multiple identities. The identity field must +contain a fully qualified domain name.

+

The nametype field has 4 values: +name, subdomain, +wildcard, and self. +

+
++++ + + + + + + + + + + + + + + + +

name

Exact-match semantics. This rule matches when the name being updated is identical to the contents of the -name field.

subdomain

This rule matches when the name being updated +name field.

subdomain

This rule matches when the name being updated is a subdomain of, or identical to, the contents of the -name field.

wildcard

The name field is +name field.

wildcard

The name field is subject to DNS wildcard expansion, and this rule matches when the name -being updated name is a valid expansion of the wildcard.

self

This rule matches when the name being updated -matches the contents of the identity field. -The name field is ignored, but should be -the same as the identity field. The -self nametype is most useful when allowing using +being updated name is a valid expansion of the wildcard.

self

This rule matches when the name being updated +matches the contents of the identity field. +The name field is ignored, but should be +the same as the identity field. The +self nametype is most useful when allowing using one key per name to update, where the key has the same name as the name -to be updated. The identity would be -specified as * in this case.

In all cases, the name field must -specify a fully qualified domain name.

If no types are explicitly specified, this rule matches all types except +to be updated. The identity would be +specified as * in this case.

+

In all cases, the name field must +specify a fully qualified domain name.

+

If no types are explicitly specified, this rule matches all types except SIG, NS, SOA, and NXT. Types may be specified by name, including "ANY" (ANY matches all types except NXT, which can never be updated). Note that when an attempt is made to delete all records associated with a name, the rules are checked for each existing record type. -

6.3. Zone File

6.3.1. Types of Resource Records and When to Use Them

This section, largely borrowed from RFC 1034, describes the +

+
+
+ +
+

+Zone File

+
+

+Types of Resource Records and When to Use Them

+

This section, largely borrowed from RFC 1034, describes the concept of a Resource Record (RR) and explains when each is used. Since the publication of RFC 1034, several new RRs have been identified -and implemented in the DNS. These are also included.

6.3.1.1. Resource Records

A domain name identifies a node. Each node has a set of +and implemented in the DNS. These are also included.

+
+

+Resource Records

+

A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate RRs. The order of RRs in a set is not significant and need not be preserved by name servers, resolvers, or other parts of the DNS. However, sorting of multiple RRs is permitted for optimization purposes, for example, to specify - that a particular nearby server be tried first. See Section 6.2.16.13 and Section 6.2.16.14.

The components of a Resource Record are:

+ + +

owner name

the domain name where the RR is found.

type

an encoded 16 bit value that specifies -the type of the resource record.

TTL

the time to live of the RR. This field + that a particular nearby server be tried first. See the section called “The sortlist Statement” and the section called “RRset Ordering”.

+

The components of a Resource Record are:

+
++++ + + + + + + + + + + + +

owner name

the domain name where the RR is found.

type

an encoded 16 bit value that specifies +the type of the resource record.

TTL

the time to live of the RR. This field is a 32 bit integer in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can -be cached before it should be discarded.

class

an encoded 16 bit value that identifies -a protocol family or instance of a protocol.

RDATA

the resource data. The format of the -data is type (and sometimes class) specific.

The following are types of valid RRs:

+ + + + + + + + + + +

A

a host address. In the IN class, this is a -32-bit IP address. Described in RFC 1035.

AAAA

IPv6 address. Described in RFC 1886.

A6

IPv6 address. This can be a partial +be cached before it should be discarded.

class

an encoded 16 bit value that identifies +a protocol family or instance of a protocol.

RDATA

the resource data. The format of the +data is type (and sometimes class) specific.

+

The following are types of valid RRs:

+
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

A

a host address. In the IN class, this is a +32-bit IP address. Described in RFC 1035.

AAAA

IPv6 address. Described in RFC 1886.

A6

IPv6 address. This can be a partial address (a suffix) and an indirection to the name where the rest of the -address (the prefix) can be found. Experimental. Described in RFC 2874.

AFSDB

location of AFS database servers. -Experimental. Described in RFC 1183.

APL

address prefix list. Experimental. -Described in RFC 3123.

CERT

holds a digital certificate. -Described in RFC 2538.

CNAME

identifies the canonical name of an alias. -Described in RFC 1035.

DNAME

Replaces the domain name specified with +address (the prefix) can be found. Experimental. Described in RFC 2874.

AFSDB

location of AFS database servers. +Experimental. Described in RFC 1183.

APL

address prefix list. Experimental. +Described in RFC 3123.

CERT

holds a digital certificate. +Described in RFC 2538.

CNAME

identifies the canonical name of an alias. +Described in RFC 1035.

DNAME

Replaces the domain name specified with another name to be looked up, effectively aliasing an entire subtree of the domain name space rather than a single record as in the case of the CNAME RR. -Described in RFC 2672.

GPOS

Specifies the global position. Superseded by LOC.

HINFO

identifies the CPU and OS used by a host. -Described in RFC 1035.

ISDN

representation of ISDN addresses. -Experimental. Described in RFC 1183.

KEY

stores a public key associated with a -DNS name. Described in RFC 2535.

KX

identifies a key exchanger for this -DNS name. Described in RFC 2230.

LOC

for storing GPS info. Described in RFC 1876. -Experimental.

MX

identifies a mail exchange for the domain. +Described in RFC 2672.

GPOS

Specifies the global position. Superseded by LOC.

HINFO

identifies the CPU and OS used by a host. +Described in RFC 1035.

ISDN

representation of ISDN addresses. +Experimental. Described in RFC 1183.

KEY

stores a public key associated with a +DNS name. Described in RFC 2535.

KX

identifies a key exchanger for this +DNS name. Described in RFC 2230.

LOC

for storing GPS info. Described in RFC 1876. +Experimental.

MX

identifies a mail exchange for the domain. a 16 bit preference value (lower is better) followed by the host name of the mail exchange. -Described in RFC 974, RFC 1035.

NAPTR

name authority pointer. Described in RFC 2915.

NSAP

a network service access point. -Described in RFC 1706.

NS

the authoritative name server for the -domain. Described in RFC 1035.

NXT

used in DNSSEC to securely indicate that +Described in RFC 974, RFC 1035.

NAPTR

name authority pointer. Described in RFC 2915.

NSAP

a network service access point. +Described in RFC 1706.

NS

the authoritative name server for the +domain. Described in RFC 1035.

NXT

used in DNSSEC to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and indicate what RR types are present for an existing name. -Described in RFC 2535.

PTR

a pointer to another part of the domain -name space. Described in RFC 1035.

PX

provides mappings between RFC 822 and X.400 -addresses. Described in RFC 2163.

RP

information on persons responsible -for the domain. Experimental. Described in RFC 1183.

RT

route-through binding for hosts that +Described in RFC 2535.

PTR

a pointer to another part of the domain +name space. Described in RFC 1035.

PX

provides mappings between RFC 822 and X.400 +addresses. Described in RFC 2163.

RP

information on persons responsible +for the domain. Experimental. Described in RFC 1183.

RT

route-through binding for hosts that do not have their own direct wide area network addresses. -Experimental. Described in RFC 1183.

SIG

("signature") contains data authenticated -in the secure DNS. Described in RFC 2535.

SOA

identifies the start of a zone of authority. -Described in RFC 1035.

SRV

information about well known network -services (replaces WKS). Described in RFC 2782.

TXT

text records. Described in RFC 1035.

WKS

information about which well known +Experimental. Described in RFC 1183.

SIG

("signature") contains data authenticated +in the secure DNS. Described in RFC 2535.

SOA

identifies the start of a zone of authority. +Described in RFC 1035.

SRV

information about well known network +services (replaces WKS). Described in RFC 2782.

TXT

text records. Described in RFC 1035.

WKS

information about which well known network services, such as SMTP, that a domain supports. Historical. -

X25

representation of X.25 network addresses. -Experimental. Described in RFC 1183.

The following classes of resource records -are currently valid in the DNS:

+ + + + + + +

IN

The Internet.

CH

CHAOSnet, a LAN protocol created at MIT in the mid-1970s. +

X25

representation of X.25 network addresses. +Experimental. Described in RFC 1183.

+

The following classes of resource records +are currently valid in the DNS:

+
++++ + + + + + + + + + + + +

IN

The Internet.

CH

+CHAOSnet, a LAN protocol created at MIT in the mid-1970s. Rarely used for its historical purpose, but reused for BIND's built-in server information zones, e.g., -version.bind. -

HS

Hesiod, an information service +version.bind. +

HS

+Hesiod, an information service developed by MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers and so on. -

The owner name is often implicit, rather than forming an integral +

+

The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that -fits the needs of the resource being described.

The meaning of the TTL field is a time limit on how long an +fits the needs of the resource being described.

+

The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the @@ -10302,288 +3439,112 @@ of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following -the change.

The data in the RDATA section of RRs is carried as a combination +the change.

+

The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently -used as "pointers" to other data in the DNS.

6.3.1.2. Textual expression of RRs

RRs are represented in binary form in the packets of the DNS +used as "pointers" to other data in the DNS.

+
+
+

+Textual expression of RRs

+

RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In the examples provided in RFC 1034, a style similar to that used in master files was employed in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible -using parentheses.

The start of the line gives the owner of the RR. If a line +using parentheses.

+

The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as -that of the previous RR. Blank lines are often included for readability.

Following the owner, we list the TTL, type, and class of the +that of the previous RR. Blank lines are often included for readability.

+

Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values -are often omitted from examples in the interests of clarity.

The resource data or RDATA section of the RR are given using -knowledge of the typical representation for the data.

For example, we might show the RRs carried in a message as:

ISI.EDU.

MX

10 VENERA.ISI.EDU.

MX

10 VAXA.ISI.EDU

VENERA.ISI.EDU

A

128.9.0.32

A

10.1.0.52

VAXA.ISI.EDU

A

10.2.0.27

A

128.9.0.33

The MX RRs have an RDATA section which consists of a 16 bit +are often omitted from examples in the interests of clarity.

+

The resource data or RDATA section of the RR are given using +knowledge of the typical representation for the data.

+

For example, we might show the RRs carried in a message as:

+
+++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

ISI.EDU.

MX

10 VENERA.ISI.EDU.

MX

10 VAXA.ISI.EDU

VENERA.ISI.EDU

A

128.9.0.32

A

10.1.0.52

VAXA.ISI.EDU

A

10.2.0.27

A

128.9.0.33

+

The MX RRs have an RDATA section which consists of a 16 bit number followed by a domain name. The address RRs use a standard -IP address format to contain a 32 bit internet address.

This example shows six RRs, with two RRs at each of three -domain names.

Similarly we might see:

XX.LCS.MIT.EDU. IN

A

10.0.0.44

CH

A

MIT.EDU. 2420

This example shows two addresses for XX.LCS.MIT.EDU, -each of a different class.

6.3.2. Discussion of MX Records

As described above, domain servers store information as a +IP address format to contain a 32 bit internet address.

+

This example shows six RRs, with two RRs at each of three +domain names.

+

Similarly we might see:

+
+++++ + + + + + + + + + + + + +

XX.LCS.MIT.EDU. IN

A

10.0.0.44

CH

A

MIT.EDU. 2420

+

This example shows two addresses for XX.LCS.MIT.EDU, +each of a different class.

+
+
+
+

+Discussion of MX Records

+

As described above, domain servers store information as a series of resource records, each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of a RR is as a typed pair of data, a domain name matched with a relevant datum, and stored with some additional type information to help systems -determine when the RR is relevant.

MX records are used to control delivery of email. The data +determine when the RR is relevant.

+

MX records are used to control delivery of email. The data specified in the record is a priority and a domain name. The priority controls the order in which email delivery is attempted, with the lowest number first. If two priorities are the same, a server is @@ -10591,320 +3552,110 @@ chosen randomly. If no servers at a given priority are responding, the mail transport agent will fall back to the next largest priority. Priority numbers do not have any absolute meaning — they are relevant only respective to other MX records for that domain name. The domain -name given is the machine to which the mail will be delivered. It must have -an associated A record — CNAME is not sufficient.

For a given domain, if there is both a CNAME record and an +name given is the machine to which the mail will be delivered. It must have +an associated A record — CNAME is not sufficient.

+

For a given domain, if there is both a CNAME record and an MX record, the MX record is in error, and will be ignored. Instead, the mail will be delivered to the server specified in the MX record -pointed to by the CNAME.

example.com.

IN

MX

10

mail.example.com.

IN

MX

10

mail2.example.com.

IN

MX

20

mail.backup.org.

mail.example.com.

IN

A

10.0.0.1

mail2.example.com.

IN

A

10.0.0.2

For example:

Mail delivery will be attempted to mail.example.com and -mail2.example.com (in -any order), and if neither of those succeed, delivery to mail.backup.org will -be attempted.

6.3.3. Setting TTLs

The time to live of the RR field is a 32 bit integer represented +pointed to by the CNAME.

+
+++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

example.com.

IN

MX

10

mail.example.com.

IN

MX

10

mail2.example.com.

IN

MX

20

mail.backup.org.

mail.example.com.

IN

A

10.0.0.1

mail2.example.com.

IN

A

10.0.0.2

+

For example:

+

Mail delivery will be attempted to mail.example.com and +mail2.example.com (in +any order), and if neither of those succeed, delivery to mail.backup.org will +be attempted.

+
+
+

+Setting TTLs

+

The time to live of the RR field is a 32 bit integer represented in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded. The following three types of TTL are currently -used in a zone file.

+ + +

SOA

The last field in the SOA is the negative +used in a zone file.

+
++++ + + + + + + + + + + + +

SOA

 +

The last field in the SOA is the negative caching TTL. This controls how long other servers will cache no-such-domain -(NXDOMAIN) responses from you.

The maximum time for -negative caching is 3 hours (3h).

$TTL

The $TTL directive at the top of the +(NXDOMAIN) responses from you.

+

The maximum time for +negative caching is 3 hours (3h).

+

$TTL

The $TTL directive at the top of the zone file (before the SOA) gives a default TTL for every RR without -a specific TTL set.

RR TTLs

Each RR can have a TTL as the second +a specific TTL set.

RR TTLs

Each RR can have a TTL as the second field in the RR, which will control how long other servers can cache -the it.

All of these TTLs default to units of seconds, though units -can be explicitly specified, for example, 1h30m.

6.3.4. Inverse Mapping in IPv4

Reverse name resolution (that is, translation from IP address -to name) is achieved by means of the in-addr.arpa domain +the it.

+

All of these TTLs default to units of seconds, though units +can be explicitly specified, for example, 1h30m.

+
+
+

+Inverse Mapping in IPv4

+

Reverse name resolution (that is, translation from IP address +to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-most significant order, read left to right. This is the opposite order to the way IP addresses are usually written. Thus, @@ -10913,647 +3664,201 @@ in-addr.arpa name of 3.2.1.10.in-addr.arpa. This name should have a PTR resource record whose data field is the name of the machine or, optionally, multiple PTR records if the machine has more than one name. For example, -in the [example.com] domain:

$ORIGIN

2.1.10.in-addr.arpa

3

IN PTR foo.example.com.

Note: The $ORIGIN lines in the examples +in the [example.com] domain:

+
++++ + + + + + + + + + + +

$ORIGIN

2.1.10.in-addr.arpa

3

IN PTR foo.example.com.

+
+

Note

+

The $ORIGIN lines in the examples are for providing context to the examples only-they do not necessarily appear in the actual usage. They are only used here to indicate -that the example is relative to the listed origin.

6.3.5. Other Zone File Directives

The Master File Format was initially defined in RFC 1035 and +that the example is relative to the listed origin.

+
+
+
+

+Other Zone File Directives

+

The Master File Format was initially defined in RFC 1035 and has subsequently been extended. While the Master File Format itself is class independent all records in a Master File must be of the same -class.

Master File Directives include $ORIGIN, $INCLUDE, -and $TTL.

6.3.5.1. The $ORIGIN Directive

Syntax: $ORIGIN -domain-name [ comment]

$ORIGIN sets the domain name that will +class.

+

Master File Directives include $ORIGIN, $INCLUDE, +and $TTL.

+
+

+The $ORIGIN Directive

+

Syntax: $ORIGIN +domain-name [ comment]

+

$ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read -in there is an implicit $ORIGIN <zone-name>. The -current $ORIGIN is appended to the domain specified -in the $ORIGIN argument if it is not absolute.

$ORIGIN example.com.
-WWW     CNAME   MAIN-SERVER

is equivalent to

WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.

6.3.5.2. The $INCLUDE Directive

Syntax: $INCLUDE -filename [ origin ] [ comment ]

Read and process the file filename as -if it were included into the file at this point. If origin is -specified the file is processed with $ORIGIN set -to that value, otherwise the current $ORIGIN is -used.

The origin and the current domain name -revert to the values they had prior to the $INCLUDE once -the file has been read.

Note: +in there is an implicit $ORIGIN <zone-name>. The +current $ORIGIN is appended to the domain specified +in the $ORIGIN argument if it is not absolute.

+
$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER
+

is equivalent to

+
WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
+
+
+

+The $INCLUDE Directive

+

Syntax: $INCLUDE +filename [ +origin ] [ comment ]

+

Read and process the file filename as +if it were included into the file at this point. If origin is +specified the file is processed with $ORIGIN set +to that value, otherwise the current $ORIGIN is +used.

+

The origin and the current domain name +revert to the values they had prior to the $INCLUDE once +the file has been read.

+
+

Note

+

RFC 1035 specifies that the current origin should be restored after -an $INCLUDE, but it is silent on whether the current +an $INCLUDE, but it is silent on whether the current domain name should also be restored. BIND 9 restores both of them. This could be construed as a deviation from RFC 1035, a feature, or both. -

6.3.5.3. The $TTL Directive

Syntax: $TTL -default-ttl [ comment ]

Set the default Time To Live (TTL) for subsequent records -with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.

$TTL is defined in RFC 2308.

6.3.6. BIND Master File Extension: the $GENERATE Directive

Syntax: $GENERATE range lhs [ttl] [class] type rhs [ comment ]

$GENERATE is used to create a series of -resource records that only differ from each other by an iterator. $GENERATE can +

+
+
+
+

+The $TTL Directive

+

Syntax: $TTL +default-ttl [ +comment ]

+

Set the default Time To Live (TTL) for subsequent records +with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.

+

$TTL is defined in RFC 2308.

+
+
+
+

+BIND Master File Extension: the $GENERATE Directive

+

Syntax: $GENERATE range lhs [ttl] [class] type rhs [ comment ]

+

$GENERATE is used to create a series of +resource records that only differ from each other by an iterator. $GENERATE can be used to easily generate the sets of records required to support sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA -delegation.

$ORIGIN 0.0.192.IN-ADDR.ARPA.
+delegation.

+
$ORIGIN 0.0.192.IN-ADDR.ARPA.
 $GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0
is equivalent to
0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0

+
is equivalent to

+
0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
 1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
 2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
 ...
 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
-

+
+
+
+
+
+
+
+
+
+
+
range
This can be one of two forms: start-stop
+
+

++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+




range
This can be one of two forms: start-stop
 or start-stop/step. If the first form is used then step is set to
-        1. All of start, stop and step must be positive.
lhs
lhs describes the
-owner name of the resource records to be created.      Any single $ symbols
-within the lhs side are replaced by the iterator
+        1. All of start, stop and step must be positive.
lhs

+
lhs describes the
+owner name of the resource records to be created.      Any single $ symbols
+within the lhs side are replaced by the iterator
 value.
-To get a $ in the output you need to escape the $
-using a backslash \,
-e.g. \$. The $ may optionally be followed
+To get a $ in the output you need to escape the $
+using a backslash \,
+e.g. \$. The $ may optionally be followed
 by modifiers which change the offset from the iterator, field width and base. 
-Modifiers are introduced by a { immediately following the
-$ as ${offset[,width[,base]]}.
-e.g. ${-20,3,d} which subtracts 20 from the current value,
+Modifiers are introduced by a { immediately following the
+$ as ${offset[,width[,base]]}.
+e.g. ${-20,3,d} which subtracts 20 from the current value,
 prints the result as a decimal in a zero padded field of with 3.  Available
-output forms are decimal (d), octal (o)
-and hexadecimal (x or X for uppercase).
-The default modifier is ${0,0,d}.
-If the lhs is not
-absolute, the current $ORIGIN is appended to
-the name.

-
For compatibility with earlier versions $$ is still
-recognized a indicating a literal $ in the output.
ttl
ttl specifies the
+output forms are decimal (d), octal (o)
+and hexadecimal (x or X for uppercase).
+The default modifier is ${0,0,d}.
+If the lhs is not
+absolute, the current $ORIGIN is appended to
+the name.

+
For compatibility with earlier versions $$ is still
+recognized a indicating a literal $ in the output.

+
ttl

+
ttl specifies the
 	  ttl of the generated records. If not specified this will be
-	  inherited using the normal ttl inheritance rules.

-	  
class and ttl can be
-	  entered in either order.
class
class specifies the
+	  inherited using the normal ttl inheritance rules.

+	  
class and ttl can be
+	  entered in either order.

+
class

+
class specifies the
 	  class of the generated records.  This must match the zone class if
-	  it is specified.

-	  
class and ttl can be
-	  entered in either order.
type
At present the only supported types are
-PTR, CNAME, DNAME, A, AAAA and NS.
rhs
rhs is a domain name. It is processed
-similarly to lhs.
The $GENERATE directive is a BIND extension
-and not part of the standard zone file format.
BIND 8 does not support the optional TTL and CLASS fields.
PrevHomeNext
The BIND 9 Lightweight Resolver BIND 9 Security Considerations

\ No newline at end of file
+	  it is specified.

+	  
class and ttl can be
+	  entered in either order.

+
type
At present the only supported types are
+PTR, CNAME, DNAME, A, AAAA and NS.
rhs
rhs is a domain name. It is processed
+similarly to lhs.

+
The $GENERATE directive is a BIND extension
+and not part of the standard zone file format.

+
BIND 8 does not support the optional TTL and CLASS fields.

+
+ + +
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 5. The BIND 9 Lightweight Resolver Home Chapter 7. BIND 9 Security Considerations
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html index 9e5cc9b8f3f..86c2b6af064 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch07.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch07.html @@ -1,160 +1,78 @@ - -BIND 9 Security Considerations
BIND 9 Administrator Reference Manual
PrevNext

Chapter 7. BIND 9 Security Considerations

7.1. Access Control Lists

Access Control Lists (ACLs), are address match lists that -you can set up and nickname for future use in allow-notify, -allow-query, allow-recursion, -blackhole, allow-transfer, -etc.

Using ACLs allows you to have finer control over who can access + + + + + +Chapter 7. BIND 9 Security Considerations + + + + + + + +

+ + + + + + + +
Chapter 7. BIND 9 Security Considerations
+Prev   Next +
+
+
+
+

+Chapter 7. BIND 9 Security Considerations

+
+

Table of Contents

+
+
Access Control Lists
+
chroot and setuid (for +UNIX servers)
+
+
The chroot Environment
+
Using the setuid Function
+
+
Dynamic Update Security
+
+
+
+

+Access Control Lists

+

Access Control Lists (ACLs), are address match lists that +you can set up and nickname for future use in allow-notify, +allow-query, allow-recursion, +blackhole, allow-transfer, +etc.

+

Using ACLs allows you to have finer control over who can access your name server, without cluttering up your config files with huge -lists of IP addresses.

It is a good idea to use ACLs, and to +lists of IP addresses.

+

It is a good idea to use ACLs, and to control access to your server. Limiting access to your server by outside parties can help prevent spoofing and DoS attacks against -your server.

Here is an example of how to properly apply ACLs:


// Set up an ACL named "bogusnets" that will block RFC1918 space,
+your server.

+
Here is an example of how to properly apply ACLs:

+
+// Set up an ACL named "bogusnets" that will block RFC1918 space,
 // which is commonly used in spoofing attacks.
 acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
 // Set up an ACL called our-nets. Replace this with the real IP numbers.
@@ -173,328 +91,110 @@ zone "example.com" {
   file "m/example.com";
   allow-query { any; };
 };
-
This allows recursive queries of the server from the outside
-unless recursion has been previously disabled.
For more information on how to use ACLs to protect your server,
-see the AUSCERT advisory at
-ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos

7.2. chroot and setuid (for -UNIX servers)

On UNIX servers, it is possible to run BIND in a chrooted environment -(chroot()) by specifying the "-t" -option. This can help improve system security by placing BIND in -a "sandbox", which will limit the damage done if a server is compromised.

Another useful feature in the UNIX version of BIND is the -ability to run the daemon as an unprivileged user ( -u user ). -We suggest running as an unprivileged user when using the chroot feature.

Here is an example command line to load BIND in a chroot() sandbox, -/var/named, and to run named setuid to -user 202:

/usr/local/bin/named -u 202 -t /var/named

7.2.1. The chroot Environment

In order for a chroot() environment to + +

This allows recursive queries of the server from the outside +unless recursion has been previously disabled.

+

For more information on how to use ACLs to protect your server, +see the AUSCERT advisory at +ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos

+
+
+

+chroot and setuid (for +UNIX servers)

+

On UNIX servers, it is possible to run BIND in a chrooted environment +(chroot()) by specifying the "-t" +option. This can help improve system security by placing BIND in +a "sandbox", which will limit the damage done if a server is compromised.

+

Another useful feature in the UNIX version of BIND is the +ability to run the daemon as an unprivileged user ( -u user ). +We suggest running as an unprivileged user when using the chroot feature.

+

Here is an example command line to load BIND in a chroot() sandbox, +/var/named, and to run named setuid to +user 202:

+

/usr/local/bin/named -u 202 -t /var/named

+
+

+The chroot Environment

+

In order for a chroot() environment to work properly in a particular directory -(for example, /var/named), +(for example, /var/named), you will need to set up an environment that includes everything -BIND needs to run. -From BIND's point of view, /var/named is +BIND needs to run. +From BIND's point of view, /var/named is the root of the filesystem. You will need to adjust the values of options like -like directory and pid-file to account +like directory and pid-file to account for this. -

Unlike with earlier versions of BIND, you will typically -not need to compile named +

+

+Unlike with earlier versions of BIND, you will typically +not need to compile named statically nor install shared libraries under the new root. However, depending on your operating system, you may need to set up things like -/dev/zero, -/dev/random, -/dev/log, and/or -/etc/localtime. -

7.2.2. Using the setuid Function

Prior to running the named daemon, use -the touch utility (to change file access and -modification times) or the chown utility (to +/dev/zero, +/dev/random, +/dev/log, and/or +/etc/localtime. +

+
+
+

+Using the setuid Function

+

Prior to running the named daemon, use +the touch utility (to change file access and +modification times) or the chown utility (to set the user id and/or group id) on files -to which you want BIND -to write. Note that if the named daemon is running as an +to which you want BIND +to write. Note that if the named daemon is running as an unprivileged user, it will not be able to bind to new restricted ports if the -server is reloaded.

7.3. Dynamic Update Security

Access to the dynamic +server is reloaded.

+
+
+
+

+Dynamic Update Security

+

Access to the dynamic update facility should be strictly limited. In earlier versions of -BIND the only way to do this was based on the IP +BIND the only way to do this was based on the IP address of the host requesting the update, by listing an IP address or -network prefix in the allow-update zone option. +network prefix in the allow-update zone option. This method is insecure since the source address of the update UDP packet is easily forged. Also note that if the IP addresses allowed by the -allow-update option include the address of a slave +allow-update option include the address of a slave server which performs forwarding of dynamic updates, the master can be trivially attacked by sending the update to the slave, which will forward it to the master with its own source IP address causing the -master to approve it without question.

For these reasons, we strongly recommend that updates be +master to approve it without question.

+

For these reasons, we strongly recommend that updates be cryptographically authenticated by means of transaction signatures -(TSIG). That is, the allow-update option should +(TSIG). That is, the allow-update option should list only TSIG key names, not IP addresses or network -prefixes. Alternatively, the new update-policy -option can be used.

Some sites choose to keep all dynamically updated DNS data +prefixes. Alternatively, the new update-policy +option can be used.

+

Some sites choose to keep all dynamically updated DNS data in a subdomain and delegate that subdomain to a separate zone. This way, the top-level zone containing critical data such as the IP addresses of public web and mail servers need not allow dynamic update at -all.

PrevHomeNext
BIND 9 Configuration Reference Troubleshooting
\ No newline at end of file +all.

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 6. BIND 9 Configuration Reference Home Chapter 8. Troubleshooting
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html index 94d3d795246..9d486e1bd5b 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch08.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch08.html @@ -1,135 +1,73 @@ - -Troubleshooting
BIND 9 Administrator Reference Manual
PrevNext

Chapter 8. Troubleshooting

8.1. Common Problems

8.1.1. It's not working; how can I figure out what's wrong?

The best solution to solving installation and + + + + + +Chapter 8. Troubleshooting + + + + + + + +

+ + + + + + + +
Chapter 8. Troubleshooting
+Prev   Next +
+
+
+
+

+Chapter 8. Troubleshooting

+
+

Table of Contents

+
+
Common Problems
+
It's not working; how can I figure out what's wrong?
+
Incrementing and Changing the Serial Number
+
Where Can I Get Help?
+
+
+
+

+Common Problems

+
+

+It's not working; how can I figure out what's wrong?

+

The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand. The log files provide a source of hints and information that can be used to figure out - what went wrong and how to fix the problem.

8.2. Incrementing and Changing the Serial Number

Zone serial numbers are just numbers-they aren't date + what went wrong and how to fix the problem.

+
+
+
+

+Incrementing and Changing the Serial Number

+

Zone serial numbers are just numbers-they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. A number of people have been testing these numbers for Y2K compliance and have set the number @@ -138,135 +76,49 @@ NAME="AEN4760" numbers are used to indicate that a zone has been updated. If the serial number on the slave server is lower than the serial number on the master, the slave server will attempt to update its copy of - the zone.

Setting the serial number to a lower number on the master + the zone.

+

Setting the serial number to a lower number on the master server than the slave server means that the slave will not perform - updates to its copy of the zone.

The solution to this is to add 2147483647 (2^31-1) to the + updates to its copy of the zone.

+

The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all slaves have updated to the new zone serial number, then reset the number to what you want - it to be, and reload the zone again.

8.3. Where Can I Get Help?

The Internet Software Consortium (ISC) offers a wide range - of support and service agreements for BIND and DHCP servers. Four + it to be, and reload the zone again.

+
+
+

+Where Can I Get Help?

+

The Internet Software Consortium (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four levels of premium support are available and each level includes - support for all ISC programs, significant discounts on products + support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and - non-funded feature requests. In addition, ISC offers a standard + non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in - BIND and DHCP.

To discuss arrangements for support, contact - info@isc.org or visit the - ISC web page at http://www.isc.org/services/support/ - to read more.

PrevHomeNext
BIND 9 Security Considerations Appendices
\ No newline at end of file + BIND and DHCP.

+

To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at http://www.isc.org/services/support/ + to read more.

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 7. BIND 9 Security Considerations Home Appendix A. Appendices
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html index ea6202b2eb8..8c7b2bf4450 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.ch09.html +++ b/contrib/bind9/doc/arm/Bv9ARM.ch09.html @@ -1,121 +1,67 @@ - -Appendices
BIND 9 Administrator Reference Manual
Prev 

Appendix A. Appendices

A.1. Acknowledgments

A.1.1. A Brief History of the DNS and BIND

Although the "official" beginning of the Domain Name + + + + + +Appendix A. Appendices + + + + + + +

+ + + + + + + +
Appendix A. Appendices
+Prev   
+
+
+
+

+Appendix A. Appendices

+
+

Table of Contents

+
+
Acknowledgments
+
A Brief History of the DNS and BIND
+
General DNS Reference Information
+
IPv6 addresses (AAAA)
+
Bibliography (and Suggested Reading)
+
+
Request for Comments (RFCs)
+
Internet Drafts
+
Other Documents About BIND
+
+
+
+
+

+Acknowledgments

+
+

+A Brief History of the DNS and BIND

+

Although the "official" beginning of the Domain Name System occurred in 1984 with the publication of RFC 920, the core of the new system was described in 1983 in RFCs 882 and 883. From 1984 to 1987, the ARPAnet (the precursor to today's @@ -126,1462 +72,317 @@ CLASS="acronym" incorporate improvements based on the working model. RFC 1034, "Domain Names-Concepts and Facilities", and RFC 1035, "Domain Names-Implementation and Specification" were published and - became the standards upon which all DNS implementations are + became the standards upon which all DNS implementations are built. -

The first working domain name server, called "Jeeves", was +

+

The first working domain name server, called "Jeeves", was written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 machines located at the University of Southern California's Information Sciences Institute (USC-ISI) and SRI International's Network Information -Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet -Name Domain (BIND) package, was written soon after by a group of +Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet +Name Domain (BIND) package, was written soon after by a group of graduate students at the University of California at Berkeley under a grant from the US Defense Advanced Research Projects Administration -(DARPA). Versions of BIND through 4.8.3 were maintained by the Computer +(DARPA). Versions of BIND through 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark -Painter, David Riggle and Songnian Zhou made up the initial BIND +Painter, David Riggle and Songnian Zhou made up the initial BIND project team. After that, additional work on the software package was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation -employee on loan to the CSRG, worked on BIND for 2 years, from 1985 -to 1987. Many other people also contributed to BIND development +employee on loan to the CSRG, worked on BIND for 2 years, from 1985 +to 1987. Many other people also contributed to BIND development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, -Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently -handled by Mike Karels and O. Kure.

BIND versions 4.9 and 4.9.1 were released by Digital Equipment +Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently +handled by Mike Karels and O. Kure.

+

BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then -a DEC employee, became BIND's primary caretaker. Paul was assisted +a DEC employee, became BIND's primary caretaker. Paul was assisted by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe -Wolfhugel, and others.

BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul -Vixie became BIND's principal architect/programmer.

BIND versions from 4.9.3 onward have been developed and maintained +Wolfhugel, and others.

+

BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul +Vixie became BIND's principal architect/programmer.

+

BIND versions from 4.9.3 onward have been developed and maintained by the Internet Software Consortium with support being provided by ISC's sponsors. As co-architects/programmers, Bob Halley and -Paul Vixie released the first production-ready version of BIND version -8 in May 1997.

BIND development work is made possible today by the sponsorship +Paul Vixie released the first production-ready version of BIND version +8 in May 1997.

+

BIND development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous -individuals.

A.2. General DNS Reference Information

A.2.1. IPv6 addresses (AAAA)

IPv6 addresses are 128-bit identifiers for interfaces and -sets of interfaces which were introduced in the DNS to facilitate -scalable Internet routing. There are three types of addresses: Unicast, -an identifier for a single interface; Anycast, -an identifier for a set of interfaces; and Multicast, +individuals.

+
+
+
+

+General DNS Reference Information

+
+

+IPv6 addresses (AAAA)

+

IPv6 addresses are 128-bit identifiers for interfaces and +sets of interfaces which were introduced in the DNS to facilitate +scalable Internet routing. There are three types of addresses: Unicast, +an identifier for a single interface; Anycast, +an identifier for a set of interfaces; and Multicast, an identifier for a set of interfaces. Here we describe the global -Unicast address scheme. For more information, see RFC 2374.

The aggregatable global Unicast address format is as follows:

3

13

8

24

16

64 bits

FP

TLA ID

RES

NLA ID

SLA ID

Interface ID

<------ Public Topology ------->

<-Site Topology->

<------ Interface Identifier ------>

Where -

FP

=

Format Prefix (001)

TLA ID

=

Top-Level Aggregation Identifier

RES

=

Reserved for future use

NLA ID

=

Next-Level Aggregation Identifier

SLA ID

=

Site-Level Aggregation Identifier

INTERFACE ID

=

Interface Identifier

The Public Topology is provided by the -upstream provider or ISP, and (roughly) corresponds to the IPv4 network section -of the address range. The Site Topology is +Unicast address scheme. For more information, see RFC 2374.

+

The aggregatable global Unicast address format is as follows:

+
++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

3

13

8

24

16

64 bits

FP

TLA ID

RES

NLA ID

SLA ID

Interface ID

<------ Public Topology +------>

<-Site Topology->

<------ Interface Identifier ------>

+

Where +

+
+++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

FP

=

Format Prefix (001)

TLA ID

=

Top-Level Aggregation Identifier

RES

=

Reserved for future use

NLA ID

=

Next-Level Aggregation Identifier

SLA ID

=

Site-Level Aggregation Identifier

INTERFACE ID

=

Interface Identifier

+

The Public Topology is provided by the +upstream provider or ISP, and (roughly) corresponds to the IPv4 network section +of the address range. The Site Topology is where you can subnet this space, much the same as subnetting an -IPv4 /16 network into /24 subnets. The Interface Identifier is +IPv4 /16 network into /24 subnets. The Interface Identifier is the address of an individual interface on a given network. (With -IPv6, addresses belong to interfaces rather than machines.)

The subnetting capability of IPv6 is much more flexible than +IPv6, addresses belong to interfaces rather than machines.)

+

The subnetting capability of IPv6 is much more flexible than that of IPv4: subnetting can now be carried out on bit boundaries, -in much the same way as Classless InterDomain Routing (CIDR).

The Interface Identifier must be unique on that network. On +in much the same way as Classless InterDomain Routing (CIDR).

+

The Interface Identifier must be unique on that network. On ethernet networks, one way to ensure this is to set the address to the first three bytes of the hardware address, "FFFE", then the last three bytes of the hardware address. The lowest significant bit of the first byte should then be complemented. Addresses are written as 32-bit blocks separated with a colon, and leading zeros -of a block may be omitted, for example:

2001:db8:201:9:a00:20ff:fe81:2b32

IPv6 address specifications are likely to contain long strings +of a block may be omitted, for example:

+

2001:db8:201:9:a00:20ff:fe81:2b32

+

IPv6 address specifications are likely to contain long strings of zeros, so the architects have included a shorthand for specifying them. The double colon (`::') indicates the longest possible string -of zeros that can fit, and can be used only once in an address.

A.3. Bibliography (and Suggested Reading)

A.3.1. Request for Comments (RFCs)

Specification documents for the Internet protocol suite, including -the DNS, are published as part of the Request for Comments (RFCs) +of zeros that can fit, and can be used only once in an address.

+
+
+
+

+Bibliography (and Suggested Reading)

+
+

+Request for Comments (RFCs)

+

Specification documents for the Internet protocol suite, including +the DNS, are published as part of the Request for Comments (RFCs) series of technical notes. The standards themselves are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be obtained online via FTP at -ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is +ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is the number of the RFC). RFCs are also available via the Web at -http://www.ietf.org/rfc/. -

Bibliography

Standards

[RFC974] C. Partridge, Mail Routing and the Domain System, January 1986.

[RFC1034] P.V. Mockapetris, Domain Names — Concepts and Facilities, November 1987.

[RFC1035] P. V. Mockapetris, Domain Names — Implementation and -Specification, November 1987.

Proposed Standards

[RFC2181] R., R. Bush Elz, Clarifications to the DNS Specification, July 1997.

[RFC2308] M. Andrews, Negative Caching of DNS Queries, March 1998.

[RFC1995] M. Ohta, Incremental Zone Transfer in DNS, August 1996.

[RFC1996] P. Vixie, A Mechanism for Prompt Notification of Zone Changes, August 1996.

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, Dynamic Updates in the Domain Name System, April 1997.

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington, Secret Key Transaction Authentication for DNS (TSIG), May 2000.

Proposed Standards Still Under Development

[RFC1886] S. Thomson and C. Huitema, DNS Extensions to support IP version 6, December 1995.

[RFC2065] D. Eastlake, 3rd and C. Kaufman, Domain Name System Security Extensions, January 1997.

[RFC2137] D. Eastlake, 3rd, Secure Domain Name System Dynamic Update, April 1997.

Other Important RFCs About DNS Implementation

[RFC1535] E. Gavron, A Security Problem and Proposed Correction With Widely Deployed DNS Software., October 1993.

[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller, Common DNS Implementation Errors and Suggested Fixes, October 1993.

[RFC1982] R. Elz and R. Bush, Serial Number Arithmetic, August 1996.

Resource Record Types

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, New DNS RR Definitions, October 1990.

[RFC1706] B. Manning and R. Colella, DNS NSAP Resource Records, October 1994.

[RFC2168] R. Daniel and M. Mealling, Resolution of Uniform Resource Identifiers using -the Domain Name System, June 1997.

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson, A Means for Expressing Location Information in the Domain -Name System, January 1996.

[RFC2052] A. Gulbrandsen and P. Vixie, A DNS RR for Specifying the Location of -Services., October 1996.

[RFC2163] A. Allocchio, Using the Internet DNS to Distribute MIXER -Conformant Global Address Mapping, January 1998.

[RFC2230] R. Atkinson, Key Exchange Delegation Record for the DNS, October 1997.

DNS and the Internet

[RFC1101] P. V. Mockapetris, DNS Encoding of Network Names and Other Types, April 1989.

[RFC1123] Braden, Requirements for Internet Hosts - Application and Support, October 1989.

[RFC1591] J. Postel, Domain Name System Structure and Delegation, March 1994.

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie, Classless IN-ADDR.ARPA Delegation, March 1998.

DNS Operations

[RFC1537] P. Beertema, Common DNS Data File Configuration Errors, October 1993.

[RFC1912] D. Barr, Common DNS Operational and Configuration Errors, February 1996.

[RFC2010] B. Manning and P. Vixie, Operational Criteria for Root Name Servers., October 1996.

[RFC2219] M. Hamilton and R. Wright, Use of DNS Aliases for Network Services., October 1997.

Other DNS-related RFCs

[RFC1464] R. Rosenbaum, Using the Domain Name System To Store Arbitrary String Attributes, May 1993.

[RFC1713] A. Romao, Tools for DNS Debugging, November 1994.

[RFC1794] T. Brisco, DNS Support for Load Balancing, April 1995.

[RFC2240] O. Vaughan, A Legal Basis for Domain Name Allocation, November 1997.

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby, Domain Names and Company Name Retrieval, May 1998.

[RFC2352] O. Vaughan, A Convention For Using Legal Names as Domain Names, May 1998.

Obsolete and Unimplemented Experimental RRs

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni, DNS Encoding of Geographical -Location, November 1994.

A.3.2. Internet Drafts

Internet Drafts (IDs) are rough-draft working documents of +http://www.ietf.org/rfc/. +

+
+

+Bibliography

+
+

Standards

+

[RFC974] C. Partridge. Mail Routing and the Domain System. January 1986.

+

[RFC1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. November 1987.

+

[RFC1035] P. V. Mockapetris. Domain Names — Implementation and +Specification. November 1987.

+
+
+

+Proposed Standards

+

[RFC2181] R., R. Bush Elz. Clarifications to the DNS Specification. July 1997.

+

[RFC2308] M. Andrews. Negative Caching of DNS Queries. March 1998.

+

[RFC1995] M. Ohta. Incremental Zone Transfer in DNS. August 1996.

+

[RFC1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. August 1996.

+

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. April 1997.

+

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May 2000.

+
+
+

Proposed Standards Still Under Development

+
+

Note

+

Note: the following list of +RFCs are undergoing major revision by the IETF.

+
+

[RFC1886] S. Thomson and C. Huitema. DNS Extensions to support IP version 6. December 1995.

+

[RFC2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. January 1997.

+

[RFC2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. April 1997.

+
+
+

Other Important RFCs About DNS Implementation

+

[RFC1535] E. Gavron. A Security Problem and Proposed Correction With Widely Deployed DNS Software.. October 1993.

+

[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation Errors and Suggested Fixes. October 1993.

+

[RFC1982] R. Elz and R. Bush. Serial Number Arithmetic. August 1996.

+
+
+

Resource Record Types

+

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. October 1990.

+

[RFC1706] B. Manning and R. Colella. DNS NSAP Resource Records. October 1994.

+

[RFC2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using +the Domain Name System. June 1997.

+

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the Domain +Name System. January 1996.

+

[RFC2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the Location of +Services.. October 1996.

+

[RFC2163] A. Allocchio. Using the Internet DNS to Distribute MIXER +Conformant Global Address Mapping. January 1998.

+

[RFC2230] R. Atkinson. Key Exchange Delegation Record for the DNS. October 1997.

+
+
+

+DNS and the Internet

+

[RFC1101] P. V. Mockapetris. DNS Encoding of Network Names and Other Types. April 1989.

+

[RFC1123] Braden. Requirements for Internet Hosts - Application and Support. October 1989.

+

[RFC1591] J. Postel. Domain Name System Structure and Delegation. March 1994.

+

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. March 1998.

+
+
+

+DNS Operations

+

[RFC1537] P. Beertema. Common DNS Data File Configuration Errors. October 1993.

+

[RFC1912] D. Barr. Common DNS Operational and Configuration Errors. February 1996.

+

[RFC2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers.. October 1996.

+

[RFC2219] M. Hamilton and R. Wright. Use of DNS Aliases for Network Services.. October 1997.

+
+
+

Other DNS-related RFCs

+
+

Note

+

Note: the following list of RFCs, although +DNS-related, are not concerned with implementing software.

+
+

[RFC1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String Attributes. May 1993.

+

[RFC1713] A. Romao. Tools for DNS Debugging. November 1994.

+

[RFC1794] T. Brisco. DNS Support for Load Balancing. April 1995.

+

[RFC2240] O. Vaughan. A Legal Basis for Domain Name Allocation. November 1997.

+

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. May 1998.

+

[RFC2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. May 1998.

+
+
+

Obsolete and Unimplemented Experimental RRs

+

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical +Location. November 1994.

+
+
+
+
+

+Internet Drafts

+

Internet Drafts (IDs) are rough-draft working documents of the Internet Engineering Task Force. They are, in essence, RFCs in the preliminary stages of development. Implementors are cautioned not to regard IDs as archival, and they should not be quoted or cited in any formal documents unless accompanied by the disclaimer that they are "works in progress." IDs have a lifespan of six months after which they are deleted unless updated by their authors. -

A.3.3. Other Documents About BIND

Bibliography

Paul Albitz and Cricket Liu, DNS and BIND, 1998.

PrevHome 
Troubleshooting  
\ No newline at end of file +

+
+
+

+Other Documents About BIND

+

+
+

+Bibliography

+

Paul Albitz and Cricket Liu. DNS and BIND. Copyright © 1998 Sebastopol, CA: O'Reilly and Associates.

+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   
Chapter 8. Troubleshooting Home 
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html index 21d46214cc8..71ec32992eb 100644 --- a/contrib/bind9/doc/arm/Bv9ARM.html +++ b/contrib/bind9/doc/arm/Bv9ARM.html @@ -1,851 +1,222 @@ - -BIND 9 Administrator Reference Manual

BIND 9 Administrator Reference Manual

Copyright © 2004 Internet Systems Consortium, Inc. ("ISC")

Copyright © 2000-2003 Internet Software Consortium

Table of Contents
1. Introduction
1.1. Scope of Document
1.2. Organization of This Document
1.3. Conventions Used in This Document
1.4. The Domain Name System (DNS)
1.4.1. DNS Fundamentals
1.4.2. Domains and Domain Names
1.4.3. Zones
1.4.4. Authoritative Name Servers
1.4.5. Caching Name Servers
1.4.6. Name Servers in Multiple Roles
2. BIND Resource Requirements
2.1. Hardware requirements
2.2. CPU Requirements
2.3. Memory Requirements
2.4. Name Server Intensive Environment Issues
2.5. Supported Operating Systems
3. Name Server Configuration
3.1. Sample Configurations
3.1.1. A Caching-only Name Server
3.1.2. An Authoritative-only Name Server
3.2. Load Balancing
3.3. Name Server Operations
3.3.1. Tools for Use With the Name Server Daemon
3.3.2. Signals
4. Advanced DNS Features
4.1. Notify
4.2. Dynamic Update
4.2.1. The journal file
4.3. Incremental Zone Transfers (IXFR)
4.4. Split DNS
4.5. TSIG
4.5.1. Generate Shared Keys for Each Pair of Hosts
4.5.2. Copying the Shared Secret to Both Machines
4.5.3. Informing the Servers of the Key's Existence
4.5.4. Instructing the Server to Use the Key
4.5.5. TSIG Key Based Access Control
4.5.6. Errors
4.6. TKEY
4.7. SIG(0)
4.8. DNSSEC
4.8.1. Generating Keys
4.8.2. Signing the Zone
4.8.3. Configuring Servers
4.9. IPv6 Support in BIND 9
4.9.1. Address Lookups Using AAAA Records
4.9.2. Address to Name Lookups Using Nibble Format
5. The BIND 9 Lightweight Resolver
5.1. The Lightweight Resolver Library
5.2. Running a Resolver Daemon
6. BIND 9 Configuration Reference
6.1. Configuration File Elements
6.1.1. Address Match Lists
6.1.2. Comment Syntax
6.2. Configuration File Grammar
6.2.1. acl Statement Grammar
6.2.2. acl Statement Definition and -Usage
6.2.3. controls Statement Grammar
6.2.4. controls Statement Definition and Usage
6.2.5. include Statement Grammar
6.2.6. include Statement Definition and Usage
6.2.7. key Statement Grammar
6.2.8. key Statement Definition and Usage
6.2.9. logging Statement Grammar
6.2.10. logging Statement Definition and Usage
6.2.11. lwres Statement Grammar
6.2.12. lwres Statement Definition and Usage
6.2.13. masters Statement Grammar
6.2.14. masters Statement Definition and Usage
6.2.15. options Statement Grammar
6.2.16. options Statement Definition and Usage
6.2.17. server Statement Grammar
6.2.18. server Statement Definition and Usage
6.2.19. trusted-keys Statement Grammar
6.2.20. trusted-keys Statement Definition -and Usage
6.2.21. view Statement Grammar
6.2.22. view Statement Definition and Usage
6.2.23. zone -Statement Grammar
6.2.24. zone Statement Definition and Usage
6.3. Zone File
6.3.1. Types of Resource Records and When to Use Them
6.3.2. Discussion of MX Records
6.3.3. Setting TTLs
6.3.4. Inverse Mapping in IPv4
6.3.5. Other Zone File Directives
6.3.6. BIND Master File Extension: the $GENERATE Directive
7. BIND 9 Security Considerations
7.1. Access Control Lists
7.2. chroot and setuid (for -UNIX servers)
7.2.1. The chroot Environment
7.2.2. Using the setuid Function
7.3. Dynamic Update Security
8. Troubleshooting
8.1. Common Problems
8.1.1. It's not working; how can I figure out what's wrong?
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?
A. Appendices
A.1. Acknowledgments
A.1.1. A Brief History of the DNS and BIND
A.2. General DNS Reference Information
A.2.1. IPv6 addresses (AAAA)
A.3. Bibliography (and Suggested Reading)
A.3.1. Request for Comments (RFCs)
A.3.2. Internet Drafts
A.3.3. Other Documents About BIND
  Next
  Introduction
\ No newline at end of file + + + + + +BIND 9 Administrator Reference Manual + + + + + +
+ + + + + + + +
BIND 9 Administrator Reference Manual
   Next +
+
+
+
+
+
+

+BIND 9 Administrator Reference Manual

+

Copyright © 2004, 2005 Internet Systems Consortium, Inc. ("ISC")

+

Copyright © 2000-2003 Internet Software Consortium.

+
+
+
+
+

Table of Contents

+
+
1. Introduction
+
+
Scope of Document
+
Organization of This Document
+
Conventions Used in This Document
+
The Domain Name System (DNS)
+
+
DNS Fundamentals
+
Domains and Domain Names
+
Zones
+
Authoritative Name Servers
+
Caching Name Servers
+
Name Servers in Multiple Roles
+
+
+
2. BIND Resource Requirements
+
+
Hardware requirements
+
CPU Requirements
+
Memory Requirements
+
Name Server Intensive Environment Issues
+
Supported Operating Systems
+
+
3. Name Server Configuration
+
+
Sample Configurations
+
+
A Caching-only Name Server
+
An Authoritative-only Name Server
+
+
Load Balancing
+
Name Server Operations
+
+
Tools for Use With the Name Server Daemon
+
Signals
+
+
+
4. Advanced DNS Features
+
+
Notify
+
Dynamic Update
+
The journal file
+
Incremental Zone Transfers (IXFR)
+
Split DNS
+
TSIG
+
+
Generate Shared Keys for Each Pair of Hosts
+
Copying the Shared Secret to Both Machines
+
Informing the Servers of the Key's Existence
+
Instructing the Server to Use the Key
+
TSIG Key Based Access Control
+
Errors
+
+
TKEY
+
SIG(0)
+
DNSSEC
+
+
Generating Keys
+
Signing the Zone
+
Configuring Servers
+
+
IPv6 Support in BIND 9
+
+
Address Lookups Using AAAA Records
+
Address to Name Lookups Using Nibble Format
+
+
+
5. The BIND 9 Lightweight Resolver
+
+
The Lightweight Resolver Library
+
Running a Resolver Daemon
+
+
6. BIND 9 Configuration Reference
+
+
Configuration File Elements
+
+
Address Match Lists
+
Comment Syntax
+
+
Configuration File Grammar
+
+
acl Statement Grammar
+
acl Statement Definition and +Usage
+
controls Statement Grammar
+
controls Statement Definition and Usage
+
include Statement Grammar
+
include Statement Definition and Usage
+
key Statement Grammar
+
key Statement Definition and Usage
+
logging Statement Grammar
+
logging Statement Definition and Usage
+
lwres Statement Grammar
+
lwres Statement Definition and Usage
+
masters Statement Grammar
+
masters Statement Definition and Usage
+
options Statement Grammar
+
options Statement Definition and Usage
+
server Statement Grammar
+
server Statement Definition and Usage
+
trusted-keys Statement Grammar
+
trusted-keys Statement Definition +and Usage
+
view Statement Grammar
+
view Statement Definition and Usage
+
zone +Statement Grammar
+
zone Statement Definition and Usage
+
+
Zone File
+
+
Types of Resource Records and When to Use Them
+
Discussion of MX Records
+
Setting TTLs
+
Inverse Mapping in IPv4
+
Other Zone File Directives
+
BIND Master File Extension: the $GENERATE Directive
+
+
+
7. BIND 9 Security Considerations
+
+
Access Control Lists
+
chroot and setuid (for +UNIX servers)
+
+
The chroot Environment
+
Using the setuid Function
+
+
Dynamic Update Security
+
+
8. Troubleshooting
+
+
Common Problems
+
It's not working; how can I figure out what's wrong?
+
Incrementing and Changing the Serial Number
+
Where Can I Get Help?
+
+
A. Appendices
+
+
Acknowledgments
+
A Brief History of the DNS and BIND
+
General DNS Reference Information
+
IPv6 addresses (AAAA)
+
Bibliography (and Suggested Reading)
+
+
Request for Comments (RFCs)
+
Internet Drafts
+
Other Documents About BIND
+
+
+
+
+
+
+
+ + + + + + + + + + + +
   Next +
   Chapter 1. Introduction
+
+ + diff --git a/contrib/bind9/doc/arm/Bv9ARM.pdf b/contrib/bind9/doc/arm/Bv9ARM.pdf new file mode 100755 index 00000000000..6119ca4ce24 --- /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øãê$ +•ŽC@³ÿÄ~ᤊµ„μa,â>OÕõ2PL¦¶@±f/páÒæe2X.¦ŽÍOâØn6í®Û½ûæxèÇÕsÞæ>wë<ŽOM÷Ñ짫ôX,ˆ0šñÉ‚%(¸ 8 l'‡åá3·¯ù¬¥Wcgïm¨nÓå—ïðÄpˆçßÑ}ÂmR_endstream +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 ¨E­v ªM¨Ý%ú‹1 †9$ª»)’„ÈÀ4tR?hÍÈìTæăeâˆßÉdfXyð–¬*ÖJ³ƒxŸU pËкC¿%!šqš‘` ¥‹æU[6UÙvÙâ°oËݾKòºÚ×M»}Ûì +ÒŒ5†y‚K"3_äñ©Žã“Ûâd&Šk­rF‡âåOŸt6Ä/kã|ßõ7ôŸ±÷¨ûú/Ú­×íûS“êé¨> 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;Ųôž°Ã`‡ŒÐ<¨âÔ2sœV qå +,¨ç÷ì!â–ÁÇ­_«:”BôbSHúêqý"b)Nê6̽Uó4Ky&Y@qFR&9bž¦BJI³¸‚|¾o‹Éyn9˜N¥2ódÈhòÖöŸ ¨| +.ƒpŽ(£cžÀØeÄÛ߇”É1hÎ}€£¼œi5ǵÛ{˜¸™[N˜‡YÓþÑ‘?—ûì¬÷ÚfÉËŽLð*]jàŒ>˜ /£_üS‡±{®JÞƒ÷«‡Uí#ô@?¶SPļõ“†@8ŸÕ”8(0¾~b3Ó+ˆš¾æq ‚ÖOóø·áÕÓÔøúrI)uåž™vð>¯JÔEK"K 0$€qÀ7Ø°H|!Z36î¹sîqA"Úל…zî5ï’a<¡ÈÔuû§<–¢! ô{‚.8[W)W*f­wI^vPþªb‡jW® ðÛ·G6…§¼|Î!ëÊãLŸhmèX@|dæ-φR× Ÿ—²9ùºt“@¢4ÖwcêOñݱèb?’Âö£¯·î¡íÜé—ABSÍ%½f™ˆŒ`8_b©JÎØÈ  ®¶»ñźÿ&ˆH93ÙM mýŒm©«ßJ†E1Û¸¦d@¶[—Á‡%3ž]q°SKÁ‡!U‘ NeR]'ˆò°uVô} ¦?a{bøöXú`Œí( é6[bŒçk›m‹)åU¡ØM€‰ )ŒžgL“ãF,8AÆÈEÞ]{ p—eäšAU-9I¦R›X +Îzè°Ÿ-&¸Ð 3*¡ÉõÈs Ť窅p)ÀÕ|ɽd‰NµÒÑ’YZº[EèÆáî²k[Ÿˆ· ®¡ös¼ílÝ9ŒI0&uÚT©’Ƕ<àÈ;Wªà\ÌúHxòÄ$ψɩåÁšKÉgà–¬#PÿÚu¶)+WùO¡Oý²C^’*:à¦ö4Õ8¾F$z‚jà:)Ï=1ëvß8’ÞžÜ< ž+×—/•=à£D°ëmõXWí¶Ï»Ýa©îAÒ -#ˆ|ó@_4ç›Øæ¬ñv¯ñÐdÛ0ß%’›hF±ÓRHAêtKqBwÁ4‚º@…¼H#¼ã]‹ÉC‹ ù³#ܶ ýäC¼ÜUÍ·õšØ;GÝS¯é_BO ‘¾è²}á +D’­m<ìpҡèàíƵáGó¿sV­þöpüöÆHh5]S¡S"¡•+ö«ßV?ÿJÖ劬X‘”-Ö/ðÞ4@ +û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¾^ÊSÂY„Øx*+À*}¬yÝôüÌ6z5F¼4\·„Ÿ¹ñ3ýää‡oÛº¼ ¥W3ýÿJF¥ÄPó%$­lqú>õ%‘¦ñs šmñZº´úÍ­¾‚Ð-༚¹Ü0÷—¢Ò]!àÁ²ù/W¿2OÁ@¨0_k½ø3aüõoÃEê~L\D‡ äŒdë0ÉE_¹=þàxZ)îö+‘Xendstream +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’%ŒA&@ÑÊ_ßÝÛ= +Ó¦ÓŒpÜ;Üí×íþv!¹ð'W± Uv•Ø(Œ…ŒWÛý•XÝÃÜß®$¯YûEëñªoî®þòΨ• ­Qfu·핆"Måê.ÿ9a^Ã"¸ûîíõZÅ"xóá‡×7ïiüþõL½ýçíÝÛhü‹ˆÅ›÷·ð×k)M"‚o¿{ýãÝÛ4/yË›÷w?¼ùÇ·w7Þ_ÿz÷ýÕÛ»ë±dRhdùóÕÏ¿ŠU~%BmÓxu‚"”ÖªÕþ*ŠuGZ{Juu{õ÷aÃѬ{uQSR„JƒV檊ô’ªb­´SÕÝCAâ횪jNe}O?·MýXÔ}ÙԲõL^|슜FeMϼ趇²½ÐìèÙû¾¹yÿfØü!Ôýñá ^ÿBUÅ_/UjÒÐH\GQÿ¿K§Ê†‰H.túŸ½åù+pŠÐÆñW8 ÷ìÅCÿÆt«µ—ihÆ2웑½’(´i²J´_†Ìu-¥ š±Î7 ³µL•ÖÁO×JŒLt¡ÿ®ZÐod“ÐJ‹ç ¼üwÒ¡5ÜÅÿ‰Â”ãö^ôp¯1·/Š#§±OÅÓ©q¾›w(;(9½¢TB' +·ú]ù=Ûü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¯Ç²`St.ÌíŽuž¡YÕÑ”c fxItÖ>ŒYû0=h¨p†“Y73áô›:-åÙdçk@6ƒÔ*ŒNÐ(Ù/à(²ú»1óËfCÛ‘ÙuéÄ°@Hõ!u"N¢ñq¢÷{<”ÅŒ´}(·Yõêz‰$ÈË®‡¤ì1Šà yÖg›¬+žšÔ7=‘»ž²^Ññþõ®9ìÙkpü\2÷>k[2"nV÷Å¡.œGM×½™:’³ÆÁÍô;Ës>·óKØ?ãà±ÜDz,])Á‰eET÷bsì‡óGLóbÞË (ê@CÔÀ’(g”êüž#yÒ¶mšu˜56HC% +ßV%˜ÞÅî8¨šæŽ-='*%=rÅÞL°¹–Á Á”ÃlpcN³f’f!$§&â4ËÚl*ÐÙ‚ j )AK^\•<O%¾¢óNà=tZWÔ9KóùXJg ˜mĦf¾›=÷ìC \®•Ñ¡²6ö:§œX“·»Ãhå–!(§ŠÅ9¼h§<°MKç¡ÎµW$X -XªèÐÓUÌ·-Ž9²áÈòÑ“‡”áÖûjî(”ÑÃso˜ûë$ +^ ±c$<‹0q7|9_²­Õ†å}žW³kö'Fó;; +¬´Ä‚T*L’T _Å’º#H¸Âª‘¾v—‹17ûÍ6e½( ¤V!ý^‹au­¢$Œ5:ÆexU>¼ºðØ]hâ2%àšQ¸•`”œ£^N3.KUaàn$®tñWäXæbñéß`1ww ˆ â< žûø.},œ³jdhâÈ«ªÈzZöKà‚¸½Ïêò7|ÆŒ±D=-gö³í–‹Bœh =‰¾vq ””†B"@_NwN6€ÖTÓE‡g–ïËïÌ>DÛ4˜üÐÿBL=6x›¹@Su“ó"‚Úà =ðëâµtÑÎEa•€ñ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¡{Ò<ÕÕ’4ÑX§¾Ñ24=롘Ÿõ£òIL›„iŒæ—ЈYrDö^4á«eüy8ê ¨æ¡ÃÆE€¾Ä$ár=NÔ.{›¡½žñJN› ùÀ•Ò©/~ƒ½–À€C©Í(]ꯤLᎽ™q ïùÉf7p[’È^`{Ê<±ô˜ [Ös.g°ŸqªiD%…ôÚ–pg²p›Ž†TgœW¦Îw™Vr¹C’Ù »! r/G!DAéÇÎQxá÷—ÊEï;c 9nÓ-Á@ +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 Ÿò7>aãæãÇ7èx6 +nÏ´ 1Ì)*¡qNÚ«´|=^?ï‰ÏvEán‹íù›ÔL¡¼d!¿”JN¸™µx‡U/01ßmä¨*´!­ZDWæÜÞp•V^¸¸QVT‰%-3¬¾è +N +JÐ}y_s5·[®6¹æʹÙÔø: 5ˎׇ»â0®ö’ÁÅ.bD¬ÙøsÃLê1w¾©ÐõÏ;Š´PµBÙºR" +ê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¿2zo[úa=™¶9ÕÜDf°ë ˜v|ÒX¡øåw[´ýR7lºVÊÊVé(ÝÊEiEe%’=’ƒÀ®g¡Ñ—F/‘Úa‰—ÃDG¤}vøD›Zj~$îÎ[¥åõs(Á’| ‚„7¿Žž"2öuœÓ–²g„¹þ†î±\¶JPÞ9Vî¨×0î€çm.?ûŸåcV Ûyì;ÅXY]‚ì¡s¶\FŽ­Å¬†Ïý_˜ŽÃH/æ0±zñ?~ïÿŒÿujE¨ûÔ3É0Åþ ˜B½G3Æýÿ–Í9ÿ7pðÒendstream +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•ØÞ8U¶³6S[©$„D”@€KR´¿~û5HBö¦¶tà g0ÝÓϯÒ z‘ºHÙ,^$Y9¥Ýb{¸Q‹˜ûÇ–5«°h5]õýúæ»wÞ,²(óÆ/Ö÷“½ÒH¥©^¬w¿-øñîçõÛÏ·+ãÔRG·+çÕòýÇõçOo~ùaýþÓÇÛ•Ö>Á¹Xf×?¾ååo>}¸{ÿ‘Çï>õ˯_Öo?ðøwåÔ›_àGßþ±þéæízzz2­,Šüï›ßþP‹ð§Ù,u‹gxP‘Î2³8ÜÄÎF.¶6Pª›/7ÿ6œÌÒ«sšr6\j’UÅvNU.‹¼5–Tõ®9Á©L¼,ë¶Ëëmñwx´j¹mê¶Ü4é–ݾÀ£~÷Î%“ µ¶QcE[æ‡cUDÛæÀ‹Ï¸û$Ê2¥eí®9äeÍœŸ÷åvÏ|Êz[õ»¢å‰:?ðÐ-Ûž—Ä˼“ÄÃ8Ó^vß7måy‘ð•ÅÊ:e&ŸÒ0pÎÐâyqŠŒO­l˜×»9®Yd”1S¦›Í&úº´ÑQš&á­â©@5ØtÜôxHûš¾yãþGuc8d²ô?M]0“‰‚MSW/LßUñw%X§îÁ/XiÊF*1J{Å!\”fÞ¥M 0/d¦£$6ßPr +>悺¾­ßó=ñä-„¸Éüò~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!­Øiy’g:–UÈeË¿¹ÜO n³HyïÏ3ÅL„fGÁÙÈq'å^XuËk^]ObÙ£+N‡²Î«f6Ë*άÛç0k…´Ïådu3ÃÎûH™”m¿á³µ3üâ$JÂBr_7Uøðª„hÕÁk}n Ò±MÈ}­3.’ ÒhPÈž0ç=„Á¶8vLgS€ Ø4/v'—ø$£l ¶Y×á}ÖnS5‘·ð *aUÖ]_våS1JyæxOÏ蜃mÿðÀ¾Áɦ@òKÓ3‰.ß1ùó»ZA]¶H1c&’FdÖÉ– SH-– ï@úéDŒ¾†*‰¥sù×Q bÙ—-Svà ÍïJ™m_usñÄ6x +ì(ÏÀ¸kŽåv?¬I6IiùZª…UjùýûoxÄü zçUE®8ƒéw(žÁÆø,Q#ŽrœGµhK!ƒ»¬ËÃã©<䧒òò‘MЦ-³áC«!ãƪöÂâ·¥”gÞ¬m•?ÑjpÕb[å§P¬J„Ÿ‡(¨ë*•xÁ“í :Ô÷suÑDé‚hJ˜¶Çb[Þ¿0?:9‰b÷D¢D+ž-É–ÿÚ5ÓÅã<@“G¦´ÍAv i”]Áñª¡'q–^Ä+*Ðr²Xª[~~.«Š] ABÃDÊæðœócPPØšLÆ"NDñ4—j/&ÿrªµÎ˱QŽ4f õ³ç{‘©öQDŸ3ëHØr+’ËÇêãŠjâÈëØ\"6ðî-ºG ºþŠë±üf1¼r¾£áÂ~|­À5ïz^§²Ë%ñ ìçz†°Ÿ àŒJ0±ÚCñ j˜SÉ5VàŽÈ€Æ°EvLÛ¼ð/e+ø­Š¼•!¾7c"‡cðO~.-¾' #1ý æTP¾2«'ŒGœoB°tT‰è‰ñH>Ét@Þå]Î#¶”¬dCyààFècô…e M–ëÛÌ,±R$²Á#ê7$ƒ$Æ Hiªâ”דɲ@ N4N”@¬‹î¹9=2õ>/«^ðÖâÔ,MÛñJr ^·'ß#NÏ ÙøÐGFªhz5—«§Îr‰‘8I'´îsÑ!‡q“,﹄ð)½4%.½x^$5¡ÃsôÕkX¼ÚgNಠÔ»;êOi~Cˆö—·^鸳hŽ¤å©c¾}œ=|Ña +t6ƒôÎ.žEÛœ˜®ý"´†)ÐPÖ'Y >sú®Ø@1çLä 8·ÄýÐÅV÷í°²kšJ¨UùX ¡?R:ŽLêCüìʇ¹øH¡÷öv¨ +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ÒÌÄ!ä`8gq(8 + ‰\ù€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äÓ˜‰›¿¯çÀ^X 1øÌðxGðžsÁ¿c”(ÝaÇ/u½ìÚ¢’ šC´g{L³ +f²}¿¾ewÅkÑá"ªkŽ¼¸*žŠÙûg:‹¿Q¨³Ô…r•‹?ç?k¥Ï'º÷³Á 4ì±_þJ {ÏtþRâ-©ŠI£bñàõÌF“I8ÜŠÏEÔéÃ參±¶½‰’عK´CÊœ† +>ðű„€q™°? BBGÏ$3)ɶN.Žq‡•³p^ Žç¦_c8 YšËžÓòr~ÂWI¥„`­CÆ”ß.4Oƒ†ùš˜¤æÙûâ»yÄ<Ž­§[D(ÜO)AP½œ-°Ð4{ +,õ@ž/$½ñŸ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‡ûü!/°:âÛ2`ÁÁ½š¾Ã‚ðoµ‹^ûè¤ñßtfnÚÔð!âÿþo ñŸ¢â$²ijæ¯ì¬Êðkõ *Í]Ýh†ÿº–ü¿ E×endstream +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øÌÐç‚ÔÕî¬Î•î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@ZÒg‚Zþ2/7õ”öDBþ{£Š‰ìôQÕæóy(óË‘ºY¿?ÆUG_౶† cµ`„yäi.Ù–XÄùCaÝZž,‚P‚_¶ñ~G'ÿ•îéË÷îNÒH‹ÇÚÍuÛ~NKÖŸáÅÝN8Àá“6ðÊu¥Mº%ã Îcˆ>" +åäÿ÷E´ýÈ4_Wóq€Â1®L©Á$ š]3ˆ»:5vG áˆáý‘©°‚‡ºïhýz‡êîèö]fǃÎÓ4Y?WÀƸqÁ´'~e=Hä²q8åÛÚ,)³§µÒ‡P„úà“ÊôU£z2|Äl¿ÓÖAbÁ6 ½^V¯öÂL¾£]8-õV¹i@:sÚE^Œ§¢D8œÙ5Þ¥ ZL‚¢Hò+Çñ×»i½64:ç3ÝÅ´æÒ´CÒB¬¯kNÙ˜NÐPjm^ú#­¾ P[ÕðªµV¼«’±ÔÌÂZûݬQ¢°ÓS¤^UF3Jeæ_²­b´Hχ?É 'äÂ8rÁ7WÝR”3èÉÔÆbC5|É$`°½O’uÕø¹Žñ¾õËvû Õ/#]»(ÕumYùñü­BâH«’G.xvPê)ÔÉ0`3ˆæUä;!&ÕW®)~jÏoê¼GÙü×úáã+™JJ±7˜!L\`L'!9[ï[랸Þö<ÐèµPmXWÀ˜+`ÂBâmsªuϳ›h™r$¡qÕC.µ#*Æ̶ OŒÓR¢A˜¥ê«Ô,ã,Êf)%€TD苘ÖÚPµ¦_…µ Jþðç ©Ì U,8š°eå„ã²ww¸Ðä@FØ9@ëŽÆÎè‘^ËÇ£>;’Îô%›¾Mi¡!KçQ•5Ùø;N+mÓ´¦¾Lmí Ï4`[í[gÃïg\…œKv1jAº +é8¡‰<b)¢«„†—¤X&Á(tÀ`Ç€ÖØABzAŒvŠO\X¿¤†Y/(UH2D&§¦›HŒc#âg Fj:”tŽ†ZaÍlñ;úêÕÐõŽŒclò¦Ð1Ý›UfL*ýÐfOV° »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áåèšÐæÇ,݉…I9õDäù’Õ‚ù-жc0ÂXk—÷Œ_õ^dÊuRòÈSþìȺÝåê´Qb¦6Ì3Ñ”*@ù^9Ñ”HüÙÿþ‚¢éØŠ$!˜Ž!<µ·}1­BìiÅZ€‡ŽB®pa@ÌÂ_”"Ä*Æ:ŒêzIc{ýªëö䣱ý4ƒ+#ÆÈÞgÙÐå* ¹±1¶-à~ÍV=Š{f…w!Ž˜Û¡¾ñºÚ¿*Ó«ÆX¯LB°` +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¿¢nØÃçY¾:št†£™Î´{ÝñDo…¤]Œwƒt“^— +öº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:>Á ÓM¿t³+âDÔù¦ªó¸HÒb³ï_%›#Ìýô*e™¼q‘ ƒ•Ùm!vq±ËªÍviäÍã«ï~̳M–Äe™›ÇCX«¬ª8)ª|óØü½måɪéa›I”=üõø ©åqµ«RTK`‰ +Œì„SxóþÃ$ý»2ã<í•ý=ëIõj°&˜IóXäeÆfÊ".ÅŽÖÍâôa›&Iý,§æ"'63}mFlê¸.³’­ˆ4Îïþ‡A­Ì¢VNé.BCøEc¥ˆˆFƒŽ@£idh²•gEÊv’¶zd×]‰õ¤Ô@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ùö·?ˆÐƒÅ(y•v¼(ØúC•GýDŸŒÎöQú‹Ü®€;2<¤’£zù¬ˆj•<_‰œ óœGN^aR1÷…ç¥wˆ‹6-«ŒôÝâºq·FåîÑÍÕXÕ³•Ã8…åüZòtêôžÒ-^óŠƒ ¨é£ÑÚ.3e:°ú¹³Ú¶´eÙ¨CWç$òxÑÃñ¦@ò³ÕD%†‹ƒ7ć¸WƸ ƒêÍ "7p'Ë»B¬¯oGê¼”O]mã–¼ˆÌS†–Œ¡…eœVQ… Ω¥u²††fœHPˆ‘ªYGGÅBášâHç»r»ï¤a½Ü·zP/ âõsaÇÆÖ1-jOô—1(]ààÆÙÒ`ïì_¯¦7&\.À…™N“6Êï¹·dIéq¯ãL„»e ÑÞÐ✽ ‡‚ ß\Ùãf‘=ŸiËHo% ÐF ä€v®­:¢‚§Ék…î0kHºïß³š´2þ<°Á}kþ;ƒ8'Яª§ëÿË¡|”pzo¢´?àY?IXKtë¤\ŒñÄBhZ ã|lÙ‹~J’̲¶·ùÀ$ΔëF¼ìľ4Ú¹öIÆ’ìE²º7Ù(À¸^¼ªm]LC,²xGh†µ‚³¬M +Íž3_·F^¢vß2Ëm @=¦Â­FÍ4F€!g,©£ïÖ‹HúÔ…ˆ‹Rφ´‚ñ¥É{ìÅI@Á®!šë8ìnåè$÷ØNý;+ß‚ÇO7Œî®:êÒª‚0è»áª¼›ù|ÒSèûþ”œ(’ ‹®ó Ý9.8 }]YàIëps”V·s ’¹Ççùdp#Eí[šƒN"wy‚“¸YœpÅ3ÁnÈÒÄ|òŒå‘!GC´Â©!㶃۳,x“ô^BÊ7`+^è¡QPGÈÆvt#pý3À¿R^¤6?L*2»<¼<(¼ÀÛú¬›Yò[eÑØÂ,¾#üSc$×>àHêgw†¨¼R)¥ÜeO½D’E'xxNDJCs˜²8¦îáRá6÷Ý8&RhHfž¥ vëͱ™ »3Ùœå`å‘ ».'Áÿ!žD":dÇ =òÿ+½øÌ^ßÃ1G{Ñ\8¤Þ²ípƒ¸žøÏO9l +½z÷þËòÿP‰"Æÿ»Öþíò"Û› ýÕµDg(°±È’`Ý«^.þ7ûzµ;TÃendstream +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ö õ9uŽ Hx@Fç#¤<骪¬[™×*YoÛ¬ØÇ>šVš¾cU—N>.áÐ +.â¹ÚáñÑ@/°…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 )‚1pE.-S¶p²¨ˆ”Mpÿ=C)Û» +.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- <Ïâ®S—ÖÖÂn5D Uíüé«Ú¡Ð¶†}ŠÁ÷Á0¶Â{pÛVÍ)x#wñZIïâuþ|·òÜWÛ +¡Ä¸ØyýºkeoôRÛƤ(fÕ>Sç9³áƒÂСgr–FO×üu’ckûÌnÌã„;5íÚÚZ +®Ý‰ÀÁ ®vª“Fmo¨íµ<ç­ ×›ùØò²P°¬$e‘s¯‹mè:1ÂRÊØrOC´g 8SJ£/^µ¼žÛD66øf÷µšº=.w^ÅMž¥—úÜœ•©5×ù°íH\„Å稌¦Nj?(Yq߇hÅÍK’’dÃÒw÷ÂâVøéÝRSbµf›VƒU¤,‹ê^oߎPõwšiêŽýîÑ:°Â€Ð{5~t5°›ëÅ¥Ünúê6«ê}èñbdËy…X~ÕÙMˆÃ#4˨½ìÜ0ëæÚUëè;¥†¨?zÀÑŽŸÊ ð…]ÊìwÕ{ NtÛ>¶÷‰ñøYÀÍË0Go¨q1˦킗NÕ¢;*m¤÷øn)¦^™¶ñ@÷êó˜.ð} +ó:ó= |ïß;O“9ª¦ÎÎö¿¤}GÞ´rDïXF÷-˃*–ž•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> 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¸”C%#èTL"EUD)‰ºþa«ç‹˜Ò°Êº^·/Ì–@î‚1’F·L7Eé˜ÎÊf•›¦ëI«ïÎ&¹ë¦/n¿neÁS¢T’zN<·?&ç?Žs¯ÜšYëˆ~s *Ònï<}Ó8BÿžUÛR“uSM­ðï¦öûqža×ìŒI}ÿ*X#á$¿>ûân/>ºÝæy«»NwØlnÜ6ËìNwìƳ²lîuîjÜ·ÍêîF?nÊJXN™Äõe)',V \NnÈ3D$_qø‹ÉUþ¢ed'@:6‹ú–<ÆØ4¹Ïž„foV‘'­ãP>¹þ|l!ìKrhÇ[;uO&TB®ÎoÏ~F§Ì_`×Wœ×ó·’L!ÁÇ…"N8S©sÓ|¾`d½k²]êˬÌêuQߺùbä°`:W$NRtUçó…2ܶEUô…9hӄí Y(LOi…êzn›ë¬výgdëM¡ï´ã.ܨu3†xmâ„å@þ]7Ȫve_lKÇéTkçL…zÝØoÞ +:ýÀ²¦Ü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 pYŽô3E-üž"fDÄ’ IÇÁV‚P‹8@ M,H—`òó…T‚…«Õ;cRI¾zwþÉÞ·„‡«Ÿ?B +&Ã¥îš=€µF—±ŒÛÿ¢].áŸaûuÖgÇ' x­˜FÁXÛÿ 5K!ɬüb*S"iz"ó‚oMÓ(¶ÞßßCöšp‚¯6ÊDxq ]’SãžbÊÙp‹O£³_÷Û‚óM N$òb5‹ 0 LÂ^àD¥…ǃ"A¡{_v”ÑzcTxDdªâ§PðM•sVO£"N£2Zï[¡²/rþÞ‘SF̸4’¤ÅÖ£¢‹')(Ì ð)á„ÿó!‡dŠBFeq¿Úh›káãÂnSÚœÕôü¶Óm¡;l¸ÂDwÝéñ”!lB`q¾¼¸|ã.êyΦÏz=©Üêu~°þ¶ñ68"ï^Ÿ/Ùd~t">Šè›»ñ³ƒ„Ól²äõÆþú3r8 ³…ÅþRqb1(cí­…¤rÑ´9Ö7Ç7’(m‘·Û]wæ*Thr°„=æ“KÁå(ÝìfÛ ìÄ*Æeê5–°›2I¯>õTÄÁxTlSBjo$–S¯c#ö/8ÇdTY.mÆÍ9?ŒàHîœ&I<Öç‘Ó˜¾¬Æ#YFb#M¸ÚjstÐãGê¦÷,ÛmÓöÖV¹;)èF'g¨ÔàË•³bèhj{ÇBóåÌΈ«Üh®»u[\ö¸/-”LŽ*ã_ð.îfw`ÞÙu‰•ÛDÝ+aRø×IWöbÞk_Ýó„}™Üê6ÛÕ>R¢,U¸àÃK'sÒVsÆXØ4¥ÓÉF CüèÃÕ\$!Özã =­ÆëLWpUO•á¢—UaµÑþ¦‹ 7:¨¦Û¬ÄFQƒOÙêº38aW^d·5øµbmâ•‚ +<¯ŠºèzÀ—hƒ NÑ7xn¦Ýã^-Ç߸ïÆ+òÐ-&Ë3ú¸âã…±Ìæ?  Lì1h–eÎÈÚ™ƒu®1šëÝímáûX j(ÿüd¹-°`ÿÊÇ«9”ÏÚ‹AÛóSv¦aMÝŠ.º©(ÓA[àiM9¹™˜¼Ã4x2õüÚ·é½S’ Üŧ½Á)9¥ì!}¤¹Ä~¬úŸ> 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ÅìÍ$ç,Ku +¿rL6È‚ëær[4ͨJI– +9ýË*$·•KM|6c$=ýÍ!]Æï;ä§ä²rËÛiFãJùÓEù­o™ª½¸eŸGâ5ÄÆœHÊ!Á@iÁ¡øzÌà©Çæ¢EˆŒ¸lúqÅYªÜ—!z´ÅïflÞI,´Ç;B}ïM„âZVgÞ±Ša×A‚æ®îF±~NìÖ“¡´¸+ÊmãžpÍ°ôÀÀù]¿•œ*B€ó§Šåç3lF¤Áí'"î!|MV5©€ +˜ê UM—jºª‰TÝ*µËÔ†KÎ `œÂfPšÎðÄ+³.ŽÛÖn¾€¨ÅÕe]Y· ¾ucÚ{c*|´Á¢–mYì« =“¢<ÄT@4°7¶H©Œ7ÎbµB³nŒî&”¾eë­s}¬–Ö, ÿéÖ|ƒÝx 5_ZS­Ì*¸u»8óI ð¦>™ØSÊ U°“ÏH¢]ŒéÄ©.&v™ƒr¡KzŽL]ŒéÄ©¢ibxOŠ—«íáúþ.Äûd9–E8ôh<"ò¼ÛBFÄ·«‡jU·ßØ^œÈû˜¸†):ù×e¼rg {BŽóïG ÅP&2ÑÏÛÓJÓ<5žIïv_]C;’ÜÉrÍŸZ=}[97Hé¶baêÿ6ïMnF[|Zâ“<³§@ò|âëRM'¾H5Ä̓AUWIç©ÍjÚgš.=ö°îÍí¶¾¼6~Ä3˜Ê œÚo'Rf«7H¸®Ñ„™?‚‘÷è­qŽín–=Ú,&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õÈýÕã‹Õ®¬@•‡"TO½~ÄÆqìýpãfkámñ +ñ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ŸciNx÷]²¼ËüœÃêS‡ VÂƉ'9lÂhÓ†; t¬xõqêÏñ´$&Ø%^O_Ž¦Dpö¬kȈpæbi¦ÝÐo¶H‰ý¯†4Œ=ûŸƒÿg +LYhÍÇ@P†žgA(+> 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$Ň¼Éa·²¥ƒ°Ù 4_?¶¢ðc+‘(áÉ*NB")“«Íþ†®vðìÛfiÖŽhݧúËÝͳ—_%$‰x´ºÛöx)B•b«»ì} ˆ ·À¯ŸÿíÅíšK¼{ñöVÊàïðgúo¾ñöùmw¯Þ¼~w»Ži_ÿõù÷wŽâ:¯ß¼~ùêÛ;>·î¾»yqçWÑ_)£B/á—›÷è*ƒwC‰H”\=A‡–$|µ¿ ¥ 2”7ïn~ð {OÍ«Sš %%R†rµ!Q ŠŠE$‘„ö‹æ͇†LH$¸ðÊ—qOùŠ™$rå©´ò«tŸgëÍC¾ùø¹®òÛuDið~ýüËã7\o£5õìeÜçÆbØ7=#ÍeS¦MƒD‘M0…]Ò{ÊâÕš1’HÉ+÷W§ü•´ØUõ1GRöHCFT(ן'˜qGqh žÒc5Á… ’hSÿB.Û´(aVln«Õå"«?à"{öNÅC?àù¯òû˜Oùu¦„RÑ;ƒM½ß§U6ÞŠp–87wÕ ,02þÒ’B>LãµP!}Ì4”D%ñ˜éàDƒkœ»U FÓ&X4-þ#ÂAO]QíFçÎYiDa'T̯˜r +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ÃDv ó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Ý=–± xseB‘PÑxʨtP-„2 §B¥‡6Mã¡ :¹Yš>?<‘Øà}–=6lAküGf6Ї=±]•}'½¬h>þ šL6­¾Õ‚ò•^Ã/§ü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úé3ü«Ö%QpI"d³.it™™ÐåW§qhfÒ/ŸaÁ€Vv£³7F1{ë…÷¸ýüôzêRÃÇŽyl'¶ °P +áòcìQ-££BwUüçã‘0ÒE«eùžj¡è Ùwµ#Ô ëêÈ4+ä(Žx¢¸Òd‡ aë :}X^®€qw Ó? +øÚbüîΘ˜¾Í> 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,ˆáÚÍvl @-¡Õh^G^e×EX(‘àæ5ψ¨Y’J+§’üç“ŽpÔ…7ÊSŒîOý,_ÓÞ>lÊåÆ7'Ç3¯Úæà€úí討‰ª!L¥FתIt–Iú°³Éë:@¢m³*¼Õ æ¡ÖØì^€Ï´c7weSc'ŸcÏ5€E¯hìHK«û}_z—P\ÎÁΗQ8 ÃOаöu¹ì'í”݆Zä°*„Nì Lò= ×~ŠzB2÷%®„MwjU®Ë.ÇõJR¬kˆ:$*DJ`”w4JÝîˆB?Š„½9½¶›Ü¯ÈOUøÔ©Ã=–Æû|7á°Å@è¼<놆òGêè|Ç=yß/åÊ$’#&4Ò¸¹ƒØõt½„HƒB*\ožÚm^[¿ Rmw”¡7)÷]Õ,ûÔü®ÙQ÷åØ A¸Ddê‚Û‰e&ø¦ˆ\ÊËEí²¥9t:®O¤‰Ô= |VtËgÈ-Ùî",-¤îÖˆþ4Ò‰À ™ÚÉí×­²>áÊ+v`÷H¼ÕÔ}Þ}±,Qzg0à÷AeƒÆ& Ò•`Á%-¢'X%J±à‘š{ä{ÆÙüæn˜ü T1a´W'´§H:îš}½ŠÅÔ>$ÐìÐç &*AȇÒnƽkÃVÕ4Ÿ©œÙD©J´áæhK?±`ÉRë©eš¡eâäpl +tÇ, Xp©‚Õ´-šËªÜEæ7ü·æa9yK“¯ +Ôeí¼ã…Ð[䧠áâ ³/xKŒ†09˜·û²BÛ@_•»`zŒ¯`96X1áåñB8hÛ šÚ =¥¦½ž¼!xOÌ×E]ìÈb·+äÀswmçûºö€ë0ð(ÍÒÿêrí2!øz‘Gd\…SH‹G•¶Ë]y[¬¼ÖR™dBYÌö › q*AÍ€çhp·žQãýúÅøƒ<š—ŠËáÔC2š¨X%IÆ'òDKIŽê’G³¹¬€Td@ù\ñ¢É®œ÷–ƹè-i$åCFyë4‘(€TÁ*À…Vx¶å¶¬òÿ¼!BŠHØÓÜÅ|™†#¬8¥é«SYgx¾ì€`!ä|qú +¸SHqojŒÉ´ÄýÎ[ øFÉM6=c˜SºZf‹AÙ¤'¢@ýŒñ‰[m#¢JdÁDZãlCI´Ca†¥éS'ñ`'" ƒøšéKVe}¸ðùol.M…-t†¡¬ ªEWšÆð El`ð` +´ò¶m–%†J‚’°h+ÏON²OÌÔØ×ÒˆCDø$ÒtTƒ†^Q±åá´uüHƒlð²-òÚO&½ ì{ ‡ž–gþeãúWa!e:fª #\rˆ3üÓ!À]Ò“ úcÔ&aótfôe£„ìTö›Ü˼39ß8ßšá¥5ôº¬ò}[´zô4¬ÁCÀÅIC4€Øyƒ†ØÇæ;¤D¢!é9€£qã†À3,;ÌŠ‰RlZ•¤V’˜|Óã0›÷,™HLŠ÷=ãí=©þ,3½tùg—W@Æ“ÓcÓ¸r´|‘‹¹ÃÒH²ZùT$|ã^×{¿£Øã² +hὧ÷ÖÈ¥?+˜aù< ø z aëÖÓ_îò%…}xuu#”®‰8öEXÝÄË.ÚX5cvb¿x ”žzœç¬h„(t±*”¨·*ý•ÒQIïáRñ4 ÷ʬ8Ø­OÝ×nµ¯çP⯟gÁw¿€²óߎ·ÉçLÙ#¦Vã¾Lõ=⫃ZðÌc–‰Uˆ>`œ*Y"UzäbÊR¸´O<7i¢… ¼‡”Ư‚T ÷9u5ô$Ù+or.Õ£Àj{¾›f_yM±Ö€ÀèÅ™*<ÉTá¤J ÁU$r^¸QýmT¨Hn”6õÇœÅyº]_}ñUÓ˜ªB»yBèæ¦÷ìÓÝÂ` àX  î|ˆài_Û;iœ©XxÐCÓŽ¯y0ôpCÆ}RËç3Vý-oDžà0V*/eý™ÉÂæRâ„“j8} 4qŽ¬È$Ìp5Æ—qEg™4½Û(æ7áÒ°}¿÷‡·Ì"-ži®ÖŠäÂDV“K}ªòay’âç6«÷r0”aS·šØ ¨$7Bz`0éƒÇ&ÞGOŠæâ•0ü¼wð¦ÛÞï?­/& FVç¯ÑG©ã(ÂûKÍÛ¼-ÆOZÔËfâ-)\°aZWQb!ï-í¥/°)uĸ%’ã–¼NNÝtá}Œ ¡ïo%;pÜOÒþ¶ìÄq³‰Í´ŒKäéA–Ém;dYáF€]=˜üã±8¬ÂœDBàL_*vQHðqT†Ä'F!Á|ú„„Ó±å +¾H2¤Oø+2c³XHŸÔl:ÀÐQ˜fÎF±á|6Î&Õ€hYŸ t‰–©ó%…ŦiáÆ÷œg#e,?¡0X3 ò“ EŠ~:Z,,ŒÄ%×tè~_‘†B#4ü6¥¾9 I(R_ØK)%Åw™Øãëê©_âypƒt9è¦ôEX#,ÚÆ“u ü:ò{ŒHΕ‰êó©ê%Y–èc¸ Bÿã;Ü~sæTv÷x|Œ8M¬Ç@°±ú °ZåLtäs¦‘G‰ÏøÌS"’Bö']ý}rìˆóí}å?Ü–u¹Í«S·NÐÙ_6Œ=´Òa‡fRl`ˆ/1±½U. cNÿêßþ㤶6=¸+ €£ü*D¢¯žÇb™õDº”ïo…®oÞ~ÚßÊOuþêåöVÞ¬úð²ûéGµþ©þÄnÞòÍÏoXÿ¼ÍoÞ¾^¯D†c÷Ó/¢2ý÷y a†òÞéñX5ΑcÁŽÁ~ê×ÑR'ø“æÈ5ü{)þô/§‡”#ʲöÄÁ$3ä{½P¸*.%×Ék+Òˆèÿíµ´Wendstream +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‰Æ£¢[YóТ©/G,Ð I-IÞ6›*RUÍ­vËÂÍj•Õù#ǧD Zr)dÕNïATy‰ŒR2lMœ¥ÒbYTM–Xš† A±rûºLRLªëbÑùI|H¨B~ÄO¯›u0‚ùÜ"ìÏ6mv/àÎVaÔë›b½«|=#zêlµ iâ½duþÓî¦Þ;¤jYåhƒwù²Ê˲ˆßþ8?[ÏôtS×e}VËnéG—uW¿¨tncS^ºbUÔ];æ½=:ºín«uÌ_ÎJ®¦XíÚ +vv^h¹öøíîÏÝwÙ´Ýs?ÿêÿ xÚ¹mHy±Z{Ç“‡CËÐ;ÚÆPçÿ—Y$xr@¥´ÎpSÜCÄ"Â뱨ÓP(%C6ï%:ª%bÔè¢QM•ê(2ö£‰.í5¦C•‡YŒjƒÑr{²µÑ^ðµ[þ(ä3*Dí†Þûž‚F9>{m;¥G*ŒPImº*ê‘£%CTé(|íy{µÎVþ„Û²²®1ÒÒò¦¨KpIuç×>:ÀQ^"sC¤s_N„š¤Do¶OÅþ ë}wÂ]³°gØfÙC«¶ñx1&§d/Hò²½®2k1¡!þ ƒË¬½ñíuSçÏC ‘@dìé£òÐp¦¡J™(8d®;2ëü™`¼T®–À#—ÕàI–oŒ`ÈCª"ÍmŠËïÑ ¥ áG&9üŽ«®X×YWÞà;(¯Pq—\â ¨n«&//ïFNÓT ]RD¥Œ¢Y×WqÔƒÖ# 5•c‚˜àR&!XöÝ!¥ÐK@GW^ÕÙ(Ûl†åÈpÂݦ“bÝe¥Ã›L?œŸýêGmØÚ—Yxº  ¥…Ò.7~G—}‰«×Å¢´.ü<[teS·Ï¼\Öú§yÑ.Öågß#AQ®÷NÛ©Výçª@cõw¾,Úà©ÁTüWûÚ°iûÊ;ž °”÷üÅf´‘¬‘`˜÷Ñîz-´_N •s)† 7)&̵Øb¯œ|Û®hÆ´{-ðû0è +ø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ñÇ DÃHäØÙùü~Š 4>Ŭ§ØÐÌÿ€bOvÓï…bŽ‘ГA³¨v?||ƒWU¤ f¶íSHx-ùN†“3ãc¿Êm?VBçÌ´fã|€@hM ]ž„|4Œßï¢ØÀø¿,ôgendstream +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|"øâCž†‘,’CV$aÅ顼¼‰O0öË›˜y’T†i"%;£ÇTæaš‹ìp\ +ùÇÛ¿Ý'â ¢P)‘N~-•Á„Lf‡‡ê·àÝY_GÓßEÉÝþIÓ’0˳§E°„ +ãTXþ«¯º-ME~úð‰÷FSo/ NB™(ÁTÆBÄV4ïŽqEÁ‡n¬O/×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é·7âp4É’°y+øxN’²oBMqÞ؇ÖX1±Ç%‰SêŽTæI’°òu3tÇW Þ¤ +éÜäÖ8`pÔ„Ûü·ãùË ·:¹•»2•“Ýl)ÇT±ÚÐi˜ç{›ØHÂ-XˆÍƒ‡]÷‡,§²,ù?4K"ÅlWBб+»†Nfa L8\MYŽ"éÑ›T)h%Wë,P3<}¼G¸(TøJ愵“Lpâœ8ziõ¥.iö¿¯âØ÷²¨Ÿ¢ +7Ŷíæá¯éw1ã¹CW΢à„ØfǪªnŸ9 æ®.¡Æ_e3ú^b, +^Æ~±œË<ÐæÌcÛ/´H„qÐV$èz\çU>Ò„Õ¿nˆ@ü¥VwÚ+3 26úFYßð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È8²°<6rØ%¹„Ä` áì´].¢>Gi„=LNƒŸùéçw0ÓЩãrÉS WFQöw´`|üøéý/4L +Ã@uÝ ëR'@bF¥MMj#-ÉÙ"ÚŸ‰iì°”)Á ˜™†ŸLkz=Z‡N'‰“[>4ŠçS£¼–þ]ÛÔ-³º<˜_ÌË]ǧ‡*Úȹëë?µË”Û³¸è§wqçjA[Ði—Ž0Bë§ï,Tso‚^3“ùã +Z3&øó@›=—vê¡ÛíÅ‚¯ÄúXd˜í Í/ ó±\fójÅ«U×Ï÷Ñyo.P‹ÙÊ«ºÔÆQ€2²î ++ßheæœÉëV÷/ßÈÊù›šÊ_êx–S[UNÅÝNÖ›|¤nò-í\e‹ò#s÷[•Ùr›Z]Yj´û&rõõÈ“ã? ‘TÓåŠÆtÅW3l”Ýå +呧Z°­½+º¥­˜É7+"Xç*'BOí&ºÄ¶$oœîÙ‚¢ ÿ¤2hT$‡.à–x#¶§+bHT™Á˜Ñå™ù}®:±wQ(4LɹFøæ­g¶|tƒ]G’sQÜbûnBqÔ0=¡Q8}.^á?« zâ0ÿ›@¿ÍœL`ï[¨6µ} dB@ª£­åA!«_œ<¥vú[#À?Né©Û 2§•*©R¢pT9Öiö¬4ç\ JœEœc‰–>ËeÈH_‚^p„šWðuDøç¤Q÷¬emŠwR¦ˆo8OcÕ=³ÀŽË^g{&[uÛ1 õ—€a]¦‹œ„t¡Xk)Ÿ]íz‚^ÛACÊUr{¯f.üÖŠ;;xÏú²PO:ù÷MnÆí“zÁ@¼s‰v½kwj˜^<¬Y<ƒp÷  ±cuéþíc“«B|ñ…áÏŒ¬ÍöFá.?õ¥Æ8±Ä³þàÁuÀm@°ê¦;Î2Ô™w þR·Œ¸p°™ð0Œ¿r¿‚‚úÎ ÝK €n°O^œZ:HÁÓ¤A9£!q½hLµÕ‡p ã²³F®\-é•P,Ë |!…Ä‘&@9°”y_@@ÉÊ`@«åój Ç_æÆH²Â³skŸ–@šŸ– Y?Û‰…GÑe:u÷Sö‰jùNpûŒjm<•­7˜ÔßA¹´wM ¸ÀèÛŠWƒêñº÷”"B)£Â-Û· ÷´&¡à•û¯tŽå8óì¼E*ÌE‘9A¸ÀõkÏ‚·Ëýi~­Tendstream +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ƒM€¢å_¿} Šr”J…9zzzzº¿î™¡:áO»(ˆRžÇ© \¨Üy¾9 Ï?@ß?Ï”Ð,=ÑrLõÍÝÙ?ÞFú< ÒHGçw#^I&‰:¿[ý²° .€C¸¸~÷úæꇫww±]\~±Ô.\üüã»+.ÝÝ\¾»}{usËÕ_C^ÿôö¾êbib«¯¿½|wuÃýV¸^¾ùÏ…RjqùîõÕîzóNx¼½ºÄ¹îþ}su{ñÛÝwgWwý¢Æ W¡Á}:ûå·ð|ëÿî, Lš¸óTÂ@¥©>ßœYggñ-ÕÙíÙ¿z†£^:«HÚ€ÒN5iÍœ&]DFÒäõ¬*‰OÍž ëì±ÀR²ènÙd .åë¬þP´\ñÝS¯žêlSæÜö¥© ?¸ÞgUõDê|mi´èÖ2ÃCSUÍ¡¬?0ívw¡’E“«=•„Å¡¬*)5»_þ%nñ¦l³ûªÀ -,• +Rç4-©—Ä„éb¿]eŠlTH"c# €–»ö-ŠÜ@icóS(7I˜yïê•0~ØÅ—‚GÄéXÍ`œÊ(@30Ûñ^h¤h LVgAwë²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±=@³Ç¬¬h0› š% ƒ$u^íWRé±Z RÂðMV‚£—5tÝ?ñwˆ«@Ôƒ?t öQAû™ßŒÔÖŒÖ!¹(—¸Z«EsïgÆfœ¿¨à€‹o $ Ð'RdF>~iØG¢`ê~D¢bãƒçãÁÆÉ1Yc9Ieìb[ìp7Œ#<ƒæ‡=¥+Æz„®”@;‚䥀ä+nÀ0¼‰8DLŒÍ‚rHð < l°kK&p2<­™åç²¾åîÙ,WÀ* TQçE;Rt —úÑ­¸•«C=ÝÕ¶è8Èxr"’ŒC¬ƒlG;áô4;z)`hŸñd&H¬ÓÞ‡Ý؇S=øpªØ‡±?´­ \ °,î ­)ÓJz…Ô]Wl¶W(öÃwOÞtâØØTWà¡\¦<zK©Ÿ·U™—nÖWœš®ÀbcØ'²Xlß4âü/ù² Èî›}ÇEæÇf&hóŠ{Ú¢àÛÒm¾+· +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†ý“˜Paê'œk¨ ƒÕPv =Ü‘µMÝŠx5w°}Èêò‹÷h=4ûjÅ„‡¬î¦+cd‚ÜTü–0ñQM*Hž&úêÖ¥ä͘ âž½ZG Åñ±YäÍfCÅcù¹ƒ t´ÞÊ°•Š)ëÀ*_0 ÑÄ® 7Š±‘49–] ××åJDø–çËÜ/|ÍÆ@‡ƒf3g.8,oÄËÄpø©Jð‚–+ ˜eÍE¶o(\ÓôE‡G¹Øw{KÙ6iY÷œFÄ‚à±À0|![êÖ”Ÿàdò­›Ž©Y3c® $#À`Dâ`.€_Ž9qI(Ló)h¨ŠìcËEc&â/¤O\‚"ŒëeÆ•R™a Ç pUÄ„ÔçˆHñ9Ûl«B]™7­L×fOÏí¯,ÿœe³ÁVsò:ì…šrŒÉk9N-€{ž¸T…PóMÖ?7d0GÀáø²ödìz/0ÑÔ  ½:/0Ž½ÀgOQ/F6†èÁ!7\õ9Ô3¼Dâ¦B±vˆ7F-“uëLÀÍ÷ź¬W³*ÆK‰Ž1vd¥Ø<ÓÐUª±kõX“-Pc¼[‰{¼bvêÞìWM¾Çxçigçñ—ƒ—Œ¢7°=£À#ç|Ö ÈUñé(`N­‰o¡°t_x+ñöÒ5ž†·ÁQ6.7=Ä°=í»–Ñ +9íz³œrÙk¿d¢´³FøíYœÜ0 HÂX““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‹|Ú#£“…¿òöžuG†ëOðÏ8Ævo)ë:²×Áºà0ø¬u© Š­7L¡(L9U2:™¤¦é( € +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Í@±·Î¿¼×5‡ÎÌW”®…²yø|‘£N«²]ûG‹’ò í†G˜Aë0@ŽæÐL‰;=ÍleìA˜B¼“Ðù +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ãÐ?x1×IÆ6ÖƒþCܘãvYobµ6Ýj~(õFƒ°èÀÄ.šµ\€«tŒlXëÙb…m KŒÙX"ô*ºÂ“wB‹6ÎìF'*l˜·ðØÀª$ú;Z?åŠýFÏêZ´‘@fÃ#zf>ºM~g:Ø4Œþª‰KB>k460f¢œ?aâ²T­t ŒµGr‘â=à|Ô¿ÄAZÆ ýeåDHµmÅx™Q›>wš_Ÿ‚¢rxyÄÑkcÕàÓÇÌÐÇÌÉ]!Ô|ø‹Fà•Í¾•¥Þ¢%‰£G±‘{œB¦–ü ¿xý,G;LÏ( A¡GÅžÖ|ü¸“zÁ¹2:RŠ÷Ä…Q*.‰ E1cäŠ/ ´’&…=?àwBÇQª™xíP6ÜGJJZû[*¨PBßÎ3é'ÅŠ—’8pôA!‰>:éSYšÿˆ9ÅeJçåš ÚPHyÒ99r<È[ø¬ñüª¤S2Þ¹‹vD©²/Ùl‡êO9xŽÖã_[PZùa‹N4臯jaýS$/öZhÚ='0|#èK]kºÃ&Öo.i§Œð%ärGvÎjfC~X`ÂçNÔÔ•îïp8¼ çŠÒ—ôª\êaö¡Û¾À3}ˆL2:ªË‹!'¦¿l1á褤¢Eýð“dœ&œÑØó+Woú—Ã,Ø|ö/rÐ×9;µÊ® )°V½¤H¯ü„÷8á ÊvAdÕèNDÏýϸB7óKø—Uüí_ê ¿g´ &‰žÿÉ‚Ž“À&ÀD„BáUt"¹ÿIß©èÿ‚bàòendstream +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†ªhV%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]=YF/ç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óÍÍüÒè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@´¨ä2;Š¸ëf -ëJ6½aeœÂ›¡{í&µ`?CªD‡çÙtÓÔ—'\À‡“MÛÔϾù''"UC!v¥9h¬˜´(ŽÅ~h_”ð&ô–Kíè¡+OXz÷¨»IYÊæ#RÚÔxª ++®–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ÆOF"Â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ªî^8‡êHd,ÕéÈ“êDf*ÖWìßoC‰cèÆäËñ:TG"h©NGð˜T'‚S±þºbO×D<ò¢(&‰.{QÓ?½—üÅ(ÎBsšç“b7ç>°(‹ñŠžúþž»ûxêS˜àqŒÏìeb¦.üz] n ê?›®Gh!»r]ÝéY]‰ºkŸ¤ø nÚ^ZVEo!«”}êóÉX£Ðw±1è¨CZ>jÄÅäðá|7½¥“í±rrºBäs»1Œ~DŸ3¤½ì뤜¦tÌ1@²ðXïøqý0Cà“Ü}è.ØOî}¾ÊïÕÈZÅ ÛÓ&…¾“•Ù«/KtB[ü\ý›óßõhcšÊǾ=pÛC\)EnEYã-žÝï:|ýÝÜñe _Jà?=â ƒÌRæ"ÿ¸°icoùFìí¾9foî +ÂjÕ…m¸”ky€níJ‘<Ü‹ÊÑ™âKâh¼Y WU¾+C¥ÜÆpç爱QiîÚoîå½µk¤Š×!8]øÈÿðjZÔu» ûuÑt÷*%‡7PV;êØ1 3ýIÁ>ê·‘¦µn’ú7;q)Þ¸²‡ »˜¤„£O}Ö²ë×UÙã›ÃPÝ +wÝaÙkYnÖ®Ò#ò•¼L”·câqñ‰ 'Y9–["Øé”ÄWxfr6¥W»TãÑH=BÊØi^J†;¾œ~^ÖøÓ¼²Œ_=žï+tq¤€ÜÒ2L¸]´6 a“°4)ôµ’®ŠLMBŒ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=‹]=w°|}éáÕ©A¦@€Æèøçд°ý£‘i!Ÿ:¾±÷}pOjûÜu°ÿÇDƒ£½á~gŠ ¦Gð÷Épdž‡‡Ú0l3í®A"Ó¼ÕNÏ¡~%u¨A@ßÑÄ(°žjÔ!À¡„Ì-‰6Ò~µ€·ÕT%;L«ô8žŠ'.Á¤¢çyW®AY˜€AZYŸòŒ™– ¡±Ã'%À=Fé4a ÎÓúÅ_A Áb`ÛµWÍ8‰î›a%C ÇYÖƒZr6íNi“™;KŸñ$i“±WÓQÎI#^²‚·©Êäa€\ ¾Énmy^š[ç4΋‡¨¸Zžþ¬ %Iþ`ÝÞ±b¶à=ÉDü,JxŠ=.>¯C+‹(ãcV¬l,%­©ŠÀ³•tjf_*µ—"¨'lÆ4zÓÛ3«$+‰%êã² ±xƒ€úÀz^ß·û?C“ÿ&‰}@I§Ö‰PD”LJ¼ÊgØœ¾º‚ŸA^ +Š&yVnr^ +#Zªôœ÷219Žóì B|ý¥¶PX—‚Eq¢daEhcÚ,ÒèÔ5ª7[ ß–”øfaÖdÊ­ëܺaë«‹B>•îüÕ +P‰Øc^£m&ËKFÂnOQaHé²¼ œJ´-j…¢*[ÔïäS0^“¸¬Ÿ:€Q3Îû—^°ø®àÕ{c|L{ã¿€n¢Ä¢n[Ô3ô íoÕVÆy®êýëŲÙGµˆžn¾UÏPqüÑm£‡·þ®ey)JÈESU.d¥¼H£Ù%Û}Ï­¨_´µ¯* º¨ÈÛµâZ [ⷾĿü¡ ¾ÛûùBÏž¨/@š¤dæÈ_É|~Û_Mýˇpendstream +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ƒ™o. X8ð åÛŽŒ¼Ey¶ïWÎbïÞ^ –YõB«±ÔO›«WowÙQà‹Ín´–²¥Äb“ün]¿[ÜÜ~Z®\ß±<{¹òÇZßük)„°Ö®ooèÕ͇{"ÞÜ®—¡gmþùé9ÂpžÏ37÷wo—l~¾ºÝ úÏ ‰Ê}»úýg‘ÀQ~¾rl)ñÇQä.Š+Ï—¶ïIÙsò«û« ŽÞš©s6ñ¥²}å†3FñäœQddû¾£Ü•tÖöâa^½ñÃÑ7´#ßS°ÊÖiSåv\•;’,(Ûõ<Á²Ÿß©jZ;ýÖe:O˸‚xÕh_CluÓf=÷P5(ë48áõŒb«(s©h±’.œÊóͦMªëø°\ŽcÙ¶ó@•p +ß5"¥.Ò&­ÒšÄDèÚ"°á¿û÷ÄåT\|GÜc‹¹ áÙÒ´Â)`¶c#ifƒó–+á8gl]˜䥰•_£üæ5`¯ °ú§¦Gs¨êIßÚwY’·­ømÚ¶Y¹§Aw¤çf à®uÙè˜ÝLТÔmW/…²RÞÝbÔ{˜à¼4á].iÒ¸«³öÄš2÷§»76‘wíœå“´‰ël‹ÛJá[ñA—û~€'1Oy[•ŸÇÝwµ¦‘‰œœ4Ï|Lóü‚sÐíÌšM¢ÅD$ÄÝ!¾‘H²òw)½.y½]z¶ÝË9´deœw ¹b +G3©ŠÓ¦á`ÙÑ3¦Õt{ž3±60¾¦'ž¤Ë„ˆ®y^¼ÉöSï1kD‘“Xs×±H0Fs|"¡ºf…®³üDæ;{¸RŒ ßØÊpt m†p"vÎ,Š®ÌbãJÀˆT~õ0`£]a‰WeÊ‹áÑб_K¹VYµÙîdÒûË9ˆ‘…”Ãþ˜6ÙCJ¬o]ZŸˆ„n4Tña}2Y0­zÛC_qNƒg™>š³‰rp +–5~TNo> =ºß7ÏŠ¬¥…±&†‚ÆhÅ¡™gÝÄö—Ò*²ý¡%r›2 r,Q]“hrÉ ’Y³Ä1ÑmŠ¾pÏJN¶ÕÓLcŸës/fê­9ƒè˳-¸@¿MË´Fcš5îºN9Ûþ2$à]ßÿÜê˜êGÕÓ”þ¢°™/õ.ô®‘G¥bNJbFŸKŽS. Xr$ƒø{VÅL½„'†>Š].³MÛÇ4-ÙöÁ¸t¡?‘ŽË–žLÌhë‚ýè‰'+a¨ÑBîÜBÂöCÕ¯d:mi­KRS×Û Ò<æB©#»®éùcX?-_\èá] à³ëzæ8+£‹cLpÂáè¦bJí€TÑ™¬‰ kzQ¶›A¨¯®Ûª¯¤¸Çc?{…É€±eë®­ +(ƒ1- Ãâý]ÀÐBÌÆy^=RºCl˜wvCHíÏx)qƒ¬pÁìD`ó'fžÚ”;@}÷~}½zãÓ;2®Ôгïæ’ÖÛêÁ”“0²~­ ëªçÒ#÷2¡:wc8´¶£:ïsŠ‡7¦ï¥6B=7;ÕMÖ‹P¢¸þë5‚’ñ¡jY¸5Í!QÌ*ôŸYÑÃDÀåfo| 4u*‘å —ÎÚæ¬F.)5sÔœŒÀ€ÒÃåH·}Of<5‚]’AKÒöYçܳ‘pr5é&“.晚ä]\1kÏpÇf‰qê« x™Î‚®*IÙ@îYÁ @ÝuVšž‡BÇ«"ñ™»å›îf,þî·û OEá3À÷4ÆQœ@{G‚®Q@ðàiE‰$”„¡¢ü2Và…ðÃþÙÐà<Ì×KWi(€âœ¦<)6Š³ÝÃMe›³šÐã4½‚½Ê¤áK¬¢Ã8îâ í‹Èb»˜UàñݺŒ«¤GAÓÖC«?Ž{bz›«­>˜"”}é‡âõz.+K;ÂÏÎ9ù>Òµeú'äçx@厠W\$ÊþbvqKégéf‚Óq±2ã¡æÍ~ah %£)^ÍÁ Ú~Õ¯nýë/o£ß^TøòÍÑî—dýãÿ-ò.ÌüŒ]}h”ì-ö7öž´ñëÀwMýÔ^çBô¬Åæ*ÐJD¾z¾œ«D.W¢÷ºìtþ¿–!Nu’Á¤sÁ÷&"ŸG1ÀÓô€‹]b0d¦ÁŬŒyQÓD,Öo’?6€GŒMmë{¾ø„ÖúþúîŽ6>mxã¡`ÀàAçY2—³Ïq(Õt>–IÝ4]A0‘}ù€WC¡\(úsBeéò6;擳)‹×§8A~IæQ¬˜aÆ`]Œ;s)•jzD +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çË +Œ5ïLkt8¨0À¦©`c¹¶Õv±-ʬ±aÈL;ì"&œJf9¼n8®ê)ñbHV£ðÉ86Š /ú¼ÒÆ[ï!)/ê +û 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óEyîêƒj `öœ‡k7í«!T}°«Ëbé+9#@ú’!ècòyöC¾¤)D X'8Mõ—œkÖl||šèɃ=~™#œq5Õ¯ööÚ^‰ê ¢çò„âL,á<Hz¢Ç¥¸àÕc£ïD—ñìG{ýßN߻˜ˆ$á~É!ç%aL¬PZpN/$w߉.Eÿ²âöendstream +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°‹Åb÷· Â•‚_¸ÊL ¢<^¥yšÕþt¥V÷Ð÷íU(c6~Ðf<êÕöê›·‰^åAžèdµ½ñÊ•eáj{øeýú»›Ÿ¶·®7Ú¨u\oL¢Ö7oþy†áúæýëÛ7ÜõæýG®¼½½¹Nãõöç·HQ9Œ‹ƒDfnÿ~ûïë߶ß_Ýn{ùÆ{U„ÂýqõËoju€­|¥‚(ÏÌê*ó\¯NW±‰G‘§TW¯þÑ3õÒÔ%˜( L¦Ó¥Äz†AnŒžhÅäA鈴3‚äz*¥Ö·mÛ´7S£‘>Õj£“@ç&¡9Û£½ÞDQ¼>·×a¶nöÖ¹²¾gZs‡¥Yo?¾û–)®¼¯íë'ZÜ[Ç­}Qs…øXw©:n—53qöÁ¶EÅDÛòr­£#ÐëwwÜQÈàçë7YÎÙZøw O)p³¸½^M°½º©7,½Î’uñX°tÜt¶‘Ð.^!GDûã‡n?|àÆcYU\ÛÉ4fÑ]ZP&‚ÊöÒÛ§ÜgLê¦ãÊ¥>ØÖuE}˜Ícöû†ÊC°´«íÕ £líË‚‹±î±ˆå©tû¦þU)}®ï/mÑ•M²Ça/; c ÒË¥ëÓÅ ·ôÚOçªÜ—]õÄma |iùƒ0k<¯ú0Rλø”';ä ÞŸ9^^âeÁ…;Û}‰ î¥Ýã ¬,ÈLœ+²,M«c!¶¬Ó±5`‡ß3Öå lù@æíg§#[ÔÙ`¤Pß=ɸšËKý{Ý<Ö<ëwûDž 4Å¢f¤Ëq›Ú K6bh=£%-±<–Ý?–PñWUÁ)u y¾Dápḹo–‡9Û ‹†ËW7oТ¼Søn†|7U¿D8Ñ 4{ B}¦ÁHñìp|›ÃÑŠ%+ÀÝ¥_Cá5)P^•® qVr§ôPTå¡è,êY+QŠz¦gå/$öí„Ò뙨"˜J&²m 4 ô±f¡S4 ¨Ù…C#=Çõ nŠã„”÷jcÇfP1Ôg*f*††ì$6Ü *OÒÕ\:W|ãŽKÞ/¯ªæ‘6 “Ú¢¾'µ&9XØ×TÉ:2ÞëEâ:Gn{Q0ì·czÏ0V1ÒG*Æ&«‡‘ñ"‰ )uûî‡ÛÜÍÎ52~¿y$­\¬[tÁ‹ÃÀ ’4™^;\+‹Ä‘"¾[Ïu +‹8z'wÙcŒ½»Tä>JîÌ‚³ßÄ`8ïjî(ê'žKnœ×ø:ë(ú„Ãòrðq#iDYÀ¥tKÇÆ*yÙ÷?nÑ—Þü¼ý.üÐ#À ´ˆ8‚VjtxÈáQM˜ŽHZ‰xühÔ–è<ˆLœÃhDaMÐ:‚}íE]ºSïÈ€^\ºæ±l_°2¡ïÞÖÃBÂdw,†àdg÷ƹg»Gkkîì¦×!@‰Tˆ@©Ç(ÙЈzhƒêÝøL´ü+Ì9ÁI8¬à©åx¨Ï•eâ@©05|FW ÎPe± 3ŽqlQpñ‚HÁ(DÒ.”¢+Ò +Ôò„Âñ5Ek4éúÕ»÷ox@.ÓOçÊž9ßÔ•0nj;Þ`|ÄÎy:s€bÅ0ŽT‚n%ÔÞÑh/ïP·t%6ßÙª:Ñò;À!öĽ%³õ«†\ íÚy±†:×ÿ¸”½j™U<ÈÚ–EÀr"s1mŒn~UFUwl.÷äèÐs–€¿7–¦x8Ç(1Z’{ ­< ;‹ß!LŒÓs×á`@š0àµe>3½(Lƒ8Ò/ÛX7¤%™ % 4,æ닳Ï@†’ ¥M Â'äµ£!Hè|m!H…úŽ®x5[,–@@e«~ç5Ø7Äú3×NÇ&H•¿ºwpÏfâ£rö0ùÌÃd3“ûk +5 ¸!T%Û¥ƒd)Þ$5x…’e±Ç–Hjš ûƒdRÅIüÕí%aæÏŸ¥DÔ]9‰ ;Áã"ï(fle;é(‚à¹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||@ÔEX +Ûä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Šç`â) ›½DŸ<$§Æw­bBéײ-Þ~:oð¿ä÷|.ˆWœsY°Çš|†v7À®¡´/},.ÊÊö(£ÜÃ9t>Ê7­Guéi»¢ +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¦äñy­0­j$ZûÔ௠â¤A÷‚o_Ý,qjì‘Ìß¾Æb@’åò‰E„pÏGr¬Û·åÎJŸ`„d-ˆ ð#S#NÄ‘B/¼é]‰ù(9“0PIœMݾ¸E×ð®æçÁÆ„é?Å"™?,árfBÁÍ~y³½îZlx¼÷ã |cé¿ÐæÖÙ³ÁìLåg $î„ß]ÃÏÛˆ*SÿÈ…òEß .Æsí¿ 4UJîÈM?Q$S¡9kƱeí–2e§eû½ðé” ~{ƒ$‡Y%=«S3P¿(ûï°OÌÐh§™œZŠÏûK;íß•‡‡~¸¬éØ…ÅŽsŸmŽ  ÞÌä±GÇÍY\IbTpR“pX‡_¹V•ôx”ð‡g^´ o¡WXcÖï +_‰ñÞ<ñQ9,‹ˆ|X½¡ñ +ý$D> 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¡}º§{†9ZÙ•”Ðì¹zzúøzFê\Ÿ:OR‘º8ÏŠX$R%ç‹õ™<„¶oÎ÷™¹N³q¯¯ξüêóB©NÏ–£¹r!ó\?T?G±ÈÅÌ £ëÛûû›÷3U$‰‰Þ{õ‡›»‹™N$t¢.W×ÿºPJEW·ïo®© Fñáæê"‹£‡ïnî/~}øîìæÁK8Þ…’Åûíìç_åy›ùîL +SäÉù üB…>_ŸÅ‰IlŒã¬ÎîÏþé'µÚ¡A­()´ œª%6!µ$…H6V-OõöBåQ›K£õ®J¢rÕwÄ›sÛ¢[¯wm³(‡¦k©ÓK3×Gôåš©ÖSA)vHxxnÜP †ý†)ØÅ©U¦¹(dž±ýôÃíMÀu!Œ.\8¼¤é ùÁ»jÎ+ízιK-ØÒ·'bÌx2>òHkϹñç»^×mUóÃSÉÝøp€beÚŘU’zÒ0ÇäàÛýf@ÿÙ<5 ì®Á¼;ȬOkúYÕhy|†¹"•ÿ­ã5ìqÁžXÖÕàÛ¬7«°±æ® DW{V@¼yøðW"Áj\ +^¹ž®[×:n2`¼Îçïî¯î¿½RÂ÷9ôƒ }Ënµê^|àBÒ%ÞÙN‚EIŸ,͉˜7ÃdÅ£X½ôÓõJTZÀÆr $]o<è¯xÒ|Ô "5o.Ó鶧Ñt–B¸™•ôõ²[朾v‹–Á½­á[j"§û‰Æ/ +Ð(fjSb6;›le„)tU÷Ô@*G +}¿Ò«Ý¢®¾ +¨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 +ÄzuIE 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 À†þ©Ûá=rçܳbuký²u]®ØÛr‡ˆ‘ò! ‡ïÝ€ÅjWÙTîFÂ6ÂÈļa5™H‹<˜MO«ìz\á ÆHúñ—·ïÿöãu$žƒŒ•É|ªH,.-Hêÿhñ¥¹øºSõÆ×t?1:ú¿•`过'Í2À$¾ã怨pzö«"Q‹£2¬Ý‡²³ü¤]@«‡€ ¾<)Š“3•|;†›ý¦k«Ë‘¤`‡ßq!ƒñ¹ßÍmñ­Θ%³T£˜1|ê/4±KÒ€½hÊAé#«½x8Ýî O¬Ì-ÞCÃ_fÒä³è4œÆ%€»»ûß„Ô§E¦b¼ê±%@|(a«ÇîžEC<,¹—”@•}HÒÈ"yãÖ)ƒË]xÕØ­jü# À 7ËÀrx‘{˜êݬz÷ª]Y×ð|ý¦^Ø|PWxÀJEC+¤ ”YòÏ®`} Ž!yiyŒ°:®6Fxßgºæûœ»;ð…>P†Ðãê<‘‡«Yéõd[ûíÜÕAUåš ììÅ^«&é¸âŸ¾âÂè=‘ô‹ÌÙPlІúÝÚĪË~{êh¡*ü.éãS.²ÕU0Ä€êGå”x«S2Iá +?$ø5Ãâ.D÷£B ª—ån5\²â\]9¹Ùc}¿@åÍ×¹|ë‘Þ·ßç²Yñ¥½æuèp\p–ãC}ëæk +Ü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÷r9Z«Ž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Û +„ÕÛŠ˜.YìÇìÜkÑ­Ü›)S)`˜á›=r¡± X8·sÇÁŒN@æ1ßÀ:˜¯L[O£THÔ«£Úâ2í6t´¥¥^­ÝÆÇHXîÕ +)÷€ Úo³&+‹4§•ß ÒŠìêGÄ„(—6´%³%ªKA±·„¾¡é¡¯Ž•ý8SЂìhDZÓ œÖ!0úÌ·-à$ŠÃ2ÈP£x€ :4ÞÙbfáˆ(Y…„2ß^Ò9Ö㊽ÖVF4=m³¢™RÖÝzz -T‘ñv9ŸÐÝf+%œqÐ{]ÑÍÏY‘VÌ—§Ï6'ß»ep€Ãrçë8¢Ë—¢> 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Ú3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +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ÿ‚”%¯Üfvf à Ù&ƒ?¶©‹4M¾©š<-2VlÚã»ló ²Ÿß± “"-r!àeEº-D5¯6Û¹‘OOï>ü”ó ÏÒ²äÅæi?}«¬ê´y³yêþJ~8ÈÓ Î[^dIñð÷ÓhYžVuÅpYŸ(ÒªÉj¿àé HùÓç/D5ôøE?†‹ÂÿÄø]9Û¿€ñh•å©ÈK¬–"­ÊŒÜ(Rö°eY–]íß7Ä»³<¿ÛbÓ¤MÉË`š×iY5‚~h²ä,;=hkd߿‡š2‘§S¯[‰LGœƒ|QHUÉN)C¼^›oª#ú¢‡É%1Ü0îˆ:?°:™Ü£…äž×rK”éÜ|M;ž¦ï–Éã—?hÁGuÖÊáæp;Œ¥MQp¿ÁÒþ%=zÛÊžÈV¶mžéÅÈcˆ£SgôªÊ“t²WA@Å ½Ï¿½”[_·¦UHU‰6ƒ÷Îvc‹»G©Q¶öxêÕÿôðJP¶$ŠXS8F /ñNd±UνØB9'nl´P:ÒÙÛ¾·¿d Žµ© ª¦[‹Êã—¿þûåuŒ«õÏ?Æ÷ë@\%NÇ~FÙÑÑ‚ÞÚo㉤vO<ˆJNÔ´åY]vè”KÁ¯ŒCÙÚñù@ò£uÃÒœ ³à­ìâ‚Àœ¾!Š>t´/ª{?É\H­$)½è­£7Ž‰>ž¬sz×­X>ý8*Ζ6‹ª®ç%‘/õ«C¡Ôï•qƒ’è±(ó€"gˆøµð¢;åˆó¦b€‡…«Û¨á‹,ç±à‘Õö6䣣ºR±=î´‘Wƒ˜I–ôKfƒ<òc»–œxºE.®§×ø +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ÐýþrV®[Ù¦€(f j68+éAe‹ÙÚ欺Õ2koZu1k¾fÉßgÔ{)oýe¢JŒHsWÜåU*ê*(¹Ž  Ø–•0<åL,ìÓ+¶2éÔ^BÛðͤ¾™PN’TŒ¢Xæ%Ë gÂ|¹h_¼°ò(¿)âÁ霯…¹À Ž”<’_¿WÆž…f­=­bØN¶ßpÂhæ=Œ_3!Bü1xaĶ†ž'{ˆj8KñÈ +ÕVµ2,Û è_ç³î:ù¯ke—U)¯Å5¡.Þf2g)¯ò2*j£Â‡u(碚Û)/òYrÔFý¸$ج—x¬ÆÉ 6ó§éiøkÝÆÃ@]´£v›yo‘!ëBWéG!¥?È{˜m&kk-öf"C3wÑ®(¡oÕíDÍï ] ½¶+hwÑš +jSlïíùn°+¼²±œ Ç9hÉÞY¢Zy’þ–hJ“60;Kƒ(±šßŽúÔ|žVü¶¨å8XcpQó‰‰Ø‡Û­5kW wR­Æ|ªîæZRÿhð †–Ç°0TÝ€†€ÉÎÃ+!@íüM˜­ÕHišñ+VÈj‘æ‚GÃÒèîå®Ä­§‰æÕÇÌÞ>1‘ÓcIç¼Z/­=«rþïÐÎf±ºëLÀ"Æk‡¬›8H!®ð&ùHÌ0 F }Àû ¥ÆYdad‘³2'lõúþZ„#¤×åLÖÜ^_¼‡2Üÿ¶a‹š¤F^LXnä+eUâf¼ø®™”Ý¥Ó­üm’ ªr:ßÿXE“VUQÏg•w?>M?ÆE‘âÏ‹k?.F•íU‡~Y\œŒ p;ÂñâökÓï”o?÷øh˜‡endstream +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Ú3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +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él6ºý†Ä‚ÃO,œa\ez‘fš.Ì¢ØÞñÅ#¼ûë0Ú(f´Rð0ó61Ê1ãdºHÆH¾þp÷å;-’3k¥Y|xö²©c™ÒÙâÃúçå7›|×—û7‰4|ißüúá{úL³Ô¥?ã°…aiÆÿàë÷?|KÐ ß´Í/œËÇÃ>﫶¡Åˇr_6E0ªEÆ2+m@hªÔÈ1Be=BŠ Â7bÙÐzÕѸڿnÙæëú™ºj[ÕùžúG3Bëþ£ËMûT~VS½¼Ç7nÙoJ«$À|ò@ÃCùDøš Py ¦}˜£º¹GÆ‘U!Xf«Ý¡Ø´3Kÿ5ŒŸªò©co-l¤Vc”  G,{˜Œá5¾«Ë€¨Û´‡zMó§vÿ1̪~CÀÄî\Ãq{×UCãqû Å“i¬ö â™a¬h·»ºü-?•ncÅ‘@€X•4B”A¹&(zˆcSiZ=„W›ò9¼Ì›1q$ͯ–ø€$UÙôuøªB·°÷:tUó8åFxn`'Òb:s˜<”y =º°Òš5M« ó#Ë`ÚLMN-G.5* + +Îtl þ?³ ôT/´ÌòL¢óÿíîç_ùb ±âû;ÎTæÌâ 8lï´ÌXÊSW껟îþù?~é@!*– ®.S@ßqÀ¦ñ‹)ª$ò”(ç’¹lˆhå„/™RÊ,4×LjžúãË‹úTFB +æ¬ÊŽ€Ÿ!$É2çÜ<³É€1£œ!©3à&$¢MÌ™Š,(˜ÁÔÅ3÷3T9%@›[M%sN»ðu¾^ïË®;…²š T—[I""¼"eS&ì© À?›3³”YínIcÄx…HÍ!/Q á"½ÅŸŸ–%ÍxÅÝÑ ­K4Ý}>®žéÀÐî£SL•‹n/(îÉ6àK…'©¸ïvØ©ø &!ç[Œçuöˆ–¯8ˆ÷ÿaâSMg¯˜¸r°‡âê%ÝòÔ¤7¿ÚÌ#ÆdŒr†L gd•˜’9«Ý]jØñvDFŒ×ˆt’I•Ú)‘´ÛZf©æWo p!öá ‘›2Lö4Ž³ÄÓýA¥ã1—¨vg†Ì:qÃó0^J Ä.ÎÕlÎð½FëÀÆý §Ž¹c6sΧ†¢,3ÜÞŽÏã>5ÒŽ5à„Ïݾ|¨~ŸáTrC<ºÈ© +!A?eÕÛ7PœÞŽÕˆñ«|¯Å‰ç¨Ösq7øÕÈfb¡Þk÷3ìb.¶¦§Îx&åïTŠfnLŒ|5ãÆdŒòœq™j‹fÁ^H9 VèÁ"c"{OygW–gjR&1èI —ûÇM~õ&øsšOí/ÒóSY3bHô!Õ?U/8#R1¡ç¬C2@]¡âÛPÌØQèºm€Õ· °P.¹ÔÉkÖ€*Çëv›WÍYàRþg6¯[_rD8Y%ÈØLè»”>sË8¦˜CÌ’Ú.;@}ÝR¹ Ô¯¾²Ófù´©|?–Ÿ*_ +â/³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á†ÿ‹ý ãu-±ÒÍ1J%gb5죚eZeÓDb‚0O#ÙØ\´(nm€Šz‚G`]nbræ2†Eõ%|F‚:d½`A#ÝüãZÌã&½ZIqÇLz]ÕN_l– €·k–ŒQ¾Ð,™x! ?i–|i,‰åû|Òaê¿ô=Û.¬P?¦=uá{ÃþYšŸÛyþ±škµœØ̼«`J»pDVkñú0bLÆ(gR@¨ü‡,b{Ùiª‹½¦¥Vãe{kÚ­ìahï~>Îá“K!ö}(›zÁ"¤ÓM³`ö¢AD¸ÛÙÃã æ0¦ïó­A+Æ`qfƶn]»èÖý»9·ŽDf@BÀ(9o×+÷ö-l¥çšéÔ‰Á—&Àáhÿ®hw‚ª<^gAvõL­)ŠW Ú`lÃk œmòO%ÎÜ2ß®ªÇCÕ?Ó ¬´¬ö4õ;ð¿±M!–=m]@·š½ÌZWa§ ©÷Aªì»Ò¸ÛQ¸Ýí«/åJZ÷ùÙûoéKò8:´ý«]:àdænŸŠ „ëÂßÉj¡(áã1-`:Šãº¬«mÕÓ…&Ê›óåûžÞU²]OfóX?Ó +ɶh·àãÖÄž¿Cš‘dÀ*ÈlÈ™¡Šâ*¦¿-Bz7©~«¡Õæ°-÷UAËÕØ­°7 +Y h Ò™¿8C@jͦÍk5íµ.Œ>=‡‘øZù£Äçüeze{îúr{z‰¯Wpˆ|,éâÕ-ÿÖ>%s'1º-V(Ì +ï³!†ññÅ1>VMKc×çÍšî‰×´²!rNÕ‚‡ó&è¿ ÂäØÛ_ÏIb,@ôY —¥Ëâ°'ŠÂ…g–Á©ãÌÓÙãþ!Ô7붮šö™=ŠáôÂåðpåšh»]‹w’H GÒ¶Tg(¨LÒ·‰×„„/WeÿT–Íœü²ý–$?Ajýáò¼ó¥Wæ:ÞðÞÆŽIÝyPŒR‚sŸ'!·ÆEŸ÷P:þn¶)!'"BõR©!SW©b…¥¼ïóbã“phO'4㉭eƨ؟jJ>2jE„{Úca‚Î[y/D+Û¶ëCiâí´£‡ñQáóè¨JªT’¸ÕDKòú)—¯&­Ç@!€®PÒäñî¾)‡ÛÚ–ÆU¼uGË©Ð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„ò%sSˆ)Àg™#D ¬Mh<~5ÙÂH–ò¡­¹äªÜ_½¢b3ˆ2¼t4WñdlØ̧s@å×kz ­|¿ 'ý6X"”¹u ¨º³i ƃÐF™ÍWeÝ⶙àRÓbÿ¼« úLC„4¼ FvèâG>K÷ˆp¨LŠcÜ> 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í¿Éä‹—¯¾ò#Æ7G ¾>qþúü՗秿^|sr~‘Ó?0ÁÌžäýÉÏ¿âÙ +ÎýÍ FÌh1»…cèlsÂC‚3GÖ'?žü#ì}uKsäœ I›-´DTIq|[¿†mCW¤”У]R#I°å ÖˆÒ=K„ê±Dqd´š)"eŽ#Õ͘&Z!ÁŒÙO{Q(Ö:O’E¸èC<ÄÎ`$è½›¦¼ª>ZÏ^pÖ›M(ô³›ØyÏëÓcxþòh©™×ew»mÞùÁö¦\V¿`LË•ÿZ´þCQ{È<ÓHs.äC1E¶ç|2 +%ˆ÷ˆµÕ¥ŠÕªÉPˆ2d¬Lûc<ƒƒ&\m×ëí)™ß:R .ï)jÞá® d–µßaû'³1Ì4L›0ó¶êÞZ;ž$[R°‹$r˜ +1 ;‚¶Â›!A ÿ QDCøŒæHÄ)(¤2=<‘FxFÕPtˆ‚Ƈûæøbú›FòàiòÃe<é/Ïí |PQ>ÐX_¸…²¬ì¹›Ç90PÄ LŠ³õpqÅ1Ÿ(5GŒp5饢 +ÉÝß•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¦)¿)š¢óá%á¥ÞTËíz[·~<8^Ð"FO3ðe½ò + j³woEÔ£jB‡zÒùT:ñ™–⸺¸â¨QÈŸÀžÔ!AfðÅÙBOgxÁH>7=)j^oëE]^]õ¡ô#Œú‚pߩꮼ¶!ºýacû +•È²R;ûè „ Þ­ƒà®´a¾ý}Y‰‡&(ÇTÔ ŽKØj¹Þµ€ŠÍlYýK› 0 +@–Ëò¦+.×Q*çŠõ®ôŸ6ÕõÛÎ^í°çy”¬+ˆ†£1¶Òçl±sÐYná¼;ÿ£ +†ùömµ "VÅO­o­]Ÿ³'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‡±Á•×–eTWãè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@%åiÍwG€Ê(ø@ló`Ä6_Äœ˜}EqlÄ©Ðú×O€áõƒ1¼®R-’!ˆ)FlÚ£ÏKA‘N@Jßu¢-¸@î&R×ý4ýfþ Îù4ý“S€P¥m¶‰ÉºWóVÉÞ§ÐÝì\ê•s9(þ„4>¹àͶ~…ä ŸùÀЮn«ëÚ)–)Ê a³"›ê`êjA ¬5ÑœKÅ9VLa{.I\–CÄA–óæ?µá +c\ðÂÊLò!¾]"M°Ü×™=G¥­©Q>™¦Ë²Mv-fBÛ` Š+Kù`ÁºA‚í é͉³”¾>v]Ž£˜ãi?Ò{dôøgV±8¤Í”é*—)ÁÚ$¹› “µ)FŒÍ3Å:†Á]S-}Á‡ËFøÖ®‹¥rµëv—¾çʈ¦¯gTžª,½Îvïû8X£°½ûßV¥;i8‘Vàø $ ñ¼ÿ®îà}UÚê¨}We9¡ö=N“¶÷ž(2NDò&=Q$ ÎãùóÕ +D%8ÄïŠ.^|[Ù¢Îá3 l«Sº•€ýx™ÉÇ|‘¸¿ªð›¾ÙØýÞø›F[¢ù«o?¿)×åÒÿýsçé£]Hþñ¥Ÿûµ¡øök°œÜ³Èí.ì— +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“7zt>|å`Ó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Þì#¬½mqdÿ(ÏJ9xÜTX!Ç[ æ¡<‘1z©ØÏ9Α0ç>†Ll—ø1Ú.ËŽÞvE| ܦ·1£~Y/×Ûô¸1Z˦XBS8-ý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ƒ~Õ¡r}G(óÓ< ¡%­‡Û(ËÊ’K˜\lÉ%Þ£>д»ï¸U¥>Y‡âMI$€ªzõ‡fPÅP´G“Í1®ÝjXi¬h²YÑÒmÕ7° CGDµÇ™×WM1{5½.ö]5 »©D¾ñtØGF²QÃÄ( 5´ù¨êª„Û"¨* +Ý÷„A›o÷MHåk²Š>hj„1°­§Öx’.K"Ò÷`H2Þ=X0\b #¦çô:ènK#ã +#!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&˜è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äÇó㣭£ ‘i0éß5i¶¶V¶oÇÚ‡{Eì¸èY¹Å“*Ýw÷æxY¡ÕÊ Ò£$Îð!#¼XBïºÝŽõÔ;ìÃ>ÍÜ?D«žô†©{JIè)%E œ´nDÎ lY„p2“q5ƒ™àÒÝN«ŽÛ¼æð4V8ˆeMBðÀÀ~§ +n÷£#™ôYTâÊã·"A~´Šõ¾³ºI2c'µÆn býò"½–怚vRòI­õ¬;’u=)½d¬\¾Oà˜ƒf`ÅìpŽJ½ë×ü½¼4¤B¯mJzhë«î\Û@qž»Z QPdŒVâl'SÓˆÓ—MãÊ°ûyšbá䧑Œ â•AØëŸ –æ ÔÞáWчô‚#gUkW7ô½&Â5EÌœÉÌLàWì·"Æãè8_]Ý¿Í×åå\†ÿ×?C‘-ßßßý—FF×–680ªÿ‹ê¶aá{nëÆåú²÷½Zë/Ljë‰o ë•bâ•â™s çÜ‚œÛ¹õ N:Éña÷¹#ã³;òŒR®Æ+¸ûqœc‡ÔªAï›Ò¾J"hxâF«Ø¨NƒñyD\½"8>möµêm†äð“VQSˆ£4˜žñêŠ †ìâ'.C "Ó¸e®jœÂb@¤“WK‘W +0/u u;õ£0e.„yGèí'âk." o;òôf)(zá—»mAÁ‘åš&mcÏVôÁ§z2 7Ñj(ÍŸ(u̬ìí¾ª]íêíŸ]>§ùðHóС¡DTÄf|ïî©D”Br‰PW"ÂÌ>yxÕbÒãp깑®#j^-}[÷Ë`$¼TÎ=Fþæî„ŸƒÐsè~Zlpß@“WWß̇ñ£ ø„qs¼‰JäB8D½N‚ äÏIôœ ¿Pš˜öŒ¢;íˆæ"Hý\†'ýæŒtñKÒÅ/%©Æä¢í:Óƒ0dìíÎMè‹VcÌà%Ñ¥ˆü,N²f¦Ùkª›… „ŸÉ(úÒ­áS~ë¶YcI9Í"¦~ÆM(¤B ò×séI*€B<õƒ( Ká§ø†b|íòÒy[”O½ fl$8d ¶ï³f€qÖlšÄYœc¶Æï4Îr6DÒ”²—9|ªÙ[²íÉ9Ú®35Û³ÛúÅœV…2-Sb¢ Fd™a…|  "86¡aÌDISUPÕHZ2‰]8ÃÏè±—L"~ôN°3áµmú]{Ƹ "gĘ ˜ü"«ÕøÇ ¼Û½ 'üŸÏ$Ú•àÛ¯ªLÒš»·6tsìü楿Jeìãÿ›3l +×âüí¿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äíÜ ³Ë¶²ó´N³V×n¥.g”¢X°–lVúÕÀf€ãÌÊËÕâF×~æü®ô«‚)Ór–W¶y¹rž0†‘‚æMƒ·UPÐv4w†ßèYÎã9W3G惟°qß¼ôáøÍ7®ìƒ:WK¤•væ³`{ýgºXúÛÃtCo˜¿7HÖ¿-¾zC e9®0Jlæ%iŽP¤‡Ó,4¡H*?¯ËàËÈMUk8á€BƲˆpî;sÜF‚"&‰ˆ¸”&bk¢÷"„‹˜AÃ%"Ç`:º²ÿ2ºèÊttþÔV0 –p09cN›µUôXA‘f1Bý²ÝýÚ*¶áãÅ‚DŸ*ØcÔÛfP<ék¶ÛLâÞA°)˜ŸÄ0së?cƒ÷!ÅXŒ²´,«Ö•Wv{$L¡Ñ‹<«ŠªtU“!þû¯]Rˆ%¶égLàôÚäÆV~(ÄŒ)¼òÔÏ玕—YesßÛ¸ïã˜Úµ à3Qµ* ‘0Û´À83zMõ˘ðQ¡fk¿bL!!C“wI\`šžÞŽÌ輜AÈ´ºq½m³ùʘ(1 ~H~F÷ÝÊm»Íƒ"Øn«'C>E±Pˆ&*‰úçômGßWÎþš.¼-0ûÑ$‘À2ºh¢‰‹í“ ³+Ì• +ì ²"†TrÒÍÌr³¼ðp^§‹EZ?ƒµ L¬Xˆ> +a扔”ûd[ú3MÞX ;ðµn +è +u‡jVG• ‹åèú‰œrƒÍP¯1¨þÈÉÐî@0åXÍŽ ¸ŠÇxsª!£Û’.tOº§­×’–^Ár©ÓÚ•ÍJ«••0ç9+ª&/ï\ß m÷ŠÕèsZzý=ë düi@ãÔ}nŠ*û}Ù›ÕÍd­ÈƒùÃ<ÏŽ !£.\[ç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×æ'¦çŒ÷àOŠÐ=ù˜rŽbû[OÚµo^Å%wü1îø#´E¶bX¢“p$š, +6îBn«®¿iW7^eé55Ez?ø&÷Å> ˜dÜMféO‘î¦}³¼ßh' +t琉˜ß\r®–©^ï0“A\ÝÕ}Óߥehß¾ªƒ@˜ÆJ¸l­L6·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Äý•¶b1Jº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”In1 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>\œ}ð SÆ­qÝä#ú¦ø™sY•mYW4’WKjüØä×EØFí?éÅMÑñÒ/Âe°8Jc—0LX×4Æ´™çMS^WMèУyX_Ö«rA=’*¶Ú:,«ÂDy,ÜĉvîeJs(X°mÅÝüæÆ}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®Û›†úÞˆq5@Í`ôн‡]b~^Ñ\sçñ$.a`‘7Å«) cMRuÒ­ƒ°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Š,°Òp–Xáá’ÅM^UÅ*Lca‹£¾âg¨x`æòFB^ñcùÂ9hg“·õ¦¡ùHa¼QJ±Ï+Årf,·[ó¶*$C›RŒ·.Lõ1 5Åæ M©žcx·åׄ¹Ñ¦øZ:œîë!˜¢£a 7ÛUFÉuð¦Z.&”†&T Ê»¶\•íQ÷wžï*ì·¨Áï«e`ª e£‚ФtŸHD¨DFåb»)‹/E„ÏUòÍûOÃéænËõÁ5Údx…¤ˆÈm ŘŽ±p¶t5uRM]±€ÏÇáÞß&Jkh:¡†vÛ)Dvæ†7/Ì©{qúúM½øŒÎŒmôþ¢¢âÖäa8àëm±(ÑA›S™Ü2Ãu¼ò)o·“( üL;ð7ÃRxé J ›Î4IG0PÜ•Êe­l·/²çCê„q Æ3Ïà]äé€PÉÐ{ dFÂ~/%€ŽàahHžF@ +À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àÓȱ ) 5Ž.ñ™/Å-q=ïKΛ†˜?„±+zgРŒ‡7”Ø |:»Sj@ìž_gÒ×;΄È5Þ¨#LÎÙí㎠£±gtãݵƭRj×3À©˜Y„ÍuqólcŒ“!Å][ÄÏE>û}›bf»2fŸ)ÚLÇPöúõTö rˆ%N¢5T‡W$ŇúŽÁ, ê´¬»Tß>z"}4ùkÑA0¯ê,Z64b­E9f¯0®à]2å´ñÊúö2_|¦Þø<¨ß‹€¢mtb!S®ÀÄ£Æl6SÖS¥ +Œ ë¶àÙë×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“š}Åx„©î3£/|'"B†ª‹H1üdÅjT¯/}'i–Zo¡˜»ó¹†`@m#ÅÖ‡ÚÓAfãRTïžÔ&Ç“òÁ7#5¿Å »–Ò%t/ó`²’¢œQ{Ä$SpÕîvì‚«Vªpî°zzì)&C’ìïkÒ~cä’¾Hn£cˆ¦6õbÿ¼êr.¬Øý“Àè+rgxÉÄå +°]÷å³é›x ò0…›5`}+²Þèw3`nS̼ÂIý¸9L§`3‡XfL·¯¹Ëiˆá2QH±ò×-A8ñÛû´W@x…"_<âì#}At @¥`ovK“>û³Lfêå8Œs¨9Ø¥pbÄá>‡°8mD:£ïàåu¾ö/c>RP)i3•¤Íÿ½€N~×ÞÔ›ò_Ý]U6_@ËfM÷9tuësæóUèt±:Þ/ÃÒ‰\ƒ~˜uÁÂY4ø½T P€(üêùÁ)L'4ÈLJÐD\õäЄ€,í>XÅ+»¼¬‚$rzЕ/¶b!0Ú?Qx­cµ§¾ .™ÔÚͬß{¾€:zIOpâ‹!7 Feã®{c ¤!Þý Å×ÚÍÏòÅÔ[”œÅ„NŽ.,¼ÔY#½Ãg…¸iD?zV!ñ^Ìv·‡XÓØ}øÁAEuÀðÁøÐÕKµ£wð¨R &E*‡GÝgõ)¬0ÝUiC‡ÁÃ'P<|MÏâ7¨~Ú‚:ƒÛaè¼’‚Fº…ßð Š)Á|>žÿF¢ )5õOF>{ô_$Oýßdÿ§R Bpnðǵu­î?²¦PNJì|“Œ°Üeý¿ª9€endstream +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Û¦&ºûMQQJ?Öµ;æ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ýXXÇ—â0ÁX£töÖ<4`r«¼¨x½X–¥Î\*/×e›WJ—ëª[Yf} +À1 +ÖÐÑ95övN/;ˆøÙ:~ØÑ´›cèòÒa——ò<ùTR61JñgBžJXzŠã>ä©+È×-1ßeŸI,\Gˆ×r-í³x]7My·Å ’†öNÚù± YEÏâ+äIÊ’06ú=N0'   +ÁË”OüÒúâ:Žjt]主2%%âLç£/Æ=W€) = ŠDâ„_>‡¥ÆÈ ,áÊ9{C°\½e“+“hÃãLO ¾Æ¬éOí}xzuÀ3¨Cë†pÑ”»ýöúøZ,AûðJîh˜ãØ" ƒsHáÿ]pIù)×”­— ÅLa×Bî·IÊ!° ‘kCk(+€ Ûm‘S|bøô±¬–ÞÄ § B”À²‹w½!ÆìÜòÑZ~Æq8¶jU— +ž€÷iÊcAAñ„F5 ¾g ùØ^fUè\.©¼Ã0ÒâÆéëhÉ¢=ÂH^4å)ñùºG‡¸*&!—— A)Ì€a¨¢†µ‚®À€ž? | Uðn°mq¬c ™šg%ÙFª®:ô¹%ÎÐÁm¿TlTEÄäícÐz²ØP°÷en¨\W—.°ÑͱU¶ô$%×þ À"àöR䡬¢'ÚDiq–µ2JZ}.šEˆÖÉYY5±¿ FÔ¿Æb¤É;„#l‡˜¬ã¶LæÂ[Ï͘ù¯®ÿJ­áq…±ˆtÁ8B% ïíÃ>|ä½Êt Êƒ‡Ï@Jq:šã~_¢›€Æ¦˜w,jîX˜‹â+Ôb¿çð¼+h¦,ÏÉãN) ;ÍòXfuìe1x§ö‹„Æg”N¥”£}U–D€÷á‘žÙ¾ÎÂ7ýÓ(œýTSÀ[Fˆj¬WtŒQ,tžŠ¹N4׉åCMÒM.ž´‰& %;„£&DIÁz¶õzýTê +W ËË&Xtß +OšÅÚäUg aòŠžx‚1e.vµ÷S~d¹çÇBßNÁc<4é$O®å¹ +¾8y¾Û…§×S,Q)3ýÒسè6 +{©EbSÊšñþC_.8cˆ]—Ûc4÷±gExùqÈ@ÛS' ·±IƒÑ&µWå¶À„ôzJ"6–ļ@’ï 4Ë*–Ò~“ƒüêÁéX;g"ÞNbÅrª¨¢–`°LUG¿R#ü/EÈx +áQ`§òPϳöŒz_—‘Ý=&ÂÍ#g›àŒ²:Œó¿J„.ªp,K®ÒO̸¡?ªH-_"ŽE׳â8;_eKÄ Ð瘉Р+Ãí®¬ "ï• ÙÀÙ‰(梲¢ðu%<=ÂkCaÙgSh7R(‚×Y.=C"÷‡² ¸Å„‚¶»öˆŸ™e©×cg8Ñ„s<еvþÎWÐ[|Í  .<ì2íD3L•þ™>9 öïåBð!1 +Q–,|››šˆÚgBwàV3R]?Seã“qÀcP«¦cÏ„§Ûàét6üâg`ˆÓßñÈ ÛÿòkT—â%ê0/m×5lÚfG”`G°E¯§*8,ÁöŸ“-&ùþû±ˆ€Ú+.Ü=³ðÿWxP)Ñ»P˜¾DÓVN™:À÷^0´–z f“E@ï]ÝJïT%BÃ_bÃçfl„êZ·¯ßS +Ÿ¦(F·›Pãk@µ "Óî¹ûÖŽ~Ñÿ`âžsÄwpߊ)HgÒ(aÍ´H3¾UTÏÈ0ævºkE¢Þ(¤®ô…+…šÊá¡1ž®_ÀlÑ)–VB‚s†—ÞP—<­ÓŽ~Ñÿ`¼ž1ßá¶ÿ»à•‘<+£òŒ´ÚQ='ň[Ôj¼8à,±F>vq0Ìh.±ÀçIߣºk~6cŠJilÔË%¤`3 cN!Ž·õžz¶Å¿wH¿©‰ œÀ/{@"eú&Û™N Œ‹úR÷ÓÇíPµêóU%x¡çÆ3z?C^„? z{SãÊÀ +çáx—¸_ÐR'Î4l"Á1žÓxªØHã q'•C×ið„¸3@ã©uàâ©SqMž,ž˜"1ýåø ×1¥]añ€Êªý“À鉄óyV¬õ01=âÐÜÊ@10µxΛ#ñâD=v¢3Ž/ôc 2§ÏNœÇ^ižœþœSï?(0ùîØ„”yPHÌP±ðlÏð +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 Ú@; #¢aT6˶&•Áž†aýÞ|µ´vgmC°33°n@ÖG’YͳÁÊ +°®jÓnAíç é?öÌVç’ë£a˜ÖÙ?yuåR&¬êá¢3ßÇ’IV̲\Mù÷û¶Ç¸£œðíTFRCܶ=îÛ ØX3/(G%R”·`YýÖ A¤VuvY~Œci;Úfn—;Äá¹Ù{‚¿.M_¶ côRÂÌgN²n¡mÐÉš± g‹BF*¶ÛƒH]MïŽi5ïví¶G£Á)Òr~ûþú ÁΰꤑŒ'AµY¦RÇ}m–‹z•LÈMg`±ìÈT^Ó{† c4]¤š&"ÒÊo$£!âv¶Æ( RH)Y4P£ÄóªÝl(òŠ÷£0ÕÌÖÔµÙN „|›hvÅI +ÿç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°õæP.Ç,Ž%^0ú~Ô/ ¸ZðUf÷`Ù`ô'q²F;Ã¥FØK:DóÐcÝa×ÒMp§ ÚS±ð5†OçìQ®Ïrjøá~k¨ÛÀ¤ØµËøî¨{kwýÚö÷íª{FÕ?^^8r ŸS™Ç5œ¹xÂ[ö奘S"\þU±oéT͈á»Æ5Ïh£+°¸ ‘,&‰òÂI¬VПĒî»Æ+-øùGˆÚŽ…8ÆM˜œ‰®³€nadAwUÙ9Ò°wÁG^lò¼m=Š!o¸7|{˜ˆ;fÛ9 ƦÕq*sÝkŽœá›VO+{ÃtH-6ÀÜ,wíÐ3d: I´^lùžÜb©&r\±÷wlüN‚æâµoÄ[ û,‰´'Îèt‚Q½Ùöœöô|÷€2H°¯¢ÆYQ£^½6$VæîÐôæO[êðÛ-Áw*üçDª&” +«ƒ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)×-;-É+ Þ§ð @,Â"¨›òƒ*Ÿý^âC»c¾ Ë­6_løNÀ™n”ËA‡u¸gÀƒ Í×Íy‰$AпBli6ešú$ë+`X®w]Oke³¬vXf"Øøýx˜9n‡¢ƒžŽSÿ‡ÐÎ:‚A0ty•p‹Üä* ®¾"€«MqÀ‘ç4æ)ÏçLøßó¿{ŠMÙßÜÛª×\°fuW™-Í}CŽã¡÷/Ò£ãä;x ô6¸nìmn¿úÔŒÂ/«˜¬ÊnÉX\ìÓÝ@ˆñÈG'0$üR4ñ‰(\ó»?H¿Öiˆóy.§¿5©8rYdž(TR§”_®ÎIÿ?í ;«endstream +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¥ú…«rñÀß:= 3ym/nÂ¥ ”É2*'0kOíjFÇ''Ýr.9™J”Õ^rÂþÎeGƒ:^ÃnÚ5Mp…•Hæ‘ŠÖ‰zYΉ6æEÕ©’|PçLIXD²/ÝÑ„ùhB³`÷åâóaGл¿Õ@×h³œ€I™':'ê’táhÂøÔñ|‹­mHC0d HP[¨Ù{wê\ý +~ãÄK€ZY””¢.h[Ç£”žŸ«jG½Š§Þ,é}´¥”%0õŠ%“£oò1I  i–{Êo€òû.A>ž“OˆàX:wföC×Së¾BåFê ßk†ãqÃ'Ijz?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Ö ïò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ËO8ü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!1ËäÈÂ×XÄDÓ»ŽoÀKwØíÚ=0ðJÆ5|œbp¿/9ÃáÎ`vÎPªÙo)¯ZÍseŠÁu{ξÛô$M k€Å^n½q}H„úgZñùÀ)vð”s0³ÙI É{w½bgW¯7ôŒ_,ŠÜ¨Év’EÛ¬"{2 ¥˜˜`œ™M0Ö¥\>Ô®Ô½\= Ax¢.J/¨#ɸ„yDËÌ&¶È§ +þ9É&”¬ƒbÉ2檣­ eÇ„T¾vaRŸs-Þgq’êÙ‚~õºá’ó=ƒ3MñʼÊë™PÚÔ&FxÃ0`efÇvÿ™ÅsSŽz<‰¿ÒQøº£éÿ&¥‹×î"À·[êÀ¼Ï®§¶ç¯Ë°<Œò´(t @÷Œ2%¤°ÏUEÂB­ÇEÑ!‡CyÇL'EnÕiÂg_Öë\]$-ðDAW£<€@¹Š¿öàpƒÖ¡ãùÏ\W››¡så27jöý {` e1NØøÀ¡üÜTeÇMá*%`t;äÛÐ\×ïeȹ03+tLÁ»@žå¸Ú@àC¬x¦ZýÆW¨Ã®F1ø¿Úûù’˜@$y4ëèÑÚþæÈÅb¦I6áðå¡Ò¶¤+Ðî_êÏ5UsZ ®k@"l6œÔçµ¹IT,Ôp|h~¢†Û—;ÚÝ?è«ý¶nxGw °Tlú]éÁ÷]Ù¡â$EìUZŸÕë(wX?¸:¼ ’¤Êõ¨$©Skâi(Ÿ+*æëq¡_ì ¾Qâ +†Žî  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Ù1Çö°aÓà’|¬·½"ŸšŸñålZU?³B¼ÝÆmË—UÈÀ§ +Ûé—Õ~!’Ò2&ÿL1òœŠ“ä_°+Æ÷´Ø©0ÅÐÛU{Wý|Í_v=œ¾IFƒ;Üøž¿éi­r‹N‚²°Ir'‹Yx6½«rN[*OT;Ùh+ùv¨v¾…b}nÒÊ€¶ÝÜ+ X? UpWÞ²”Ž„‡¿ÌÁ5Àƒ» +Ÿíè}¼¾¥°.`P…äü §›×Ã:ô͆¦f}Ø—óXùsQ8‚ãMäYr êÜðKµ@½®~äñc<àÜ~’ÀáövqdHZÿïd÷vY¹è• +£Cž Gɦ¯7í}‰âd3¶^Ð w7JŒÊ¸ +[•=q0÷¾*tý‹´[ë8ªö6ŸÒ¯¹ä)Ø°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±Íâ(•oå@-Íì-ŠbztìبYKšÀzÅoíH³>ûb-é8;œŽÏÜ1µL(è‘Rd,/¸&õÐP¥&oˆ÷pRêËzãÍl{èw‡žë·ß’ùò)”|évÕ¢^ùK*#*ç…/ùjãxN1»=‰YÿÇÊœé3åMB¡^üäÖù‰¥ðõÎUÛ~-D Žã]¸’ç›KÿëP&Á?cDþ…‘^ûåÿïÿ| ˆÑy­ŒÿCb’œmnIé3ÌýŸCÎQÿ/›iendstream +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‹Ÿ½TŸÈ™¬ÐZ:Îè1£’mÝÞ—H­IgÈaËñv‘ ‘¼}(›ÆÖ=íªáÁKoj¨’sÆy®á1|c}lÊ]µŠˆ9ULåõðLW GB½ï-3RÄù¢§½ÑŠˆ&p<@‡Öq½”ø”ä:pO㶃ívUcɦå@«ˆ­ÜÚž¾‰û}ìªf`AŒ2eÐ:D7›ˆ +Æs%“þÑ®ª_9— ¸SŠÊRf2ÎM²Œ“C È1ý±Â#„(ÁTšþØŠL…¥‹ä~ïTkœ'Iƒí˺>ð±þÈWp¯¯š•!2ÃR9²ú•„”uß^'Æžž$Ðë @¤3¡ Áá”RqË)g*ó™vV€gÛvÇ=YÆòL$àÄŸ¦pÃåÜ'(~ü¾·ý`×(<#‚¥At!ªsŒ¯¹/ yø;n{¢KÞð|ï·Éðhí¬~¶Æ(£L–\WÓ€ˆãHI“ƒJ%3˜f¦rãHD)Ë…™ÈˆoüŽM ‹“…ˆK!§¡ +¾B¸¥ ýBœNŽrÀŸF`uï!Á—i‘%w1›“ª`JféŒÇo²€„[i‡ªmzODyœ? ÁuM+—ODÈCXµ»{>Þ~éC'½ÒÅ™—:[U:(We`ç‡òØÔ)`Ž\ëâcøKV»›¶®ÛƒK4o)gÙî5ЕsT2's &°Q CËáYòÞ’ýú=5eCïÙ—»ÇÚo&g‘úzž …×9Šª—Êô³šù²8× f”r¤kˆæ5Ýž-PÝ€þ±:œ&i–×ö~ ™–_.3Ρ_sýZ?dŠ [ÛØ®¬A–øxÒ´Cµ²á«Û7 Ê=ZúLº›H)S‚3 êÛw~$ðÚbœ§LÐÕX,àé²ë‰ò¶ˆ+ŸžØ¿d²àA|PJÀùHÈň¨2êEO(×vSîë@g#[Cúð(š`æ“šä}{ 0˜è‘nb½/(&Mªç¾àYðeþ®m¿êªûÜœ×É"OY&eºÐêLˆyX±Òf·]ÐâvRâŽç—Ó ®Ä‰á)^$ð'»B£ M‚„HÁä9Iš™âÂÌHzRk§ž!ä)6$„Å \h )“gî‡lÙëñŸ>ã:ØJ¤bf€™B¦Ç֥ݵͷ`÷ + ÿÕ+÷®°ºsw -çtž:5 Ϧ\UµÏ6ÀÀü¨<+lñBÕlÚ'Ô´M}<§ âI;¿£FΨ)Ãå‡j‹ŽKD)L êŒê{œ»;¦Ÿ—º/­?+tB¸©0²â¡oœ“2ˆ1ß §P­œ8=Kv.øñtàôy>]qèÚî_Χ½U†îK óN'\ýЬÈ5Õë|™è€ +¨\ǒ¨¶Í†¿ô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ºˆw"WL¤Ð~~ÅJ²Â`ãQ-GŒË)Jʉó¶M° ïLjLô‹HE#™VÜÌ»Yšñ¸ ÊsßgÄ5٥ߦj¬}´kQ\Û†^Œ7ª d§“ÓëýÊö~/ ³àüÁµ~*´~î­Ù ÆéÑ€‹“îå„1WsøiZ"5mó*-[,¾On†°ÓíBk~òÐé ¦¤,6k))Ð3•‰iÍèÌS)cíaL¨.+_#ù期A!å¸B¯¢òÒ5"dÙ9¸˜Ôóšæ€PËZ."à¡({h ^RCRÇ=¢¿BUaU¤Š™BV—ûA)tÄ!r(¡×ÛQ5Á +í3A¶àÓ¢£º·n¦:6Cψ<—EðR¯ÄÙk+/ê‘$´VšåÐy>3Ú 6Ú<à|ÀÈçzÅ´6b6~Ó¹s9šRà¸Æp¼e˜¤±‚ü|óýKZùù¡nÚÍv‚ ˜Ñ©L­q§ÑǪ:Í@Ú,5Eþ—Èó-WGx;5ÉþÑ‹¯”P›Ï£46Þ~TƒF ·¨Itß4¦ñÆÚ¶ÈI®ü %?èW~äìæÊH]¹½c»§Ec­ÇI~Wåã°»Á\ù<[$/7™á'»}?Léóèh씎îŠë0œŽŽ¼]øˆ{ÄiŠ–Û¯u(ÍOž£y0î½û(|`à€—A°æ@Ñv_ˆu>¸€ÆeªÅ<¸|Ä™¥ó¼Rd§”0r-Œ-ºófÊ_ÁÙÖ¯Ýð¦ÿJoà˜*Å1ÕÞã"­Ì.ãê{‘tôåÃàÜWõ°tñ/œ&pè$›qæÑ›Ÿàc€Åªô²Þµëjs< ݧÞ_óIï÷þ¨›úŽP?bªB² ÿ ˜Ð:}ü¡ü4>4 +è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¸¬ž({T)Ñ‚‹-€8`¡”F£¹ñGœdµ¹¯Vÿöa¾Ê¬ÁÓ‚LÑ’IC.I*™tÒ`úêœ%ie»—$ZdåÆ“ƒìÜØ×çC)Td+?°©Öžw’•žbM9õ¤z„Õ½õ¤ÀGYYû§ºòCÖîÇfGð÷鬰ǼžWëˆGbŒ¤Jqw$”—÷CªÃÒ¼Ù)’¦Uùªö4”†$e]Ïüh`‹wl:²K3ÉgOÏ‚àÜ!U˜9™gei +ëßfժÿÕc,‚3ê*=lÓ³-ŒµÙ½ {ÎËîù¼Õó ±ãIK傧IQxúØx +è"p:”‚:ñ6Ѷ3&IR6똚Y¶.ê㊀Á{®öâ lÕÖ&›¢[JíÐDª×¬ÐDÚM¤gžÖ¬èhO ’I³o"a$a°ÕŽÊgUQT^ë`ü¿r.·"‘^î ¹õ×ÖLÿîªâ®—°˜¤°·½³jJw»Å—?;´vcA™oºÄ©¯Ú_o8eJ’$NÝrè.\EΧ¸ŽÌÙbY‡…Œ +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ëO­ºíD#§Õà¹ø\tœaì‡VD?-Ãð^Ž ¡¡×:žÆ7ΉE‡ÈU®a±§ÛåŒ40ÀÖgYpþ˜PÖµ°Ž®þ˜™ÕÓS;Dಠp\ßeU»c“p<Œ\µ¢"•»ÜŽ/ÞúåE6.ÎY3´Kö:>Œ6óSc'«|YçU¸ªYG°ˆêÍÒìù4è«E†Ó·³6aõª¬³¼$}ÝTÛ#ìŒ!ole‘mšˆŒf:5Ó®ÍÖõº-cW?zja j²d¿Jd4% þHN‰–‰~Ny‹Ä4Þ«ÿ¿YÍFÈÁ‰Vêðü< +²Âc3£+j¸=ÔP$’ĉ`ýU(ï‘`ï’q\ùp…õl¬dãi®8•"Þ¥L)ZµPÂ|S¢ñµöSô.I µjL _°¶ê±(-ÎÕ¬cøþ¸«r¥F×òd:põI˜V•øv¿^ÓDâ<³}~lLÙþÓ'f#UL$KãAà/SšÔŽI‡Ågˆlf¶MIƒŽÚˆ5œJ*ý)Í*+žg ,uÑe2B¸'Xã²èÆ58RÏAÝÖ?ÛÚ³ø–«€"³Öi )y‰L>ì3]óââB9Ýf‹Í^ú1ÍØzéÿ6–sD¹-Ô¾LûÊ•/ª\¡Q7ò„r‡†T†ôŸÕÙ¸¿ìj÷f›´…RM(‚¤‚ŒDWcª¦>Tr+_ +N•B@SŸ›áÄÛq%Õ‰Ú [ã>ƒ®Ëvd¦ž_ä³T…¯ØtaRšzâcú·u™ 8Cs65P×/ò²!ÏÃkèúÒ'ªK$iT¹ï@ÔSAÂã<Ç|´ºõý +G2ëéØâ#Á  ç«€¥cN÷›Ç¾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ó ”ÀÕÚúÿ5‰¨Dendstream +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ÒL1s=™-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<@baŽ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&Ñú(ÉâU13ZK¬t<¨,q2+!\ã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:ŽÔ´¶ÏÝ>6dL\ñ ¢+£€™eŽÅ•I©Ž‚Óh A¾€²y´Ý%!hqüYLÈhÇ~¢³5 Êä@é3Tºp:ù&À?í-Ï‹û®·ÕZ¢ÕNºãïüÊ—4+»n!‘ÚöÑÜ“™¾ì81ÏÂÅ»÷r¤Ñ'Y*G\òm¯ée(Ú¡óIѽOŠB¿ +»†–°]Cm1€s].ê᥂¸Ñºð‡kEÔ«™ÝA(ö½L{Q&õ·óÚ„¼tžCMRÑ<4ŠqžÏfvåe¡ €„µ¡v0…Ât:º¼§…ª¦Ñw aVxÐ^«]\$=˜Lp¢€7®ì`öR@L= ±ôtY´­#µ-`ç®QN=å^Ïn:iá‰î:c1í~ü¶Æ3†õg¼ ‡#>¦ÿd$÷02º+ªyCSζ_.ÿ1§ â”G}'”{N(;Å;ÄõEm¢({RÔᄠƆ&<” +¬Ý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ÞßÝÐ+±^Mo¦³éýõôòÇüãd:ßûÒõ×F®räçäÛd¥ÒíÝ8ò­'ù€ ÇŽUL<ß…¾çºíJ>ù2ù{Øy»SäÏFÐq%WÏ ô˶aìûNA?†ë¸{mW²‚º(0¤æÚË/ RRþj\¸V.¿»ñÃNdÜPš‰ââ$ˆ%.ˆžU¬zF«Åáá_=|G>Ò3£¾È)7"ÿíÕpšÖ'ÑÈöh"m=û]B=ùÕ.ï<êS%]ò"è»N| ÉAÒò!§¤‚²R¯à2Õ“¯¯È~¯{ŽýHRÚeO ºAɱëÅTPrŠcÎsö¤§«ÍšV­%œ#Y¦Çž#‚éqIôH0§ùVÏNŒK³R4¹ Und¹h–GÞò?š·ÿ°’p8Ä2h]ný0Œdû†lV)*GœÈU{Nƒâ|M B;Šµ1ne0zĨ·ÏeÛô|Ï7h-T#d‡FŽ÷¦åѽT +]ˆ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-#œï`“‘zŒ´Øá³SÃ’ž¿hŽ–_wKÕâÀ˜zø¯›¢Íɳ +R¨£'ËMø-m\EÓÑ;œ¯UT-=­²%|ÁêEÉ-ÂXƒrÓ%ø%ÃQ1‘YX ȆŠQZçMe¸›/tŠ •áèφ´ê4xFD²«¼!£¤ó†¯Á®l*øº){*ǵÆR%OA’SYqø˜ÝTŠŽÉ  +(ðÆ|í›bIêAË +ZÒç &¼’u‡ŒÚ¨ýÌ€D¨Q*%4;J¯ ›*§ ƒfÊ*Ñt +Þé½ê,q\±­ˆ=FA~Hecù˜hª/ä? ›¬KÌGŸ´äœ$€”x™Ÿ£3ö ?ú)éV1=u##ŽËdÍêîÛA« \¡T–2Û£˜¯ä«Ÿp7‡¬Ì·½`f´nÛDÕéÂÚ÷¤²å´‘ e·iÜ)ýö¹‘G[fDòô÷‹Ÿ×ôjb¯vËg´Â'ßA–’5‘Öwòì¸%ïY`ú»ÎJ›Ø‡Ý’þ²6Ló¾G«’Õä•@î]ÐÍpC¤"ƒp¾(°¬³›Ãp°4L§xŸ‰Ò5FÔ¸äûFá @G…ç Ž5Uª¾}æÔËêͶ=€oKÙ±rÊϺ»>T×Ù{,Úß Þ|k>ü¤àÉ F9‡ q·ƒvBÙÐGÄ¥v£g–·×ëç¦ÿÀÄ Ïendstream +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 ÓhA#²æÿ´â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‘<ù’*ª•f‹™É¨y9÷õ–‰ËE°ænÚŒ»—€Ê½zƒ¬‚G=»ýë<6©"³¢ÑÎT¶|¥çý}wˆ.µ¼Š2OcƒŠÅZÖ[r=Ÿ¦¼¶òLIt÷Ö¶ j¦JÛ®[ÐöÛï›/wv7_®™ƒ€lïm\Ú¸·¡Èƒ ýZ©Â6j¾½:Vý?ßÏF#endstream +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þÓÁQ ˜e?®Êcî—ø¯_)ÛÙ²hZúúÃcNòñÛÑžÊzs"úœœ‘M¶,í"+7õ¡h·;/ϼÞeE5â£CùܳpøƒH,„aZ§f¼k|ñ:³Ž5²k–$io#<å"X®Þ£xÒãÚ¬µ;[µôùÊþE¢*ƒ Y•SçÇ&ÛXOKt +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ú†œ¬Ú[>G¾´^SÛ†9=|ø„A ´þeåQ+pƒÙ²©Ëcëq÷Y»EχG,bÒÑáZçZ +@ÒRžœE2JÆÇI'(c28ƒfïmE ¬¡–öRºRM#­3@ìõ;ÆírÎÝ– ÷BŒ 9¸(h`†Öõ:»ºi©çDÂóõ±Ýýmª *²lÃÈpF1óij£ðrv8V6‘Rám ì)²à¨Ûg¤¦÷à :Íã«ê–ÍÞ® +ÜÍÑšN3jÓMZž„é™rÇí&¤ ÑÏ$‘ñ{c»_ÄT[A3 +PŸ SvSB›S>„‰æk©w„ð¸-ÐÇàM‚Ž×qGrÀ6;´è)€´!ApG¾§1“lëc™Ó’K?ý kƒÑLe=`BS¬9ãBÉëÎiˆuÙ9uXHõ½}Z\tPœ§L¥ñuêi‚úÈAÁ)*£#òÿÚ:sæÑ|o`h;¯VpœO`ÅŠû '€½ J!ñ Zϳ &ž°û>'çŸd äé‚IÈòåÜ°²ï1yr5 «PbJ—¶Ê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Ábê9™ÀHYg¹‡„%Bµã&¸»X†Â¡^TÐëÊhrýR¡.é±uÕ*sPêNù»ZÅ©ýT­‚U×½ŸvÙX]ä[Ñæ¶ÝÚ×- +?¥Ï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õ‚´Žàù‚}¯ˆ¼])9<7÷MW0qÈù”WEÌþzÇã´Û¬¥±Ç¬ò=º­Á']z^ŽçM±©²²{CÀ·#HU…©‰/k=»go3hqéøI,†ü@¶_à,Ó3,I»çéÑf5žX5YS ‘ +“ü‹CS¼sqI1vï‹R|ØÁæ{Ôì A‘”’4k8êŸI¡· ÐÄÖV~ápÎSÕɪ'zêÿÞËåxð…[£G¿º –’¿]ýÁ¿°¤ó7uëÇÜ™N/MMÒ¹£iÁa ŸÊ‚*Á’54BŠ¤74Æþ£—‰¡çséócÓ¿ ¯ëð„€à"¼Ic‚’ö˜þn0$¶Z•un×CŽœ×GÊסÿÛ$Ñ\tŸiÊD +Õæ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§Ÿ˜t·wò´Â±ñ{Trá·åº3õk6Èšñ'h +u?;úÛ¿tëˆ Z‹iÕ©f±†E> 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¿NžÜØé¥×Ø=[¹iû@‘Ä Eª"iǽ¹ÿýv± Š¤(å:—̘ °‹ß~BbæÂ1S¡ãúq0“qà„®géîÊm`ì‡+Á4 K´èS}¿¼zû!òf±G^4[®{s)ÇUJÌ–Ù/ó÷¹ùyy÷x½ðBw9׋0rçß¼¿¥ž˜ïî?|üáóã͵ æË÷Ôýx÷áîñîþýÝõB¨PÀ÷Ïp惺£Ö7Ÿ>Ý<^ÿ¶üñênÙí¥¿_áú¸‘߯~ùÍe°í¯\ÇU8{×qìÍvWAè;aàû¶§¸zºú[7aoÔ|:%¿ÐWN¨<9!ÀÀï P¸Ð¢™ c'ò=ßp]vIC›ªÖôl¶š¿º®Wp;¯é™é:=ä+qw9– +'vE|\¸¡ÁÃfFÇûý¢ÿÁ)û§ó"ÿO:mòª´ð9BŽyj'Œ@Dý%Né@å‚„¾ë¾'¦áê:nð[H/v<БÝI¸Z*äv_š1o€G…*šõç;Yµ£šXvxÈÊQ~×]â‰ú®š¾ýùíòýÏôb¸–œ—ín¥ÔÛXÚZžmg[ëšH0Ôu¸j®S?ç冺’2³Ÿ–Y×{{ÿDŸîÍ'US¥UÁk’5ö!ÐRн@†WÑL€E¸s8ö0¤}dz´…«dDª9¨Ìæ{ð%uÉyµ· PsÛ·Kò²xå¾² ü%lØ#I£ë¶ðÞ"1ON ÚÚì»y”ä‰c‘çl¶Iiù4ûrí–È‚½äEAè-+Öë\²²Ê×TôL«Ý®-ó4ixà%o¶#¥ÝÕ*á)AôΉbüF2DIuä}ªó ï¨pG€Aµ[dú9Oõ Úá´„ð£ËËwTëЂ/ˆƒxÈ€A»ˆÝy]µr)¿£Ã§.‚âþ•:P¾ø\1!À=ãKÑÍI¿¨ó ãn<ŸûC¾KyÁÝ¥Ö™Õ p@Owï .üŽTë|Sj&þ£*uêƬT†rÏò½NóÅÐÄ1ê²1"`[ ´} ]cD Ÿ< ôz_“(wôö²ÍÍfá#gFì3±,à²(Qß퉸¿Äïm~ 6Zç¼K8Ø$çÖËV£ÞKÁš){îÚ[<=]]‹¹¶¤úë6iëFghÑ$m©É4H»‘pö{B;»èÙF {NŠ–W‚­Ëo?„²§8~  +×là-œÏ[Ò["hY¤œ¼¢ËÇkN+Bˆ(‚p¬2£sõ‚ØJZä4xˆæ õŒb£ØQËØÏ—¼Ö(7¶>ad}<}g9;±;£mH× Ã€‰;«5É,6µqGk*è=k †Œ*–ã«(n;/ó&·†7­J<¥MKȢ΢J8j²×ÑŸ@»IM»gkžï¬(³azZ‘ yÀN_·«d‚¥w"ÂEë³N T.;>Õy'ÐQ™Hç ×úpÐÙbƒH<ñ.ÆrêòúÕC/:JùbÈÑ0=•Ápp¤ÈQÕ¸óuϽðjš¸oàczYÛ¡ÅŸè]ÞðL1t®ù|ˆÈÆ0´!¥Œ1¡žŽ—$ËØœ‚ÕubPþ¡‰AYpÕý˜×í =àü¯ýó¯÷`ØŒ —<#Eñ] uDV€ØpƒuÒ<Ë´Ã$/ÁR3©BèÞ?Üß¡˜Î£-ðí2ÚzTÐf©ŒêWUŠ_èQ·E…‘ÞsÒ$ !ÂE.:ª 6˜S+„±ò±¼Æàá`ìJHŠ ÷`D¤zGÚ‰ƒksmsþrùÓmM=l$Ù;UÏb<559’Ä®¿gÔXI߉„? +¨õ×´h3>CÔ§óo`ôeªûÊÆ›ueí³†hèÐ/÷K‹0»/k¥Š×#T´³aHþêyÁíþ}ÃÃÐüé:öæu~~¿#«ˆ]Ÿ>?Ý}þ„­}#wçSº£ñö#ˆdþMÙ†¥óÔP:“°2ur£Ìã»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ôùc ¦ô*)`‚Òx3rµÝŠ%I ö×fVjór"ásR…^7ÔÅsó/š÷Ñb.‰å£†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$ø® +еœòhfpŸ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ÄÜip ~f×S^ÌÕôî— 4@“íñö ”wU̇JG0¹ZÆžŠC/ÕíÐ’È›ŽŒÁv(€&c÷ï/êÁsÎr¦áaO[K,\­¼ÓÀßF–L +ƪó-²aÄN H’‹ÞBÛÔpcÑÉùL&”íÌ3øÛ V1΋sÅ©$œO°Xòœ€gŽÙÉF LðϦÝ=ì¿Â7±lƒƒ9ƒ"Lè'ìqÐðãn•óW¿(eö”³!üšžsðŠˆÁ¸ â4A4¦Æ ^sÉšœ¤S0ïmé½¼Ði@]ùƒ M±]ÀYJ/@$CϼÓôÄQ¡¤^þPdaDM(>nJ¦–Ö)y½|>/Ù6põšžèÑÐYÜ F„j¨ô}MﹶFtœêéÆ»²òÞEe}•ç4 +Ð(´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ÞÅ2pç™;˜FÏš—¢á^fDºä:öì9ÆŸrªGħe•ü„¬2 îYVA%²,Õ磅!·FÔê ·út|¾ŠeœÆZ{[ΊØ(yáÄ¿¨\§­°OÇgÌ­$ƒ˜ª±g¸•j»$»p†ŸàÖ+\VŸŒÏ˜Y6ÖØ ß$RH-Ó~àüçyvÎ{ä|*¦íKéÿXHfpr9¬¿ ¦WÏ?ªëcª8 +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.˜VýÐÔ«Â †¿þð´KA¼ýþÇ›»kˆZº–R‚ôØiƉ°*>È‹ª‚ê8˜¯Ô!WéÍG•3&’k½£ÂÕ)¸\i.·‡uF¸Ë ·hgËèqµ+Že«D¢À Ÿ]»ÃY| Û8IÜß 5/¨fæöÄ¢Mcañ2Ѥ0ÌŒÈÖ* Ç4®Ë{Œ’8>6B&¯­­…Y¾k¼Á\bK{59Ç$7ÍÛ¶XoÚ~UÉÑŠ\SJRát6Ô ¢û œÕ;Ì£¡µØ [ór^ý…á%ÕâÂ63êªi·×nº›±Öga„2˜wm8[ÞæÜÔéjÇØÿXpïg@æ¦.ÄXe˜Å8ð…Ï]é·)çÔN Þ0g§˜ó;üžï‹8j/RÙž4å”HUvÁö±NL‡EY¬wÍ2ÂâjÕUÔ,wí¼~®ŽìÎe—%æ<)Ö-ú þçO1ÿðrGãàÖ„ +ùºªŠïÅÇÒ÷«œï‡5¬(Ÿ¸Ÿ¡§?ܾ¿¿¹ûö ½ñ&éå þºæêvˆä5Ò •:5Ôô¼zác“ ­‡}ŒmÙÍ«:¨ÃÒ>Ceg®gEr褡öꨯ뾎ª˜F« >¹uFÅ–/Äå°‹Õ<š­Jì\)–Ò"ÑàAÏÐaP0Ø,L‰„@u@·ÚÒ¤sÌ?ç ¶2„ÁQèˇãoE±aŸ+¹Í+§½=x¤…ïLâ§Oøˆ›æC²wE&§Û3rìùŒÛà„‰XAÊ;ì‹”í’]ý‡) ü…¨ŽÎÿÓÒ6‰;}Áÿö±ÎH;`!¥þÂüGåGª[GxEäPèà/™^ £Ã:&Ä&vk3w@I¬Ì>>˜Æô>‡‰g°iœuGX¤•ä[S†Ü8åZÃ|7ß!É¢5èF‚C$¼.éä6p‚Jlé%§G»Í«”ΆŽÔUÍÝUiRtp‹(1”ÕGÑ‘Fp[Íè8@ýð+ þ“b¼ r=0Xqd¤ÆïŽÞ fôÂä…rzZ‰P@B=€¡4Çšð¶©!Ñ›âÙocáïK½ AjÐãp‘ƒ›T|×b×>Öû²ÁÑþ±QË{ ý´]3Ú1O µNº~ïf‹—T +RÜ‘î„Mý.îŸ}\ÖuÉN›^é´å$oxeU®óU´ådãØÑ¢q$-Ÿ[¿C:&`x´€˜4Pp»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¼XpK5Ïe1 \[Å"+¡¸¬f¹ Ë›}ÙÛ2_eUºÉ›ñ®yÌ:¡}Ô:¨ +dÇ‘4ÒI¸{*`}¢—õ¶-êŠÚϩ댗û&_SWᇼ@ËH[ÓkZ–õ³oÒc]oRš/qƒÔàŸÒ¯¾'° ßÞ¼ùp…¬¾Ç‘ÆÂy”h-Å»Kn—yV»çè”R:ê¤˯E]¦´ì®èÙ>åÔxwó‰›6­Ö©ÇÒ©¿5M"Aðiùœ¾ø5švWdmùB yõ@$dy3Z„vàš»K»Ü—t´p\~#Äúûº}"©wL‚ç&mÚ|Gíß8ѽ­ÔX¿#‹Œ^öÛuÚæ@ýX[¼HÆ6Ž¸9"ÝÜö¡ŽËm…”Wu[<¼LÄ•‹Èp-O¯ÛAÍ,<Wn¢8‰ãáÊ׸êë÷ÚöAY$´I?‚¼·Gè4‡Yó;ÓŒŽ ŒÒ:HA¡¿‚k¼”€DÜ|¼»~ÿomÒGwØ0B¢ã14yÕRëù)¯<uü§®<­#M¾ûŠ§ŒE@·oŸê]Ñ‚ì‚V8á— Z9~”¹•dr™=¥ƒs (óÉiX0Zœ%‹Ø¨HéŒ& îÔ¸íŸK€_õ'ÌœË/Òõ)ϼÖm`£ÇÔ 6Ç&v@ÍD6:¨34L±!  Å*¶`Ñr"£w`Lô †üA ­·OÝžNC/e +¹&ˆÂﮃģýÁ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ÕØ…í}ST3ŒJD6QžÓŒRà…t¡ibG  Žb#µ‡¬êdá|FŒ r{ !Ócâ(AÛ;<ÖŽMšL^ÔyµÞqÝÍJh@,¸ê(<²eÉŒñlÀ¾!*ؤ/Ô@žQë>§g³Í³ƒZøPæ…•Ç:àü"Î@Ïø ipó¢…6ßÀ–qJŠn…ç§"{¢f–6žž¢¥g ²²¥mNQ³1ù€×´u”4›gWl@_Æ$¢ñòº¥ÉÏõ¾\SÓ ´µŽusž¡‘ܽЫ“sn÷»ÊOyÀ3ðÃ+bwˆ¸ð£…_0K}ÐcM A^Ó!wÂEDv›íÒæéh£,IN‡1}¨ãaLå"É<ÛïÜÈØw +ˆ=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³Ž ’lcL0ùžëØogKÿŠ~™¼“Özd1³²ç›õòÁÍ©7ôöèÉ…—x )S:D'ht'p„?44'K³§üoÞܵ¢Ý'Ð/_åϧ»Ï==šp¯ <å‰Þï"û¤ip ‘6¾Ç.¹Å~Ú9õ}Ù_òe¾+0+„ãƒlÐÓZéœ(6š–ä±dpFÔë’~|V44\0°Æ,’ès!f­œ¬J¬%ä;—†£HHyöà&gÔ õùmȳ\®»^{Q÷ƒe]Þo݆8ƒLÃG .˜sï»XÜâCÞfO«Çr?çä•òžÞƒÃ>ꄶʞvB}¨ãN¨ƒr:òA:cWíË6Ÿ¤M\éHÆÂœ^¾ƒšY ß`z¥­ÿ)(‡dÆ{xתgŒH¬"3}:ц\B\Cvº° ¬’“pvÙ -èžX®©E9•™)ø0 ë@ôsu”bãó Î é¸ae’™ÌåªÊ) ÷•´çAøÈàjÖ3¸š1¸:‰ Oø÷åÙƒXòÆx¡NYOÙSZWŵóeOP?!6‹Oà¢y pù&ÍÐ#T«@ä…IdÍ øé‹{„äD@ø!ŸñܾéqCǘ:¸2Ž–â~¼\Å|yÿby5-5Ä à·Ô +|¸øâ˼JIP½¶Ûì ®ãõõF,ÞÕ°¥EWóªÚí˪ÁñÂ- +bAJAå©ç´Œ]¾\ +^^ŠÍ¶t¡9ÙyKõ>xúZ*´’Éá+pرŒå¢ÇÞ?w`ÒbEÉÅêPôþsâaW„ƒÄ€çæ„q„å9®Ó¶±ƒBv‚ÅXëÕ¶®Ë‰Hhe²è£ZÆ5]Ô©wš—3 ²9XÞ×ÆAû|‡´úÌÛ9¿LS:îR|æö$Ô–©]Ösé5„íм~çûzN ²æ¨ÏV‚&gê¿}¨ãçÒA…œy… gD6½·Àʳâ4Ô C¯zhat@‘ô)æB~GŒkúéS²ÝKut—ê¨eV—%A¶íb¼å oPªî&„ȧ†p`µo_•Ô šP´<.Ä›HÂuKÈTœÇ…6TsX"ðõÈ”qጕ/8CÏ}Ú¾Žyÿâ‹›¸êÃË|ìŽ&MAÑ+ŒôÙ!˜ucô[Ƀ§ë×Ig +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~ßÀêObpº äØ'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:CÄW/8šdõ"’ÂÌØ~/W:øsMðN¸¢"9 ÌÁÆcÆr’%è \'M 7à§MM긩é æ$xhƒ!‘Rž^½ƒšY~`["m¬ß~{ȯ›lWôt¥~˜ÑCH‘éÿG§ºbA“ 6zJÊü™-Oñ~¯îÅóþYÍÞ™Û$R1ÎK•È3Ògv暤ƒ¢*®»48"6âÜGïŒtx¨™å‡Ò!#®øpù¿F8Æ› ‡¦Ž +ÃI ÷yJ8ü™Oñ~·p`$øiÆc̹ú^ÙàŽýñÙPHi»ËÓv•Qê‘6«f›fÓOQ@õ,Ö¯ú L…$@ÍÐ1üŽMD6†ì`@ˆÏÕ?xXhÓwlÐðW’Êk=>‡–¥‡ ¾á¹I?ç¾Ç œb‡´;ýPK¯YºÛ食1¸ÌwÌú~B‘Äñ~IBà%ë®Äg$XE‰íîÌç¤NÞèïâ:˜!yºžÒ]š­ü ˆ3£ïOZÿ%CH7 d5ô‘t=»›º’pC)½Òùº¦«—ÂH›Þû[·d{¸ý²áˉxùfE‰Ÿ7ùÉe®ýˆ¡‹ è¤Ô[‡ßp¸ò¤Ðã—›ë_=¹/mæ®LüU•‚äÝW ðö˜Wx1A²àvèNýó掞nkð|÷ñ56î…®ÝìòÚƒŠ—É+zúOúTG%´Ž?G”Øsç/GƒûÿˆY#z綳ûyí· ‘a ð0]ªx–ŠÝÜNP +Õ_»'¶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Ç—ý:\;âúãñ‰üéÆ&ÞЇ h—õ:ÀÀX=&02²oÒCó eD3PMtð1CrZûbœ7³}t€mA£d«·íä'ÐWŠ!è®»½KO(°ƒÔ¤‡tÙKb•^¦Ìì »å*’ÎÕBêFåmY¸™`Uõ´™Õ -¿nÜž í½³`*TûÞ£jg“¾=Ås–A½R?Ô =}³Ú§l +¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\Ê GTœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ*êèJE¢]8hÍò¤p0R±ˆ$Á(+Á nÖN¬ +qª„Ñ«ò^ÿï>‹«>÷— .13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7ÙaÆ´Ëdô 6(WðÚºK +г2"ïE9~  +n*Œ1½÷¨¾x¥Æˆpîâ‹&XîÃœ§³±è\íD¤ßä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎr)`˜¢Xh¡Ò& „hb—H°Œe"Ãêʱ„£~Ï“a³tŒºìZDß!#Z¶ÚÂk! e'jÝ=§ _tsÙ¬ûÍ&­Nå@‚i¬ˆ3t%kÐE„\H–YZxÿ/U¥Ç™åë—Φ@±¯iW H +þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5©/¨vp÷o`kA“ôr ±ñœÓ4N.4Žæ&F°ÑTÆG%V½ Î'ÌØR5¬BÔ‹`qUžv-UÍ=ëÆåQv2ë_ ”¿­qq‚~èr¯Ú5ÌJ¼ð˜°h»P¡õ‹kÜàéÚýªå>Ò¸D °o»Îi¸CrT]¿MJ¥ ÆÖ¹’°;¿ö‹ûóZ¼¬ å[Ç-œÁ¤ŸBx¿ýpü|üÈÂendstream +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ÄŸGÇcg'µ3™µ=µ[•ä@KÅ5E*"ióõÛ/€¤D;µû@ Ñ~Cê<„u'A’ëü<Í£ U|¾Ú…ç0öÓ™œ¥CZŽ±~¼?ûá&Ñçy':9¿ßŒÖÊ‚0ËÔùýú×EèàVW¿|¾ùøÓ×ÛË‹4ZÜüåóÅRÇáâæã?¯¹õÓíå§O—·K•ÅjqõË/÷×·<”È?~üü!9ÞXôöúæúöúóÕõÅï÷?Ÿ]ßû³ŒÏ«Bƒùãì×ßÃó5ûç³00yŸ¿@' TžëóÝY› ŽŒqêìîì_~ÁÑ(Mã_gA¬£ä|i¢ ƒý繬‚T)@JãµÜÚðÔŒÜ>ý‡¿"×ÄÙ¸}¶MÛ‰]OÇFÛ˜ ÍòT¬ö¦i¡(XºŸZù üvŽžñ…l[Ü…xûžÒ‚„÷O À"€â¤hza¿iÍÐy¦œÂC'a¸P!wEYyÒkÛÍ®Œ‚5q´ã.D¿^ÔÍaWT±:t‡  ™i0=•Ñ‹\Ê>_¸¸„?övØ:f½— +q39€p":”ô”;ó‡ƒÅÂá^DUÄò ß#ù™Tø¾ØªB>@‚⇠§ºy©fŸÉâÑì‡b´Cœ”ž¥¾kÀc›ð/jÀ#¤·KÀ‰‹nµ]îŠýÞ®—˜Ò œ(iP5›,~—tJÅÄs§i` œñq3WVĪbònY¢€ÜèQÂi2J+È©rlâtññËs$‡ä$<4Iã ºgÌÁBá¡Ñ‰cÈW³,ŸŠ]U¶hB…fŽ¥-žÁnh²- Gu(R `Á#2°Â–D‹ë,‹Çä41›=,,iØe0ê®Ü9r@g6}5gëHDSÚ;YZÜ„D ÿ,ëþ7ÛWÐý]KŤ„ /Íá‰[¬1œáSŸ?OöPÛŠÛ¨8‚-^Z¤Ì­' âÖýÕnêšË(³¥gXg³ðu™ìq7º‘œH‹-RRÐ «•Ýs z¬¦Jâ%ÒƒóÚfõD9@]m5Æ;eQ£IÃUYâPÌçäÉ]ÎÂÉG’’,µÜĸî±&q†§`Iê$Zä]p¨(+.÷9-ˆ®Ìô=ûÏTr7h°N!d/â3ÞˆGgOûþ°oÜ:ÇU\å’éUÓ aX¿ièt&†Æ»–nŒõ¶©óX¸yù½;ûÂu¹ÁÈ€ëjòb„)›wÉñX3ôLìTœâ S2%Hže ³øÌÛwÜä×ȽgEfYD&PtŠŸÚ¾p£1¾¨ˆ‹Ö#¤] +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ÔtEÖê39;ÀS‰ü#¿YI .r5¸(&6~×2ð¿ £\~‚Ž»l‹Ibg¤‡"|€¬­,±*dƒYŸ.gWv£€l.|×´ü”k‹ìƒ"ÑòÄ¢ç\¡ýH$¦°±HÌf?bTˆ²è^±wºª4=´Vº dŒéš[þ¡"€ô®_!‰)WèŒûB…[‹íVX³@”–s\x)×”ÿ…fÁñ„3Ðð/#&”WðÐ +ˆF]}ù*+ÔÙÙ]Cy´ÁǶýι€Ó}"g[¸6%9=ö!½6¡à{…T)V‘ßÒ:t†¤uØðZ‡®h.@i½Z*”Áí+Ûq>›AO ørL=VÆzØwªÆ´'¥á$.'zz̼:"™›™ûâø"—r>>†þi9aëÄI"Ž¸$IhÈᡬ9¸&+ +"þ,Bp¤Ž—;ÞïÙÞ¶IÒæ1ýnC¥'óLµuÉŽ·»}s(¥+¡r­ÈþqÉÅknö"2kƒ•dŠ'ªÂœ¥*wotºùT1â ‹žì~]K} üÒ‡Ïww×Wî·"{°HP…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Õƒ_GgY§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ç»|Ù¡ ¼-®Õœ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ܦ„ÿwCsÎùÃÔÝÃ<üzCŠÁ àô6Éܺ;⇠ØÅ+ü%âSæ!ž{¼Ÿ¤4娘æ±2¦ÞÜRn `( –õªÄeå‘óŽ':‚¸Ì¾sú¤_‹]ËÛWMó}ÿÂÖËéÓÑŸ\楨Ç¢{+9‹»½[Ü|þ|/nî¿]gšô +Áßâ)ÐíÝ#úœ)C£™„t·H¥¡<kÈ;À,•”,øcO­8$÷½ +ÞÓÚ-ê…SAK¦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ó£«ȶÈk¸ýõ¾¢™rMpRFôü Àª²í†’ Ø¾tAË paà¯yµç.à£dPªâY}η.w@a2 KÓ€õòTdÕ…d+S!«G¦G9 SŒNlOm&(¥6ôËu|oBCW̺íc_ã±ÝZòÚ)pýx=°$[wW„ãZt4 Ô‚C¨*‚r#Fäp–ì&i¬fÁ*Šjy„²¡§2¸ õL¢ƒ´ÎLÖ(‰m¿Ÿ‚\b…J ˜™y螺8)@ͼ{;òNɶÕÂ&@zàƒ†7rÞ¶%dk™Nß1îÖëöX=óFm[8öûàò.’öH¤‡Í7Ð{ƒÞ§ýdŒB÷6«ÁÂn¿ _­¸ÐoNC(®÷ß +qDêBƒ^\@ 1–«Xx,©Øü”ÉüŒœŽ0/«™îšòJî°‘=›¡ª÷ˆ‡ôÊ'Tñ°À‡0­#Šû8à¬^S"䦚åµÙsfBÐÆãÓÏ å¶ ß„qäm‰Y6œ*j$5í ›ªyrÍžðGþ¸åUÍd½…[ÅÆeC»rµr¶[ŠhÏéÇ5Yœ¸aÎeÆ„ ™ö‹þ k³'8‰Û¢#ÈK¾ëÊå“>÷}¬6Ëé ÷-ó²*]æ¶æÌ¿îoh€("ð‚N&0yš ‘ÕæÒO¶M ùDï,œMø¼¤ª>øô¥º‰S|Ð3ÈÕ„ÂþØ0Mî63Ü÷l>à/ú Nþt_gôBºpNo*Zh3fb"Ê,0tú0á±Þaãt·Ð×<ÌD¢”ñEé=†‹žÏû¼Z´]¾ä&ÐgÖ* "Ù_ˆ=DG0Rø6£/IñÃgø‘ëpt¨è`•»D ì'›]:”Nݪãþ;æîè Òv §ªØ2Wõ‡f*ä›ù“¯Ì`³Õ¾8öR'ì¾ +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’¼äWC£Pâ%uñ÷©ñ³tmnw§PŠ¹·¤E¤l:Êw¾¡2 {O Ö¼u©ºuE8$XÇ^~Qbn½!ø A!ÛàvO™<=ƹÝ@›yACoÕk1ØÉøÜ‘¡€¾¶°ç´<3‚„Ú@Y +ÁÂ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`Ú||„úÆ”ôÀìOö_î¨}®1¹£¡"Yú’ .“¶ƒLš&œƒ>br((¨„s©²òÖvÅVP_õá4u°©lÆ=r¦üö~!uø‹þ‚‰˜}²ï0uÖ@šBù‰ ¤©NüœxÞ€õÞý+£Dš$Úgpá"‡'ÏÖ +ÿÎàêk‚üðÙ,&NGô‡ V¡á¦µ‹ =>ÜñL•ƒðËGpk!” ‰fl!†{­d3ÀÅ·Iš…”§Þx†¨~r´ È€E¤õèýÚE›ÔwAa@[âˆ^vÛ)'“¹×Mÿ„4ºÓ÷&£Lž‹ßhwnÃè‰éõšpYó6ñ^i´ÖƽgÚ©> Ä( AÄÏ%ëaé@o‡Ë¼åÖ‡™`æ=|³è8¡"ѧ%$)“lB”Ä™?~¨B] +rYp dÇɘuðkqQ¿6)}^DñFƒÞbÂG~èÙÛ Qh~¿5°,sÇW‰™‰õ0‚Ž:L—^}…þ¼¦9F ü˜4ßí±ÀœzÍæ@<ÿÐútÚýñØŠ8÷ggñoÅ&Üüã{ýŸÿ$íø÷zP8ƒé3µ¥ŒE +™Š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±ðªÇÎ\ÙYj5³Bg×±‹uÙ#ÖIéöÅâ°o@¬g)À=¥¯3±F8è¤t×ú©Ò¨2ƒðdJw f¼Äá¹Í?!ªßÓ ÎÀ}±ÆC8|Z#½v]ÒTSìA)‡7.“ &œBx½q+ʾ ´ÄjÒc:Zb,j‰!'blÔÀ2ml‡ixé(`£âÀ0)ÎLfrú¾néËvӊ˲ñ‹”Õ'è¯ã¶”ôM ®*µœ®À»y LJ[¡ep¼­8`‡´ŸÀÈpÀ ¡ÿÙiî ?ha½'Ï 'œ·yø<§¯JZ*ßàùòHÕ`%:@ˆ Ó¿7ýíáQ-òź¸liÑãªã3òµôÌÀ¢Èà–%ø¦=™07ÓÇ0ÓqØ^¥|ÈжÓD +9C 6ÿ¹¥‰ Uñ5‚ÿ‹Í’A¾y…äƒLCEî–cíÒ >QB8»ÂTb†²&c– ݷΰ}´ge¦Ï¥wÊ¢`dWìÒ¶X’ {¼ÍÄ´Fœ¢Êç‹KÜ,P~…ÈÞ«­ŽcrÊ8ãZôs—Qå†} îÀc’hóê$ûõ‹¢u™5¤Û‘-t2™>囃÷E× {AÖÕë\‚)aÿØW&„íÂ1Ðd*Ó'ÛÙÞU ORú¤¤-šÈóˆ/‹úP6£g­—‡)‡ä éòô®P[pé¯Ü¡ƒ‘•ÕÂm,t ºÙAþTÎËMÙÁ;y‡5óÅ¢h„ði‹Llp¬YׇÍa"Ü"•ç²]V&›Äcˆ%V1×"ô‘€äý&G~ +]“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†©Ä¼Pw±.ç ëäJŸÒYs¬@w S½A +%Â\ç!b0ÑKTʬU}&16šÊ-„Ÿ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•}=ÒKXܺâ Þ<],œ³Yªú¶‹ÍNÎù””ê§ËÝE—?gycÀ¥Â±«sÂ> +Ë)ÚšÖ{¼¤¡ç%‘sP& 5QuÙèÝýF¨ñÎÍ” …€oœ:¤LÛLÄûï· .PaÝ»Bi•C<²ÄW(íUªC‚ã çSâG¾PÁ »zï!RÑž‰PÏð¨&9ú›ç0zêÝÁKçX|1tÄá9UG}_ +‡°_|Ì)(ÿ¸ó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è +Žçú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Éœ^•À›g7Š†æ·.•*>Ùå{×òÇb*͘|paÒÔ‹ÏÞÑJº“—îr» ÖÛBÑšñµïá%i©4Ô…ˆ,JK‚BbŠˆ­hÁ5‘«w0Šæ¯ÍĵEx¢¢Ÿ+üúÃ=avÞ{Ž\šPÈËÂ&l2ý%ÑI´¯Þ19 Ï{¶ˆ·¨+wØà(þÞ)™>¼}ƒRe²{sZ X†û$Àž+ØIŽ?‰ áªCƒŸblÌBdîò ®n¹ kšK?Ž“š©ñ{øOý§8wúU¡2Lº{ÀÑf„0–) Dˆ)w *=o½€iÊTŒ°þ?1øEýendstream +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ˆAXL8ü‰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[kÖñ&Ì)™zÞs8¹QY4;‰¨^e“mwÅ|_f[ú•'ŽžÝò†&çYEƒ¬ljâºÉ‰Òlòyñ;ç2_ÀI•LÀj4s¿*æ«v}“Ó2H¿.ߢ:íòª +¶[µ| i700…HSÏ?åǦÈ3ÜG=ÕˆÐ;Ù3¢Ð¿·™ÿ.J˜ :Z ¿÷«4’é‚`°È›‚VÁä&Ü%nMÒÎß<I ǽ±wûrW€Óá¸y'4g0r°Éjq]ÅpsÄÜ cY":æz³+ê*hç¯ÓëÔÙ7ùcDtvü3CßF¢MÒ»„)­ÒVñäTŸØrý›>Yõð’Fÿy9æϧ )¸p$¤Òa“œ‹‹›ôÅ‹çJ¾ßáÈ°Ÿt,Mç÷»/ÊËM”WÙM‰ÉuðL V>üÔù(P½[TCŠQDñž‡Ђ!–`î8–`òwnø}±["6EuÛ*ê-æÁ#ì÷sX(0Ä€žU‹N«ƒ’ŽÂ™`>á´÷h¤n8:Ò ™Yp²”ªn }½™pfC‹1¾þ¤©ÁÍépX\ÒŲŸ£S…}¼‘Já‹£u¶›¯ ‚F¿íh–±8šMŒjòåuö)?ŽÀp·8ö‡Äyb€€ðõ·0Ö>†#@#q¿2@ªºÊ¿Æé`—ËV눒¥ðþßqcpÔ~PßhI6rxö™ÜMàa DГaº1“ý¼Ï·Að9ˆC 7¡fN ÝÙPµÇQ½ã(H–uÞT?ìhâSUßñfUsO¼@¬iMFÿ~Þç šã4  Bâ*‹KjzY §ÓcÔà0%M{_^RÜÔûí<9pܱ áp£GÖ†SÙÐ ä¾D#ЃA³÷ôm3îû 8QêÔÀ÷1CV}cäéµÌÈŽ?{ÔÏ aå[ÑŒHïšD–¿éÆÀ€jh%l!Ç×ÅnG¹–VÞ20yôdH„ybÞª$DÓÊ&§6ìzyuþúõI  à ×`”Y.õ×T¸ˆ\£5@ÜIŒû")Á˜?IY* hêØ|r{õëˆù­ÓI8‰Z#•d”Ê&c (¢(*ÎÓ&C\»‚2̘´ÅX#J¨’¤|ÊÓÜÊ'üà™Û¾Héšá{ðxâѸ…˜­×4ÞW›mqW”ù­ÏBJÀ†‘Ï‘»AY#ï‰VLÝ9þ]],â;ï›åÅ@êX"uk „‘sLh— ĆKœNìáR·îì“[Z0·á­1GóÛð~…Œ d/wd€àÀ³ôsÞŽ‘Ë|¾ƒü,äÎùv—A¾W'$γCu°Ì ‡Ohm$‹n•¤-X§äö6! áP,X¢•>øΤuáÞD뛓=œ.2Ì%‰é¯¡ TRâ;÷4®žê ;™õä¤71T/q#«¼~¶¿èåc •f¬ýºÎ„TrF£<&©bV+÷¸,ZÇAV¶+Ž®ëÉ.YöñMu6A0à‹¥À%eJQžsÕstcµ¯‡ Žþn@@¦[]Djš)¡™7ƒ'ŸÁ”®UOoìOz°€'<¿\ËÉëÎ3é©•÷û&ö\&Œ'óJ)àRTzù Ñá]òo’–jX¨ã,Æ~19ñ6€‡©'ZiÈ +]?ÂT0"ÏœJ Ò°¬¯¼p•ú(ÝõÛ=&²œ*î!ÿ¹©±€ÁÑ/¯?g5¸V.Xj´ÆÉìÕlàèV7x¾!‚oÙè•Üûþ‘i;C¾´é€QDÏ6›Ò'N8×v§ !XtAÂñˆGV=¢I.ï‘1ÃC>„ Bs\JâÃ’¤Ø'Á¼—ø’yxa€Ü€¤²PkÒƒo - bã ~‰Äo|ÀW¨«Åw‘€d­ø_NÚ®x DÄž1É—@Dê“.ó=QDrŽn¾?Œô%?#šr‚‘yNçû‘§¡á)@¥óí -j–èÁ¹G‡§a2R¥­=Î^†ä˜JÛäjÞbù%ìWáð‚ÑŠÇ££Áßæ3ß?:†n(LêÆsõ–MË8°õkö$Ôìÿª«-ͦBˆÈßÔ½_®Üé,}›ë|¾Êª¢Y‡ÿ}ëÖ2›ç¡ÊÅ2Ý&Ñ2›S•Åη¡ô—WÅ3uZ ëß&ßÑ , é³u5¨Ÿ}]ï«Àè›ì¸ Î´‹ï¬õò{ú„’TîwMNzÆÃlsY—e}ߥ§ƒ>/¾ ü÷¯ÎðÝÎ'Þ˜rÆ ÀäñR 5þËVà‰{L»BËä# +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› À¼Â=e_ÔÊã2\ lšz^Õ‡rõÌ´ýY­.…ɈvS6QªgeƒÿjöX~)*îâÿ|bÉL‰,ISžæßuUL¬¥Aª>µLÔòC±-ªÃœÖÎÊ­øTn6´Pý¥ØïËeAO‡u1¹WpJñ†–Ëýr³¢i +^9(Ü÷h7õ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‚ÜÕ6UfÈÇ]õP«%ˆÝ%lØŠ¬5øhfû7;VUY=Òð¦®o"]ƒ³ãVÙPk›WÏô涬Ž‡‚» IØzˆëûm9'PexUÙSØÞòU¨PZ2Ðâ’ ššëú¸oHÛÃé@åö¸¥‡/ùæX gÖŽ—ÍŸ{³&ÒŒV¼ˆ¤4Õ"‰\FRŸê<’ZªI$•ËÍ$’’L8%íeNZª V†h‚Q¯Ü—MªE“¢I!:~%$A-ÿw÷ú1ú:êEO& d©YÊ¢ÐoÔŒÁÏ .ÅàR#p)ˆqº ê‚+=‡-Õaëÿ- ™Jê_@VGtXLtÞCÕÇé‹J…R^]ä£%:ed«ô$¤=N> +ÌC8~C«+|ì;)|Þ<ØOê২³(BShµŠí¥:ŠB¾Ò‡’‡lPú?©Ÿ²Y†íÓËhêS‡SKuÞOMâ òäÄ¿ÀJK5ÁËÐQ9aŒ1ÓAÊÈ)#åÀSIÕy*hOÿž +^ žJFlÑ»ÁSIÂÖ bˆGØSI‚Wx‹EÂKÁ£ªd0˜äÏá­¬±¨ýÀzT©Bž^ìË|3ÿíXìŸç{Ö ° Êó2L3±þT&Þ@.5`à‡Mþ%f4òò…“iÝ tï€ÅzY.òÍæ™Æ·4¸Í›CpVÐÝ{_ã#ücö¼  Ý„ÎrEìií2ç«ãöç ¸²È+„ìA \ÏÎÏà ÂÎnóÅšú›clEf¡y¤Ó´rú#Õs×l ùs`(+꣤§Û´+Ò.oæY2ûŠg«ŠÃS½ÿ•òjùT.k:üÉ¡EÜßx8‹%„úM¹ çTÈh!èk¹€vàSƒ8#ÑÂ.–xÌÕ*)€Æ÷¦lFsXÑì¼ÜÓºÛ^ð„(¡2HIÈEÐCΰpŒrlo@M&6±µÀ®–&Q?‚+x>Ýžïé(Ž»VjB¢Ä¡ÀH šà‘`óÁ¡DÒ9qE‘ÙnïRÅ3  ˜]‹ºZ +:»ÞÓÎ`ÛÒ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ãã±!r­gB™DòÇ|`–dn$3îÄx)Re_(ûô©Î»“–*H§Ÿ¯êý6?Mµ…¹ÌDK5ÁÅ0SÑ,I‡lü+$ ÊÛ~‹ ØxàqÒ¶X)ᥧšKÈ>`'¼¡–”6Ö¼™Š]&Î'1zs`à &˜(H& dÛÖËÁb¦ìB8é5Ó`ÎÍóM……PÓW”!ÙÁé(·˜†Ù2tF—cÜ)aSwâc­ã°–…$„zâÛëRB ‹ÉR ¨éY„ƒiÅädœšù¡…øt¹lÄT\¡R\O',éêv(›³ú‚¤Xãõ MC¢ ÛB +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›tê «'ñÜ¡K̵9:n¦ézœø‰)²:Ðâa±.øçå(ÜÇjD J´ Jþº-㙶z&„ädB8LLÙ7!$=cBüÝ‚PY:Š”†Fïžh +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ÈŸ—!ÿ„¿ø…‘ØÙÖ¡ÏU¾å‡tðСlìy˾*ßÊŸ•†Ì ¬#ºo=峅ϲ´Œ|UTiù“¨0„Å8‡J È9×a«!:°1ããÊGˆŠ+¦F鉘¡¨ZŠƒ1f(ÕÅ qÌÀúëè(:`Å)¥GÑ¡·¤âè€D!µësÓW"+=%žÊp”¿Vˆb­O!Öiþîà QÇÜ:Q>IDñUND±É—ÄDÔ­”'Õ›ö«ÎœNN°þê#ån½'á"o+ZíL®kà|•%£3òÿ,ÕUÊH¤_¸ŽíS]ð‘‘êä<çÖÅé}™†ó ÝE&Zª¸PÚ#$^ÅÅL ´ÌŬ±-z„ë1ÙV=L—ÕÿnŽÉøŽ}&þ³ËjºbòéKB­ûwŸ¨V\ ú|‘²8±Ü¸Q «âÄâ̪8P5Æ‘…óè°tÁšÖý[O§æ~hàdl˜ :1stC™ ÞíW$à™7Ëôôfê¸Kçh›rÍŠ¯,mçÎf?~ó‰z°ðfXÌÊâ~-}S^uM½2qÚ­ /?QÍxç[>ƒÇ*4~Ü-Ár”‡†M­ˆ$~Ÿ(ÇÆH ®„iƒSCOAa:8ü£Ü™Ú üÇÍ&0}1˜A3B›/h›# K“à k¬¹1Ä¥Ö|‚îåF…rŒ6á:n¿ÊüÎÏZ'‹MÝ̇»#àM8âáw¨H‡m^;^Špg5ÞBwªÍ%$ÚãœùnWä{ê Ÿ8hçE€¹¿j&Ë‹©°*õíW¨›ú©ûd¢2’‰DêqÉW@Lù6ÜXtOx(Ùæ£ÿõwãÝGõI& G8óy€Î ktXÂ'¦p‰;uñüù)ëÿÉ%#endstream +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É9ƒ¶2«‹ÜH!½7œHÊé·ö’O›Ð¹«êæ›bºY—Mw_­×—ÜM«ù5Óúž[zBL뎺U5«ÿ`LTs¥d ¾Ç~nSnªeÕlè‘®Ú„ d$ ü/\2‘¡ážÑÀ²‘uív=‹Ï ÏhY.á™ûvM”‹íù îÞàƒ“LZ‘;:–qžZ ÿÌÝØ“\Ogeƒ  ö ¤PÏçUúa¾¤î*ðöTW»@°&‚8óÍK gîÊ…â›ÏDT7³ÅvîÅŽÃeJ ®WüS‰ðœ £Â3û+ €Âj励võæ±nHÑÓW£ln5‹bö'>ÞY(¸>¹a¯»:£#s^>Éu˜-L º[´³/ÄÛGߘµ ªÞÃv]nê6ÌâÈ¢ÊL•åLŠX¦rÅAe’Ј²!YVš"Õ‰ëÉžÌ!ܘÜñ=U‚‘‘‰Ãm[%8¹òéÊeh•]â6´É¹(ø?R/csç” Ï¼¡Õ«¯³jµ¡6)½¿¦°`X D¡˜벚SwÛþ@óúÓ“9yyÆJÀY¦Ï_ÞêôåõTxr±ÉN`|{p|íÎó‰|ŒïàHrÌÈ[k‘¡jÝ€ñb×ì/ÇO"sÈ嬢>¢3þzÃ@rYÔÝ…ì©š„nsc¬û§cd|侬]`º™§À`½PÑè·]•¡´ s…Ôc@z5öKÛƒIÔ ¼Ì‘úDOh„Ë•,Š×øié|ØáÒ~šºÉÜÀb§×¢ç¬šñ‰ñRYä.ÓJå|u饂ة_Áô 4:<ö‡`´Qœ®¥ˆ‚ùx™>½…ÿbzu$XK +PV~Ãj¯«“¿&ÐQ覧´ýa÷Bðß_/Å䧎4ž*®œ —öçrjhŽèpP€ýZKfp-Øôùþµ[ìðé¼¥Á¦ÝÐÀ®îiˆ4†¼Ý &Lƒñà$(à¨Ô¥°ZeÐ+¢+ß…U@Iç ºÇv» g$zg§acEŽÊN +\Àîð°WjlDÅ‹„‹\hA¶\­Öí +¸†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 óÁ ^=#ç™é©ÜŒ©}SŽ#v~ëP\ WŒT +Ç÷*“{•êhº k9b™öžg0)éÂ’}¤ フf7”ŸÂÔ¼º/·‹Mx +àëXC2° ùÔXš6qé¬qu©…ó­Á=…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‹>ÚO­VU¹¦6&Û¸&EV¸Í¢|ŠÍjý„&jÕô»Tb)M™e.K€ûuJ±’%¤8¨ ƒ·VúÀìf‹rKUÀ/ÕÀæSn²he{ù·»ŒT!Á‹'lˆi/,iIKZ°Í°¤…]*iéâDÝ„K;ô¦ìuj(rQÆÕ,<›¯fA#T³2½¯[á ¯[a#ê „þ¹€]Ç1Ý°š% –õåÞJêŽkV8ñýx‚Ê\8ŠYHƒÅ,³°›*f -( xµ(´è€¡Ø}Ü +VâTÁª¹ÒœŸ/4y5c +’ß‘š½¢rõª +Øÿ»r%µÌ{©r5¤: Ï=ÕÑ]¤âK0 Š³ôT F¾Ë€£tÜyø¥þR%˹uîµ:Ð/$צ‚0·E]í]¯ÿ hàÛ1c´ÖlÆ´X™ +Kí!66pÃ!¯Âº†´„Ⱦpà&Ç Y¸ê2”¿¼?ÀÆ'ðÔúBd˜˜R +PSÉ¡ØS[ϳ'•mç« ýG +W!•–²/§ƒ_ˆï­áQ¶aYóŠe£~ûÈÊ ¯àF +Šìi ½§š +$è¦Â¡!:84hG?»y,ÃäqÌg±81 # ›òÂùz'üBÆþ ®gǺú¡! +>ÎV`6rS¼.Þ‹'ž}¨Ç“q¬¯RËýy»°©Äé Ì5å2²sïçÚ%MÌÛ6<¬Öûûž âá¹P‹1Ïš¤F3%ý삈\— 8¢‚« à†Ég\ÑødÝŸ`þ&§·>¸Þ/i{xpÌCLÛmh *Ód·=Ž3.BÜ3:-¼žÒ¾Z³«BH»£rF°WjÚÚzX›”᳤ÁÁà?‚3-7}©ûsTN|7YÅzYÿ²NZàP¥_Fd~h‹`FMo‹¢€@¬yôqkh(¥Z0Lq4îÂ* d*¼æ“ÓÏ{m‚™§r±í“/ì`ÈET„Ѿr¤N”EJéXÂ-1àИé;ÿ¶ ¬±úZ.W‹êM2ü’9×}ÊߧR)ƒÁR 4è% ìuö á6´êDV†H4•º‰\Ú"怜YiwB¥¢M|Éb´éCyX¶‡T씃SÓQñýîMàî¡~(ïž7UÒA.A4;xß¹mÂ=&˜Â×|¼¯‡Ð%€ÖÄI=x–º]å_‡´FÂÛe šöµ^n—Ô)ŸÊzQÞ-Â\¹l·Í&Å2ĵeõymÈ–SyƒÊ çô¾pÓì„FcehíÊ@V‡ê§T*×FDÊÿ=V1TÛÃème 6å:˜Û®ªƒ‡æU7[׫}¸—Ô!˜€´µ!»úÛQÂŒq“³NøÒ¹Ó¾¦–)P`§*™ýŠÙpÉãèrd¸»ß8†©X"p,}†Xst +&”avt +š\?„— 7ƒð²§Oð8R£uqÿÏÕl/x“ó£‚3 ¶àªqsâöT/ðp¼ò¥Óç˜eI­õÉ¥íCÌ ŸcÈP:ðz«ü;‡0ºw$ø¡EDshC'>IÐwXï?Ãðà ýA³a”šB>íøÜFº= ô&v°ºàÄtÞ6ß!|aµ]Q€‚ã_ [Èá×;'¤ó0çD(=¸ð[¦§›°€2|‹ö,R\yØ„Á]¹nèë +ì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ÉTD )d\‡œ÷}³þ7XKĺendstream +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¸À.ö É™€?9Óq§a:KÒ(ÐBêY¶»³gûáN2ÎÂ#-†Xß-ï¾ý‡³4Hã0ž-7ƒµL Œ‘³åú·y„Á=¬ æïùøáñ‡<½»O¢ùòñ—÷‹P‹ù‡ÇŸúáéÝÏ?¿{º_H£åüýßÞýº|x¢¡˜×øîñã÷Ô“ÒçÊ¢Ož>¾¸ÿcùãÝòãeȯ +ùóî·?Äl lÿx'•={…†dš†³Ý]¤U #¥|Oy÷éîïÝ‚ƒQ7uêü"mFñ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èëŒú˜è]ΦŽT&ˆÛ££º\°Ý Q©÷àê™Í¶ù»Ü3Ç’@¤P2et[­'Ö”&H#˜E8‡<;šâ%_°Ï1*0R«±vge‘Wm3±£ +¥MÄ«‘Ž7 +‹ +dj×ÁE$äpë$ˆô[1iˆu=&uXHÅïB„eÞœï›hH! zÜÜ×#Mì;dÛˆ 2*ïK¡B%ƒê¸[9_°Søz +]£õÓ:¯ä–p +lÀÏ¿ð0˜LEPVW 5rU ÎCJ9w*®{"úxéx•¨ ÂøKÂ;VNÛóõ„˜5F6£ºˆuM¤a™¼%ÒÖ ‘z,ç‰Z›}žÌ3’ †˜y{g4±óI) –B·¦}î¥ +Î ì¤ +_G$ãz Ëǽ|ÝbÇš¼% ¤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é¹ÅÛBL85(6Ӭ߅眠ïMD"G¬ÐàáyFÀÓ€©ÿ ®.×%®XÒHZ„Nù‚£16ß>Yô çkQ:Šq¿Ð‰˜ÿk›3)䋯ŸHaïSJ+#ëÙ;ã¬1›E±éˆ— ÙçYK9ÓÕÚ ïSì Þ1–»Ü §Õå:oZšÑlÕØÌGE+¡÷„Cƒî—­rZÁÛz^!s`âÆGÎeW¿äë¯àR@Þ¦ö¿f^á[™W)‹Œ”~ðX7 ÛcáŽÛºiÙ´E‡Ñ,Àª.l;ÍMbs›ˆk‚Š‘uG˜49&ã±¢J;9ðÚæJx{mi…oùÑ°2¤ú4<¸$9Þb!y(2êÄúPtKÖô]å´Øgˆ8®„Î?Ö-©y Z®Ïµ¼ØíË|k¹+ᤳN¯ÊT¸ýA‚~[¦C¬ë2í°Æ—¾ÁÅnì­!„™PÞ&¡Ãš aì¯ã@Å*1•WË^Lü†ËÖVy}l‹l™ ¤²®?÷Í(Ó’£¤ŒkHõå@¡a1ÒŒ|•om‰d®'‚ â3Cù Ål˜¡Ñ›+õA©RÈy¤¿,c^=að¥RDƒâ çß噥Z,N ¡Á9¸d²£Ž†aFC¥Á-Ô±*Ú!W]m³¬MÓŒŒ!UÒLä½ +]8Õ!ñ”•¤+.v‡‚ÚŸ‹²^Ú¼AsUÚÏKæ/¶<ú%6Ô5]‘sF_T,®W%’ª0U%h+wï½è^]hÜسâö:Ïè\-•Ê)>Š0†{Q¬ÎŒÝHãu¬Ý²>²G^)µ¼fíp‹”1oXû놵{,'©lÕÎD‰íÍÍ;¬‰ÝÇ÷gÄ&Ñãí—¾è:pÇñÀÇìŽãs;‡žN™^¾ÿ•;ëªÊ}h§²®mGÞdTàíkÇtUX– ¾%ù<m"ÝÛò„Ê$HánùVì“8˜ Ü”üëºä;¬ézáHø!zcH£oîßaM0â5Lƒ$4ñ˜ºôGfŒG}œí#‚¯Qø³ÈÈPuÊÙ#_€žót9NÑË$Š²=èsž|h ‰'¯¼ŠÓÈÒ†F,¾´ÃtürMK÷}IÕpÛÈnƒRÚ0–\ý}µk¬û©–b}Ÿ´Ô-Hž¾[0cËK¹d¾ù—}á+ØÞsFjÛc÷ª0‘·68= ½Õ„þ),$"ñ½‡ZŽtøV5ãá«N¾¦tWJÉB÷@ÇŒ«¾¸&{B€À¨qÑb_ò6/EþŠá “ñÞ¼ÝïKJ½Ü²{{°­{"qÄväO>Y°401tš_¾ç„ßýƒjÂ¥Rìï¬Ó¡²•F__*E}”ø>`+ªx í+P]È;û²4ö$Ëg‰ MÕšzçWb4b›üxa™ª³ZEUr½ñÕY'I§FËåOÀz¥ºê®dš@"oÞ¨! ±®»«Ëª²ð¼ZüyÌ5˜|îM +:¬ ÆY©¦êˆvXX€DB&jàZˆaßnC1=n¯?èÜ\ +€]Q±Ë£â:Ï}ÜŒZ +WŠC•—7Çý¾>¸r'³>C ÅÅs°‹ix9æëwë21l…a„~‹½Òú„4į’ÙýBV[R®’Ƕõ+;[rA˜±û LKZ¦‚ïÒ†3*È$Ýù­©¯¨¦œ’ç>„ ©Ù[W[ðÕò'6\p®€»eÂVþá•FVy7ooz‘“ì=àë3—,ü}f£ –ôvèT»H1Aä¥Ý†LLQÒÌ„3rïžëɪ;DÕTÄÉtÑ]rÑý×üPÔkw#E#uù£mø‰áËÓD7×ìÔ¤A¨ä·ÇÒu+õHôH®lQðþ—V +á® ·öï. 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€³»ò¶&_Œ•' +䲶¬¥=ÇûØéÿDʬendstream +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öÚ‘« >Ø*)‹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§>ž>‚ªÎÜrô*nr‡Oü¢Wáw/IAáÈÞÜÞñt„7~ ÞØŠàÉõðFÙoqðÆÂÅ;xCxªÏy²ßIÁoëö~ÎSýñ”&éÚæ—0vDŒEÔ¢3ƒÆ²kgLÜ?îZš‚”Æ38ß…oÓU+»µ•(“‹õ`w’P/PZ2ÑtpñQ·;{_û•¶MçüM„“Ôä°Øøôhwµ‹gR%¨+«ö™­}j|sU÷Ëƈ·"Úˆ§žúx4Ž£û\¯ˆK¡æ^Æ>^b§iº§ éÎs „°Ãë¢,3¡à'PzAÛ¹#ðN ?8DË+ŠHU»: RýÐ=P‹Vr»æ¢WKßØnŠzÕ@­MõÙ‡¿{Š¸Â\œóÓ1O : ñrÌ‹¹NǼ‘ Íî0·êeÿbÐc2ÿŠ#׌‡añâ@ëj‹‡å®=*‡ýàÈçnºû{‡hŸ +qÜhÈïDX',>Žq,—ú(È©Rú$í“ŠxlQþä3Œœ…Ï¢k:áÚFèøîÚ†¯¿¶5›\Û(`zmƒlwm#<­›»¶áË<”Û.àw¿±Sdßy-hcðÈldÃZ•˜ž}SŽþ5E9Ÿ„Cü„4g¹>-‹æ1å›aÆTT´KU‘g…„# 8ž + ‚ë,ª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î:ðƒç™ð¨P ”UO®ÄÁp=aÙÃí}Oä;ën$ÛOU&¦Ì€˜-qŽå—›®ë­QѧuG÷œÜù9Òð®~&ÒšnÙm4[ø|Ð)º&Š“7“ôS Ó !@=]Ýv #H¤7Ž¸»Œ(•g®mc½„ûü™†– 6„qÏ?ô¶YcQ¥ÆDòðšgmŒwÈáô)‡E|v¿$wÕG뵫ڙu›P뿯V”*¥JÈ| 9MÿV;Û÷sRám npç}S¤à¿/¢ÛILc‘Çðæ\dŠƒÃlåæHIŲ¼dâ*$~MI5RnøTIÏã³äÆN£uaA9–GäÐ{ÚÆð›#î±Û?Øeíª~èì“­T<¹¬`cÜÀ)m ‹hh.9 Ø&ÀEû¥ª¾¯ï[ë•ñ A<` œ`0弜ºÖuצ­½¯\컂x” !úc4’+ê‘D¼«ú0ÍåâÂåýõŽH]_SAn€JN*(YE–®(SmÁ 'ÏÜ <®Y÷sѹ°,ý *ï¢a¤A’+G-rñoº+n&R"Ó¥…‘˜û OÖ¶ÄRûU<*¢e||t/ pÐ:¹ ú~ë;XtŸ\J¬”檼è¼Å¸L”Æ!5>+…àÉŒ©bë0móû31Þ^JÚ°ïtÅSA«ÕÊ¿`yno y Âf¤™|ÚÔ¸qþ¹~ÜÑeæë—6TCÏ!—Œ`J!jy@ÖO[§ƼŸØ¾ ¯GöK…™Ë+Šº˜^É27S”Ó»!Íá>ÿË-dfðåxb:g¯Ë7s{ò7I|-Ô›98üE‚ç5ÏßPG¢$×ú/ÍIgW¤ÁãŒ"V?Ôí<ºs©ïofz‡sõ&÷@ÐጾþA@$ÛÎy¾¬»PT#ÕøÝËa' È¤–!0º­ú4Eháp`12·—„¥"±J&•RŒ64L*CÃ~YÚÿ6œDUôC‘Då•Ôœª ŒAM§j¨ïqu}˜S{Ùû=¯365¶ +€ï|áN6²F§9}ãUg¢ÞïŽA½ÇÏ ÐvŸ¦ƒü +·çMÔûû "ç~Oá +öLˆoûA’ c´z±–üÿ­åpÆA&±ÿáŠec§J9¨ˆ +^B*#LÆ ÿ!¥ÈTX>• +–)~\!䦑à™2 + V`¶$ð¡„r6•ùäe#3ãÅ4žˆ„d¸”<0vÁ¯ü/øm»o) ©õByÕ÷>âL|>þöêð«Ø”° ¹™}¾b‹Û¿ûWÅ=rVˆå‰w0Éò¬ +,: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ÿý”(YÞäšíd2IA_²\ø“ “Æi®òE–'±Ò,V»3±¸ƒ¹oÏ$ã,=Ò2Äúúæìõ»T-ò8OUº¸Ù´l,¬•‹›õ¯Q«ø(ˆèíOWï.¿ý÷õ›ó,‰n.º:_*#¢w—?\ôíõ›|s}¾”ÖÈèíwo~¾¹¸¦©”i|}yõ äÔœ z}ñîâúâêíÅùï7ߟ]Üôg Ï+…ƃüyöëïb±†c&b[³x„Žˆež«Åî,1:6‰Ö~d{öþì—ž`0ë–ÎÊOŠXiÕ±“Yš–Íž OTÆ€ÆJ©·í•Ë‘¾'ÏJÉ$NÓÜ,2ª*d‚ +N“û»×Á‹èñ—áz!Çt‘÷媫šš˜ñï#9âÉš8JŽx:z›=ÖSœQcñ£©ÍpŸè\Êœ—Úëƽ²T9<ö¸‚E :¤àêEfžô¸Œ¿ ÌyÜ)ݱÇƼÇUÇz­àæ º ·˜ñ¸Œõ'GÔ«“$º(@m隶p¹[ÚDšÕgoL& G¹4Ï2R'qwh=ý®-·ÒšD5‘¤c'†¦\gÊE{aùña[­ªn†4‰@ý¼‘.›æ‹TêX•¼ø…ö—!Éã*!?1™É†Oši³Øj0ˆ_ŽIOñ)&s[eõ˜ÉSf2Ö¬w·Ó]5uI—…t åÖ)ºÌ43ý!"=*E€ägŒx¼¯VLÚåQÜòJÒ ]þLZ$‚<™D{ƒ³ª!pËLŽË\ËVùø8Ayóö(ÑAÈ Ú ]ÛAØp¬‘J‰Øhó„cÓRÅ©VS!c•ƒ¿Üi0ÅeHrÎi˜8Í’aãÓŽ Œn®3ûyôŸâ1Iã\¥é˜ÉS™Ä:39Ë›"wajKgürÆ6~ÄTÒi!t0˜Ãvu_®þ Û¦dV"O'êuWTµ/)tC¥!H¸1T”\ö®ðõuWqdWPC×âÀŠ lšC½ž ô~r©„N8A äF'jÌ "8…+˜D¾/é¶tQ@Žro%…œ|¼X±x“Þ·8‚ˆºw(7ÞÞÅ̸­ÇLÌV7TÂk ÒYuÌ´Ä|ªÚU]õ¡¤î`G¤à”‡™sêôtFò‘r")IñÐökjÁ…£÷Ûœ\_Ïåht÷*ŸV•TNY ´»æÃd¤_t[ÞUuMI„"-͇DÑý ]NqB¯Hí±-¨áRYHü‘¹ð¶üÕ“:J÷˜ôl7îDgë±,YuœÏw$àÌ ÓF-Y^€ +;@ ž%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-?76ÍòwGQÛ Bîb÷°ÅÚX¢4U¿ ýCåòú¾Ð±*+ǵ#BuµõúUÎÍ„›MŠhHìç¾q^ NL%f„îÊnÎâ„'o©,<”ܸö‚…äI«Ç}ùl¨í Ò®LµåY0l5¸waXñ.ÁHîÿp…!ȸ®ÊáíÜ9%àƒŠf„0”Ú°³^Î]ü˜Ya#_ÓåÚ§dŽ©¦åk•Ðs„¦Z¦¬×€Xl:ª°Z_òܲⲣ°C9Õ“TLÒRu0˜Ñý oF§ý3wS£óÔó5Poï›ÇšÀ[ Gq‡VÈQË(”UhÊÛýÒ+&àO°Å„^A k˜¦ +®£î”(Œ¤9w\m2¯“s}.æ"8UyCw¨]™Ó…)&“u¡†¯‚"0¾GÔùV3½ÊO¼|fÔi–ɧÒ2£g<$<,- ¬kaÆò~÷„w÷ÉÒ Š™2HÓ^„ÖÇ„CzÆÂÌY˜3—1}ËhëÞ V{×Õ¸†-F/ë«¡Ä^¿ƒ¤}ü]pµ‡ï‰©Ñ_Ž'™ ~&qöa8»òû +ß"~š|ýš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#ˆ]Ž›©Ã¿‡èÎ(â|·mêâÖãÝ–÷ŇÊWŽ"ßü0Bœ¨ÐPK }wH§¾F_w:šqߘ•.;ú*ë¿×¶Õ®Ú{tõã™3#æñûñf2=©€¥Îyò÷àšFüO•Ò(‰óø#sqñ¸Œ?#ô¹ÒêC–SYd‰^Žúد=4„=Å·À ¥.š‹ˆ:hŒE‹#AÝ00ÍÒð8KÇpj‡” +:aœJ\Ì\—ÿ‰€ÕýÝ[Åß®é@ÐLTÂp†ˆ:¬©€F]ŽÜ$¸‚!ÚIùôF¨VPÅ,HŒïÐ꣤v|.†V>†cžÂ/ß·ÁºÊõß ÔRgF'OjÓà*°rbÖXŸ@^ÎnH“s¿·Ó&ÆÉÍ|„¦ðâßâ ?TÄÏyÖª30Óˆ0Sȹ9ú˜Ùÿhï˜õÿ·>%endstream +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×a[)#èB +ͦ®šÌ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 }P2$¹&B(;àèÈÿ»YÏ0rLÍsBð<…#t¢03Ä ˆ&~ð²Ó»öqÄDuv†Úgœq?üD;N¬4ö%‘g­ƒóŽâ¼Oò8È1îà¬å~ãpä›|9bœIUò»¢ÁÓXåÞm0y+ŒÝ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®»´"øæ(hC¤2r¢€0åì%1CHK 5èé¿[•øðàFǨ<Í®£@+6q…8 +[I&€• Õ'–ÄBpž(àLqÄUÞR>C :Ö¨VP£·Œ%icIvˆ±`8\Ó2Lé£!ì:"4ŒŒ°è€ +þ³®ò1 äW•99ºÝ ¿¯šß¦n°´ì~ÿ—“L+NŸ ‚kZ)ùÜ *K¢äÛ¬‚(þ…ç§újï0Rw~Šv0«©×inÚûÄäåŒÖQõÛUôûj]R£xNëÐ0V㽶|Z–ÅòwS{Ö›PïªÕ[ÓøK 'Ùÿêöiâÿ#r2íˆ0YB¶Cƒ½‡Wp« :¦Š:"­aã¸5å­ÒÌ2J‡³{[oQÙùçl )Æ.óaÐ cê(± +xé_!X%¼;Y=ðv}³GjغÄOª=ÔMK"'dY¯_õ6ÑA¿†Ç#‡†ûm¼ªÇû÷·ãé8(Üi¨ý±(KÌb—dÆ)Ÿ~êg¶˜r…”Ü„ëÓã £o]žÌàu—¢G%ù¦W’§Ô>d1GÈ>ER{38]–àá +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…Ÿ~Æ­õ—?\q„Dº¢&×Th9yçÐ`ÓŠ3Ë&€Ä ÄU<Ä›ÞI8bˆù‰<Ä{ˆlº€ÿùôêP3>N2’, $áÂÖ“_'ŒPéœÀI½vu¯ƒÐñõõšOÞÔ Ñ¤'T"<ïSBY9ÈÁ È6džNáº#ˆeu? +ø˜Þ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ËÎú‰*ºx("{£ea¡ÍºÐuó~1V ’T‘`&OŠ÷æu•¯ìÆð–}sP.9Æ ð“6m ðj¬ºCu†ÑxծͿc¼ØÈ>ëݺW9·»qdG™Ùñí5‘”õvc»Ÿ2u陬xÆÔ{³Î˜zšåYgŸçU°›Qƒ–$wîüþݬ¯@Þß,fÌÚÛ”6°Ú-sü]åíc½ýÅÿ¼¹Í:°·Äq€gØ(ª%®Íš¸t“oꮳ*ÑŠîdzžñ¹­#FNÞƒ_|Êyÿ…pä@™s ²h%†6|¬ÍäÔÍ:K ®Ä…ÒZa+x2|ñaÞ¹ô„£=òôHÓÂÍƒÏ +~]ü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 áÐ 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·À@§ÿª³Îâ!›çëì¹ð[+ŽKz’[¬â­‹ò‰Ú3züI^&$!›c<ƒ” žr_>¿¥Âb•OyEHຊêöeû¬Øx¯‚r}ÈÊjüÉbª¦?V (£X@E¸Ü‘X µŒ>€+*Ó¤\d²ÐV¥¬ ¨4U¾üŠ°hÞÔÔVÓ Çì¼g}`úÖù±}‰ +Û¬‚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ð‚Ÿnbœw%xë5ª 5jªªwô”©Ó„ò้0B÷Ãa:Ž&R6Ý5uU,sªÔë"4¥‰†Uƒ™l¨2’@sY¹.ÿ×°-[º#"Ýé²8x½åQl5ᄇï4U“…´Ø¬‚óh$|ˆ ¥qj¤B™Áöù~FЕQµôT ê4;X_Mõ8A)B½ª!% ~ ±Ž¤åÑհϪز&nžÖÔ5§úoy9Xy´Ú@ÜlÁâõî84®ÙS› C}Ÿ-~#>òßЙʺïßAGø4<ëxTž‚Õkïœ1"+©‹Ç>Ö!…—=.ÕàwBà}nï+™†¿[¼K§ß4Ŧžù<^HŠ¿ú)aW!Uót<@ŽD!Ø¢7å¦ËÜíi0aÁ4dògpñ*ôî¶Anoö«fC‚Ë"{*wUí³7;˜6ôwÞȨ½Ía¡ÉçÐ6o‡5š¿hÊ%ÈŽl>¤ܧʛånVïö³MþœofKH[‹r,ù<ÑÊØ€Bó ÿÜHo‹˜B~J %Ð¥ÁÎq—p“©wß¾ýüed@c£œSr2exK`ü¸daOŽåW—j*yS ݈ՎŠæeßpUåù¥ëfÈ £ˆB_ɜۋö®ü9å>µ—7sæ¼svv$AŽ©œ°½éœIQê•YœvJq>©‚§7ýÈ. +°oõ+ÛR–µ—ƒ/ëb±¦aý51C + +›5)9ÿ–ú蜃B îX¡]k§ÈÓ‹Sä©M$ønÐ~ÿi,o¼0’‘¯[Åî„<yG$>’ñ6:…² œè¦i'jm;4Y{ãMà ÞöœÏ™¥,±ÜÆpó,xæ³±{h›cŒ²Ëi(ý}&²ýÞ'.ÎDÊ`O‰…¥èÁ3Q‰éýŠÚŽ»† +«<ßôÒ3-sâáޞˢÊæ›ÞÈÄ tš0aœ 2P¡-ærN?H”Ã|’ ç¥Á/±i¼.|$2h9îÇŽL©!\D©Çÿ>Ž!Eñ«pùÈ ÉA^„K‰= ÑM¢y{0cÎêx EP8Ñp¨xî Ï:ö¾·¡Z»eXiù ”}ù÷âaD…lÐeÿÊ_âŒMøÓšÁV=xs¾*%`0b“àB–·È«ŠnS:wmz‹®S\Ig™¸Á2W°+u9[)œëheôÍ‘oȯhn¥FT|Cè¦0Ôú4 _«cs‡XŽq¸Þ‹Cè£8„BxÄ8„¢7twÌKqhY"ŽYsœÐ¥@´iÒÆlCT2†@®!ž ‘\æÿ•x»^>€>³ÔýíÐÃ!}`)Ä^¨áíŸtC+;[ƒ54g¯{›-ÖEÙ‘õ.Þ9½÷Ë™W¨ InÈ“™$1H„»±äo)•Â7NiwHæ—ñ— +­Øf‡ ¿oû]z(ÜTdQP +ñF•"<éÒIN.”5àµFúÙ' s +I×~Ð[YUeR§ß!hºdÀg¶¨›pYŒ5Ÿ·R@õHßG4;A„§ W¡ŒÃéo-o¦q˾?\ Ó--‹]›»„¬™s{aêB´X76}àÚ(×ú¶Ï~ð³_æK.¸ øUoGM¡/|Pêê þ¬ +_ý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Îã4A@‹”MœDª$åG¯ýßofg—¤dÊV›®0 îsvçõÛÙY±I lbU‹DNL"#35™¯ŽâÉ5ô½9b~Ì, š Gýpyô×ךO’(Ñ\O.Z6Š­e“Ëì§éË¿ŸüãòôâxÆU<ÕÑñLéxúÃÙù+jIèóòýùë³7/NŽœ^ž½?§æ‹Óק§ç/OgÌ*󹧰gÂë³O©ôæâäÝ»“‹ãÏ—oN/;^†ü²X #?ýô9ždÀöÛ£8‰U“;¨ÄK>YI%"%…-Ë£GÿìzÝÔ1ù)a#e¹  J"-¸pDž™Ž˜Äq<½¼É‰ÃmÚM[ÌÏ{±Ì‘] *DãÉŒË(‘L:rÝôfgú§8æKßw—y¶yFÕ«ú>R[áç6ŪX¦5êâ;?eÓR¡¬|¡ÈòVK—~D[ùïMÚ¸ª?䈙(Üö ¾ÍÖ³ÍjM¥«üº(}ë]ÑÞP© —E$7T³<ÒÆZX×yñâ ÿ°³Î«nnȧXʼnà ‰L ÂFÃL™˜KOÄ"„ÞÝäõ1³Ó|gåfu=®\”N3¶',ã %J‘Ç­S"PÂÜ&G ¯)LSª‚¨ÊŒÆeÔò±,îgMûàL¶Å*‡Q«5ªË¨é*O› Î<)OºÉçU™…JQÎ=…·i¹Iëjgž K€kàú_WËeuW”×RÜ1á­BrR”Ø4 ‚Áæ”Úš¼.ÐT-ú uÃÎÚ´(q‘á¬yµ)[”&¶µëw'IÛnÓåƯ¨v}a²7v˜V­Û¢*ÓåòÁo”þR•~J™®`‰6A 0"I¶I$Ö‘€æÛ"¿£’ÁI¥½ àÀ(t£UWÎç³lOßïJK0]§Bìî$ +×Ëê*]Ry `ࢪ©ƒ¤tf?{‹/²APË-‰ñZèé´UÁU瀙ÄÚ–Üv±‡8À&ä›JnXð>¡§×Åm^R[?¡£Ñ“Eoô“ú‘z@ºð[«VE넃ݸިe:ûVÓ,_¤›eK¤êüœ!ÇB)¯%èÚ’¥––°''·ÑA&Xòäå>PâŠG‚ÉÄ£Æ'Î MÜ: þÊ/#c‚%X€Ç1ëa‰ë-X +»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™uhe õ4¹žPËp-¬ãZTt– +ß,Ç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¤ê°#?ªÚ›ÎÁ]® èªÐŸ^U·ùˆêÏìjÂ_eŸF©`nÍ7u·½}M³Þ×´¿åB[ïkP ¾ÅyºièŠ…PÉ•]è kŠègc~wŸé‰Ôv¼žW”?èÔ\õ‰¤2Û‰à]cþ}$ãn‡{ ` Ùoe}Šîÿµ3Hq;ŠÁ|¶R…R†"Ö„%f‚U²711’2„ÿHKC~xš:÷†k›Z1Ýâ™Ã9£Î«úR@ C‚•`ã]±\RÉ ÈïÓy»ôÓèz­Ýa=rO5  î yÿ5AˆˆY%ºËæcBe<ó%£Ÿ%²mû£ˆa&KÜѧTpK4jßKì”’ +;gÅ0±“ÉÛþ‚ƒpuoð¼«<8蜴½‚;wž}¼. W\ŸYM³¬¤ðbLº®;¢VvÖñô”÷yAŽ}Æm€{öuëv´@ààLCÉFÖ€ÿtÙñïPÎgÇ=ÿP§«Uêe¯ÌN~\G*‘f˜¹ši W¬¿€ˆ|å?'yYk’m´¼ª®7 zÈ›/Uý£I¬~?®ëºº-²|VÜ/êCfù»eÎÜ´Ï¢µò¬ü;kk€æ…KŒà˜pììÝS?Ãóï®8“LT„˜y¬wõ_é³JËßÞtSXXÆ}>íîßùCtá>M[»ŸÈøã6üDQD…ß`}ÖT›SØ•b-Vð«›Ë´A(‡€ÁuTPý×>oŒž Ú{æÖUÝv–ÕWh?3ˆ)ÔÓ®f·z¸1ýxcpXÏoLíÙ˜ú]ãœÅz[`¿}?æ¦ UCУ;÷´Ï»ç+ʹ84ÚA«Mz½ï]kà·—£pÅ’t’¥}ÂhNáÀÖ: Z³½· +¹Ã›´†S‚¯ABqÑÒ¦©æEÿ–Õß3ÓaXµªÚþt¹h—«¤Î)Å +aƒhkI++žfÎy»"1l„]#à(©PÍÜ©˜ú> +ç\.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/6gÔˆ|ŒÁ×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Ï×»³äüƾ;“]þõ¯—Ÿ.–ÒY¹xûçËo®>ÑPÊ8¾ýðñA<ý=ƒôÓÕû«OWß^]üzóýÙÕMÇË_™hdä·³ŸMÎ7Àö÷g‰ÐÞÙóGè$Bz¯ÎwgÆjaÖ²=»>û[‡p0–ÎÊO&BiÕ©ž õ"ÕJ~¸½XjcOõ‘›²Y×Åzí}Þb+]ä8\H·(vu[P¿)Ý䲡ÿ»ò¡¬î¨]yý*ßðy›¿fê»üð¹›Y¶ôŸ3–U}wäæc¹ÝRkOû?£½=Ú{ ¤±”RxkU`í·cq(‹†Ž¬­é¿lᬵL7÷A6Åm~ܶÔyÈ·G†×·ˆd8TBiœ°.É`/Ü‚h¤iCQk8Ì4³ÊfœÔŽgTõ àZš§ˆÀâtDx—Yh9á¥É 2sº…J„1 4„`¨ÊM±,¿=Ììf±ÔÆÝÖÛüØàgÔ‚€åbWV(M=ÞAê¡ÓÞ‡‰n±­×ù–`¬`5pÔį[:i ' ówyÓ&ÉxÎ0…Ž¹ÙöuµáMËöžT$ŒÌ‹…8:ö²Z³’‚’z’tñ¯º*¨Õòª¹ ´'©~Ï@{#l¤ìÐq¥¥FðmþP H%¼t¯i *g²Œl- iyÏzæÔ´KD–y>ˆ§bN¿¤Þè8‡wž2D¤½™BïJ2"·Ù AešÅ®2µX!3 ú²á9 ¨â!®Ø×MS®¶… ƒDÆC<³Œ)wJÌëuþ bs‹œÈÓÙ wkþ¦ ÛÏ‹è9˜f˜×{T´L—²e¦¬­aeûf(‹Ú +£õmOÃŒg4ª Z/›K퉶ö’Ý·‘Z€tõÄ7ÅÀÌ:Œ¡ø@ÿ#¬ÓaèDÆÏ  Ã¤¥¯×Öÿx)¡67f@ÞFHö u(?Âá “¤qÞq¿¯<Ú#fUX~lë]Þ– Û'¼%W­Uì{ (5oPÉ‘¾ÛšþñHu0êÏ¥CA0ڣ߅·¨Š €Ð˜ŽUÇH Dó2¨¸Æh_®ï©9`Þ 9ô‡74>XW“Bk·¯Ûo e¢û†¡îxa¸ÏÊpõ\*f4d,ÞÛ/Êe7k$‹æ¾>n‘JHBóícþÔPû±>|FËISζ? Üq'HêŸsçN HÖí«Ý¹ÉTLQj³ŽÒšÎˆ^¶¸Ìû‘Ÿd¾Jþ'ïÏ!²îÀ%GôneÒ +°™ll¡P"ä4ÕÅÓƒFç•)äu:­‚™Óœoá¬UÙÂØi…6é4‚÷¥™ÀI¹ãÍjí4:%Å_¹¸­Kñ{¾ÃÔ1ÒX2E䀱qÛ?c*½–Êêxw÷Äž¤bײ>äÍ},1¢—ZׇÅ[÷-`ÅC-fZ,œ‰Ãúºꌌ¾¸Ø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‚†GPo`&‹Ì ø—$Q‡”|&¥Îðn]‰x—€ð±˜õJØLÙ>µ62dz íÒÑDgÈišüŽ¡{®±¡Ò€Œ0“ãÃâr­>†Æ:xÉÐ5Ũàm“Žc#…Ÿ²j3&‚Ò35wD©¦ó·3Ú:Ä|ØW‰ù2‰“ÅCŸˆ‰yO ÄMò™cÊt-2kÇ~óeVÀ÷öw!8î8ÂcOAÀÇ*ĺ„týž\ïXp2-\… ÏUýX0Po¸üþ±Úm]oþDp¾ˆgü=ĉßF.¦ïóv}Ëfa¤èI)SÃR=/þNl :UÆ⟨?ÒÀ:¯¨Ñì‹uyûDN*ÂýA°jß“Eß °‘3’h—ˆƒoÜs‰®dT<‹ÎJAöKÀ IÛ\ªÑ­±Oy*.Ê3‰ Ö7É×m–)‘8¥Ê¢O¹': 1T“b.Ì3Œ:ž÷ì<؈H@-B +æ÷Ë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Û‰¦BNÐ7¸ t|]öaÁ“c‹bnŠƒwBxU€¦{-¡”hŸøBÌÂ^M.Ä~Ilrsýá»7ÓSqN¤6‘ç&AÒ¤D ÒØáO9qúr8ÿô%ç+Òp]Dº]AÕNI‘:YšÚ-'IݬH8ÅÆrD'ü.]´ù–yð‚²æJn³ñ»KÇþ+SÉâïŒ( ¼[Á7pšo-iiÕ~y|Mh4¼B 'ë€L§“›N˜lýdO4å]•·Ç˜›iÛE– þ8€n¨{lH 6>™À"ÔcB8 +¤è®rB/¤[¡±ßÕ&Nj‘£Jߧ¥ËTg‹Ë¹úv|‰J×ò®¬ò¶ó¶ƒpóŠ +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æ<¤äVw2I±” «Ã±¿½ ñ(°qÝ—Àá[&q¿ÍÆÅ­J…vÚñ1¥€ûßAY•†HL®\›öœ«×/µ‡ó¿ h­ðY–þ?±†?!¸,S^8( Æ^ø?ßÌÉö6i;ùªäµò}G•IÙëQwåÿS¸=µNðþ…wo¼¯HNgæÂÖ ¥ºÛ™Á%ˆrIW;5Ô}÷ñúúê-µ©fiŸ¨G‰\Ýâµ2æÙe‘¡×Y…4 Á'l4è·q¬…4ò%îæ/‡ fìæïØ€#Ü 5ªûDÙ5§¶g½Dà 6²Ýt]F‘.ã- +¸ºÄ§c ìä­e'oêÑ£«–ºJwï@0ÀŸr±?®¶åšÚ!Ľhiºr†?üd%?BÖ û嘘otÒíî}ë°åëaB4«"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öc_]$¿»xû.3ÙT¤³»Õ€—‰bc’ÙÝò§ù__}wýþr!tmiî²ÙôËÔùƽA‰A5Yd2¡g‹$‰¬ÖÂËúsËüÁ¯gºÝ]&fÞtMÑTÜ•WÍ®ì֛Ю—DÐÊ@Üç­[¤Šž#>®…Ýä]ÙÔ4æe¾I»b™wyÔB/ß +ºi$V^Z„§H«qÏK÷D¯ÿ0P8"s—o6ùŽøélpNÀNhÄmž8¤ÌëêÊ«JêȤúHSE•·-ÍþŸŸ‡q²ÃMÞëEQ• G?Ï?òårçÚöƒŸñ¡‚c¤þßéñÙ˜›p[:ºESWÏ4ýÙµšÝ‡º¾­#›eéx^MÍåùŒæFQ4µÖ›Ú}èíàhîB%‘Q2¿òûg' L$U¬çð¥X‹º<@¯Gímþà&,ø'}Bš%›¹_þ%'`“ÈD½ô2Næe‹O‡šÛæÉíVûŠ:kÜv¯\ÞíÉ„h-È­c¥Žn3çÊucÞ;£u»G·£Þ¼nŸˆî'~yûµÝ»Ý3ŸŠL||BËr…2­‰Vwˆ™ªùÒm]½ô¾ ›¨t|>­$4í:òö#L‚“j1¿éƃÛ|וžÊwí¾u¤ WÍŽˆrNÚ/×n«’yÑV°Ïuûm;e¦OàËš=e?’GE¯Ôfæ{†ÍÀIë Çöxf"­g{žú%b„‚ ¥Ï|½L"@µÊ•”$þÈ —”GF’OÅRABçßnó‚û)@=•UESîy¬u®&êþy´N»¿MŽWb§¨¬ž_1^0ž¦öØc–d’&#烻ÀFŽ3¼ƒð& rEceÇ“Ú†L7€í›ïùep}]Zzsĺ †;òûBgQ"d0JöžÇ©‹4*Jc™ÎT¦ ¿’â5É‹ˆ¬1f:uYôC–>/É'Mi+ÔaåÞa ©uq¹ßß&dÏñŒJ$QœÂ!„ô±gÔi”eI@~³:œŽ'ÀŸ¶‰Y–ƆߣÅ"‚„ÌLal*'“r½4HÑÜ "ØP0@Âc ‰Aœ¥›Ÿ:vô`ÃÆ ° F÷+Ÿ›ŒdJT©l‚úÿ:ؘãbÈr +lQ¥ƒ…ÿk)ê,ûûdì9ž‘üadðôFBžÂZøµÉkápr¬¶ ŽùLmâo‰Ìkµ'#%cñ‡Ú`*¥õŸÑžÁWDï‰ò°ÑªåÍuùÇ©ts!-  l”Áœ¨Aa«©V~OëKGŸXQQ÷X.Ñ R9Ï9?Û¸b×e»¥X’-zBGÚŸ3 ¶®rEè }>bÅܧv $~*g)È(,I{Fêž…XBH§Tvw¾¢™@/T &„,c³4èGd ¨!Çê +IJ’D·/Ž°ÆK » ]n;~qE:Þ0Ç` žU_â%_ý¤Á²ÞnXÔÑ.Ê•±ö¥ ”özÞø5—˜Íû択ÝdébMd`ôL&ª"ôÍG‰hK|K~¶åCí µ£®Ÿ…ÈR>³ƒŽ>óz ,ê`uï†SÚ¦zDøÅêÃf‡3ˆé2 ‰N#‘óÏCé ‰›±*«ŒJ4aý=uxø û8Ôúú»êžò°£Ë7A ‚¿ƒ0ö¢Æ¥)a믪¨9÷<ô‚»|Ø‚ç$;ÔûfêêÄ»aÄ—û-ÇZ—ïÝÀÆT 6°«ó +é£{ ìû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%æW7#Ù\aÊœ–Ó$Öù£± †ß*Ïå%^~wz» -¡îIíËûÒ³‘exMÊ×ã-G°—‡—å$2[µÏ—÷®pKWÜ×ø‹?âÚ®ÁLï|/TuJ¼Ê0ãäEºÀñPš35ˆÿºÔï|Px8§<\rbƒ/Ø‘.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€×\±xkbF^û`G0¸c¡Âjö«=}&|Ãwí˜ÿxÛµuíÉOì •$C´Lý-„ÿ¥™øMÜvÿËÙ9üŸIe‘4FLÿGÆA +ð—,îJgÇ’÷ÿíy)úÿÓ±µendstream +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¬A¬xÑDSnù·Ë ”2j)¤6¥>.'§&Rà˜ÈT–›†.h¶ •¥ÿmjf\ƒ6=ÿ|squùïâlfÓåÕç›™Š°6½¸ú{.Z—‹³ëë³ÅL…6†Óó¿Î¾,ç ñÉ”:>^Ýü)Fñ7 t1¿˜/æ7çóÙ÷å§É|Yaiâ…šžù9ùö]S|ûÓDºccåžw4)ÑÄÀ:À†®—#áäëäŸJaãk1µ—?¨¤s®Ž ÄVƒ@ˆl` {‡`êH/dûm0SMM›F.eAú!ÇÄ«cTmH(…N‚7Ú†Jb.»!ð×'bŽªc`›·§>õ„ÍÜÒ5£ݑྲ&¬œˆþc!Þ«êôTˆ\»Ì»M7 Eà I3*:qÂJ¼\2ðEg½ÿìNݦÁŽ$™œ”»ú˜)”¨-Òz¼ÿ Z]”zËáE°É¨4š^–R²“]¤;âÉKÄII Z¯oR[—ÀŸõãKšìˆ/¹¥?”¥Äc%KõÊ$›_2.€—DbàW}^•ö¼$f.‰I|+5Æ¡\ƒm¶‰Wö\Ï (%ë2ï:€·°ØŠÒÜ›Vè ضå´Cçµ)P®D#:úG§Àé…”jÎ&7nX<—-½*sHç¥K+‰-êÐWæ² âë/+\êF‘› +}­ÔÏ—¨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>ÆB–Êå*W©ÿ&ì4é[b²]åêdAIRV ×^ž!/[a-&=õÂäŠ÷CÍŠÖ±ƇK¹“4èÆnG‡OÜ0ÛÊØ/Ú«d˪2ÞKCoŽìºJÒUœa{qƒß•É£ +×÷®Á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Å€Á£ò”ÃÎzj㙵=/;3•‚EÊâEjEÊŠ§jÿ}ûEÉtŽM¥\h6º@£O(ÑLÁ¿h–ÙP™<ž¥yZÙÙb}¦f0÷á,š¹'š©ÞÞ½ºLô,óD'³»åHVª,‹fwÅoÁ»¿¿ùåîâæ|®­ +’ð|n¼½º~Ϙœ‡w?__^}øõæÍywW?_3úæâòâæâúÝÅù<ÊlüZ$¼Àpyõ †>ܼùøñÍÍùw?]Ü gŸ7RòŸ³ßþP³ŽýÓ™ +MžÙÙ>T幞­ÏbkBã1õÙíÙ?£YbÒŸ5Yh3N(Ц#FQæ:5³Ôæab´! ®w÷®+Ïç‰RA×o«æá×x:XbEan­&òuÕÌ·år[v«y_­…­Ù­ïËí—ØÜçïc‹F«õÛ§ï_ë{™vu_Í×®ë=ÙSÙ}j·Ÿšö ûû³|šÕ¶\ôíö‰é6®_}jܺd†¹ÎÃ,KsL˜G*&¾ÿÒä«ËXφM,Qxœ†*±¡9êlSØ¿Ú¦dÓ»í]_®Ë¦çÏ÷åïJé¦ê«¶aŒk +~íÜC9,t0XGƒ)ÄQ¢¥é8 V®c¤ãÁ[!‹vóÄTí’1½žËSËv{2'æ‚2É€h_Õ5£îýÔ}]NùBßòýo¶çQ´U!ávýªÝV`€Õ£G5ݾÜvüÁû êÃS›±* u}¬Ý»1´ ©Œ ²@ù]F /1*Ì’ì«F`Ò0ɵ%Åuµ{,¿joÎçFY!0‘ÛBdÕñèx  (7uµpL‰F0š÷–â…@úŠÓ„¬ì¹ÛëHCâÔ² fí&v 'Ê•J„®®º^6¼)D€)¦£˜È–‘ƒŒÆuËÇÀ¯(¸ú…±®(Ýue' Kaðö0ûIǼýÊõŒfCÇyÖ"‚‹¶éÝ¢a`Ħ½Û€× }–‘v ˆe)ï0,¯TqWçQ°.V BeMñØKs ®îZ†Èá@<¦…nj[´n +ëÃÂxð4î‡ð¸Vû0¹Þ>1AQ.$­¿¡è8è·à‰ËÁ *'QäÀ€^²G¯¿i·=ã­‘õ›©,GÚ0CÐê^ãF  ÉZ!´Ð‘DB¬\óPŒ¤¨€€Ã„Óåϓ Ѽ–OT~†8Ð&'Tæ3º‰ ,»lÌD±l&Äx"ÇÍIŽÌthtNK´ ŽI7%QÎ}Ȧ]G‡Gª¥þga”Õ¦xÍøÈä±ÎÌTð*X¸7§o¤ÂèK£gœ`Ñ´ãBè^È +"í«~5uÏ’EÁÝíÕ† –Ám¥JWKF9Ðçë’a:5ìü +Ð^ÌJo˜†wÀqøç ä¿ŸÌ<{H.=ŠÑÅ( ¥Vì 1~#ïa¹’S(ҒæCâ”g[$?Ñ’Í{«[ð‚Y瘼Kå‡=hE†‚8ÇŸCN”\tï¶=ú­ÂjÌs-¸€¢EÇÜ‹v q¥à½kp¿ªYˆŒªg†v‰êš¸k¸Ÿ²@i&9ì aÜÑ|·á/Öe]A­ ¡QX ©Á\ñË{Š€4Ag€ñ$ì«¢_…SZ»nûÒ3Fn„$¨ æõ ìÏü®¬ªš?€“Ê´±Ú5âQ…ŸYz¦v×ÁÞ:½qMœ“½ /–;ìd¹×´~`@m#Ç»Œ· ;k캒'ø½LÔ`£5ã úKpƒ%«r-,¨‘‰K†ô1XÀ”B(#Ùà’2,& Ïn½©K4“<£»¤ÏŒzÈr©ÑNs—G%Ž¶6Ì èâ2@–%óËÜ‘Jì:'Õ„Æ"ÙøÚg]=¬Pu dŸÚ¡5›$—+N2_ +“9çTÄW ):aý&• ¼€¼>¶§Òy +…³Ò“ ò™¨Jƒî ¼}ÝñÇ}¹’j5 À”ž„¤n÷µÀՒǧvÇÀf×3=t•ŒQàÛÑr·¹)G… ÷PK³­6Fj·£( +Bïß“­Æ¸†ÿ±¾`Ôj$&T‘I¿G¦gy±ÙHÀm¥×0Z‡qžK¯Ñïî¿¥ÕÐPº-@ÆÀqª9üŠéƒR®6œšâ!„ˆŒ”†r0éE¹é™P*rÍ1ÇQÎçl¸¶A+aúɼ}‹éÄ yFN_±äÞ|ÝŽPÕÖÇâ5ÖP _È]Í-ëF,uðîÓ°Ü´ý±ŽzH3L_ðÄÆmE´í÷ÀûëÛ×¢éU)*9”ê¡ËÒõ»1~(·Ç5H¦7Ï ÍVï°;¡ +s2K³Lo 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ˊů2ÜNûظqoœhöÊ$òòdž…ß>(·ë]Q/7wP“A›øyèÂÉC¿_bg@¼XUµØCÃsœÅ­/”Mìc”…£ÈÂôºtäB‰õ©µÏô'™³]KpX8nr1zƒ“"Ýîê‚ãÉCé£j˜PÔE +¿oòBáÉEâ|õ…‡虇–àq[½ô-x.ì‰}ž>ÓgoüCã®3ò]g +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ÖŽ> 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ÉlM¢Ð2£`a<“E±}M¶sÔÍ·µjqGS +Η;¾+Pfă_¤Ô4äRÄÁœˆyŠô–•ôLèñšì©Qôœù/œËç›"%bkÎ,&Z‘w&Ú¤®:/ÖI–£À ÚTfÃP:Ÿ’2+Ö*—vÔ%(£ ÚoÒ‘âck•W­Lº“E¶Y’Óä ˜ +wæVHF¦7ãÚÚ³ÓO%rZ!ºêIòù·Åvd^z‰bÕ7Ý–#S‡š)!e_;ïÀ$¹ ^—Ùl ò‡ÐÌV+l‰ ÙlV{""ðùû.Ýf—"HËš¹Zú#Z¢ó°¡j–;Ô'à8[ÐjûbG„×Ä3 +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(ˆâ!Áƒž…?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ªù@×Òí}Ê8dëö¨sû<¡Æ};°×ügv<œ—¶<;lñ Ó}‘Tˆ€–gœ É5˜ éƒ× t€‘@:bΠ£æ:(/÷GÀ!!¹Ó­ãàð\#«wÁ*Œê.ÿw¢£ÙD®‡Â +êìó$8<ÿ™ç};8´e‘ò´ê%~¨•Ö¼"LÄôñò8:®ƒb«-‹t;ˆäà¡þnÏ<HÍ5"@ èNM_‚¿ í}ô7¦ó­e€´Ã(Ô¶³ÕiøÏlz8ïÛ1b ˜P0ÛIí7\ç̆‚°cÑJ„œA!y&Zµ¹N ®æ:œÔnIA:tHp¨ÜèÓ«7\#Ëwñ&ðÎ)ê®ÿФ˜ +ñ¸þ> +%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Ì°è> 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ÉÅãíÇ;ß_ß\ß_ß½¿¾ZrqX/ì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¨‡-ê–Mú™€Fƒp]¶oÒÜR^W[KrYµe¨ôþG )»öFþÃxZ˜Uðd¿ªìºk3°쪲vx-÷¿&ÈÆ€ª-=‘ˆ0(³æ­Ú¿š¬D“Š!ødðð)ÝçžÕª2;­Así^•‘$èZ9H£™Ç]fUøÖM+ŽYÀ¹sVö‘8#XnÑ¢Ëè©~ß0F"·b\œÝc“æÅ!Q1á-wzžu<éОºH!ÜŽ$S!¦Xçoé¾#é™'ÎÏ™~AOÅɌ鷰&Lßa!ÅuÚ¤Oi ì^H¦!­ž¦ì±FHwî+sÑ¥ý€ÑÌDéL8LŒòˆŒ38ñHóAŸ,–õÒzcD©›jOÊî7–K`7417pöƒkNK6UQToF ‡1D״ϳóÁåË^³ã›µK "ù;ü-Á˜vä(s%ídJ?&hdÎÞ^òJºÊ–ë¬È·¹]ªŽ +¥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\Û :ý`ƒQFJ¶âiR!4¢Ja”0uj´˜3ÇYzS‚ T¢Ö öà¬R›Õ!nQ=Ó ¾Gù¥:ì¡Ð¡!Äf$ašûFàúò•ev‘u10«0R=wk\'T6·ÿ¹¹g4y ˜ü@ ýäÏee;› Šß×E ßmŠÙ^VMÉ cD§)¾°ž“'LIƒv»¬´j? !GÞ¤I!X%¼ÝyC«²ÐŽUýRŽ6¤zÂ¥V†Ìx7À +cÛÍ{£IrÖp8‹ ~& §uÞpŽm- «P`òË?e{zaŸžHšb°ëü¹Lí·øbQ†º[þ7‡SWCPK?Ü=<\¿§1îaxÒ-Ã7ó.G`bGºf{7éÚ­;}ï…Oë¼~5oÙ¹;C&v®r¨ë&HÀÍñÄLzbúÌ÷èaÄð#ò‘‹‡ÛýùÃߪŸ>ä—ŠA-&ÎXJ3-å˜ÂSÖ…šEZ¨Öÿ¶Nœ¯endstream +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|†,—šË²Ô¨Ïa/ÂÉT¸h÷ÐçKP¤Ã) 8Ñ]E¾_¼9—µ$œ‰ ʘ̹`‹§(Sãglï˽š2’r(Ö¸š‚P”èˆ6”™)ªTä¦ &¦)Ó œ²ñ® ®É1²ƒÚ²ÝÅg:´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'$FmÈ,þsG%*8¸Ø fN·gÖ,`qçÖ›ãÏ_ŸíîtËCÞ@4ÝÞ_ÔƒÞh„åüã°°ÚêJóª4^ï¬vñ±°¸ÿ’埊Ön¼»)â}ý6>áMì1n{ZÐpy@ž“ìèß<Û¼p›Óøä(䮎oïK¼V¬ò°-ØŸâmÍ­Ê jªŒïìÃ×™ صOŠ¢ëõý±5fâôÔvö +r¬›Ì×¥•Åƒû¤áçlPŒûb¯爤<º bYa€kj_|ƒÓKðz„CK„<­ânüÏöþÜ +>ჟà9hƒ!UV˜l‡‚3[ûÆ6¢pw“ã‹V€ 5ˤ-Áw’Iwʦ‚! qΡMˆ@1mQâ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ÝqkG«Ê…Â@ ïŽû–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~÷îžÀ·onnï_ß^Ϥ6VÍ$~|wKHoîþ~{ýËü¯W·óvËýcI¡q¿ï¯~úEL–pº¿^‰Hg©¼@GD2ËÔdse¬Ž¬Ñ:@ÖWWÿl öFýÔ16YF6UÉŸŒã“Í¢X+íùt›+8OO÷×éô°vÔyÞçÛ¦¦vµÇo2]ºmé¶Û—ʵ{v5ðEÛtún[ðÔœ>W×ù³£©«œçÕ‡¢€§Ãzý‘ñò¦X¹å`.oåz‰˜6+¦\íÜ>oÊjKDËÙ<˜IeÖ* r³qË2oœ_ Íè(~4¥³ÐŸeIí|ËmEߧÃÖÜÓ ÞK͸ûk™NuÜoù¦Üº%°À¨xúŠ ¡SÖD¥;%_VnK-:4êòy +Žœ‡f"“0¾I§% )›þYåÖËk‘¶ùÆBH;ž´ãi @àrKÀ¼(*ÜeN— c/e³¡Ò|Ü )ñVµƒ3Ñ㤹ð†x´ºZ1gX½sEé©/ à·yŒL-ÞDÔ®D™V©_{>Ƭϴ·³,'¤Ža^Ž’S÷¥\/ ’eÇ{|RLï«ý&Gy—RNoh^³*™t9¼•Á"OGCóÇ»·Ãõð³°BÀ?9&=¿:8ŸÙôP#ß°ÕT´-9† }´[Âá6 úûƒ«”oáy±Å±œ>ó¿Ýþ@-÷[±Ê·Ï<Õ¿v\bá®åÔO‚ÎÑà[Ðí’L¶^ñ+[òF#67g…IÑ»Pì!óðÛÈš>Yž^óØs;Ç߶òúˆÜ…Õˆñ¦=6ŽULêX0· ƒ÷gyŽŽ\cà/Ü„ÊÂM(©ýLÀÿêM’ô4}&ÁZT¼F ;õˆ“` iˈÝÊÃ7 u€‰:  À¢X+9-B*yN}XüÇ Äóã÷ÛûG=&¥áœ»|[ƒ†§›žI'Ñ*r£FB± +†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-: ¨µ[?],)f€‘Ÿ•2¯îÀ„ N†dA:².3ž‰ö|ØæßPïeUúêN†Ò„÷•Á=¸˜•ÝSo1jÆÙîcR9¢œì}Õ¸¹ÎNzSHäÓüœ o·Ù5ÃÄö&_r>Û¿‹/k×0ŒdRÎ7‡ŠCÍëº*J¨|ž=”ò.ÍÞ¦Ô] ÔVlLW±QêÀÖâ× ÓO!àrTóiY7mx?Ü`WrˆøÑ)°Üàðƒ.ƒW+W±¦X"$ð›„Ó½ÝóõÃríº©û~*¸°q"³05’<¹“ćüàêê°/\èÁ—u— ò N÷Rß×<¬ÕfDq`âÇD™‘¦çWj›ÛòS4a¤ñtM<~vôv³é¢Ú{Hõ⣛NŸ¨¿¡ñ‡7¯ Q a"KWûrA–kˆ .ex¾TA`N]:8R.û¡wAˆ/éáÁWGhâxA +•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í¤9‚zí+?@Ðß‘*h R-·OXÀ ò®TP«8èÕ?6Œú*}ÑØýÌWìõÒâРʑ[«LÝâìO÷4"öI#úúìò}S|“¾âpÙ¸Šj³«ê@ ¬_;˜É)‰Bˆpr>îó+Ã*9ÚbaÆ ²W*ô5¼†á<¾­€eH™`¡Dv‘\(¶è ®î˜_nÿ!Ô \ê ’‚š +F÷õ …sÃë¬ +û÷ÿ‘ Cv¢.\Ž åRð Ðw é€j0½–ÔÕžMGof¯ôPÏ+Å æaWXób-&þ"a‡?œ9IÐûg­yçöõÅÇ»w.ß/™ØIíE(ºïË að÷¾ZŒ·ñèÜqœAÄ5[H%¢D_Q Áýó„}w:àÏúNýéSºxÞGW4m2)Žþ“ØEjpÙ•ìéıo±.ìÄÀ ¦åp'ltËj &^ØÏeE‹i'tϲÂïÉŠ$ÒO|’-Ö…œRkë\p¥"p?Óa¨0ïRÚ ¡¶§Ií¼ïï5Ù–ž_Æfìë³Uµ4‰b™Æ<¬ìø¡"ƒ¯Lm<Æ3Ѻw_ü{°î7qØ›¦êÌ‹(ˆÒò†ùDöÛŽ1Voëÿißendstream +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 v»¿]À|Âà_>Ñ&6‰H&6Q±f\O·lòúÞð0fÚ švGý4?øñÔˆI'F˜Éüº3—‹™s|2ÏþˆL,ãC˜Eÿ~~r8šE§gï Æ¥Ò":þùèb~2£†þtvþ†( ÇïÏOÏÞþ>;:´*šŸ½?'òìäôdvr~|rø×ü—ƒ“y»äî¶8“¸Þÿüñ›d°»_X,§'Ð`1O1¹=PZÆZIÙP–—ÿl'ìôúOŸc“b<æBËÉTªØÁïÍÏJåbËlÏϲɔó8Ñz`.úŽÁ\¡Ú|±;Õ”³$æð?£²±±–·bT²#FÎu¬œXÍca¤õb,Vù†˜¾Jos¨¹ÄFõMN´¬¼M‹ÕN?Ônàî¢ÐlGÏ‚¸‹ŠÊëòn•Åe¨´O`!後Èl ª9™ +'ƒŠñ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ý-Å@Ù2"aØzSܦ›bù…šwU\ +I¿*—÷ù&|§›ÖÐ)²ø°_üÈðh‘.ü‘‡êlVá敀͒g'V²¼ZlŠ+Ô^lÞ”XaѲ\}$RÚLÒÌ»¢ÊU¾»Ú¾ÿÙŒ´ö*¿.»6y‰euSÞ-Û1ÁˆÕ"%õμ«9/ÓÆïjŽŒ1“zÄccm-™£Å2­@F*EöHÊŽ=’ŠìI%¡ÒØ#‰–åUS£ÈòU½µI02¥bíù[Öå¢\ÒÐëôõ®W™ËàvŠUU§«Æy½†2¥¢;í€ä:,Ù—i¢j¯’q„‘œ’1H˜4{CÈÿwt8U‰ ¦^1Ӟݭ=WLGYZ§p$­ut$‘gåEˆ_!‡±¬o: ­†ïòîk2ÍШ x“Ûeðø^Óà#NcãÁÂëpe_ÂÛ‚¹¿Ó^î¸(î”ÈÆÌî¢Ê'èRXr—ÀWÃXl”ëÑúj'bp_†\W½®Ëå²|(¼aÅãl#0ýÇS»Æá’¬¼*Úù1à°Ü„QÍ¡«Pd Ô«þñX¤­¦k4>fú? €}—ã«ñ`*!†¯Ö0dˆ|ƒk¬2ÞF‚‡¼)+4£ +Œf–…ËÞS;­h +rvN¢À½KƒGÖC  RIÖ +)¦dº¡ëìâ™ßÀókÕ3ç÷MðÑYcŒƒxO©Ñýg·Ë’}Ýrì1.Ò’ÇÆÅEv*lˆ‹Žà0Š#CïM8U;b“œ³Ï93À¾ÎºöÁ&œÑú¦l¾èeŸJ`Zƒaöd%ÐpÌPý~æñ—½ÛHW]ÈÆ[÷Ÿnê"]>™€yçÍÝ5v¡«ù¼u?‡qºUÿ (VYb º(ñjA¨_7Ç*üb­üJ˜ºÖVSË Ý vV\=ö>ƒ´ õäÝÝ+‰IPñL‚2„×>l8ù¼Îë:K—ÔÕM]„¯I7¡"ð£W7»B™"}WL¥,ðó£ ÿÅJKRÍÓË7?ÁÑ#‘EJBN“›sG‘ÑUZåD®ò IÀ]Åíc†#iËðe{l 8Àª~!tv÷Ší«Ÿ—豘[Lµ‰`_/ HÔ`k¶£ýDYU îc=ïØ`SúÌ°äbˆËåïË ‡ìž‚ɃÚ0—5µ ßñÉì"ú¹eVíÄWYñ±¨»È7ÛÁ¡ÈG0»a®ÐÒ 0·³êWœäSBÅ,a#>NÉ$6R!9>?úí™JÅÅéCRÔ&h¶ËU±ðL†fÈ¢BÍ›éÍ:´\§Þ5&f‡í6!¶C‰ +Ýk[†¡Zwƒ¯8}'­‰…IÆ”J+‚ bÐNE³|½L^˜Å%õR€z›È†zÔ¶ÖŒE}C5Z}ãSã;_0èúe™ð*å'ŸYIdt·þÁûš(÷åAÆ}Žù8éEîƒ6ßZÑ7¨J-ÄzuwUS;§\$.ží^™lVÎ0›œú$ 7iØÃlB†¦a¬gÙ ÜÉ SZQýBHG ažò™´]=¶×áàPSe H cE¿rwµf_©»ï`ÁÁTDVvX¹%DÏ ãddÞ^¼0¢àµËîuÀC?.˫ƈ¯Ëª@Hì÷åÝã¦Ê³6uú…Êwï8ÚYê+6ÛR±X15’R“:dv‘£?ŸŸ¾GÀæÄc³-œBDÇ¿S…‚¨  pHH¢Ås‡Pñ½ÇÞ»ê =^¡ì±ßü+ìww§ûÍqîW ÜÄ*Q#PPÊ°Å}Ÿ]¾9,Èts`… / sn< ¤áFtcŽŽS$Oâ $í–w7ùŠóÍ"嘹a>ÿJ€ñד!,Q×á~ÅK€ÑE뻫e± ú'•´ªÊE 1£vð¢ÚÑW_RÝQL÷G,B‘î~_ñÆÅÆÊ›%œŠ¦áׇSÃ!Xzd° Ù(HPÉ?/À£ûëDl^—¡B¹C¬‘0Œh…¡vñ¦Í%ä³fj+ !Ù€0:»ÜoèºW—,´‰-¸‚aø ¦È^ß„3¢Í5wXxXÚÜûÛ‹ËÄ\—_'´¦á‚ËnX/‡;KÅÙC!Xì´±B—Aªçðo î:áüÉu#§ëFÀ]R­Ñwjy‰`…ònR0ûdCó5]wòæºS4)‡kÊìMû•?÷•˜‹onHõ™¼eùàoð Ý¢!ù*¯ë|Cù;¤Ó  …ØGÑBnLm |Þ3€ºÅ}Ĭ5\øJuK¬úá›ý]!î+ø=N3ø2—X=¢k\@©H¢çGó^vÊî §ô®¾#]i@5¾ÑØà-ì7äE®§<àjg¹ûM<í5½ÇðYŒ9,Æb-bêåÑðÔ:Ó$šVyýPn>s™oî‹æÆ?],¶©?äs‡³O¬¦e·+Ýeï7„Ù+JãVq@ܹX[éw ˜&Çd’V]ÓÚ¿RBR“gòÜÞÝ{D`Yƒ’í×­‰”0çNæ‰õ ±‹†mGgƒûM<™}&žÞâ#JÎ!,6FX>ÿ0÷@@†Pû·\TȺ<9¦:^&i–à[-zªáó?4:+0ÙJýôòOûeUIcçÐVxÄ© 8%±«s"%¥“»)ÑD;Šû·g›{L =+Ã,eM•üsQÕç{Æ%ý·\ù{.Cá2V¶{ÃÖ½j„>öÂ’ž@Õ¶¯<½ý|ºŸšJ¿¨és™¯ƒ5Ðö+|ápLÑU‹ý> +Û¯a&‰º9„­N 2"Þëi#Šu4>ŽPIIe›EÓ€·±Dö È-xÙ¦WqX_,¥A £Ž|Ú¯À/yƒÐÙú+ú¬…Ù†ø5‘‚ÞŽ\`ȺÙ<»,Œ^ÒY€}ë5hzhÌ|Ès…éÏ€ê„ +¥¯€ò!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ݧɌqOÖÖnR›ä"a‰ŠTDÊç×o7ºAQ2eÍî8µ)W™@ãjöù5(1 àOLí* 'qú:z’¯Î‚Éƾ>ÕQà}uuý–()=Þ¼¿¾¼úúŸ7¯ÏãЛ]½¿&òÍÅåÅÍÅõ›‹ó©P¡–°â-þýþú‚&]^}wqþë웳‹YÏòðµD ßßÏ~þ5˜ðvßœ¾J=y€Nà‹4•“ÕY¨•¯C¥¥:»=ûG¿á`Ô.S_H­&ÓHú*Ù=–ŽàXn*í'‘Ö§Â[Ç~¨c½’¾PZõ¢Õ@ô"T~¢”žÄ:õ#%••ý͹Š½Ù9°“Þæ\$^³íÌ´[r{± F‰7/뢬Ô¹k6ÔX6m×b3õºå¹ð²Ž:ECãuÓñÄìÞP«[šrC³š‡•2‰C?Õ_E`CZÆŠÒr`rØ!T©÷P†Z dÐ ¯6ÝC³ùÀCEAƒmkZ°‚$Ž½‹k³)W¦î²Ê’ï­™Úƒƒý#Û|SÎMA&SÖl_—o¨!D†u`D!XQŒjÊþóô©ÂÄWà“©T~ú¬e>ÙÒ­8n"AâK©OYìo•X©Ü^} ©÷K ƒ_¤ ÛrQgÝ–$`BAìå ˆ¹¬[ì%^‘uµ²-è½îÊ<ëPÀHBã¨Ñšœ÷¡®(MýDG!©ëýkPW¨´ÿ%¤A5‰ZÆ‘×vÙ¦#ZsG¤Œ4µ9Õ5›²{<Bx }•D{Ò‡9VúðDéèŽÂ<¼ê3¾ë˪$|Q•Dá©ÅÚOÈ^üöæ\kï_˜”¢dás•ueBS èl!›‘÷`ªŠˆjŒŽ–ØG8¤·fs_æ¨PB$—YWR:ÎßÞ¢—~ªóĉ|FU¼”ªœ¡|ú–î펫 +6ÃTžR•–4»ÙO3T“^g>v$ ÎC}˜V”8-ÂÖ>àíóÞ÷ϵv `NÁæ'D€æ‚ÈYˆPÆjßÒµRÎÒ±ù°,ó%7­Ñc‹›½ÑcÇý«ãöÝnq;|ÖÒóöûÙçB¦Þ+êwËŒšÑ£hV™S[»]¯›Mç”û®l;ˆy9"†£*È毜C‚Àpw*åG"òE(üIjLù:fÛ_3¨B EÚ ehD(µ÷“Ó‘²Ãb@~‚ÅTx€ÅŽgyó9PløÆ/¥˜¤?U#àš8ˆj„ÿm•cDD©¯”Ä~ï×Oj D~"Óx2Õ±ò…Gtï + ­µ/ES´d|×TUó€äü奎+#¨˜Ò$„ãpI^e¨bš·w‚L}©€šgEOÛ†À^nF£,{*ãAÛtHݺ«‰tŸUå‘tî*þíÐFz·Ð±´Žÿ_T/˜ñ´L ” NùºVÂ’˜ÀÉÔÑ‘ÒÑNóWug6àÊÇ=lxÎKe¯0£ þøçVG˜¾ŒÓSÙK‹Ô•Hù."_š(¼”x R€ì¡……Ça$½ï^_cCy›®É›Š(9—¥¶ÀA¦\óýÕŒh¢ø´&ŠUYLGA‘ÆMH°Ç {‚5ü(ö¶­ ŽÐâZ<öJªÄcoÙ'/꯷›uÓLƒ±ôæÛŽÈ´áþF{E1ÙÞÃ|aá&®-«nZZ\JYÙlhäÔJ[G@¾ž†òŒ¿ð_q‰‡áA@xŠSG`³ÖS^˜öƒ{2Ákˆ±@ÃЇ6:n¸C‹ø<+Û®+ã_ð"' C?'‹Œ0ÉA’y¨ ’xì½3 ŵ„^f ³d_?H`HEÂÜ›ªYS5—xóGz‚á~ÑRó2÷ßð:æ¨Á¾Æ?ÃË7™xWXÒH° ´©Øb‘Ò5Di—}x·÷LHöhÇî³MÙly§ö±ŽYjgVœ6ðÞažµÖ Ý‚CàfãF|Õµv„õ¦ÄèrPͦmèÉ&:n`ͽÔ5Ð_{H “Ÿ†=B”q¢Òç±pã';à¡d€·‚6ª@³ÎVL$+‚Á»ÎÔLZ­«2/1@+•x› ¬×ÔçIhRöÚ;ŽˆÚ]l0s•Õc‰Ä7úÅH´¤DÛs7uVÙ ƒÈµ:rCólDê2k—DiaBâmswéÖöðú%/œ¼ÎróSÅ& Ä|I̼¹áMà­aË;êÔMaÁ:Ø°ÕȈ›X:Ñ}p(`/|J+Ê–H;äbxõц˜½4Y£tkËp¨Rr{6ûŽîq—¸¼ä“ò¦n!ã*¤> &dXV{n/²GS0®dóÊŒ)‘ì™»yKßðßkæg¯¨ÄWëÚ Zã ¬C¿ýØ8 ž’*F1Wù={±Ÿ¢Kíü¸Y™Œ4¡øÒ‰dÂ@éÅÞVu¬;áÕÏ.W<½*WeGDÊä`…Í5t +e¤ Þ±Ÿg¿‚L8:w“tïX•KVƒðÖ †&ÇûdEF»¤¡e dƒ]Îô–²ªÐ‡[¼v·ÌÕr’†»=²â¸„A«RŽ¸tï j=`¬äÜ»ÛF9¹ º(k@³­eMz?.ËqGiAøè‰@®[jY“ÀÆÜГfBjÃ'2¼*ÿ0nAŽò³¸%u‹»M 5…/Ë9¡ß'ûp`¬)(»ÒðLë‘ðtõΘ®ÍÆ¢’:g”Òn Ó2,!淪iyšPË“—ͶbÔ3çaB7Ò%éqÅK¹Kr’ ‰GÞ…ô8\‘’à=vðœÅ\‘wÅk3z@´¯£*#‡•)s…òîÀ`×X¼`n wXÊ–'‹H¦Å6'd—"p"^Syƒm˜™Á`:°ì•uÊóG"Û goRåØ«Ø}_`5D¢î^Àf­»OšgùžÆ®t‘•ms].lŸ\†ìÇp:üx|–QÀ.…-›z#—°—TˆÔÂ&qÎÀy6WG°g›MI…cÚˆ®5q¬YÍÑqyÑï‚ÔÍ#Ó¡`ÝšwêoDa"‰Öó‰þ¢`xj§\Úplü};¸µÙöšpp?"®BÝØÞ×NCÈÎ!ûã÷=>—†Ã_óJù È\ð×—çSH¿i™ÝÖËÞzcÚ–„7HÛ¨‚§u'l.ÉŠHÓÇt«§TD'w¨öíSJM8¡WL*&L%:kI]åLÇ'X¾R¹…קùÛ ôåÀÁžTìóµm·ŒE3iÙñºe¹XÒ]Dê»j,¨ÃüCn| ^GP¨ ~ÉôŒŒYã ¿Q°?ৃIŽ€ŸØ ‘‚6-a_J2ç_#°îËâðPºDŽíšðÕ˜}cô xw•á&D©*ÛPǯ þKmH³`ž« ¢ÏGàeùÂÎCÆ Ì6‡ë†¹ ?J`yp‡2Kø¡´Ä»Ù¤O0@ïQdåC ÊvLTkcØ”Ú[5˜Ñ$M,Ò¥Àϯ©iýBîp¢HeˆT•µÃÐHˆŒ~;ÈkYo]H‚e8µ¥æà P[®7¯øØmK2wõ‹‰¶}.âªþë64)ö)g&ÊžŒ-é-,¶£\{Ž®´Å 6®x$£}ÜŽ +òâÂþôÛ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ô¼¹·Î¹h9}ZÏ8÷Ú +2Ôñ]ÓË}ˆˆ7lqm‡ï + +˜÷wÁÄNoˆœÝ7¥ã +Âb‹ªÙÃ'àl-Ch4Qõ·»ßw†±¯’äÈ*úë?fÊ".}ȹV‰¯°þœ|Sendstream +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 É>NRŒá¤Ñ‚‹€ÓåmsÒrÚ3;-Úz2y,g]†¹ºÁôâ‚áÿbQ[ä]YW±Ý5¦]|qi†#àÇMù©ˆÖmYÝ`ö諭[ó›â€¨î~UæÙb¨ð*ê]T]”‹,'Œ§s¼ºƒÝPdü´HßÔ'¸ M_§¦Åçl¹Z/ðë.ö[–7·fÛÛúnGêÅE‹™â1Úr"(—m€µfÀo Zç1â–8*ñÃÈ Æü=Ekb4ÕyŠA¤ÁX؃ƒê Ò` ”$–*ù˜w( ƒ [kㆦCT8 ÂÍaTãýÀkFrb‡…*1ͪXµÍµ|QϵüÇÝm™ßb6¯«¶l»(Ê3'Ÿf(iü¼*;ÌTëåUÑ`þº^,ê;ÏVB“ûAOàõ2+ãhU¶,È¿ºL(›Ï#kwѺ-¶XPÛeÕa¤I³wd{[f‘tuu$X5нbá<¤a’H¼º¢©ŠnOîó3qe»Eý64/–·åç~V‰–ÝmÔì®Þ™rÒ¹ÈòØ&ðÙ@Q“DF#Æ>ï1nG™éûrY.²fq˜‘Å›„#‘BN”D*mŸ¶ÀÜW-0÷0™ä‚8F¿$pb±3ÒœÂÁGI}0ö+B©Sŵ?¢¯~ø@~ùž¼™]ö\q×gç¡”1„‚ã°V¡ŒùÂÿI¹# ÄVˆ”û¶ùzdŸw£è”SŽ‰ÇâÌŒÁ}âå¯p†¦Æ¨Ÿö`êÉ%§Qø­;‡ûòãù›GìWìÒ0˜|dçðÇf™zb„êƒÐ Ø›0ê­²kb–0YØ~K1+ˆ¶šÇæ/E¸’çåµ×âº@eª¨òEƒ0HßÄCµ"–9o_øûL—9Ü{¸×«²Í×m‹÷ ƒ!ývâo‘×ͼÑÝÇ IœdxF8õ{¥æÓyÑæMy6@ {ïUýÉû…ÛDf_Þͧ¢‰}Ú®N·¾®¬p“Âê³Ø.ëû–E, +[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ÚÚõ2†™­ñ-D™(8Åð0vSLúèæ6È£^cÛÇðU]ÍËêÆëëxœ†•SÝ·ë@9hÕtø™ÝàVhýÊ]Ä6×æà–åÇ~uL“Ȫøe,P‘›ø|U¯tœ¿dtú®w!ßíÔbóy=jÊŽ!¨áY”sN|EÙU[/Ö]_Ë"«ðÞÚ|äÜ`1hšš÷@Aƒ¸Õuµˆ ˆþ`› ÷­@^ƒÙ°¿÷¢AÂWâ ?˜ÚÅå56ɸØ8‹M ιJ¦è­úW +Ÿ +EÅ·ŸYžbb(­1Mkn»aX{*Ûç®Ò°¸1–Gf]äizÀ]„“„ú;<$^ËuÛ0 7À×ulï`˜ qŸ°„úSà¶K·m—Y—,N‡a{î|Y4´;?}s¶çÑy<#]ÚçcA^{AøÒ¢qýéÍúƒ,Ã/'»ó5OHH…ôª[Ÿ6INRLÛýøѪ>ƒið«½Æqðøòt¨ÕP ¼þ»h0P7þÚ&aØ‘h—?PMï>-oªzãyVÁ^œ…ÈLÓc“u)º8:"dË­°C‰‹ýÝÄSŸ_ ö¾ E{¥ÑÂü݈S@Ùªö7-›qF–ÜÕýÎSY°ÒÞK†s©±vÂÂÕº'½ŸrG”aæËuã½¾ÇÓWšÓ ³p¨³ÂŒŸµ µ•ôS÷×Ïgã9äõ2<~çš{ÖI]¼>¤6<ù Ùê²{ +wp + ‡š|Ûä<ŒÌþìx,$1ܪwØòVI8ÁZ"X\O»è¸„Žèð'ÀÃÜd8òóâÞ͉1B>††Ó³rî>|ˆñÔc½"usó:ƒq`ïQ”Xfù#«MI"©Äiýyß,9®àmð©pùÇC4ü†HXbµx!ɉ”N÷í¬!ØÝ€ˆ†h3øs!ôô‹Àï±gøg©Tþ‹` O¹ v„I¦¾tŠ¼nô7*?Ñ«7H8œø8g‰,@y ög?üÄ |÷šP1¨–‰~*ìLôgWª#ÔèLþˆPÿÀi¹M,Øß7¦âgQÅ ö§aWô"žE"ûòg[ð:Æ·ÙI¯«¢Œç­Çš:½]µë> 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ö?8YͶ±’LÅRzJuñîâ½ÀÁ¨:¥&%5S:J'ôG3!X¦T4R”ÊX"#i…G“pNÎyðÎt]YßÓùV«_Z<H‘móYÅ,‹El§¯6Ø“4èÊ­ï5ÔVå'Giî܈g^.©ý7ç‘© +úQ¶Øê §Ÿ2¢ö¶ìÜxÝ™{³§û¹ÐÙQÓòRjjuÙµãå[³nê¢}¿RäuAë•s¸¥wûr›ïËêÑÉhA*¨Ýë}kÇ¥ÛDÛTŸÌ¾%ÒÃÆÔÔƒÃ:¶u¾¦ƒK8x †$cí'QÏÔ)L»Þ—·ÆIÚ4Ô©{%Ð˽/×-uk žv×Ðþè7iQí¦9T=Ïøtä:EÙ®s;µ0îVp·[°Š»¦ªš‡ÞHº ­áF»ÇÝ>t­ÒÉŒ¨“÷»ëÞ~ÖU6¬²mÏ^!Πæ¦v³Ð\*ÃN½N0H•Æ³$S,©ú¿“™d)OOüî¿›å7ŠŒS¦#žžßÍã ËuýŒ±¨°?T˜Gš%úèÕC‘`RJ5KtÊ¢Xgößݼœ‡<„¿¹8¨òM@É×ÁRvì|v*R¬?*éGâ 6÷yGN­ÈØœX#fÄ´Úøyàl½ä¦ji M .Qdm#§rf®TÐÀŠ{ê¶fï|K%ÁCYUDöݺ ÛÃzÍ6§³(8 â×ÿz}óëËÅ5ôQ·îšº5í”áßÑn·dlÍM9ï +Ûü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ø –ïªr]Zl„ô>˜ÂJJ( àùœow•yAP]¥c¨>4>±‘|;è£ ‚¸·\ÌqŒ*‡Ðó„R1!xÒ—±+5š®3Ï_óÝî˜ëœ/Þ~ŠŸ¯'–ÆÉ‘dГªÔÙiº²©i#w·± 8JÒ1øë>¯Û*w|0rLë8kñ–¨yQ8¡- ØK„\ÔýŒ2µe‡ì [+ˆŠR·Ö"]8ù(]Erþ*Ê:´ëCÕÉòý.ŸÐ ~"S‘»n¤N©p‘: Þ®–ÔqY‘rXFñàRi3–¦²Y)µYÂÉìðh>%ÂÀ6/ÌXReP†]n–òB¿çªjËûšRY^c’Ó஺°«cP“§Åò‚8*sgy%U“@Ù—÷ˆzaÌS1J­Ç¨(z·kÚ²3D>.d½,Ç ÕZþH´ +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ÞåD3ÚájÿÐ0Ú Õ£Úûç)ö\‹µO2LÉÑ¢0”Ø[BU[þå®rè0Ð9ñD"–wÔÒ® cƒâ×ÛäŽs{,Ù-?YìÁsâyдd\YH9ÌvcàžSé‘Ã{ÇÍÖÍö‘Èç<[UK¬ª%þªÚåë!Ÿq„JkfYF©³¡«ê µ­Nn–‹7‹ëy¨„äÁØ!ú8> ʆ«}Û Ž ì¡”T°TÅésJI“± DˆD:u ^ˆsÖ°s×4l`mç«[UOåü¿ V ãB|±F ×4ãȱÉä«ÞEIJLÅg},N'úÏ”~ƉRûgx(s×r„§ 1ã,0=‚xøC[ë¸@•ÄÂÚgJF±ƒ67`-®áÎãì%1 úö¬GX‹m4{ÝÀ‰fƒCyÁáP²=”ŽG&€á(Å%qÒ?Ùcé!ƃ[Øèåcñ eÆ1Ó + 4ñUu„,ë#„´3¿"r,ùÞ ÝáÕ<Ø훹PÁ§’²<’°¥éÝÞžná–¬<'Ž¦®Cœ€òÑT? µuÓ¹ŽYLœÂ&ìã9R¡0HÃ>ž [»¸\w¤¨hó{ƒûGÜ*«ÝãjöÄØÁø §Ïò”áÆ,—jzЖ€{Öy究X ž# ”àf´Ôî –ŸæPPœÈìçVeK_ ß¸Ãß—õ“8g)Kd"gCÿù6—DçWY’ý™8÷å€1ôò˜%:Nžùˆ$ ö±T®¼9>hüÞ¿Ü_••ë½.÷ô~wîãR ¾Uƒ§V­¡ Uï©ïDf´µ7 +Ô ¡4^yÙ•£#öG€XÛ{²£4uyõŠ‚KE=ú¤µCcÀÔn[óñà¿QÀЭ±_w g>ȧï#Xtþsƒ»š°ÉxõGi£?‚}ÔiMu7~ ^WyÛú:º0;\³öO…ôÎ'@çÓ(ÓËo­vkÆŸmú}·¹ض{9>‰k(Úej9-üõðµ¶ßÕº:¦cDZ ¦ŽÏVásd#>#ȨÄ÷bB -¤´¸~õËo¯/§Jì-ø(‰ôU"Á'$@A/Ó~î°13J ™e±G‚MúèL8è¿ôøqäÏûÁ»ÇºË?ÿ8±/‰O¤ÉdÎIÓ'JKF¯ ¡-Žž.ž,‹cï'¤ȯlÄÐn‹69qS‚bé}8÷±ÎKŠŠ§ÐˆÏ¼/}ó—ôc€‹S&µŽ¦_û×C¿+{éì꿹Olþ?8¥àÑendstream +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‘öâT1rÝ›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ÿ0;5*lïçu6‡üs¶®mƒS8Õ¹þVûíÙèÏáõû«»¸¹f¤´S%jkÒf<=“Ï–éHÔX­™ƒÐ8ŠAPê|<¹¸úýÒ÷e¾7ó*ÿlº­šq¦Ý>m«ìËÏûJÍ4”¿eŒ›¶k †K Ë\Ug`;}˜9÷ø±C”†X;†bŸßSt?“š%èibûD6w‰ƒhÚ§„Ê昢­hæ,Q’×òl> ÉY¨DÜŠ) Lå,;ýÅÜ”%­Pzy·6ÑÂ!TµRÉ«\Æ“=2·ƒM/ØÚ¦ü~<â0®nçëòl-ltèe—³Ê/æNø®€Oðò£`¼ì @¨„üæ1…à@™6! Ä7‰.œP±D§ÏnœÊGv­lF.÷¸ö˜W«Î‹NQÖHõZDƒ¼Nv—™›(8˜Ÿˆ.ð|ÌKsÄTK¼|#ðN?Vß«“7þ63‡ùq ÕLø ( TâOÆÒ®ÊGJ[JÚ•ºFÚÕ(@Ïg³w\Ö#G9 9¤$™0ùD³«Ìí·ÛçP‘œ|Ú7gqüm¼içàR>®ŠíÜ´ÄBDÁý‘@ØŽ¨f ­2çÌ;cÜ…èKöµ:Uó”)®õ« +U.XšÂytªÁ©dBDé×eÑw!Èr¤ÿ¢-êX÷+!TDÇzVöjóáfPpñÙœKšA§#Åmt†LCè¼{×fð¿N*xÆ€J'L¤2Á­{=ÄÍ4•ÄÔ ­­G؉7ãè]`Q¯a”j_'5Mj4¾”Ò@`átܳqU¼¼šVÇÐŽ\`ß¾®³Òâ¾}2Ë}y1úR™m xò3¾Á4 +Ãów£Éh:D—ÎFÿ\F´v9 æê÷Pú+¾q6ëUÙUo –„âµÉÑa¿{äxì@è“iM¯°èðòrʆÓ÷èÌ¡—ç7`/½ru¼ÈA³å„` ¹ÃΧ9w‚3÷Æ  arK#=Ž×¯cmQ¼[1‘ç'/nç,|éÍOÿÀ›ypê‚.£ø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¦*ÇET@€!@Ëò¯ßîé¤@ÉíV*ÒÁLÏt÷ׯ!1øç#«c&S5JRkÆõh±¾`£{øöî‚û9“0iÒŸõãì⇷FŒÒ85ÂŒfË/3kùh–ŠÞüõú×Ùôn<šE&O´aÑ7·?ÑHJ7nßÞ¼ûûÝõ8QÑìæÃ- ßMßN醴o¦ã —J ` =‹~¸Ò¤·7ï§ãϳŸ/¦³ý‘ûbq&ñ¼ÿ¹øô™rîç ËÔêѼ°˜§©­/”–±VR†‘êâãÅßö {_ÝÒ!5)!c#´M¤Š­ß±­Leœ°ädÛÿnU8 ƒh8ÖçO@ëðòdXqÌj¹ŠS ñA¼Ä»7¾êŸ K)õ(Ñ<F&ÎúÛ¬¾/Ð80[öf'ÈTã&8k¶*[°¥±Ñ"«‰˜ôljG$Q³¤î¡!bÙl×í_Æ kµ]¶í&m×lüª-=ã?´]±èH#£›Àjå7ùcbÛvxNÔçx8ᎆ»À*.#<">wm‘#¥p}McÈüxV[tDt =9▱躪h¢µpÆ+ E‘8šÕ~“ëõ®õ<çÅñQÉÓ6M[vå—">uÍ,X\µoÁסñ'ÁÇáZÇŠ'âwðÜ/9 5ml,Uj^‚׸ YªZê —ÆQO!— +`iS¹¼hÛr^ ¹´‡ÍC]l‰¬³uDSéä0k;æ6*ÚfçˆÅÑè¢qÏÀG€Óˆ4}æØ­FÀ=gQ»›wÛlѵô*={H‡7ou0Œ…X!NM´Øm £5ø‰HEhôf¢Í0ÛÒ8•\©tWùYKã½æÅ¢\gaüvsèõ劆7Yž;?zïs8­Yù¦>lD„„>ט@¾de•Í«‚>…ü€´+3‘ì%6?œP£³k6äÐ}@¬—XÅ@§”„È løql1ç˜CeÆq´à­c-SÞãMü\i‰{¬Š¯ˆR’â±Â&ï(%‘ˆJ;…€ +LìñùuÐïŠþ˜Û!5ñز½$ÿÌ,{wwÕ=i·ÙàÌ(Z”Y( xäp¦HËŒ@/‡ðï®X8MÀþ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Œ _$á>¾Ó•£²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Ú3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +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ëò­•G˜n—u´þ¨zšÊ³ŠˆVš¥¾6˜ÕšˆªÈï«loŽÚ¨†ø6}×eè[Cՠ“{sÎÒ0úâYYªƒ[©®ØÏÕ‚ÏÇ^ sêV½ùagv“ÏáÖýé Ãg| ¨V6¸;ôM"~(ºê;Sö¤”/wæaäÆ.P¹ªPÚ-,¥ ]Ä%j×o%QCÜxsµ¡ïÛ?è; +7Ù2{:©”û-Èè‡þ¼h雑­Âhd+‘2-ÈV[¥ÖfÏZfS®ÂY’ÆÖÑȬ£ ´hÉSŠ\BÔ2åãÔ¢Å1ŠGš˜£(œ9ª- ¦‰öE§}/7û—›5½z$·ƒ€áQpj0#&]Rh5]aaRØB–ƈ5©ûAVM´µ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Ú‹´ìd6uH–[ùì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‰ÛÔɼ£[ùYƒK­4'£†.[_@õÛŽ^¼½yýa=ÿÝTóÞ+¶u]?­jé`(EzçãFTƒ ІŸcöúnx5‚{°(ððŒ™ˆ#N/KZ½w,õÛè•i7¸£ú‘yRm/puLtõsòâú´^²gÙXÖ·¹l:¦š-Ð˺_-ÍÔÒ^wyýÞ]¸!–Ž4Eݱ5=1Ç7 DÄ’0ž*B‹ù×ìÓÏYÃßÍ<æ§Iè`à1ÀÎ~&àY$v\Îng/>à¹GÀË{ãÅ’ú2Ä÷Z«KáÀŽqœò‘pïùçüÀûž#á?Ÿg_üð÷ƒ©Ó,‹{ä¡ŸÆÞç{ ‘ÆH¿Ûù…OÙ".ûí¨BLendstream +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<> +>> 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<> +>> 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ŽThcýîGþûŸVë0ò—Ÿ?<þ‡FOŸVQ´ü×ç'ÀV°AÂåÞþ¼y`ÜÄ[4üåwp IÝÖï?zÜüJ³ï?~xz|÷ðéí*‘ËÍ#ÌðFw›A¦c¹¾@þy÷Ûþ"ñÿtç{"UÑâß Ò4\îd$¼H +á åÝÓÝ/ÁѪÝ:ûŽB±Ü>¤ ô„„ÅñKF©ª$t/¹Z¾ï/³}S×±ª«œ­éú‚Ç(ß纹–okšÓ´V¶ö…¤½¿X‡Ê‹“TØã>V¸)¶nûš[úë¶-¶¥¡YWÓ·Y©eϔܣÁ†hºFõ)ž’0&U^WZ¿&Ÿ¹´í‹dÀȦz)½:˜Š/ˆÂàc…ŒC°€(¸G ê+Ò˜B¬. +õí™…s4Yñ|.ª `Ï’ø= %³™Œè)åEñ`ZënæÈ ðÒ(r(ŽÎb-%î-r¸\»¢®ÐÍ=€r±ž C@v`HÄl—|–…pj «a•µ°9kÅ°TäÜ €%Ë"À8Ê2Y>‡‹s‘ó@˜®øp®JFøPÌ7EgÐyùÑòCÝQ幈ÿ©›¤t' %íð—„Ê4Må×-„šu¢hL½¥ïD­CAµ%À5ã]Õ–i/®7L©¡`j0ªlÊ´¶†iQ y©é õB>…¯‡M$Ú®)²ÎU9à;a)˜JêX7];íoŒ¬þ¶ÃA„±xäöÆuû|€ô½0Š=‹`¿òî ò-2î sÝñ1O®íóÕ¶à[6)Ûº©©›C‰rG'=ÓÇñ³Î@ÓW˜'pŸi_÷eNã-#‘¨Êó¨E„ ®#ˆËÜjœ\œa¢2îO%—{Õ%&×’““©àtR.óšç{JbA¬h«[J>™T*]+–?@ç9¿:o¢\W8L¹Ü×”­:õøUŽæc4’Ö"æoù’e1 ²Z¿rôL §ô‹˜Ž*¶0‚‚`ð5Ð9üE@êͪW¬¢•'“ÔuH•êÓš_z¶.P*vNþonã©K³R€O¡f%‚¦Û×9_ƒa¡nºŽ @ 6færG‹ÝÖ„â¦'º2 ñ=C¶xå«x_?Ø„Z~~‡¢¨[³/”'©áZF·…MaüL•øÎ*«bù¶lkwÝ WÕŽÄóäò =áôÒ†±ò¥^˜âVók/#Rt‘C,þÊˬô™zýWìªTšÐea0•,¬Šã}ÚR¿0êà»ÂK cD­3 íІ'J©9ñQ< +Nˆû„.W:hÈ›9­Ï¨±È<‹ÅÀi?€u×áÛæ´¸eh;dà‘³q€^Tƒ}}äì–ë74v¬Â:‡Žx¤%úùd†sÃûmТkç&'&à³Nù׆u”îg’ËË¡þ¥¾<Ž~'°ñ‡k¼UÝó„óLŸý½måøV}Z[œ'ìpt ~ý[ô !ÿ§žÉÎÆ€»¨Ã,Q²]Кl™zÖœ]½kôqïê;\Ö=Ü Â’¯3LhËgŒ®æ]&ª` ù+Ô$­ÎØ0blù瑱UÜ&o›§Ç¸ Žh²xX,¬ÊƯe@A{òò‹××}j f>,ãb*Ž±‚ 6öÑ…à~ûbÎ4¨VØi^Ë%]3rú]+xËPN•nF· k—ëBŒÂŒÏAŠ1¦åßÞ– p ÆâÅÀý‚ p•Ø “˜HͤÙ2õüX¸ +‹Ä´>Öe‘çËÆ(ñµ´¬!ð`k†æqîÿLÅPýO['OõÁ8 èèá±[×-ƒ­åÀ÷‹1GZÕÖþÄ~Œ]èâ9¡½ûðÄhºÓ4²a8¦_ºðÄ~ u±.X©˜åÜ@BK~ /À*Çøë9—ÁD„â¤>µGìfuC¤`†ÁÚ#Ká ˜˜/¹§~×Ø;®K/yÙK£¬®:8Î!ÉD)Ð6æÏî© Q”¶ ×;€Õ6qÅÐÛ»bðØoK—ãžÌöêgr`¿œüî”ÍýâT ¿¬£òã¼¹åÍú‚ë½ö'ø˱sàmÿûÏ.#"!ÝW*¼üeÁ´žVžT@„/e˃ðææîïn¯þ?ºgendstream +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,‰ŸAn^„^¯Ç]£†£Ö¦î“˜ˆý(NCK#?K²“ûâa+‚ ðžtÛêŽ þÔkPÓ³áIâDà|&r§`Rñl>{Ho %6\tÿ +ÞüžŽú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$—–å¶ÔûoFY3Ÿ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É €ÉáÔÕp1ß”dRå¸`²ª˜©Þó¯!éKÝ4„ÁÉŒÓ!¶Óám²Ü­µ¨é‘!ÈÈür¶Œžš4ÈÙ5 ê¦"ÀÕ,Â|˜,ö0+E +fqd"‰½ +pTÀ4 pјéß©ù^5+“³K™›-“ç9Ì©ª.±ð?]”00%ýüf»¡£àÒh½S}žÔQ|gÖd +Ç '\ÞÝ0 ™YhíŸ#:GqÚNªçÉ5…q¸ŽíÿOºùEºX€BÁÝ Ðe[f€¡ßt¢Èª"B(â,Σ4Έð1H‚ðc(‚Hl<ˆ[Šs¿Ûñ¹KFËꆓ»L¸mB`†^™8Ì{2Øø!ƒ:¬…›j»Ňˆû?vC*ò:u! ›hž)Ñû"¢ÙhÙÜUeXó‘ŧš[˜ã} 7=é";FÕæšy§ØÅa2ec¶:¯éçî<Ⱥûß™ˆ™¿•Û¼ŸnöòoWéwª9}ùûÛÊ‹»ž;h°Ž"”yôÞ\®æò“îÝ›zlé‹êù×^!{äÞóTÏm‡Û›¢b =¬Xjâ¥+a<@)_Ý|ë’Yå¼°‹_t_ƒ¯Ÿ|¿fzRïýwO?!”ð,pöÃ^û îÉ–£-¿¶+ðòjÓÚÃ"aòæí βnäw‡q¶•, ¤ºîÊf¬Ô°¢Oµr“SÅ¡ÑF r÷ì¡—í€åCÔ‡®Æe¹¤RöªJ=RÌàÑΑY¸KG¡¸`z¨D嬓ñ‘Í$éØ¥K¿©Êi«á亯Í!È ìcãvƒ_ï{Þ¨ +­Ýv?v•ÕšÁ>¦ð­ÎÌspÿ +/o“¥9”,‰Ãà«qP¢ßÐý'À_U$ò‘¦Á€aJ"۟˹–G¨“,_å¹kÈëÊq©‰+b~êÝë>ì)-=ÙH!Àï:Ê®ƒÔ•®æe÷tÔD¥©í‹Ú!ßñ%ÊëÙ°‚f`þk¯\Šm­àlS]¿Ù6aáÝÜXîkFõ…œ‰­ºq°×vJ‰„¶wÍ›¤Ü¼Éä¹]g2|[7²4DÂWÓ?ƒ&Ÿ¶Uþ6"ÄbŽ*?IÒ œAþˆ,ïþò2}Ò‰âiœoDúY’Óg¢¾nôýü hØ.$ì $[ؽӋÖ[F±pûpëÌt¿yqíÏÍg¨‰é·«³ßéBþ´2ì\…(8F.ðçz¨9Ð|¥¶i0µÛ(Ï}‘‰øº¶/jÇËõÝ*W²’$~’‰OåDÄp‡%aàçAøûI™$¶K‘û¬Ük¶‹…1§//—‹ÏYytmùÈÕ÷xW7iu†7>Þ$jâº÷ë*÷Úþ[ªðÃ"…Îm’Ôí’Û°å—7ÿÖi÷U2J|üƹæ±cÙÎ<ôysé\C~™S„®dÑ­µécé½¹ÿq ‹endstream +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<> +>> 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<> +>> 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Ú3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +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úÍJódª¦%G¡%X°”´7Ý7¡®Ÿ,¡ÆC€]‹(¸E'@4™qBÐg3:Q’Ïí{Só„Í òU·32µ‚G›ò¨ßéžGû¦´hž–½Mg!ÒPò8Ƀ²)â¯w !G¡ÅÁ­Û*Œv϶ožÌ˜~^ûÎF;ÜP-aŸš¿´1PC¬ûeŽâ™ +T“¥‡RD¡J@ʼnJ([øG†¼›­šº0-JŠ0R >èÂV¶·Æ!›¬ ØüÅòéÛ)Õ¿ØL-d³ë}[™7T*•EdÝš‚ôË™ƒS"ŽfDúƒ!rd÷±€4¬ ºðšØKÇ ¡…§œeg‹dçªz•¯í ÁSTl[cÊÂPßT¸äÊôÀI+£$ݹž'£épRúL ãš31ŒœéžàèYPvYÆI-#6¹Þ@H ðÔ×Sñé”|ZÍ8yeÁæÀß;=Ðaóà¦)¾éÖô×u Ã1á“c´2¡ ¼_1à³]Ó:ÐöºØÙÚ8¦«01$(ºR_=ðµ¶plgûƒ¬þÈëfšNö\éÊ‚tµÕ¿‰¬×5Ì÷£XÀPØÙ”¥M]$Éx\oû¡#bZþº^Í®×לd‘FR¬wÍdœˆAð( Œõ›8Ä­ÏY¼ô©8Xd;nËÍn¯W¸Ñœ).ø3z8ÀÄ(w«ˆ”õƒG^ÅoOCà—¦ûf*sà™¯!<㪣1V©™HCìKXi5¸ÆÖÈÒäe½ '®id¤éœ*Z’—hÊ‹¶œû†i2²3~· ÖN—eI¸~();ÒL÷ü•.^øËé:G9e\¼PH uÉÂfÐm;] éãXùOvÌ‚¯kþ^™Iÿz4µC‡ +Á¢å“oC +!mg8iP¦üoð?SP­ (®ÐDŽñ04È•ï!¼¿Àzÿ:"èòà윓BiòàK}%õ;QóVöLæù\ñð¤@ =`ò@= |ÞÙHTö>«­š};ˆcgÒ=JD¾:/ ?MÎ1 Wëûlc6K&…'Å~LÅà«Ã¶ò™ŽRé:¦Ø«¥¬$MÛ@mm†*6×üV–vOô…¼°*tš·"Àõw»Ç{WUYÂÆXçú]S•Œ¾Óôªó¦Ü û‡² áxÚ/zQS¯‚à/XÂË+^t‚ø¤ñ¦! ÔŒ‘BñW¨ÔÂwÕöwólÝdÑ\í:|æjý³Öt´êq7lMõöUÜQÂt¿ˆ6¹á´“AHJñ3’³À\Ý\3¾G!Ž + FÏæé{*úú§3/Å‘÷‚Ÿ¨Ï(ˆòÞpà® Ûjáò­Ìô­¢‡ÂþNŠ<´û½¿O3¹:M30;V¤¶G(F4µÔó’ç;ýd˜hc(„&EÄ ”m}'*C87,08Þ p¶~Ñ< êù;ßîz;`þ3ó3 Jáê8´„zo ¿O¤cý(ÉxxŸZ¯Håxåa£ÉÐ:\¸hf£öQÑ©2aIm6¼ô'¼*&k³wLó Oݧ¯3øÉîÉ~> 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š¾©Ö'GBqwüL×L#°$xE›VŽà‡3Yâ^|¨¡AiОŸª´r8ÕŽãa¤Y8º«ç¨‚›‰·|¡PÐ.Û3æMaǬݗaB­µ±0_ã?1ùxìü-Ä&\…‚“1n•8^uû„ab8î¶Ä´\úMÜ´ïE’˜T_5’!„wZÅ¢A’ó’& ¸db‚+ÑîÿëŽ4bן¿ +ã!t½™æٌʓC#†åªÌË»­ QüXK³·8çQ®I;ªß>ZDa ¸–ƒ® _ ˆ +'¾né(ÐfÊD̃Ð(¨0pj:ú<ÆY>WÒh‡^¢¨;ñÛ½ößaóë…<œ‘‘Þ¥Œ¡ÆzA(¤zK½ÓþŸý ì•-'½R¾Ž5ÉaÞìö^ôÿð®B@¯a +®( +Çý Ú³‹šý€«“À>DÎ*4f·gðz…}ÆäAnbù'èj¸oI BìÃ8øÛϹt²0ˆ"ñ±Ø=ëψ4¼LpÝê=@i¼8D˜"†5‰¿á*Æ1¶l·k û±½}2Æý峋¬‚Ð\› ípñe‚!„"RTÊHÌ9Ä/C¥ “!÷â†8V fît}LïS#w¢h¼ý??'öÁ×åìë…Oó€+¾Ÿ†p^º›¨ É Ìn`»I«t}o/ûtop…M½é^k6Uº¬o +K°"¥z¬‚tŠÆz1k†QÙUúX¿‘™u˜úzÍ,Œ7 W‹ (Š°ëG÷: v ½v¶¾^ìÖòè„Ù‘¡€òòjrvs~ÛñÉY ¢â²5À—"Ÿ½pµœ¼ZŸÇü¾››8€p¿„¨\òÏŒbÆ@®^Žb¤Á#Óe›'”÷|š3@'â.~l®b‘?Ä9oîbÏ#Ú´.CŸÜ³É˜µ¢Tè}6·G1´L·ôKy*ØB›UEÙÙ4Y>›´¦–Òý^Ž¯¹06qi3nŽ(†.éz·È·ôn€³rí2H«C྘;¾lV·åBb2[íÀcwˆne?1W¤õC¹þ´+1¨p‡8ªtF›ôL¹\æòsØÐKnaÃ:)î0 'ŒÜ§¥à†«<Èté¯)' á:®»ÊÁY¤4p¶-7Ô>KÏÕfJ9mË·ŸV­`‹¢˜.76ãÞ•«J–”Q DC„ª^bÉhGsäT§E5i–Þc& +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”›|N­NDì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áòÐ a€èH[óÆMDbúÊÑ ³jV?RCtä&/’{×›³|C±"´'»\ãáomн­bi…»ÝÒ1 °âÒÚ_è7ÎË 9o-ƒšñDý÷ÑÑ_(nÄ4:lÉnÊHøMAÒÓv‚ÖUYUÎ!AÁA= hëØ‘Iê]"ͼƒEÝÔÞs.yÑôNÛ¤ÅÜû£|ëK³´ïü¬ÞÙÐ|(Ò~‹¼(5ûOvÜg"@¶¬¼['«Å¶õ< [ãÍBáY¹¡=ÕùtäÙç(p¥ÑÊ4ùÏQnRð8þÉ·ÉÔœ”KmIí,Sö¾áÀš»„Ô%Ø µT°ÙwxgÎNé ‰MKãôjüŽÈ¶GËTµ°§~Ïáx€£«¦ÑîC€§Ï’a Vˆs(´a­‘m©R L¨l5ø…]·À'öœªEYÛ¯ Bév‰W'ÔX?ã¦ãfªÒüÞ“k¥ƒÊÜfq +T§Ûý²°ÌP;+î ¢Lië`4kóIõ‰ºÏ)œ¹¹(ãåÙäÜÉÈŒ;Ó™Wg/Ò‡†qÝ­]¸[ãªK|A¡•%‡îrYvWJp¬7À@g +~ÏI‹ƒ|ò¬p÷YB…ó >,s5Ä +nëÕÑû÷(wUYÎ7ï³bdUó?®°ö—…Î5“É ÷oj;6…ÿƒÆõc½ëÅ(YûTÕ˳0Z¢0pá£|õ~øÒÝ4Š›0êÌ°)‰°+À3º¸zEþo9$Þgå®oðØàÕl×ç~ñ×¾úÁÕQê}™Â& ã˜BIâèçþÓÀç¬ÿ”÷xendstream +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<> +>> 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<> +>> 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ü¶W/qØšï—Q@†Ñ7õ^!WÛ° ò}‡«åþ£ s|än9ü} [ 'ÑoœcÔp’ó™ÅvEqü»XÄ`ìŠ<Æ 21Fc¤¸¾~}}EqT<¡4{¾Îž6ç¾!êaÊÜåÈãwû’–›b¾t6[Ÿ/qÄ]_[)2À.¢.äcðJˆ/¾<ÔõJÙUôeQ²‰òú%ýÉO0ߘr„}ˆ6!¼.ÂdfÛ¼/%xbjì{¶3¥Ên|ÊÙ\BóWpHÈ5îïggEÁvÕ•Ô¹næ™gà’ ÞP>KaœÈ¼¸ `*™> á²5MÁ€ÇBõƒdã6ÜÄû¸ˆ+Û6¢Ÿ;ˆyÜW˜ýM¾ò0Â$¢É²ï>Ý|Q‘Ź’Z¦/‘ eñ^ÂQ/"àÉœùô"†”-e Â,ˆØTˆ´u÷ b*¿ˆÈâpÜG‡()Â"N“.ëc´‰s²‘£]‰àgUjj‚#þ9 Ç»@L) DZJCp[ÌØ4µU÷ d꾇ò ˜Dz*âä¹…AY'DÄrýžÑ¡+XP 7šxL•õ ,¿}ŽTÿ‡09…Ù{ezuå¶1!. +|·™â²ô˜æ‘ö”K AžÀܽðL©~ì*©*¼‚À^VÕ5xgº»Ák(_$YõËR8þ'Md# “üI;¸Fp¶\wÁçb„=ßmÂw¯àû¼+BÕ59=ŸòBx½1ÃD/ØݲØ]Kv÷,v·©6ìÞÖÝcwSùD&ÚìÂ$Îòñ)UF~(AIÇBç˜ÂLceŸàuM´¦0×sg "„« Ö$ÇØ0~‹£¿Œä‡µãcHYðÑR‚© ›jŸ¶î|Lå³÷$<Äà´~9nÃBTêù¥ÿ‹NI¡¡Óšh‹ +%Åú0=Ž±WcA^c!f1±ƒkÕÿ¸Kyš¨Þ_ËØTC«èû®€实±Ì¿bè’L·RÜ`º7é)ÙjÌ™Nåys9ìËî‡Üªº†üLw7ä åÓ}˜A¦ˆF‘¶«ä½ä˜yàQ°çh„Ý +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œðÖ–o­ÐVE¶å zòÓ)†²®Iì,Ú4¶~ëÍÔ¥( —h’)eAHKUöb„lª „Úº{2•kîãGq—`Í}Ê^È)§,.Þåˆd.¾ƒ¸Ï fäz´ èòUhˆYHQ9âê°•zJ¤Dcªä?†§§C˜¨YôFQ2!­¨‘¬…–bŠ\ £à3¤,ði)ƒår |6Õ|mÝ=ð™ÊKpÔ¡o{‡.á4öêRBóâ2G•¼¸“ãbä’€5#l¦bH!Ù}»8èù~"˜xðÔú¹ØéP\D^•äw9ý·ôT´(Dë©Ç@Q_8^3¥ú= ’ªR,³¯YU×p¦»ÛÊaʈkD©xR»Ïo{ºè(ƒËQLôLÓLz"¢ï—Äa\ì̧m´W³Ï¢ã>}×ï—(”KHŸŠWu:|Šz qêC, Ã¹ÚÜT£¾ _ä‚uÕþ¼)R3_ÓÞ€'8s¹—à6¤,pk)nKEµª6ànëîÛT>MIÕ°fh'¨08—¨¦Y.ed!„õéù9‚|°•ý·ñ[÷&°I¾©[Þ]ŠI>ž¡Þ« +²öÉÙ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ÎÐX­TG$'’¸è£[Ž‹<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<> +>> 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<> +>> 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<> +>> 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<> +>> 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Ó‚@™÷_9³÷.³ßQ7Ë›³øO^±þb¶TeÛ]ó/Y^QjtO(íRO7­hN*o®+üK£ÄN¸.5L¸’R^û0áVèágØFÂ;Ø2ïåú"ïå*tdÜ +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¯ŸÀbkàɹ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^> 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˜æ(Ô ¥;Љ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+ ¼$«—ˆDVš’¿B¶I¯0…ìb +UÈÄæpb®(*6yýû¬“ðû<ý‘Õ.ã:?Ø*ÂýAùø´Ïïîk‹‚Hh,À¹²6p‹M>áü€bc}ã”NÞ1̪„b¥\5•ã³È6ëª.Ë¢abF]dúnžåEñÔ02V±Xª5 i㦲~ªª2Í×uVá·üÁ¶Æ¿°+hMýßÿ׳Óxˆ™Rô²ÓH¬¨îHÊÎê—ÌÛñ5õ?Zo¢endstream +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ç…C­fL9g0ЇÉ]Á¢#°5@ ðòxDDD0rp'/gˆ­+€ù‘ƒ…ý_–ß.+¯ ‘.[€ññà …;9‚a®ÿã@=0àjØ@ `€œ–¶‰Š¦€YIÓ †P€¶›¨C@`˜ ˜`w@ÿ:@p˜5ä÷Õ\8¹d\@€‹y {‚ÀN¿!v€ØÙââòø €¸l0×ǸÂêfý[À£ÝþG“3üÑÃñ{$Ó†»¸º€œ!N®€Ç¬ÚòŠétµºþÎíy„p›GOk8Èí÷•þ`4¨+s¸‚=]粬!.NP ×cîG2'gÈn.˜í¿°œÁ¶@gk(ØÅå‘æ‘ûwuþuOÀ¹=ÐÉ êõ'þÇëŸ ®.`¨ '&ïcNëcn[ “ë÷¨¨Àlàî¿ìÖnNÿÀÜÁÎ +Äü{fXE­á0¨ÀlƒÉ¥ w}L `þŸu™ó?×äÿ@‹ÿ# þ´÷×Ü¿÷è¿,ñÿvŸÿN­è…jÁ‚ÿxcê€ßÌs:B ^ÿÎýïžFà¿4þ;Wàc!d`¶Íàáäæù €¸(B<ÁÖÚWÀ}¬Ô»Ìì …ÀÀýSL7÷ß0};Èö»ôA`˜õßå?6éx.=me#¶ÿöªrèA§Ë‚GPè¯íÇ9pÕ÷rþo:# ¸õ?¿ùdeáž^7Ïãú=*áðû7¹ÿñüë¬tu†x^psr?Fr~ÿsÿÎýOÀìo4 +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öè=”Žòíí`õ§ï3t;k‡–Bf?õ[¼„Y®¤¾ša£„+gl’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æЖ(¾+ÐMoûÁ|°>›à¦± 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˜¿\扯â ÈÛ.|âùúÁèéᙪ9 x°¶`÷V¶v™öÉÝçñ–%®¨eßùbU€|;0}õd¯ºGŠŸ¡*ºS{…Oi,ÚŸ‹í–0M¾U_jL¬@qª?Ôªuo›`ö@è­Åû-€›-0Múp_ðà*Kþ*š´ll´8ðc©ïÑJ+cCôcr÷®4$G¡ŒÕ<;i¨Wi Ùªµ‡ý^gµ£¾ÕN!Î*{¶£ô…ÆW5'xs ^ÅÍ&o`Cð¸OïŠPÑ©4e¼BÃ9jÝ’N7t’2_M´Ô¢äÔ¸/\ä_‰¢{\”ñw“Ï‘qú\®û7«X­”ƒÞAÁ¥}Æ +¸È÷»Œq„z`²\F棖ûEœ!~õT¦¾\Ž'4/ýCîe– 7,î9tãÒ¾Â1 ¦’·IM^y/¢˜kIm;˜¨½}O«•oÐHâ•¡Ç6—]í7ôh`† J­TÂcweófœkÔ­—ÕRÐÓ(9%Ö¯c +Ó·_Ü€¡èüêr_7ýGmÔ&œÐ‰lÞÆŽ +Kê#TðÖ†§øñÞ ¿šûDE&ñžËœ^QH¶!’Þ»¸>àáÉà̹ç$ÚxþF`Š×Í4IŽ@N@ÒÖ>_9²J¾ÃEúOêá˜/kIÉu~~¦r–æw0§øF¼Öë!ÅÞÍ<-Ñ:yLj]óC&üwÏö䟃!•“®²h!¶‘6òÕÝýOÒÑéÃVwc1Ì{õX/MHÕ¼“øÍT(¯m­)5~Þ÷ú?É6nðýYº³`æj¶]`.Ò’·Ã‹imzdëøjXJ[”˜OX8wâê^ÞÔGÓö†^& ÌèWZGÅï] ðÍ}Ù ¦L5«ûrkÎw¯C3íñTS‡n‡a†’Í|­ïDÔR”ˆŸÆþÚgòý·¯0,‚…þ«dñ6›ô@‡Úò ‹6~ƒ +uÿ'¢µ?s_¯Ð‡öÿŠ˜'u +BêH—‚?ý +$OíœàÅ€DÈåìصö„÷¥½O%©4žñ­¢¯‘ÔðQ±¡8M”¬|â ãhƒÂ!ãëaž!ÉÇ86e}YÐ7IÏWë]¶Ž`…ÏÜ&ÂcD×rZ‹î”…µöíòj—«§ÐŒô6ZÑóÉÎõ»§ ÉDdßÆçxãT  4ã¥éÐ|ùw%h± V–¾tf°‹ðÃ/ùäanЇhµ•]ªU•²ÆfÑhª¥Hm9Ôaêëô¦É’T›À…á/‰¡øOõ£èî.êš;{?W›¥~#ÂÝGÂÚM†ÑÐuEh 7m[E†lûÌì’ãÍcT±ˆU,ͧ˜¤÷Ö„½wú°aV.¯4žg®r ¯R«©*˜"‚¶±ºž¾<«0ÛÍÊõòÂh„Û‚†½z«Ã÷îîÛ²±žˆ©Ë_>)FMÁ¿EIÕú®´ËRÉs¡bÌo™ç-:ƒÒìXÖS¢ªÈœ‡(2³Ü{Y¥1³$Ê&?ÎIX>µWÑЃšÍçnPÊÉLÇ@¼¦‡2—­eýS¬+‹†^WD£gu¦í÷ùBü]8¸ïOÔ5mVl³Õé”VË(¼ÛmN^nml ÷’ s ÊõÙ±…- ™x³àiΛ*µ a1ןáu«+@Nñsâ),#Gu-/JÕ¥[òmš¬»º_ä>TÂåg?âD"gCó5®™,ý’ «gº%q\Éw&áÙ¤Û‡ø=rM±‰©þAÓǯ{Êò¾fņWÛ²%§›s¶J¡üêí;7¥ÒÂ"¡äÉU’wlQ-OfÌÚSá\Ð*¡BI:àà¬e’,Ï—¨xF)f‘ý\0l±÷„½Ý…ÇvãûÁ‚„@>:ûY´ÈÃ÷µ[e|&.$UÎ;M“íj¹ª_¸=*Þ äSó«—M¾¾rµøds‚ïP‚Ò*’÷Öåß `2¬„ šêÁT^£„J’¢¶¦ž¦Ÿ+õ¦ÐÛc8ÎÍ(¢•ÉÆOûX™rZu"Â&U =oöE±êPy*2ßî"VåÖTú•¼Ðc&úø¼-ÿ{ÄAÊ+jV•f³þ¥œÃš°8ãö©Ÿ· \b,>ÆÜ—(hwÌ©¹û†}ÞwW#3?¸šn/fƒ´ÛÇœ¥Ÿ— ˆ¯¼ø–HÕ‹ ÷S+AL—£vÊÑQ†¿«l0v^£žÁJIL”½}ÓÎß>ÏØ&é(üôãIßv0Ûu îò'+¢gôô÷Fvˆû§BôYO ­g©qq¯Ë+ä(ÖGb›‚±›Ì¿xê!±ùÒ‹§G +>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ˆ^ñ*£–—qº'À°´TÈ8‰ÂWÏõ—„ãŽly&V¬AÕ²Kò^ˆâ½þÅY;/Vwúí}<÷Gc…R“#]›gùDÏ råV¥k¿½p¾Õ¼¥}ÃvGšAÐg•†7PöŠ²S +ÃÐÙ²¶©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“ׯøŠ‰§j_dI*¡ +»]‚ÄÙª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Â70¡ðW~—ÛC!_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë±‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~ÜFY­Yy³]ˆ:¬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÷åû È"QÔüFØs(úF$'‘qL ®/¶!õÔ ¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ° gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd +ÞyŠGÝ ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’ ¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?ÒK áéá@F)Ø,êw÷ó?È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý @¥-«ä%Å~jÉwXjz1îi´·î¬%uÕ3^¿±g¸`d+ÎK[ŽDe—„]âò†YèÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š” ™v_Å [ªJÖ®²9m=·âú?\‹k>¼à¬‡¤*³Ñ³ž,Y ê<‹ý¹uÓ Z/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_ï‚¿œ%%½¥åŒìé|°D>W²7}C–Í#—ZR¸­$º`bÛGο…a¿9gÝS%\”Á/œîñhC|?s§ Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O +üõí+uqfº`Îa‡„°£â,I§ã¯½/‘˜÷ÇÝ›Á¤'P6ߢH‚Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)wL=(‚Œ£± L|)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í; ¯åä²fùOî{&*‰äyÒ¯9ÛB±T¨d>è.òY[a-³ZyÏ•px9ÝØÜ>穾„»*|,4°ç Žð=Ï añŽ©{ZwLVqžCÅo, H;ç_7Gg[åGx d½DŽ…*~ÂJSÛ/ *ûÎÔF‹µëújQ‹jw Ý]_-Òq;Œ,1t³õ2ߥÆíËòê{:Ö§Ùo$<×ð¬žôôJ©Àëóüλì„b›F=ÍçåcT”u;ÐuË›÷#³»Z1q“ÒYÖgHŠ^fiyv|‰¢,PkŠA±¢FH£s^…EËRôƇnQWEÛt%Ú·y3™{æÈŒõFbKã<%Æ)â"-L+{墒zS'“#é²ÊòZÃ+•÷U­Á׎#Ç©ÃCcæHŸ,êä;÷=íÏô .óYäg:¯jÔn¹¶Æô×êS:c¤¬UºW¹Þ/Ëf¹ŠšcO¥ÛøŒM¯lD‰Á¦9²ú:­ÈùÈßÛ˜ìÑËr6½õx§ç±2ú]úS¹‘ p7O¼,j1îöÐËÚ{ž$ªS7O–xYŽróæs÷â»ì(è˜Ýš‹ÏD‚@§­Y#žC²L%¯íáž›1A•Ã¸©3¾~M+ÖAîDí>¤¶¯cãµã-Nˆ¥”ûÚÔß ÄÖtzâ"¹tãØ'>(˜“”hSðÕœM]ˆÎÛ…0ìŽ ñâSPÓKD³—dOj nÌó®|KHtÞ‘Ñ+㢟S'÷@6„iõ“¨C,÷ág3B½žpÖáΡÄêφÖÑn‰Ü;ɦc“ _7T,Q1çTiHøBÕWL8­¡¾  ,œ²£.±ß u2†)¶=–Oš ¹ÿêÚ´­Ùê², Aq¨¿râ^T!1í¢ëç2)áN\§‹¬‚)æÄËR…Ëbž÷ž6Cb5ü´çêÞ›Ô;ð¶¹mH“üÅL¸^Ȭü¤Ý¸Ê {>«m@Ë›ðzéN‹›´×»ÔÌÃBÿ]¬—š@)õp[jÊâá…6붡²BSHQøר.öØ«N÷Ž`ðG¿§zŽ^n)?ìû±«892ÉÿxÈÌÄ÷Ù%¼­Ø3ÕÎZJðô]\ÿ^¸Äé„SXA㣅¸r}[(â0Ò@¥elöÉmi¶ö­EWÕ9úQѲ´ˆC¶Û¯µAñ=°g>MF{Q’= †*Ëk¨+™×Øõµk¤i@ïħÕW:x<›ó"Í}<=<²šC½Q¤4Æð÷i©UµSöA-ÒiMÛk×qnñÔÆèO“¦R<)D¾€÷/ÇT#î¡ÍM© Æ$ÖžåÔ3³Ð¿Á¢\ç{Uª÷Þ<UW=ˆ$®&<ƒªZ€0óØÒgÒR*¹ÉÒO¦1‘'£ùŽŠj*5wË-·‰ûùT j4ÝióÍu``òh߯µ“K…ݻʔÑk‡‡A›”ôÈÔDôìtk¯ö2ÅÛö÷ú—¨§$ÌöZ¥ï@Î^ùÝêõ^E~§”Üúí¨u4߉<*ôŽ±§¸KJßùy/žn•C*}…ÃåLgI£J·8jŽ[“Þ³ ”ØT7%JÈOïä,Á!ØžÈ+ÌÁ¯f—ÉȘs‡h`Úq¢O”1£<ƒ3(©dØOfBOŸ º'"p=Q£B¿âäpJ}ÝØü™ŸZ®¤!p{òëÈa}÷qÑ¥³äƒ£DKXôžòxÇ(žÏÑã ©¨“{ÏçÉšj¿dqX·ã·ŸP¦Üv£ä£Ï€³i¬¾AÕ;³@øyŠ*œoLœOœÕøë…ú¾›ºxOÛÝËc -@YšUʳªø;žBiäMÖð.•\rž;ùU´¾Rø'î…ç)眄š˜ …@ƒi/_ A®ÉéÙêr«0áFx<×Er;¾zÇ´UÏšøSÂö²Ù„.¥mô÷Œhâæ¨É2Ø’ç/{I;õŠjÑm÷¬ +*s"}Y ;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}U¹ôZø: hÁ‚)8f÷EµÔëÛDäµsüð¢ qTMŠ:ù‘ɸX!±l®ûÔ”Ëû ΄,ñº17ýbŸgûŸ&fܽ×Y'jeAt ]ôÛïwV^þ%ÑåµÛR¼”tμ‡Ël¥¿é˜¦j¹„‚øϸ3èm>YjŸÖCƒÕ¸ÄžÄÈÊjbÆn“ªŒUý©?ô‹ïðu«ÈÃWøìý#ë,M€¾ߥJBQlŽ‰âXè-ebtxÃ]€s<—ÿ¢:XÝQ…¸w¶²-N;N¾?Vl¤‘vG‰…,Å%ë9êçöË'bìη9|1.…±!]¹¶DšÏó=RԌݬ¤Iˆg‰=Åh_ìŸ5rÿ/˜ÿŸàÿ  tv…;0ÿAõ¨endstream +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ñ+A6Pu$Ã’èÁmœÑ k„¿2Ü8ňØÙUPPk ‰PµÆ@¥¦P@ + €RRRD줓; +fgp™™róòòýËó;`ãþÈÍI4Ìà¸ùp‘NŽPæâ|…0öP€- ¨è<ÖÒÓpiè™4 (Ê0p¶ÃÀŠ@C¹¶Hþ—#ØïÖÐ7XJh€5íÃnŽAÝÀP§ß!>€åC£o¾04ÀeÀÜ̃À`¸3ä7¿-ò!'ò&Ãñ&vf€DcÐ`Ì ¸©j ªþOŒ½5æwm4ì& @ÚÞdB`çß-ý‰ÝÀÜD1Ö0€ºa~ײ 0´ÜÚý¦ö ˜ +ö‡†3†°û> +jg‚À¡hô Ì öïéü«OÀëÞÚÉ îþç4òOÖ?9À0h(ÜV€(|SŒ¹©mC þ^-„-úËqvúGÌŠú3 ®ß;Ã}C‚DÀݨ-‘ sSÀõ?SYà?'ò@âÿˆÀÿyÿwâþ]£ÿv‰ÿ·÷ùïÐêÎp¸žµãÍüõÀn^4@ðûù¿r­ap÷“ý÷DSè_ ÿˆÆúf J»)„„þrÂÐê07(ĆÛl­á73úã7A@ (8 ½ÑòÏü@1±¿ÅŒíaàçˆßC—ú‚" g~#ÏÞ‚jJ:ZÚ¼MÿdܨŽ1vwº!ö_}è"!ÿ4~c(+#Ýžü@ ¿ˆÄÍeH‰Jyý›z€€ÿ²u­1(˜àÉMÓBÀ?­ÿ×ÿ_–åß`Ô`$ä÷ž€0ÖÈÍjýÓñ; vF¡nýsÛoZþ‡ýgÉ¡P7(˜hf – tHLI”ѾëP}ÒÞ +Äé +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õ¢À|ƒ°²<ë¹]­Aùù{jž[}ùŽù¡ÕMÿ“—hÈì‡x@Ã,ýÊùÛxÛ¤ «?l?G)xGµkiïú.Ï{hæÓ×ïh .—‰&nõ}~ž*Õ•w¸’Ž÷±ÌzH Ã7[àl¸öõÛ‡Õr¥„1TÐ6® ¢~ +œ…›±Ø§Ï«Fc³}m½}ä®V‡6Gr\> "KªYIó½1Ÿ·²Ÿ÷9Qg††1„K¬”(æ33óÞ5±§Kí9uæêMæŶ¯’–÷O÷‘™÷Å㣛RðsZ1ÆŒ^&}ÐùQ íívRæXnúv†e ^êÛ¤J³T×_+'wßsšßÚ&ŽŸjUH§¹ÿ0Ä~QzNÂí#(êyžJéêAB¢]±\ꞚǼû¼Å‰#¢»WwÀnãa`a%th¶0R2Äüýsh{ŒV-ý"þ¬¶ø£1Ffz÷¾î.;M|Jþ­å´òÿ·ÊÆoNz5˜zó£À¤hÝ¢û(fbaUáž©ŒZC5…°ŸXÙžQÀ]ùþ錬˜IÙ‹0b®“øtî"Ý/n9¡21¨AÑ Š<ž…Öš¥•8"•pÂÈ¡–O·Uëõ‹.Ó<–’‡ÁêSFA× Gß÷mŒvÓù pÊžUÅ]¦a%2]½·¾Ú›ZMo„âF½cÈÙ—Gµ¤î>|>dšŒCýIP6³±=˜¬-£þ<\¢D°„l\—åi{)ÚgX$ŸÔx‚M¡ˆÏ`k¹JKzv_OòQйRÖ´Yh9Uz² ¼êˆ°j¹!+òàt€†®K|$îÊçìÐy¨š¨rõî¢ý„ÑŸ3LIÏÊa´ÍÒrÖðG¶šl<ïÓü’v)9²†NÊôÖ0ˆ ³Z¾|ˆØ£Ð w)ƒÄ¡ÓnAzy—_;ÛtYûLlã|î×?£Åë~¸–6|(HÏàþõÄ?ÚèÊŠs4ø‚_¿”ÑR鱢ápÖD|’Xnó.}­ŒdŽÎõ”fF5¤÷%"62;0}ÛfPËOÏM¤€)%j‚éý±Á:*3_¦ÆŒßœ=9y°ÿ“–¦eÍø!Fdtz(dtC•2۳ܜUاuÔøÙÞ•F}¸â\bù°z[`”ÉàcY쯧‚ÚW.‘ª‘vé_§;6Csg>ª"žƒ×p걞̖3Ôu™ä²Ûر~"Ÿ\VþJÀj0ºÚ@_"PºV‘.p¤`G´”Â#pñú”e+üjmË]'ïà|ë¢~bĵ4ª<3¯ñœŒ|ˉeï2g÷s#ZNe*bÝpÈÖ[*B‰Ç.yXì¼qH8›­¸<Ò™Áà[иXYV†kàŒOëÒ{Êð¥=0=yÐl2¬>Õð °€–çõ[âr(33Rθ-W|hµš½˜úÃM +»øã}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ªŠ·Yv—ÇLß9‚äÔ^Ç$n<$.Œ +GáÊCÚÅ*¼ä7/*§Åín‹+¤½oèg¼cèÿ jÇ7^96Ü@xÕÙf}¡ñÂSµË¸õh‚AF—GÌ‘ÿZÙx~åÓ‹ú®2OBëðғͦ´z+! v2gÅÜ‹†‡´©h³+®,:®1wJ:ŒéÜÊéxK‰ûžq³¾êüX¢'ßV IUm;³ª€‡HS@ž=T_ê ÙöHWçËm_åè˜#hcWÂ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èžžMШ%m³©óºKà:Ô®L1"éNZ'Þtª“WG™>qè6ˆaïiÚoßÙ¨’^¸*§e°yŽU<<’wÎ%oJÃQuªô@âMJOÛˆwÐñ^ÏÁ¨RÜkZ(LQúaïSäy·ÊÅ3ÍäG«Þ™3µF‘ 0ëî-êÈ-ªäid—ÖBj‘åÅúEZp“Þ8W—0Ü/c-<þ1P§ºÚDÿ3 }oî +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Ê“!ü¢µö›¹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>à•ð좒D O±Áø¾¯F Þ8ýe–¡C»ÃÇž;õp§r^ƒ),"F±P¦ç@ÿ£)g +É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#ô9OR”ÿAÜnU±1bTþLò¥Hy¥\ 2¾Žÿ¾{…O¶q£LñW‹Î"ö]åGÄ"16äA™ô×zGL>.ms›,ì„~.’FT%ò— C¶|zÔ îÞÚ%ߤ¹M&ÜiPÇSœ÷‡åcª™lÛ-1ÝÔúÌíõn³ÇØ3e·x€_ëSqö›k% !Œ:kdi¼—)¢öõRG¿®-©%È—ü}µè‹Xi"¹[4Á£³KÁ¯â¥x5˜nH=|NâY`ù +]‹gkh ¢.@3‰\§NýVró²C#Ô?Ö¿`죋žÚªJò‘‰æt·×}sæ/Šq=ztÔQîiÖÄïŸp…ÿÐX'0¥Wq-Ö°?ß^z®µŸ(U/V~‘ ~[žw˜ËC(Ϭ²ï%7¿ Øž©AâîÇ>6ŽÖ:¶Ì^Žî„¯äýèz‘"=*†eöX8mìº6NÕ–šÕQtפÌËð9»7U…°4Þ™?”'Y¿Æú%Δ`a–73”dØÄd) ÄŸÀé1}n½|€–t¶ö“TaXÎRâ¤C"Ûc~Ðå7ut$spÛ=€ñæZs“>†‚Îñ­AfLÂõáH²€à™’Á‰5n/–ðÇá©”ËïœßýàŽ‚Ïåšô´_K‚m2·Áï9ÇÊ8üšýU”„=볶2ì®øX_Â.ØÂÒô³£³‚ýųïë–~+·¶ó϶Ìs¾z´aðû ›ÀÛë¥[Úý y¸t—6Fa9kcpیװÂMu×c÷ä5Ípû¼Õ°ÙËÄ£ãP&WIºU~_]îX_vªéâûåÄ]œØ{A]³}'ŠÚ³.¶üvÂÜ&êVò>=ÇS׈ü5ÝÉ¢<ñ–üÌI{ÏÕc}™6¾LÿhýĘOŸQòI7KD,uÅÚ6¬uÛ0¥¬ç>Y¦ÇÌôN=cöý =|1 ëÞï ÑoÊõ Hë³Ù ç2×ÁÖ}*Ä3ßN˜õÞ71]›<Ý×h;°)8¥ ¹WJ§(°+çKl)mÄŒ(¶å>ÂJV(rokÈ…ú]+Ñènd´ì§óÌoNæVÔ殊 ²R®yºn3àôØ"¯JÜe›ÔH O¦ÌÒ"ŸÈ‚¯bj—Fù)û¬7†‡Æ §§»ƒ˜fˆ%HÛk8qû'ì3X„ßh;‘×®KMïßG ?‚$õ¿i-T@/h³HyØVÂò™é¬¨ˆcCÛÜ‚œONp?·ÎË?b¹ƒkÖrbs¶å›¥úÎïº9ãúrrçÐךY9/3ÐC×[ëݹouíÜ'_ôYy«o–4'¹^Hˆ~Hº9¬S•®ò.áîÀmñûqÓC‡±á‰>mU»2ýxLæó¹R¹Oí‚ÈLh ejQs"ð2îã9šÜ&ü‡á°¤— #ö¼KÈ9Ú– +꧛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>ªÓ™^IùÛGôÆ­d•³þÌcòZ3ƒ¯´Š:‹\0s¿ŽpK{>aÙQ«*-ô/~»XѼÒå|¢ñ­üHŒtÅ,CÍ¢ˆú0”ÜIU1Xi(Ró­»û1[ù…K¿P+—D&B⺖p1¤7»+÷yŒØ«Aú^Å[Á8—JCV­ñUÏ“_XÍ8ò“Ffh†ÏuðTy +ʃ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×´Fµ‰Æ#…Æܤ]gì¯_»}§Žý¸j¥Á%Ùù,Xξb ûIçñq཈PúxÉ~S©g'Ñ/¡·*gTžµƒó%•øf˜Úø šñÈy”U³^$­dxgGeß‘ gËkT]S·7j*,˜ï–µü MæÀê™áú“¦Ç…ظD¸‹Éÿn»†-°ü¹ZvñÉ…öÜSe’XkW¸)\&,ÎyêÞq_^–dQ(ÒýáÈÍRL†¢¡®V¸²ó`¼0ÏýÕKSí™ôYuæ–(,•{ƒý^E†G±©Zøõ}m5Ž'´{Z .µ^÷E?Ñë½,Û¯&§ ‘<-Aðâ]căýéâ>»; ©¡3! ÝÖ£tÓì{ݨ1”m­°>cbâï]NÏí­ ñj÷ªU²šÚ½‡M;ÄØFïf[¢žÖ½ß¿ðÇn\,–òù©}ËiÝZY} ›Š+8:¦N-¥?ù®÷²G1|®})Xz‹÷„ÆÑðÕ+štön©c¡p Õ;H¼\p“eÖpù% +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µæ-ô¿üý€ÿ'Àp¨5 +ƒ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´„ PDLï~ |úW¢#B  ‰€:8z4!. +¿‡­\ pW''Ö† ]V¤Àú¾³ÿ¬ +wtòD@ml]ìzÚ\\OþŽð‰ŠŠ,=ÿB +$Ôx|¿pƒÀ~Wº§P‚À!ˆû¦Á¿s5­AŠ`¨Ëïqì¶..Nb¼¼NÖ È}Œi͇¸ðrÜ7ªË;:ü&@âþÖLŠ€XÝåÉûOÝìáŽîpïÿ[Cáà?F»:ñêÁ¡Î®ç +ÿ“|Âý;fqù¢@~Äñ°²åý]R×Ó òÈ÷; ‚ƒ}¼Ö ⵆÜ?p½‘ 7Àá +ññþßßáòñÀP+€%Äæþþf¿C¬ÿÜ«\PÀK Èþþÿkez `G8ÌóïtuÀ«¯*§¢®ÅõÏÙÿ•%'çxOÉÍ',àæ¼wÊ=£¨àÓ2þK‹¿tø#ª ‚þOŸÀ¿)ŸÃ­¢Žs¯ã_#¹AÈ{oØÿ°1àßùÕ] VûßÖ1 +ï]sÿàû¯–ú7ü¿ëŸ5ž¹Â`¨Âþ§€{=UÀoE` Ĥƒ 0ÏÿòÂ? ºÿÿÀó܃ZÉÂm`ÿ’ Š|õ€€5¡.V¶Úå/•ÁÜCˆ¦#úû&¸ùùþéÚB­ìá$òþ,þ€ pð?J*­ÁP¸ @ÇåÞ• ø_ß°•+q/Ïtÿî_{kè}ƒˆÄ +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ù¶’-_å³-ËÜ.CYK.$çɨ›ž8úó|,—„±„NãCž8ï”e.¡^´‰+úÌ×¢ÇIjCïðK׆°€ É%oÚÈ ®3R \2dßÜD}'ä{Ÿ&x¡¢ôWiW Þz7òL +Ÿ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ÔÅåŽøëÔu‚9¼ç?žºø»i÷äŽl¨ÝŠt9U’Ížö¢õç¹2úŠOBZ\$jIw¼šŽ|M’gVy˜ çŽõ¸›Gõé¥B†ÃÌEæ„EÇß‹ÝîWd^JøÏ_ã=Åîþæ…¨g!ÚyÍÛg8è>u¥ühO²/áz8hËïb.ï®Â&f‚‚1¼OŒx‘³¨r|T@æqîP$‰‘*-Ú ^Æ¡1ç]Åûо$£$"…‹íÇÆ›‹ÙJ»‚òEXé×>=û5à.*省iV¯¨É•ªëÛmrÐ3{¡µ’Ü׺œ0™ÏúúÔ¼·.t!îu›¹ +%;³}«Õ!ù˜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²øÂç€êÍòc©‡Î¬K“ë(œ¾¶´¯§ôI{ˆ¶w5¼[§ù±å6þ«(Û¿õ—¹Zӹ̂ÝDîmrýÀrÚ¸’¥ÒêbÅħÚT?ÒÁٓǶKJõ¡,´¶øýd'$Þ~ f7Ϫôs¿>æ¿FaßjÃ~ÔU8xži†êzkùØicçÓ„—æk'RkŽ^©=Jæ„kyGmЃ—ó„;Ìà£T/ÕˆÞmàÚÐÁÂ"»­lÍÍ„g$²m«ù4£_ 8 !Ê„c²{_bÉk·j8u»Ö¢UÇ[léÁŸ`¢ÝÀ‚â›,aüJ;Ó€¶0´I–œ(¬PÝ‚4Ù››“+û`°ªùBÎÇòEBm¬`WòÒ;ó¤#j.‡8;PÌbòÚvQC^Må·ðÆC‘îSâÒù2¤ì4:,i;‚¢Çïô59«‡÷|öu\íÆV9‰•/ËKaÓÖ/™N4KŸlæÔ¬zÇ-Œ¤ê´¥”ÂÞÈt꺠ÎÃÈZ?¢Ýó“¸Rr±öäÐ6™§­g¸Š2·UÛ,Õ´’ƒñaz™/¾LÉ"túsŒ]bŒÛìRöœ?(ö‚>1dÑ=›òNóòŒh.* —™uÖ~åÈ“zu“F»åiM·rÞ1úŽ˜~†ÙH ×LYÖ,ù½èJqw.m€f²ÅÞýÙ†o®ÌÐ:#¨ñ×®£eHÍÅä‰Èß™µâ{ï–íHé ¡´èkµ…}ú#4ÍŠfi›š¤V‰«?DÆÙ4kãÏ8aÏ“°¼Ÿ$%¹Z`˜“NtµóŽ}¥/ýJ’{cZ#ÖjÕp¸CEY{ÆÄVd ¿NŠ´Ýß½±U×ë_R'$óÝ™På‚WËL»j¤…Nœ¥PFÍkìGËÜr° öÆØΩäså•3r;é«Çqi¤Ú^¨‹ò]êÓ2s8ÄjÒ0£•/&ßr=&e.û‚¤æ±cwä,4Ÿí>ÆÍ[-çaÝ~¬\yüð ŠV”ì#QÒ›ˆߺ!b’¥µ|‚uf +•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ê.« .ì©Ç'2_ÖE,œpRGTÉ%]‹1Ÿ™ä ‘zÏ/Yaz +ʉŸ¸Ã¾ÌܳBÑ'ŒVÞ¥‚½ þ¾øECÉunŠ”|Q!RsÍÅ~bP˜œ¢ÊÁ]UQÿî Ãý^-“@E ÐÉËwÆ%R£1ù³*õͨ”²u)ˉ}šˆÐ"îž²u0”iJ%JÓqc^GÝrTâÅ£YTìo­N½æBµ'¦Àүʶ­®4ïü˜ÔД’Ÿ¡_(ó¥ƒIòœÖüŸú¾[ ‹O³(Áûc3‚á(&™a—`.qÓm·]ðS\ÞÁãlòX'Æ0eSË« ¿µÜúŒE¤›UU˪£¨ãvÇ”AVÍ÷¦ÈS´3ðÕÃAÃYuhƒ^/ÞùÁü˜T—·J5#eÄî†Sfÿº‡LNc#ˆÈ‹öÉ”#§)-ÞcU¬í(†ãd{¿ÿ}Q?L6£jn?4"Уªü•AìioˆÏPˆŒŸQþ[„ÿS~çoqYåÁ«{¦åôxßeoØ[)]i òÑË:qCQ&§%²CRäæa:òpoÞo˜Ù,,¼<]Kœä>§:F´pë¨ •’¤!_{G®U'þ­‡£–£ØÞ3î8ƒbzØÌÚ†Çe²Gf¥ã5vEƒ?{XT±´0l9kE8eqê¯ð^,6ÌmK|ÇfSKyiéqÚšƒ@-zJWó…e^ V‘Ì“ÚÇ™|Ðwè­€Ñ]­Ñ;;=DZ•Ew¥àòv¶|°¡}luô1øQÚ—=¥•jì0÷Ž¯8Ÿ=I2r(IVžÖòDt-r6¹? ¦FsU‡•°¿à! }1óÍ~s÷EÆ·igZxHeÝÕ˜h=šQíì lìÅ£UÌc —ø_Y‘œ,2õ†à¡{]Åé;BÕfX¥­IŠjiªd}ê¹ ‹3A°¼ìLy])qc&#<ýÏ?ªŽ4Û§{i QìœåêøvN~¦ ×EöE6·¤CZLËö6X§xiOt`~炇’˜ hHvqÝ]'t¸+giC… w¤:XËù4˜•y«„}äA›éûäû{m¤äM!èû•»sZk¢6I™œc¬yÈU‚9ÉdÞ«G“y$h³íÔþ–z<2øìJ.‘è}.›vQ‰RÙ<Êc¯Æ#f+-Z%žºFÓ]±ä ®¡nìMçÐŽ–·íÂÓû²Õ$=‚›ètz8 8c"©AöÄJÌ- )Ù±·’^Tr¶«Äb*?†%£Þ¤þ Ó ŽçºûÆ{:ù¶˜¼GxÁ2îêPJõy82ñu¥ýâfÏŧy•t.p«L6lšÝíOUÛ´cÅ”|¢1yïšgÎÌrwÌF£|ÊÕ7çÑ·1¿m7˜M>ßa[Çʼ¢f)ÑU*aþ©‹Nw22ã_xYÞ.Íì¡[ò̓ö}ø>I‹V^úerèó-!‚°Æ.±è«cÞ£¸Í÷(J¹„Y ÀªÏ­m’=Q÷°òöƒ#Ë'Ž~¥¦žÌ†‰tu<§ ÂBȃºr)Šo<¬ÆЬò•¬¨ü³IúÑ*/õþ.µÞ.s{±\%ÆLg__¦n£Š.¼§z˜{sê>»”.µnපÖL›5e Õ!jóÑ\°€ïëØ2´W—¢9dKuÜr×áá!­Ÿm˜iüû™3áîÕò¡ +'ÞÁÝ%·TœnKMõòw-Vקª¯ß‰”s[¶Û½åÕµý9ÜŠÆ2v‡z¸iˆŠ?²úÎQ^îAÿ±Ž»Ç°'îK6.W±¿~ –VöyÚõÓžW vÏ\ÐŒT+obÿ‹õãükžï»ïk“¯áM¡$–^WÑòB`·µñ¼a°ˆ‰Ù鮇/›„·®wʼn§”Üìˤ÷ãe¢kÛÁN¯hc~i5ŸO%àɨ¶žP§¥ +Ø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ö¥›ŒKwB;€æôöF]®×mHVíà7H°?–ŠÒÿU–ãk¨ +ü•èÚz0B_­,èPÏ?þL@Ê +шèA*aÑaö蹋¢£”<±àOUv;Œxé9¯Ûû¬EïÑè%¢®h”ƒ­gÞ|‡aV 28„Za”äJœŸÞÜ-bëÝÝžAvþ”|#ï³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öíµQ×ÝÒ‹7»Ã¤À7/¿¡ÌdÄ(°mjõvk0× +kEtº›‹bÈ“¥ ·Ä‰O­©c“°JT’Ò× +r“ƒá?ÄwÍÏŠo>ò¯”))A¢t¢åÜõã#k¿Ê銃¿ ¼*ëðÖæëtï sÇ4nÕ•Dê„ÐõoÑ+%¹WZ4^mÔ/¡„IÑo¡¾DwÕ­Ã2Üþ:6[lÎÒcžªÁ¨œ"|Wt—Á7µ¢î”šÂÀaMjL‰"SfB9áY­ %Ï?®æІ3?eÖ&ïøàîìH cá«m‰Œ:2äz阜yñ%‘Á˜àPÀ˜‰;V,L¨×¯~¶B×4ÄõÒ©uÖ.°’úÃѧ™ÖäúYâ‹ï³Ê+r~sÁ€WŽfÛ…â%9:ã™gîÔîG…d~X×b—PåKÚiJ’£«GX>Þ`qN×>Wpœ¶Ô‡=¨k ›EF|1J6S†Z<é¢áÖõ¥ +]ª>úÀ”¤þÛ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ņÊí‡Ç ÏÎ_„ŒleÏlbqì3ÚXó6ƒ¥p€„f)M_gú"/:'ÃÏguû…Ò™ÂNߟn¡cMrj‘ÉYtœì|1Z:[ÞY[&/@ÞŽ×Q.I|Ûdt#ôÌ ðÇ×ëŒj~}ÿƒÓª1Î^¥Æø@)­++Ãî37hk€¨W¾!2ñçšuuå¢ðœ¶ŠN )±Ï¾^U ¾öyÅË•%€¢~‚À#[‰ÎÍëŠ]D¾ÅÛõg}o+­°ÉEIRÞä=äŒÐF+± Éí£Ï1¾mOiÄBx°¤]gyŸ^E7!¤¤öV*¨,ÇýSÁ†ÌuOw7Ìèë‚;ý6÷2ƒRDza$E%‰¢…9Cv;b¿®çMO=€ï‡wˇíGE¬?´¾&‚°DIPR­oY¹Õÿ)^™6¤eøˆ²Wq„‰Urò-©õ~aAEh³~2ŒNre6b.ã„r*Ÿ¥Ï²ÓL[CÊ®(µô\¾G[†ŒÌ.•t»Ù$e¢X¿&Vì”­ÑZ07ÐgfËvçë脱rºÖ&üÂ\8J/ßô>,N¯aAnÍkØSÇlÔ@1éÛxw{%IÔE³¦/—½LŽàuþE'¡!FÖË0“>Û?Ãì¶/ŽlÆÁsr7Ù8YH•N™ìÒ>ÞðÊ0?©dÂq«ltVª­:ŒÙ¡2o~…/ŒÌû,bÂf6fÝÒK݃T›7Cê7¿½szRÀŸ·cç:àµÞnE"m{ÀŸ76b˜èlŸ— b¿^KÎǃáÐYwïLš¾ ®¢¯Å¬›Ñ«9í&Š¢ƒJ[Îd»—úvIè~ žŽôÏm—m]ŸÔç»~¡ø$¬ØPHËúàjP'­ÅzyoA´º”ìÐX̯è°šÔ¬zQ57BAsk]´¦hk$žÃe|¤¡ÉœWüÒ>š ›.?`ñ¹\'Šó>ºƒ¼zÏd.k³+áµÄt~+ÄÓðêÃqªæ;-ãœø UÒ6¬è¢ŽVE†ìPªÊ³"&=>Æ£l©5QAƳ¬¬4—•ºéT³þå?´3Ø[íÅÌ'Ì>åÚ¨É*OYdSm=~êẖÀ ñ¬€ó²Yj w½ÉxÏ€ÿ`ËË#盬|Lü¿üáþ‚ÿ'¬`ÂÅÑ„°ÇõF@.Žˆß_àþ/>’¤endstream +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 ¸+›/ä­òøÆ2ô8’¦"€W0}’Ä" Œ# +9 +¤rBkÈ +¹È0z&©Õ`ýäL°΄ñ,bR8! +l„Ó”šÔ$A•à¿…!mÆ»TŒg’¢€×”L: EBªÖVRXk1²LjùoÈš^?—ë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{^ú ý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]¿—Äš±*!*[*9­^n3ãÎ̱'¥îÖgøæƒ×Âù» ÀÛ•‘ £•þw»'´ù®WFŠ:9³Bª”¾I”íM¯ÌÖëºæe7w—-pªÐ3¼¶žùÄð%÷«ÓƦÍ6óðµ’Hè;[UÇöë®WÃc5œ-±÷ùѸλ÷s‹VS©Ÿ¡Æ¥õcºýõáeÖþ£;/eGXh¾ëã^&.}mS?Ôa[žt˜+tiR45÷\¬*qü8FŒ—E(Úo§lY=,­o<±Ûaç*§¤{naˬ…;7ÿìöxY–¬òë„€óü‚¬˜s¡¼þÀ9ß{..VPJîÉ¡bqÍÁ´{âÞðœç?|½g2ºäIìYSQá «ªïŒoE‰døJ—èVÛZ]·º¹¦¬ptn­Ë†÷Âœw\^sòßÝQÒÁû¬}œºŒxù:ñÔr·oõ©Åœ㣰Ö5Ùz¤ q\Û×äÒÈÌÏ•ußØ5¢Jiì¼^žÿ -k¤N´WïŸÃ‰Îg´Ï ìfÝÿèjüçߥÖðÇ.ˆ[“¯õ~9ºn'ÿ¥%™EO.fȉU=¼y–O³#TSëØÿá¢ü¿ÀÿD…–㦑ã锚ŒÉendstream +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"‚²]¨‹Z( Œ€õì`P æâRAA€(® +Ä@df0@ˆŠDdddˆ¹*¤ +êàˆÜ114ãåç¿û×Í/€×ŸÖ u€¸±îéc°ÿkG#€q„ì¡0@EOÿ‘–®àŽ†® @‡ €0€¾¶à!£!¼{ +ûã!à`è¯ÒЂX.%4@#! (Ö â ‚ AwHÊŠFcŸP4À„c°=À P8æþ•öÞñ;!$ +µpÁbX2}ƒ¡ H U_Uý<1Ž@̯Øh( ì±–`ÈíWI¿1, Å¡p4ñÄüŠe€¡h$ è…%C¢ ¿ÓpCCáep€‚8Q`ÆÒ`¹uç¯:ÿT=‰„yýöFü¶úGP ³$ÅÆa°± pb¡_â·GD„ÿ¸»!ÿÄÜ!¨ß ºókfx±IÁ8Ì †Ø é"0Ø€;ÿ;•ÿs"ÿ$þü‘÷ß÷ïýÓKüï¾Ï§VwƒÁt.ØøcÉ°[xøµg¿«äø] 0¯áõwC3È™þ"û;¦…bÛ¡wÀJ" "*(üÇ5­õ„€õ¡#ÀÃvë÷½  AÁ pVÕß Å: ÿ 3v„‚œá¿Ú/ñƒÿž;V¨ß™ )««+i=äÿW»õ·¥>v0Æ^Hà¿Ã˜é Àÿ8üâQVFx|$E¢RÒiqa€´”ˆß¿ˆø›F䯳ƒ‚z,………EØß?¿ÿF B€ÍŒcÇì¿` +…U÷÷›-úÏóï‡@§÷ªeg»~o(²°Öøe~@¢Í?=bQ¦Ôö¢2T°nXöò­×Äòç—|«ýít0ž¶TÈN‹ßmÞŽ|Êyî&)þÕ !ëB²Œm³ŸÝ®YH +›®.½30´.¸¸~k¸I uc÷„7à¶{~ ç1’ü (­æ)m3EUÕ‹­mcžî¾Þž¶}‚Ž/ÌüÏŸqɹ_#ãŽp}άhaRêÉ© 60DIb•¤4Ì1ëCö$Ò]—mVÜ ÷ˆr´˜V‘šµHM¨@a5¨w§µ_“ù‡s‘h0á«1î¶ ¼üòeï>÷©¦ýýØèùÚâÝç¼þ©Pëd¼dâÍO>v<*YTòÓv zE}qZÇ +ä÷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†åZ‘<%jÏâ¥g¾à§¿UÅiyÜ*.ìTÏh-ž‘2(’Tä¸ñW­BÌišùþp[MSÛ-²èu3»XwQÏGA¶4 ³ë´ÊöaVqªºUCKFXŠ£µ:¿[?pÈÞ©“’ªk,› .32.½ÑöL‚eýu-Õ +ˤ¹i0ªøØ>ÿgWcrBlñ§buSx‡p':Í=r÷ÌÔ×À09øóì[ˆê÷"çǵ¬Cú• ³ã¶Þ£ +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¢œx–Í+ ·ÉÐÖ¨¬§ýÊîzMŠ|’þª»Y-ú¥ÊéŽCå@Õ5#JW_Ùû^¤k÷öcžs£–=å™Äfë¥7ƒ"Ý5[k jΛrA{\“²òb¯5ÎøÄÏ“¡_Þp~³3”Úš°)îx'¨Æ{¦è!go±°Gm)«¡‡d°\>²õÉo '¸µ±… +0…Ødgç•771ô|Ÿ¢‹y¾ÌõºbÓü–u0Æ_røªvùMc®ç¹ÃBÅ\n}HòýÇHyðîµ³p%Èuë@k+…–ß×ÏÔ\|©bû¬ç´ËOª?XçsË,[Õ©EWJaoD’ןÚªÙ‚(eT"Œµ6¼AhÒ7Y*¿é½|8 ÍÒäÒx5Ámê#)ѹ å€n_7¯Ë,f™·­ž³ö-üæS17É1I©wŠ—&ÍÄ°}ðnñô«ù\ t§kôaLs(‹‰Ó³ÅÇ?=1òJ8¹¬_Ãkvy˪7—‹´nK°°=içé0Â!O³v£þ@ë¬QueniÊ<¾³ÕµÑ”ÒÂIm¶ŽìQ#wœïa8úá‹ ï¶ù´eöä—ñsç•2´9µrœ%´5“Å%:ø”rBSÛÔ†Çàš¶/BÄ)¯o½ÑäNÜèÖ|ÂvthùL—XÿUš^ðöá÷FŽyÎö&•'i¹ÛuTL'oAÀqKR‚µ8R€A¨ØŒG­–•äÉÖ …ŠB‰£Fú²žÖŽF„»@óÄôdRÐqœLR9IRaû= +ÀÛËÏ›ë"±¦­\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—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ÓÑ{£ˆÜ «ìîë*Õj€¨ø61õ&¿<+Ç«Õ\Ô²Hº|ý¦ûì¬uáñ¾ªR+;Að¬·kü©è÷Ì[5g"P +/%É =Þ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{ +ßѦ@¤í¯,*ŽÈžÙÁc]ÆÞ͵T¶…†F?œ¸ØÇâMÌË4ú¦&:º³^vL%ƒƒq„¯/š¶åÖYœòæx†)ÈöþIŒnÐÏÞQa&/WÅé¹ôó”ÕVz©àîMö¶l?¹úsèkEòƒÁ4#Tå(í`¿<1 oz/÷Û/q¿Çkñ.ö‰ïÏã}ź„]Âñ"ÌM Œ‹ô¸º¦²Iˆ'(Þ´ôâœÝ¿,6%8ÛΪ¨¿…Ç2¸zÏ’oËKÄæŽF»èC^ûÊb”ŠDÒ}õQÇ1—C‘„ÖÜ”©øRÍð_qqKy¸”5g‘](@ñFž7ãæŒ #“R:¾©„w”_+åZ5°yùrØ¥:‰Må<8… ²Ž2ž\ØÞLþ*lh.É%Õ‰?‹³È*˜ |0Ï›•!qd #åfnè„ŸúÃ/¦<½–özšù«ÙwFäÐM§%«ùÇcÙo´‰?¼h¢`R\˜°äoTì<9›¶gô^l¾ø Ÿ>ÌÏÿ¸Þ󲺭I‚Ø”$|MbIþRZ7z®@¿… cõ«*ú’æ•rG½ªü9N<ïÇ{L +o>‡…~¼GYøüÈuQâ*³AÙŸK ¾ôµ‹«ñ–Åad|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;âÊ(â',aò>ÌæY$–¹ý”27SxÊWpènK[çÄ1l 豬y¤i¦º·É ·öîáÅ,ïo²ÓØv®‹w’ÄE‹¿¶«>¨•–|߬±*ý( <ùi+~R.EF&-¯ÌóÕpzF>ç”ÁyOwÑU™sl 9FLlÌTiqÝéV‘éù)§jÍ«ëÜbÁ¼Ï‹…Ý ck-¿Z Çê0e%ÔÒÓhÿ¹ÌØFˆõ¾iòzwsªYÞÚîÑÈNYø‚.»sçÞÚE!58ÎìJ:Û;5`¤ŒTƒC¹¥ó§}á`­4…¶­€"Ì{>EÖôùÅ„Ù«Ìi¶X©6Ýh=ã’‹¼íîËgÊ»·µV®Ýï¤ÌˆÚ?éÜ;õI/ˆ¿ˆ|×Br\jUôÄÛ>‰,2Þ÷þˆL!‘ñôF-íÔ…Ni™ÓS +¥~-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#j !}Þ5ÒÊ@.ÌLж¨VJ=aAø|‘jž\íN[ã” ¦…‡%cÕ‘Ž¼ÁàCÞ”r;c¶Šb=vTA¢E1ÆUçCݽ0=ã$ÕÚ±qʾ ª‰Œ8!ÖM}šÀ ±šËÌ'─ÎE—º4ÎýZ&÷ï.9¼>vI†ÄûÔ®×ô/èÜÇ~à£jh¶ÌBW˜J±ý±2´*T¹Beß9dK.j^¤"{R;–®®´¿!|xÓšgm¢5uFcXx£Ãßä1“­’¯ÕnÄOÀ)6dQ×·¬³°W¼¡Ì¬ZÚZ+ ×Û3yíUèŽËþ˜"Ë©k±.—þ Ç·N(´¢ÿïz“-ܺŒ¨OóB%7g³¹I¹ûa¤ÆQØÿáh³0u^Ñ• Œ!7 A¥\ÇínT`£¯;þ{€|“é =Ï15zÍu–¼Ý­ÕÖO7ïQ$…ý(1•¬| Þq”XÄð.]®>ÊS’kM<óK`ö…dí‹*y’u#qµÑ#ôÊa6E§¾Œ!σ Øq›ÇokkQúæżtyî{+Zþ¢ ÝuWEœwGý˜óù í[„+«92\8å—ƒdbDËËÐ1ê™=*®esyƒU£fǭ㌧[Æ€^J7{بÍ|rÌÝ\Ó7¼åâ/MZ„î«|–œŠã~®n§‘Eˆ.£> ­6)ÄŸS5Së,ªÓ/Ä´$Ó—Ýž%¿ £]‚(óö~õǙЎã—TØ-Ý]Rf¥òíÜ»f0é~Ç7 Ú¼>žéçöåtKà}Ì9‚ÖUÜ©å±/¤à×û05ºÄ[¾ +¼RK·=Ž–ùóoú©G–c£m¨fk•óæo_s^^ž3XO¼ò1ˆ +³Ÿ“öÐ^£²P¶yWmnÏÄÄT‹Ë^­ZïÚ]:Ê>9mTl´ô£i¥OäáàÑýlú ±Ê(À•ªûjÊ,µrAAx-fLjpŒ >¬ŽÐþÐ3ú¾3êÔèû ŽTõvõZ¼c ”ì5¤uQÔ”YN¨pL…2ÌæôçV‹Ë@>‘ÈÞ N_"ˆ`†ù¦z§—¥„¯ +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—ù +—Ä:ê÷ðÝ åë„ a ø«}V+ +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‚ɤ‚ówzç ‡®ÛjñE÷0URRïHOn!XU¸|ð¯øjiì¾ òŒrÙ—ã¥|ÁÆÝmÜ iV+O´Û–‡1îvaº—òⸯTÉöàŘëÃô§þ.0Íg ËÆ JæÂ]µZIbQ*g61·É5{áóCüÿÿ'@0…A¸QÎÄÿûß„Wendstream +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‡à>ÀÀƒw×à$¸;$¸w×à„@\.ÉwöÞ§¾»³ݺS5SïÓ«{u÷³úíª¡¥TÓd·t4Ê8:¸²°³² T@öæn.ÊŽJ,@k7Us0ðp£ÐÒJ:Í\AŽRf®@À[ %@ +hàà°óóó£Ð$!žÎ kW½¶Æ[&&æY~»Ì=ÿ¼Dº€¬¯_Ü`Gˆ=ÐÁõ…⨠\m€+TUÓ“W‘Ð˪hd@g30@Íí¥ €ÈèàdX9:ÀŽ– ß­¹°¾p‰»Ì. è% èa„ü†˜ ³=ÈÅåårX;›9¸¾Ü«#ä`v³ü]À‹ÝÊñOAgÇûì…LÍÑÅÕÅÂq¼dU“’ù«NW3×ß¹]@/0ÀÑêÅÓÒÑÂíwK°šÔÕ äàpz¸þÎeX‚\ `3Ï—Ü/dgП2Ü\@Öÿª€à ´6s¶]\^h^¸ßοúü·îÍ °çŸhÇ?^ÿ¬äê[±¢°s¼ä´p}Ém r@yó{Xä¬ìlÙ-Ý ÿÀÜÎ.ˆþ÷Ì0¼aféèöX­PÞ¨8º¾¤ÐÿÏTfýωüø?"ðDÞÿ¸×追ÄÿÛ÷ùïÔ2n`°Š™ýËüµd/[Æ ø½gÀf΀߻ÆÉ ø…™ÙƒÀžÿ&ðïŽoû_|‡å]Í^.EÜÁúEvV¶¿Ì ÐR äja°2¿ÜÙ»¶ƒ%Ð r¾hûçZ_‚ØØþ†iÙ€,ì~‹Àýt°ü{ù/rý)þ†¢–®œÓ¿Û°<Õ^&ÁUËüWš·ÊŽ–ÿ<üæ‘pôx³ð°X88y¼¼\>vvß“ñ û¿ÎÊf®Î €+;àå÷ߌþF#í`áhù{r4]Í,_†íŸ†ß°…›³ó‹ÆÞÿ—¦ÿqþ3ö@ ÐeyÁÑB0Ä6=+õ–0w`LÊ ·›v RÒ U˜PíØ埱É_aúPÊÚ8!ðÔâ9yÜU`Üê&Óu¥?’úR3ôäc}ÝÆË´ôƸ=ãÇÛï“9¥ 8}6½­1u ãⲉ6Ng¤“k†j÷ü<š+†ŸEZ}<~;V#NmÁá×I߯¯è¾ ôwÁ÷ì’0åÄ#Ó +ºÃ¡¿ŽpÊ!Õ×®ðŽdÚ©Û£ˆëIÌå1ñ:–¹M !LŸ+ÏS·×Ö:çñkÏñù È [œÒ¡±Tlü+Û¿-ë•øET×—mÚjËl ò>õ _Ô‹vý,8èáÏ D›[©ºœÛ[3zoÃC±)·úˆyH cpeØhS‹GéZuk€ÉaëCkú–J†H‚O—ÕVf.~†÷þ䄺¥u5\càÞ91f&ê~ºLØéÂÌe_|Ÿr“7K5¸S¿iÊl–œiýæ£q­]%Ã['ßê‹t{YÎ(”o¢E +jEÅÖ*|ÝÊ|™w{›·þÃMѶ¦šx7Zmû ÉJgÜó]w2ÐÏ"|&&WŸÜ~±8Æjt +Ý–”èíC›ÇO/äÊBEQwÚüEšm˜§/ÞôRų#m ¨ŠçöØ +oJª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'Ü¥çýüªPXXÊ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Ä"} žŒ"Ô,®ÿØmo¸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Ù.Ch’Ŭø^AQ¾f!2¥ý+RS¢°k¾R•]ÍmËç ëDuÙ˸‡è™¨tÓv-º'÷W¿6ÐØW#ŽÛBÐô6Qº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üÈ+>Å”æ½Ö^ƒ6iDõíݳâ‚<¼èLRX6Ž†šÙÏÛU®`¸ My“ïµ#.“O&Þ‡Ãü‹A©ˆóºÓb~öSÛ´¬Ô¹ZZy„ÆŠƒœ§Üy1=!µRÚ4)Ôm$UÃVAÛ—tÃ72?"P„t¹á„~F£¦ì±žÅ}e—9!©ÛFè÷çœÆ£ŠõN°Ð—ßC¼­õæ«Õ€nÇ“Ù,q÷|‰óÖ!šžŸ¶|Í+ø³fÖÏ· +|Ò‡ 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  «Ÿtq†(D=d¾qêN‚Cw#¢që£`"“AýÊ=×4}Æýn– Y“ª2<¨Ú÷åqñø'-¨iaŒ½¯©5GåsFHñ’]&à~ÿYkÚC¡ Ï‹…v^-¶ʺ%eö>¡pý"³ê+åß_5rÎÌð–rbaú‰%&ù +sÆ@es‘Xü>¹eéN!I±rÝ<¥ImÓávL^Vc°èé4%ÐvcŒ~ŽuŸÚ:æšÐ(^V©FšÉFÊ„5¦@w:¤ªO!¸Ò:¨M„Páüòonñ=¹/ )‰=D¬™‘x™( ;o•94‡Í‚¹m.Ïÿ&yj:f•… +ã¯ç´½y5âC̆7’gj óÄâ|ÈÂÚÔ¤à¤ò„[ZÓôÁûòúêFù³‚V"vÏ[´¯'›0¡'Øüˆu‡Haq>æ–‡›äã#‚wk¸WS½Ê9¤_,-Vˆ:´'Ù™ªÎSË^eæD¤‰0 +[ê©úɱշÆ#]ð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¯Õþ·«Ê/qhÃP៻AxàIèŽòÔ*a‰íŸñýi"ñ”Îèa¦J‚ãU«¿hè6[é¹Î]¶ú£^þ Wœ ­„úž@Ô úØÁq‚'QÞG«Á.·C—‡¬ö™Õš#ñÕY”…ý !A¦S3çìºâÆe²OÙð<è4ËÕhB\ÎÛ/f–Ѿ39ó6©ÇfžÝ†ÒanÂÁÏ×áá–>Ï€V=Æ]‘ïÈ|zˆ•T°¹ÝH’“=æö+•ÜÐ~áâ>è?¥ðR­M :Öª”¬¯¤1ÕUÓ2jmƒ<ì &oÅ•M<Ã,Aí‹KoLÇ/ ÝžKÅ7™ ¡„<¾Cšì+Í5Êhk£JVY+x°ÀBú€ÛH¬æó§˜W+°}_…{½FpÓV?aÐ:Š&2ìå;t‘Á(Ò#8UXÊÈÚèhÝk 'gY;ê8?çèX¯^a’öþOw£RêOé}O`)Ž}yªÔí*°¢ÑSK2qLØ,V¯`¢~Õ‚Íà6ÛÊ¢o&߬þÁñ÷©â¨)m[z2{i¤o‘ê&ÂÑÚ\Œ4æ™m’íõ;v¶,ÃT¼ó&æ·ñJö6yŸÎ4ôk¬`äÌrâœîL C¶ +Ún3!©E:qg^˜½“ çEÉHûK뵋Ùãi¬r°"×$n{G4.ö5b +C'75¾caÁ¢ãmƒž•å ûZ *œ®ÉÙ @œË¼,A¾‚úqhîA¨øy#³ +1j ÚlÑ&³¤=mÒ;HW3ßF]-˜b:¼a²-m½Í¸×8%3,Z¼RåØ;*…0â+1wf ž¡¸rA7DZ Ž»µ‡Á8Êœ”ÎR”Ä<¬¨ÅòBu%Ô_`î”Eû1B–Y«æ;7¢rœ–õôú[¦uÍê«‘âa® +Ø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×úˆlJ<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È.oðâ›7Õ̹Ήé.­² +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ë]i¤ê/£lŒ$%~î S,…@õŸ’Ñ– hŒµ£Nó+G“} Õ‘Üi­álNͯmÎ#ý#¾tK§·¢žZí%ᆠÕU©„#àš?,âŠãµ Ê…Å_gd4°‘½ÙÇTK°$:áÙO"LÁØнݳg¿Ò/Õ˜Hh¨1ÊõòþQD„ÒðügßÞ[2g¦¦.åy*)­½[Ö}vDÈ\ºpw3êÛÌ@Ĥ΄˜S_8]_÷á°Ô ®EØ6ä8—×w‡lʃ\²i©Tu^Oª±O§ µýä†ÉBâp;>'óV(œe6W¡¨ÀÙYÜ6fâ¢SÓz«ýPy çjÒ\ló”µ5”Ñ{mî0r\™\Ùp†?ㇱ9ŽìµFÚзæM(j +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ÖÏFSPÁÈl`«@Y`…# Œ‹H…ÝÄN›Ëo¸¸˜D·è‘Í[ÏZ{¦ãg¹ù8|ü,1i•€Â~6Ûn„DQ¥ßæÊR¶ð‹š-΂ÈV÷²a~ªŸ´Hqef±ÐkçO;l§©ñ÷’É0ÒªÃê»ì™p细ÖKL8þoòÌ¥;»\Ç‚ÅæYq½ÉšŸ ëi_×ñ mÞÑ ‹MÙv{ëø– ÓŽÓÁp³*•âú½W±ÀCqJÞ}‰É‰ Vþ`õ¤›Ðòåâh"*f!)|÷Y² ªS]-×FÝåߧ˜Á'VnŸ Å7H­z2wt_›^9§ïqŠ;II+pÐÇ÷óÊé¥ôv$Á‘ƃèÙnô°ù.ûû˜'¶‹ò¢¹ùž)ײ°„Ã\f+5ôeP„œÅhQ¯5F-1á :ÝÛŠ«ëm&5£‚Êñ@Š"œ¥JdIrù’ÔW®VéTÿ]ìò‡¢ªÏ§Çñ¶ÛÑûÎQó×pàûŸVŸ¦«ãobXÆ[)íz;J}$ã%!ša˜¡(¤<¡Ú»álÀ¼ìHÅ­p$Èkßã:­xkuÂUö–È£×=#˜ôŠ»küÁV"‡´ÙCz{XgBSý¾ïĨf¸ùU&Ò´|-–â¡àÓïº :œ÷^NÈ0ˆnµKÃîòÜãwv5n¤_‹—b¶$‚Ò™‰§¹?<ßúÂ]^8y,»1!Œ¬y]¡ñùÂ׌óÒ&(YÑ÷³ÆLô››7“«uí’Î>ÔnžOÒ!œJµ=Ód&Ýhi%Âq³Û=xTR ¬ˆ'ï +¿Ø„× óF¶?0PA–ßâeP¼šxoyT×]ƒ ߯ q‚éWëÆóªVüš'ƒ³DŠgªš­µ©’((_«¿ª²*ÉêjÂÉÀhýìÀß,[Rz<™ð<ËXs×;åäÚg&Úö7· lj¥*j¼}Å3®³â=Bºê„YSÏë +¢…~/Œ%뺋 Í_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*à&Æ:-H3Ÿº?éU#™”@¬dn +ö;)Ó5†90öê8’ÊøïSÏ]m/‚ƒÐ _èìûD"6ÅÐ +ó/ ¤¤IÝn×ャÃH£J©´Á×í£\^"^?m¸î#ÜÓã­¡]?Âǫ̀ôÍÄ?õ}ŸÔ½ºCCv‰ ØÕÅóØôÉ‹ŽcÄqÙÅÄ 1È‚ÓÏAK–&ÇqJáw‡í¥óðq-²º5{Ü9cúxsœ…vtàtf>Ø.V/èàl)]ÆüjEÞ)â06¦±/ˆÅˆÅðŸ—Â>¦O9L:»åcþ‘o†, 1ÜÊ È6dðdrx·±+ +þuch`’WZÔ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Ñ"ÝF2”Ðq×,aGÑ*Ù¾¿~}õÏ'Èzž@öýÆÊÈ5Têr]Àü)÷„Vݾ¿û‚{²î}v/G•wæ[;)¨nåj7cŒ7|íÛé¿,ø¯:!öUKÌSDßØeåÐbÜn ]`EŸñ;¸`“eŸ¶ØÉ`<6,¸“c΀Že^ðe£Þ”gœãÈÕ­&)׬H1ì¶SdrvëOËx0P(îée¬-ÒM`¢!03ðÜW‰M^®#YâX$››ú4 ºÂûgG/lPŠêÛΣ›îXßl’ìr„”Úå¨è$IãÔÒÅóJÔ¿ýä  {Ø蟉©U³ ´¨©O²Q×FÞ2ÐÒ{ïÛ#ÔQÍÁ@W®Zædˆ}óº-ÅÉæiW²…k¬6$ØÌ<ÝòÔá·º7_´UsÁÕˆ=·¯(!Ä ‚¥mÊ3ýÅÿ4Çà§í†+é–nævÎi©ÿdˆÍTOwˆ +.„²5ÚþÈÖñ^ž/|†Saï½ ô»ØIvê +Ý»ê}­€‘D=Tÿéâö·½‡žëÑG]#ÂâuöñçP2ÀÂ,NÈËpߣ¶ÓñuþE+ë¼íà0 Hû"C«™»‘ïìºúŒÛ[rzaD%ƽ¯ÅSØ×¹Òøç7 Á‡;"ó%O,Gaes:εç2g‘ÇÞtR%>”¥I æ7iÚµ;Øù,Î’`kõK%hDЈßXˆ“maîÝÇì’ …¥âœa ųáb•Ž-%ÎhÈà¨ñÔÀI• °{‘ÓÌÕ7g[{H"Ó·°G×(RJÖĤ®PgŒHºX­ó~ø6hv÷bÄ„)Nà‘o\jr¼ki´Û¥Z²ŽâÃ‹Ö +ï:/ÿ©Aàéžµ@vô®ž å—þA·žÈFàQ=á'ê²_Z»ÔÙÄη+YS1¹Êƒ”ÞTRcÖì`Qœú}V› v1g1ÒŒŠ$| OIq @Ý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™¹ííD\Ìxf¦Q3 €™››Ž bïàá´°tPýå ¦¥¥ûOË?.cGþF:-ì~˜ÙØ;ØšÙ¹ü¥ø¿T13¸XšÌ6fE-)y •„¼@ÂÌÎÌÉÈ èjl4ÈMÌìœÍ¨æöN›[LìíLÿlÍ™á/—3Ààì`füfænbæðDp0s²:;ÿ}NFv.{àbڙظšþSÀ_»¹ý¿ +rp²ÿëaûûK¦hïìâlâtpüͪ(*þouºX¹ü“ÛøØ›ÿõ4µ7qýgKÿÂþÒüE]Œ€vÎ3w—r›LÎ6Fsÿ%spþ« Wg ÅV@p2³0r2µ1svþKó—ûŸîüç>ÿËîl<þmÿ/¯ÿ¨èâlfcÎÇÌò7§‰ËßÜ@;8ÆFEÊÎÜÀÌôovSW‡Ç~˜9ý«ATÿÌ õß"ŒLííl<¦fæpŒòö.S¨þïTføïù¿Aâÿÿ[äý÷¿jô¿âÿ×óü_©Å]mlälÍþø÷; øç’±ûß¼l6ÿ'ÿÿê©aöoEþi¤\Œþ¶BÈÎâ¯ôÜ l\LÜÿÅîf¦Š@K€¹‘Íß^ýË®fgjæd´3û«é¿Ú  gfbú/˜ª%ÐÄÚîŸæ³ÿdfgú_ëÿ+Ó¿ªgÔTURÕ¢ýßîUz›¿óeÀÌÁùoŠ'ÁEÕÃÁ ð?ÓiÈÙ›þÇâ>aa{w€=3€ž…‹õïdap³±úürÿ‹ˆù?×rF.N@w€ó_Ò¾™þÉý€Þ¡³3±7ýgvT\ŒìLÿŽÛþM\œþªü¯àïöÿ}ý¯Á73s73[ûeoÂl•ž•áR‡72%ª3ÐÇ >âPÚ¨ZTè_cßë—¾Ë]iø^ÂÐ4ÃóÙî±|æðq(Ms4Ö‡eCÙ›jvU€ïCJÝ_ˆºEÑÉI{Ȩ_Š˜q®íu½$»¡ÍÁ¤~´7¥¤¬_òE0ÓÉêsýDíOú£ÐƒìÑÉ×$­!³ ¥ ­îçÙ9EÒéÓ#åÐøèÈpï dÿ!mn,9ïDŠ(Ç\<mµ +±ªVõ¶ý^Nc_ñõiܬ槕Q¿ÑŠÔ+«ñïPYŸÌôZ#Ûõ½¼6SºßS7Cç0ÂþD¶X>ªO¯Æ¶aÕl¾JüÁøÒŠuwßùöüh¨ÁŽ7n- ª}»›ËÏì¯ò[ùwµ gïèÕËä‡× †¸ºŽïÛ­IZR » ˜Yâu#1¯› t,’‹¤×CMMW•M¬îÓ–$IÁ]•Ð}}™ß×(+X{—üÓHï=s]Ô½í<›Øáb57U‘Ct¸¹# ¹@ ²KCúFúØì¸5Ö0ë#‚OXíg½FC'ØÐÀ"¤¹ú,ï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]ØSanWùì72§`Üð“!â£àúz¦ÓÁ‘,£¸º!6ãã +d-ãµ!2AnXî}uM#Ek}ÚÛÀ£>ñ´0¥š¥b˜)£9Ëà_dö%ÐþÄd'~}?ý›¤þ ÕÕ±9.ß Ô¤ŽJ·Mµ`òÝïTî%–äS#£ÊÁ7v,\<6Ós^»9¿Œý$ÔkŸ‘)Ïh3§‰+¢Žò\ËÎjx.] íé„`lfÃÊET“»ë£Ï4—S»/ÎDüCÞS[Ñ›'UË«£g¢ªÉ7fàzÀXŒ +<$Œ^ƒ™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ª—‚ wgÞ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ø­ÅlŒúÞGéÂìSŽÀ>eñkk©s‰÷ŽÍ¤JÖuèaGÞvÔ3ò'Ú‹¨ôteÊ'þã20ÂZ„ù+-v ¡s_±Ò¸Ò–]§È퉸%D48_‹2U4óô¥Á‹„äm7«ÚT#¿ü”©Ï,8dÂbI¬B淗΢¸e”ªø“›øç}F?|o÷,º<a[#†h›h‹©ŽÚÙœ¢ÇÑ¡™>J úDhŸéÉèl†Ìév¨À |1׊,=EªÀ1ž£›÷›,ŒzJ ‰†~ÈK^Hü#5kÃØ´ä*~ÎxÓ!® Eجͱ‰ÆP¼ŒG+ÄhF ,Z bzÄíWÂ̈•b9Û „N“˜_ùQ‹òèÉ4¦3廤ËB(‘;šŽ»uí°Éû1|È>ʺ>´`¶Ò6»A2ª çO9…J–_Œcñj`øê•iɸE‘œÈ’Dü9Îè)Ï…óeü¦õsÄt¶û)ƒØó]øƒÜ &të¨*é5–ö0âŠ?ˆ÷©Tqâ·DýJhž`h¨sp~ +ÌŠÚ ø,Å@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Á„Ð’'è4ä²¼=€¨†_¦ÈzÕy¿É..ZôuͳPä_ÃA¥ ní…ŽÇ´/®| J/´aGÀó«b“" óö&~èùIªÀßþÑ*1Ö¤ó´÷‹‹Ó€w“ú7¶ÉŸ—0S¿^Ë1š·)_¾Khñ/Z‡m¬^#ÍÁÍ ’ #§ƒvÛm8£Ý#¬XeÞŒÜË2à¿Ëƒzs_Õ¯“mC`ïZ2r8É_'¹Fväf2ÍÍgÊ0Äs +ÒÀ^Ò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ÀàØ“[å#.´4šù¢%0Ó-[XF°cY?EÁ?UH.R-Ê £ˆ}¥‚çר_³V4 =µ˜Œ™±q¯x™Ó˜uTú>Jpœ²4.Ã@ñ„ïÁ°»Š÷”¬õ0“éd1‘•{/v°xqÝè°ZŽiÝ&r/ÖQ‡B|'„ñjŠ6!ÔæY"žbx=>ÛyòÁPD=áJÚ Å¾ oDãÖ"ÒB¿3hõ\¼­wxLÏAYj þzçð˜_6€Ûèm +µùœ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¬Qzt/ w5^b€òœÌuŇ 3dOÒap!^#{ÛÇ›ÉöTº0cãAf–ª…5tá,‘Îÿ·Ñ>ú;Úk¨[µìÆÃò©² ¢¬wçíO5:Åâm°Aí@Yi©<¼†bV©A±qaú \c6Ž'dR«€ãæ{7­nZ‹W‚žqꚟØèUWÕ+wׂsëÄ–“ñ+ŸlñË-ÓGQØ{š Nîê¾0ÈÍ-ŽÃ%Ð夭m.ιŽ2ût]#ï䤽0ç6+ªÌ#–Ý(æ$†äCfÚ™°ß¥zXØœHÓÆ÷è±p2ÞÉðB^ðf#Iïf×x_n&³„Müè7¯tW¦:Ð'BuIÚßdC¢Ÿn%,~úB´ØÏß hQ(žC£Þ†7 ãÇ m/7Q‘¼ŽÑqJÁÁ_« gäÊ%èÎeµ+wØY¾vý‚‚y`hkÒô÷±ÁGv=ò3ÿc‹œÜkç8³ã©h»·:@P]$P·ã¼­Ûj&æØ‚ˆ–AóªíI´˜ZQuþ>sÑ¢'îïߎjéZˆJË+Ö‹gÕ/¨R¤þd¿CÀ07ôFâ>V¡êxV#SþF G¦¬{ís$¯º¨Ð6Ù‡àe8—Ö߇SµÊ˜. Ѩb;ý}ì¼È |sSŽrÑQr¿q,7¢:`éØÔÊ’û¼Gß(|ß5ªöÈò×ËV‘ ¾ß+ªÞÜåHùîÙã vFw§d€Ohߦ´y˜µK¥yàu9-™—» ¿¬ÛÚˆÿfÓ_ÕPû✮’¬ë/°~ë@p½ ö6Ý—TÏpb¤£¦ßÿ{YÁbf!ëyk~®Ä^–Š;±½¾´LD°û©úÇAvpJ’Vðä)?X,g/+{de "ôÞP÷ªÖá áp”!`.nv÷¦ÊGNÎF¢­ %韥$o8Ÿ ›¡™Ä&û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ü»:ˆŸ¡2ßÖ©Á7÷k;m慞ݬ+é'ëT0è^žÌ™h`_x¸²4]‹åw¸iGø$/r·ÛÞîŸÁ\ ®áGy t:a*bóîUw'lµ!«¦¤ƒ‘¨“ŽÕürд`3ò¾ý_¨æ‹[·½| 1¹GŠ}!/óßVcYÍž*½?7/k&n¨¤â?kw‹ GÚ ³¨’ZŽ;©9yÔG>]!šQt*à +Ý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@ÄôÑDvx™ƒïˆß†)~–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¾£$ƒãéÊŠè"Ÿ¢1¤¢¸éX$Á-Ùÿ*Ò!¢ù9JaY±'FëíR€>4kZVÞÉ ëõŸ„7kuuf¾¬ŒU®:›ôNŸ%ëâˆL "È`ªhyM’M"Ñã +SUŽDŸ˜ƒpj U=y(Ž~{×R'¶7UÔG.!ÜÃe®ÉA+ðÔ±·v0H­7)m(pÍ~û%ƶ*¥â9êÊ<¢¨›]`Òël=šV¾ê5³ÝF2…2ÀG›±‘ƺ»8Öñ‡%…x‚©ÙŒx&rq],`Ïcj!¬¢L›‰‚ꌻxݼ'§x¥V‹–[Pb^ܧ:Û+º]©Ï`%ƒ®CP?A>|&= +—”tšJ°7ͼû ›¹yéÐjA0/Á ³ bHgnÁ¯'Š€•é?d+lDVmË$;6†º—u™ 9>üAZØÁíšw`MíÙÝF:d”ç‚y³ñ\fË_3e4SLÞë‘L»Rzà£Qu“ªº7‰P¤ëaÿy=è¼õ%iqÿ8uëØöÀ—Ú[Ô+Ædµ!‰ µô@ÓÅÌs2{¡¼ˆDî9N”‡½3BfÙœ—p'Nž{õŠ¹þ2þª€³:r‹¢ÁsšC¯SÖI‰iÂî^ì< +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/;˜˜ßï–ª%—âŽ.’-ZëÊ:‘‰¤ÙºþŠá·¨쑱V&2Ÿ6 |½¥a>þÚiÈG‡-ϘŽµ­DqˆŽÏíëh…k{²÷Ÿ×w=—ù-îÐÖbÇÔm‘@HBa$΀ž\?¨µJªBp§Já#«ÕmfI˜·PŽ*Ál›õ 9êu™•\%¬=xYW:Žì]ÞF#wÇ BG°')ÁA:pôÉèzGu=ó¬”í»ÊŒS€ßGe_p×Î@!ØŽ¾ÒÁ7 +ÐýÛ¹\g|Æ\ѤÇ/1—«ÂzwîP|MF¦‘ƒBXOèȪUŸâD b³NGd,ŒÛ÷ÒøŽ?q7<ÚÖ¶fÞ>õL„ëï( åAÍ…3ÓäD‡Åi÷Bý—›Âör)èø­MC½Ã©ï/‹ûoÂJZìª ¬_?sêe>åÀæÂò×!îÙªŸI à®¿ô{»Û‰ol0Ê›ÉÁìÙ•*I„w;‹ºpœæ+ÕF8»Â”›¢áÖæú¹ù çiHÛÎl1|(ä%3¸?îcî³{d=ðK’~kÁ¶CÏ ˜úÄ«ý¸=q“¼g‡m‰Ô!–¡dϨV´ R©Se†W†HMIsÑÀq…°£ÌPÄ\?þóãLèQŒÒþ× !OáŽ_;„í@Þ¹ÑÙëÁ–‹È¡a6 ¹¤ô¼ëâqþxÎÐEÀE™ƒ¯ 8JÕÓÇþ{,­A`´aý˘cÚ5ôÀø»Îü¬ÉÚék‘óýÒÅz_ÕXƒæg_¡ÈkÈ;RfxËXcïEHÛ«Ä· ¦ÙR÷¡0}²ÿVÇéêúÎ~GE¬j%ÖïÔÁçèvÚù`ñc¦ ¦HfâB¤Ë¨A˜ûV´y©A\øên¶”/Ú¥•†2LæN’D£^º¶î"sÓZ±‚‘ñ–-¯Ðí-hR¶ÅŸƒþ¤ƒ¬£ ÒVU‹¦ Z‡iuoøsïð ãy¹?÷FŠÏù¸¶\c®aBN/º©yØ,ŽÀ‚^`Ûê;éº$«…õw °§5—½¥äÖ ÷Ž7kœrpJ^.~éî¿ÙPÿÄOÖÛÄX(4xU`úÄ‹ìó¹ï½Wù4|ÇGÆ7‘cOÂ!Enqµ' ØDv3d«pv³è~~S‰‘<¤†4Ÿ¢¦…FîØ^.ÐŽ;$¶‹ŒímDˆŸNŸÒWß”CgÝ(û¨DcAîæìw8ð“ßðz•ù‰¶h[Oqw¿-§Þ£·@|¿«ª³ø;ïÙCÏzlÝ×{e}À‚]±ƒSNu©‹ùIToýYêŠfMo·”8i§;„ºÑ4M ˜É€•@èwrÅÎNêäl=.½[Î{^By¡‹7 %åô?‘ëz|H­ÀTÖ³)zë’ ¼¤WÊ þH‡€NM…BþÚãû$–+¦‹ú‰K=Jtl~mÜÔD‰noy'¾r†](³³‡ÃÕNtjcoû ‚€–7kï.0QèžX´8¶ªöB,Ô༵Ó %•˜ã·xi&µ^Ùhh¯]¿UJ—W? %ßÖ|”ò_¹ît<òsø}¹ä±M¼h]\ÿ›YìÁ +ªõ'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Ⲷ Íé…§îÉÝ¡J33k©ÂCÛ@ã8ì"õkASÀ’ôLd® Îìs¨>±ÁOsô)úAh#”;,ÿé…ÞWמõémn(7äã@¦Œöˆ@)œ›¶äS7ŒÝ„u6žßàÔnÐRq¤öCÄÊnò:§«ýÅ~FÊr¡Ë NxKéD„x?{o©v^¡ü G¦Ù=Ó)+èŠÇoû·l¼‡^b­ê¼iMìl‹ykÇ©‚j®¾kÑA5ö¼;Âÿù/Qþa¥‰âC@þŸƒª¤èà8à +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?jVxf¨Ò‡(m‘ëyL±‹‡ç©nBÀl•­šø‹S³¾¾×‘3Gþ”BâÒ•[5ª¯n†"_-ÑkFV»½Å8Â$Y øRgºëý{ßqÿ–¶úØ'Œ¢J¼ f¶^ª .`Ý*ÀÝ5cUO®'¢$ÉpšYh È;¤@ˆD§…²ä²«krºr!ži‰1¬>½åY¬âõÓÆ;Öï·Zq#q¸ÈnQxH%C´quÎbÚ95Ì×ÅgË=C6“œ¬ pŽ®´]Áöeîg˜Ð§# hߊŒé3ÔÐ…xšS0süÕ2¤xã––ººÄFþôEgòøæ‹©,»ý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 ˆ-¿q û1C–g‚–w—¥&"_q¬ŠË×Rì[ø:_ŠV„¬ñ£6 —Öɧ› +ï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ËÕÔªƒ1æt¾ÎuÝ!MºAÊ®ï Þ6 à,‚càŠ1¤þ”qím{ Ǥâ‘8¹únäéß?ØÄ\ ntÊôñ·QæèêpADh$ÅEú½lÉúÄ!#YÅ+•Jr›æ#©¶ÉCEƒ˜ºjÓ—Øž~¿Ø¡ +ÃÕ³5šQ^­šõÙZfé©4ûå-Ie U“®é +šÉ,‹^Ì*hÞÔ@k-¸¤òˆóÅ`Ìhpà³fŽçÅ»­!4ÛC7©”aDNìú!n*IìÄc]= 7=³'|D±€úÕ$X\Ò;§Rùùüš7ž46ÍF´k„ãJWóÝÛ³³öªX +Ù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îél6˜†ý\k˜H‘VB ¾ä•íé‘0ßQV‚mZ¥ß×´I=v˜m^õmù÷ fC÷Rp@][0‹[…B€žÉˆáL~ÄïäA›ª…]úåøïãíç”K*¿ìø«¼“î™b§çcÑ Q´WS¨Ï»:œÑCžÅéÖ ä9OCüW•âB—9ÂÓ:Á£ÿø `¹¿wÁðí`áœ)„^ÖŸÛ‹áìù*–C€ìë9˜|83/yí¡Mª¼xå“q¿b‰¤°SiHP8?áÀª*?©d cZ“|G>9e¬­'×QÂË_AÌó1I¬ó~/ø–dúI¬Ì¦_^¼HDWRîav^]Vç’åAÐ *\qN|n¬ó´ÕSxùÜøÐú^1ïœü‘¡u÷F󻈥 ¼6¡ŒGì5éäö•J– W ’_å×iú†²ÕŠó”‘Ñ|˜â/ôåá™ÎMÙBŠË‡šÁz¯¦LCö™± +¬Ë.ê‡}D×Ì M$•€29<ó‡•1$5ÖøY MšŒØ#ÅàÈfdØEò†L'›e3 Ž #öÔ€s*þ7ùÁ è²Pkâö5hÊ—ù0ýD³¶žÅ‡?ªR©=_Ì|ß3j¬ÇóìDE"F…Uå. 1&…•I Ft($ËÒ»¶ +â*á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’ƃ|Qh Ú¡ÿî>†2v£O8xÍÕHØ媚:_øÓ秜ØGÞ8hùõáyQyáíšßål0ÌÃxñ¶ât× ½<•W°Fôä‰Yä)«Ë’%¦H¯ØÑä冰<–ý&Í—.!l/C2CÉ›ÿÃ’iWMvM´a¯à¢¨ ºÛåòÏ’«€G¯M+ëèr(“9Ù 5ØöB/ÏG³8B°‡öšuæÑ麃Uʼn`¶¢LWí£Ç'NÖÄ"Ên!Ë·³ 5béË &Tæ}ûÔáJUÙ°n“ÄZEL_,”ÉÜ 5£ŠOË[Ât¾O7Zî`EÔæ@Dìœ[ºã.èØWÛœéИ»ö×NÀœ¼^›bßFQWee{6Ý}®¦ º4èi^J2z¡¢ŒÛ”+Ρ}`Fj9ñÌÌ"¼`³’…2¬ªul당ç­åÆ7æ·׊5^ ä®ÔÏ‹OûŽáí6å MÜ-UúÞ_…:¥y·”+3Í‹«œ|Ž(!}LûjSÅß¼¡3XóŠb +÷z¦iB‡®”wufX]¹©ô£~n¼N-ã1JtIà³7–›fãm~|GË×è§õE’N¥h­ÿÁ†‘ÿÜÖ1„ÖZE”BôÎ&ÕaÁðÃ_ç€Õ¶ÇÍX¤kÅǠĀ%_, Å¥oCÝÃu´Ú[ˆ·Q +ù¹ñ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ôu@ ±äCîŠoãMf_©×íÞ¡µ]–ì5mÀù‘ßgsð=|é.°«»PŽŽ-Mâg»åþÌ>lFGÑ @Z¡Ù‡/M}a}Ý‘{.±ž~ó*½?‚ë&æa_³Îé•dï()ê> +·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ßÍ ™?œù“•—3'nù1^7f|fflPšÖáhÀ•+s鮞!×ÙæSÚ•g+qº¾v ¡zÊÙËI AYÎ*» +Ó2±_,¬0?$éýœEAíÓ!yyÊ$ð¦Ïœ6{‹1‹'®[+\Á‰3‡ŽŒóàyp)BèÐ ãk3¼Ý(ì08á^,Ánœÿÿ‘^‰{zË0¤v±âú”ü¼bÇÑpƒ¼¾¾9ÙÖ˜T«…ÁØc`6m«vt1K`êSL ‡õHˆ^› 逩L:%–«¹¦};î—€ü\ûÀFB¶ÉÁ _îgì@YïC½˜¸gå4†²ÉMŸ¦ä=’«¢#À›håÞ„*ß:ïÉ컌Â×à#áå}Ç ØFóG…«SÌ „¥é½§ß£Mܲpݬžo¤ßx¿Ðõà¶ò;‘±­™‹­J2˜´š¹¢'VœÒ&|`!4ûŠ›Ô§‡RËf¥È)žJ¶¥#ýÓ•îîFmÀæ,ßþRQ$B¦ð…dU;ä†B‹yKštÌârG¢xíÈ*,žo8˜:Tœ8”€ù=a$õSD0VE÷Rh“å{°m+d’ k@3-On¨dÅ7§I¨í¢;~¶—¦öìW¼Lk={!%FŽ¥#Þ„[€.Îpa7…t˜Õ1š†kvòý󗱚_Á×Z]PÂ’µôú‚¬³4 ^¨!ÞR³™îl¹WÃ@à.â•Þ¼§“¶f~B¹ÞZ‰©ZÛVÍã™åük W¼¶Kçj’Ôª©œ0[n?ZÖyzžö]> ­XÐt™Ä;™!„€~ä›,óf$RI51ášcûÍÁ†&Ö‚ÅqŒÔ×@ÔÊKq”ÇEò~8gøm•(©°ò~s %Öf×l·]å m‹p†fþp}Ý9{â¾¢î»ÙÃ!ŽEýˆ"; èô!ÿ–¿moVê‰à™ü]•ü”™aŽ} +ªjDÒG@œ=ù¢0Vþ23qð8@R‚¢Sx†€ÀˆQšk>Ö˜IÛ»åÆnÕ@ Šœ+7ƒ¥ #xA&¶#A×÷“š k‘ìÚIÍ!]i¿ƒ–A!’ª5•JN¾w¢O’ ˆvš·Ò‘*âô*,¥×¤Q*Þ=£•^¯ÄìP«Üé툘Ífó®U‰{™™®ºû¶®á·Rû™ÁØ aûp"ë¼[÷—– ®k=¡_„ ë¾´6÷g]Þs±ã¢V×/h_ëìË4J#gBó³Ä…¨Ýûí:½ôy­ã~ó•é«©W-ªuuàúàÒã£^N[pa*'õÖÀ+Z“XÁàæකÈ}†J~NZ_?ÿ}þiæxA‚ÂðòÎZÊ6š§Œ u£a£ÊýDAEËÿŒåkd'‡Œ®2Õ؇¯ +V°î2»“u=œÕÏ"¨¡ ¥}ŨRpÔG0Ò|Ëÿ°Á÷v¯×ã#Ði¹j3ÍTâè(3Z÷†]ö‰6$áHý.ù2rä"Šñ.Q}Œ[ô(~áa¼ô|·g7LÜëèi GÕzBƒ¤ìò°ôÉy,£–¢€%ÝÞû.î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]}+7ÄÝ Ú‰-¬ú‹O ›ë}KHE®r¹ çbÛŸÉwO0t©„oµÆuZ¶Rèt•qø’.ùã8M“ƽ7·ôº8m [lC)¤ŸÙ¾X<‡ø¢ø¨7¢rLÚIQº¹RоR>„OôºˆzMЃ·:¨ “Päkæ ŽwS´RnBßÆÆ<9Ų|<ø{_À+¾>¡zZL¼³S©6v˜I + ?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ÅŒœ¼  )@ h`e°ðððÀQDíì=AæÎj5e ::úÿ´ü0öøÏßN s[åßW µ½ ÐÖù/ÄÿñF àl˜¬QÅïZÒ +’jI5€$Ðèhd øîbl 2ÈL€¶N@€™#Àúß €‰­)èŸÒœÿb ;ŒNö@Ðßm@w ý?.z€=ÐÑääô÷r˜;Ù:ÿí³dkbíbú¿v3»²w´ûaó×÷컓³“‰#ÈÞð7ëw1‰ót¶0rþ'·è¯`gö7ÒÔÎÄ埒þåû ó×ël²u8ÝÿÉe ˜‚œì­<þæþ fïú '­ù2 8ÍM­NNaþbÿÓÿ¬ð¿Todooíñ¯ÝvÿŠúŸ@ÎN@k3F8Ö¿9Mœÿæ6ÙÂ1ý3(Ò¶fvæÛM]ìÿÃç +tüWƒ¨ÿ™š¿$ŒLíl­=¦@38&;ç¿)Ôÿg*3þ÷‰üß ñ‹Àÿ-òþ߉û_5ú_ñÿíyþ¯Ð.ÖÖ +F6àß àï cüsÇü¿bl@Öÿ›èÿ¨ü7Ãÿˆ´³Ñß6Ûšÿ•‚™‘ùßF“Èhúälb03²þÛ£ÙÕlMŽÖ [à_-ÿÕF 3óñ©Z€L¬lÿi:Ç¿]@[ÓÿÊü¯<ÿâÍ$.)¡,£B÷_oÓE}ÿ«º³ª‡ý_bÿ£y;Óÿ¹øCDÄÎàÅÀÎ``åâpr³¸¹X|þ7ÙþÃòŸky#gG;@çoÉÌ,ÿ*ü¼ÿ¹Òû/0â¶&v¦ÿL‰Š³‘­éßÁúŸ†Ü&.ŽŽõü×Yÿ[ð¬ÿ5â@ ;ÐneÑ΄/Ø2=+ù;ohBL§¯‡b(ľì‡jq¡­]·_zø6O•á[]cÓ$ïÇ/…?öïû2´#=XÖTÝ©À‹2šÞBÔ Êv.ºƒ@&ý2ÄŒSh¯Ëy¹-HmNfõƒ %eýÒ7(ÂÉv6G˜ËG2×B ò{$_“´Æ8Ì”&0´ú¢?§”IÇT£ÃCƒÝ×_{÷ñérã`)ø\!)£ürñµÕª¼"h3Ç&¬±„N™Í»‡¤¹ï°8×ÂYÂù6ª†Ü|.°oŽ Uà‡í”†H\ά={“fzüñÛwšÌ(;InjÚß1$“.]dþ¬²¡ó»ç§c!˜-ÖÅH»FÄäôæÇ€;Ãõ=Ä|Û.ÛE‘e ë ¼ŒPxÏNV?±W£¶Æx›5VB¹®u%GñèêÍà©Ne„/GçÈƬ÷v^8 %1ÿƒš1KPè½qݤA‰?ÇèñQÚ!©æ6ø$Þqs/ª A{øƒOÅзëðÉx~X¹vÿØïîYÍaWtM=#à„‚&æ¦Çå@ÀЫ®2 å‚+°ƒ~YqWRcŽÏ67H­ŽÓüÛÚá7ªù« Õ0–† ¶_¼Œ¸F?‡ÚŠ‰½Ž ?B¡‰65Ôó½ø® +ñ½¿Ý¡$ý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„‡Í!³ÿ²|Ø=ðÐû})ñËHzÕøQ£ð·)k{U“›âí÷T£Â•¼hð-· ÚyX3ïIIìŸÐð¼íˆBÚþ# +†{z¼*†ÆO0RÕ[|+uØ<»×xB–)ûµjÃñáÛTK!ëßP.GJ¦ šïHídÏ·Âó‡8ÍÈÝÑìᣮ¨¹)KÔ«£" [ßáØÓz'f?r÷g‡ÏÁ­õûd„» Ë}áY‘’¡žRÞÃþÛÈžiuMÛ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”ûsuQ#JöõÖ1Œsoæˆ •X1K÷·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ÿ¤dá,šýÆWý2è5÷]ËÚló±Z°~ÔS£çDôJݬhö´þÀ†×Îåõ!ï뱲㹦ý’ëÊ ²ŒGL"ÅEàcï/e$£+[>»lÛµ—JH¯V—丵^tú¨±6oðºä,ν«x‰B¡¸LE$Éz2¡8~´"r¨º\pyç³lðÒtR.—Èšqáp40i›­YÚ† >þª""*`¦É eã¥R¶!¶; +Ô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}Oi²~FG´ÝÞÓXÒ€1Ó¯,»‡Oœ[ÑH'*‚ÏwÙç Ý;¾òk‰¯Ê¢NN„5S¢í}ùGs½HûzÅZ¨½B@0„¡ÒÒ¶Ðû´~¼øá4‡QÂYìô oPÇÀÐ1^È'¼þS&J–pa•K—h}%ãgÆ1Œ[g€¡w–¨ü±¦S Zߪü¢Ee} ;ý°Ú÷‡O¿ÿ´™“œV{ï¿4êŸ1;cr§‹ª`*Æ*îòÐ<Àò`*̽ö=­Ë¦“îUn·„ûTÕLéÜkwÆüúWJÌÁ¶u˜²")aAö%ûýº¾6Ê Íkö£ï•·ØÃݾþXD?ãÈÑ ¯«K”бïk²Ÿí-á„Ñï­þL*‡BåÚI×ûöŸ¡½©c×üóFÞéKhØx_Û¸¹Cëw¦Ì|•5ß‹„ãßÏX8p®FyñûÉŽ ?š¼!Û™û[ кN½ŽZ9ËÊNøâ¿‹ˆƒ·Õš¦Ãˆµ¬£¨é‘æ=à³9$¨Qo©}õ<Õ~'ù9:xö þ­CV´ß?G¤kívÚ6ü|<«ž×XK³ÿ\DŒúWÍ/’Ez©äügå=3p•7M<~¤ ìôŸ-—§æ'?%ʲØUû²æ&ì +S–2¶ò¦,|Uº•¹åÿŒ ²]d§ûHÛ±^'Óàrê¥Ñ'Wží¼IëÛË­lžœ‹¯‡ýôÊ0àU\|¬¹.wÑ`7ÐÛå/—êâY쵚ûU¿ð½@'Ã\Û#ÿ¨tÓ"¥ÍSûã†ÖÑ Ö9X³*¶?"D'Ö ótÉ‘mtåÊù¦âÜÓ^ Ê.ΡÁÕp¾iÏ€>°¹ ã¶i¸Xæªl“£(eUÜ"!÷{d?¼ÍÚVÊ-v+‰o y×ÄO!üÕ²«…ŽÝ›äÐÔ®¤cçÏÑûð1á°¾tùTÇÆ:Æ›’Ûô8™k‡ý½+]Qaÿ±ZYùîÔž/ùZ¨•b<Î ·Ø!P‰ýl•Ÿ¶ ÙçÄ;S@gû•ÉH¦ƒ¦Õ®e†ìDe7#„ ÂŽpy¦#›±ÁR¹ŒÿƒuãþhËNqšVfà î™q ª†ætÝ€-« ½Lx:]Úñ ¾¡oD`I¹¼ ˆïÓ2œ&3¤Ÿ“’³ñWzøµö^––©ëLrH¶/±Ò~Ö…DDÏ7öØSb_O)9Á,­¦)ôü±8lÇz¿Ü*–\qßiSgb`ÑÞXpœõ ú~0èu†£ÆBß^ ¨íHßÿó1p}PŠÇ!"ûÀ#š†Töƒvy†.ÁÅþh\Rœ—xF‘k¬^ºÏóômTkºe¡hèy¬$êUÇ—ÿ÷À…é#ôo#^qÚÂ!r$%¡é%2j¯ÓšuQ¨šm²cÁ©âj—¡«„èo6¸óø®†LãÑEP`þÜ°+ ÷/†Cn(€¨³×v¶YÔÚð­‹¥mw4˜ž#¾ÝýpŽ:´B@f¤­P÷ySú6öâˆ'$m K?ëë‚Šú÷ù7—3“ú\X¸>¬V°a;å˜ÔP€”f Jÿ‰(OÍÕ"?-‚+Rûüe9oA[-wõ,NòµkEoãˆtúnÉ•Ãê»y+©2:³š[ 轕µØCNbå’ãi›Õ¤ºè´ò%©ê8»p$4 +ÿ¡QÁ{þ­ +Pä±\7Š‡òÝÐBÞz¾–ܶ< +hÞãBÚ'¡ê{üŸ[gq«JNi9ª J¡ö–”ÍÎBÚ &eš"¡„™Géùý¢à¬äñtºls5 O·±„vãá̇ Õôw«¨@…úÈ;fÊ>Gé„b›žy +0ũ㻢×JïØÄæv/éÏد¹Ci)ïiçOî‹Z%ãM÷Þß÷m”Α¨ûÃMðQº½›š¢tžVávjÚ.mOMè¥×¤ù—©b}‹Bq1Ò—º‡§Çòº +®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×¹­9â‹ ~c»iî' àŸ¿ñ«K¶B˜ËàêÅ©$s÷\ÉÚë>ˆÃzÍ:¡¤¡RÑH-@×_|eß·ˆ{ +>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¿™—´¢´•®]jØM–ìHUUÃ;ù·‚jŒ[ó·oi´áPä-æÒãµb‰omÈSn,aV&d­ ü _zFö~ð\ñz8¬+Do¸Ü5"ðˆ¬Š›îûRÆ÷Ù €#‡Àž¿nÊ»‰Mï$üÞÐÈ£€3(J±j½ÉR&YK6Î毒ͮÉ$2)¡S{yv¨É/îje1Ù‰ñs‰Õð®[;±ÙžI´¢Eç^›6ŠÖn8¶XÅ|ºø|…Œž +]éû.@U¥”¹7n0B¹TñÖ€•Ü’ü=²Øü;ApÊ|,êºJ CåD…rÿ}œ_PHqÆ»LO…NEt"†‚©ÛAѲ‚÷&¾½&WáõÔ7j§qÝÄ´Öoºêe--Cª±G.y–æQ12Ò7C}Ϥ$)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+%{ 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Óý°¡©C'We„‹ŒHìE¨¥XÖ{°jæX¬ +oöw¡‰Ç÷ LN(Ú–Ç•ë|¦ÙV0f†BckÔ/ÖözåÄò«ÎMüPC‘&§¤sâQOŸîì?`øá% F€Ð=dGì¦[Ÿq»ê–Ÿæ5ÎS-ÇBÁ…OeÑÁyÞ'Ör8·w|­¥1Š ×þ3Áòkl/ë²OKMêéòdËÖ0q{mo˜[7+À +u€2DZT‡ÿan<øF¢àƒK＃ÒÞxpÂä_µB…•’Ä5$(Z£½X÷˜,Çn=F„I1°Sk€/ô¿Ñû’-Ú%6©`Û/XwܸýŒPä°X{]‹{ÁõIê=/uµJLÒ "nÏÖ9 áTôÍÔ €¿|"= ßäüTËKŸŒ9¿ª>Ì…RUC΢•ƒèÉ®#ÃÈm"æ%…gL3:Ö*‹¨þÑß·ŠËgó6¾OžÐZÔ_Å­iÃõÒš=ÛACز†é™ÑàØׂ‰Ëíþ¾¨?T +Ê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Žš +/ †¿oy7¤‰¾Ž¯‡öÛ“HlžI-Z“ß]IFØõÖ`/qæÑÍÓÆ_àä87 £Œ êliC9Úî |Lsñ€ÖãÓçjPO´ LÔOër‰ñ­w°D¸ [¼Àºê{½mYübbžšÜ“sX¥Ïqf#<<Eq|ÑE§;¸¡Få¹úÒ5ơ̂܀@ I³ÛÏX:B|Œ.É;¦®ËhˆÞ_ñ4cúHC[}\ Mg÷jT?) ß‹ zYVÄzô.Ž»f6Ä!v³ó£¹tÒÛ°§*•$}»Êãæ“Ve*"v1pu'„Q°›·°jw(»ß–tJŠî±˜Ysé–葈çÿÌÙI8ï2òÍ‘¿Ã,RB¤¯)mE+:’­'¯Íƒ¨D®QŸíóºåïÆw¥M0$.„¨eǬýÃu ‚ýý.òÑ +¯)$QF!ËêbVqâ!Š–i× ÛÔáZ4 z³2„«#µùjÆa0Ž¢”½¦wÝ̳ Mx¹c"ve·yäÒ0Ëdao† ˜’|¨äÊÎ |ýªm¯;°”`È$ùúgH÷ôT¼‰K6lºæð°1I§Áü°¯Ì~δ¨ñ¬ &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¦¯ge&ü¿ˆh8#u­÷$å†7 ~g¤ ÌÓj7#)¸"ãbø=ËÈÓF7mõÏx|)Ê ¦R+ËY'¢Æ‹f¯µ"­'›é *œCêþôêYßFÐÍÌ{4rO‘GÕÇ•-ŠÜŽf>>Ù£kïSë0N^6I”Ššwu~}Nè]Ä1â&ŽV—… +é0;êÈÞ šGû)¼ÕÝÛ•qòG­‚}¢v7~ýUÌØ{/ª//¶£@¢’BxP ?×㺽v/Ò"¢³¬É–²7~õ¥-°ú¾Yâb²4GáY±Þ\ÛêùÑò:u|?í¥LTj/Ïäœän”…xÞN[³Ö´Yg$×p‰¡ín,:ÆèÅ`¶é¶ËPÿ–ØUƒÙh|oätƒYGê9 +GZläÞ¢Åë6}oÛ,“Nxúœ½™§~ãIf7Ù,’y®KuT§Ä‹óˆÞˆ:‘¼ '³é~”*=Ï¥aæ½L šá(ˆ#}AÀ·åÖ•INø™Õqy»±ýQÐBþtSè³í¸ÇZ[ÕáZ”DPà†&´xf ;áÿ´ÜU:óŽ|wS ¢‘°µÃ;\¬¶W:[“e¹—Å4R{¤Ï5P‚OxfIˆõ$žˆÖÙyÏÅ+;S!ïuI‡b¨{ +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£šÀØà£ésÕYìÔ÷æÚÝÃv­ë\Z-þþªÐšPH‰›¡¶i)Pžs\Â,­!iӤʷüö%O»í»úI‡+mLcÛ3‚½¸/Pqñ¦Éz½¸s†EÐMšl¬,ÉTvßšøNÅ’ü€a+˜<òšO’ÄdäÒ”×3T §6Åw’cü]·yôZZGš-%(s‚š¸½€(ì5üýb›&‚Ÿ#)ïü{ë!ëúcàÙ¶±°M¨ØUO +ÁÊýŠ{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 ½ MÑy“àJjYÕŽËýZ1“¼iy4‘€sÛK¹|(b:9½”—î“úÍ4$~<@‘KŠ3ZˆÑ,CÎŽ$&35hECª·µž,6÷ ÇϤm’V-,¬ägigiNwtÎ5Βؘák‘¡½M€ØîÍ{ýÐh®ŒòéZë…å‚+S¶-; +Ûfãu¡ÀÐZKÏ¢ÊôG„“ ?î]¢ozNS¥•oNüÖA797mÄÚ¥âFËëŠò–M<§„+¶<ÿÁÑVxpÄ4éåq<òú4ßï,‘û’. yQÅbˆ½¦k_<¸þì…Aã%y!'^êsÿûÎo&dQ;φÇ0ç6æ1¸Üv„Rô2¼Ÿ£O´ªýe¾/—Ȇ9”\ý²±±©æ»ßd$ºcƒð +!üÂlŠÏY™Vß‚-#õÛ"òæ)ê§4|÷4û•¦Ç\£Ù.,u˜XÞçAO¯é8h‘$?³DUŽ$ÐN—ýÀôZO¾h¹)8’]íPlÒó!ÌÖ¦¾óí3„@ÍÿBkjû"qJº„‡›áûÛ>Ä£c¤ùÄþâÂ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½h 뼜Ž'éøbP¾DGÛR%F.ö¤Ä˜MXêÂ‚Û R¾’jÏú#ôF²X²¥;mIBuÃé[ï’r-v½Ç”À0[›{Ïf+zpl©‰`[B±P¯º—$I¦þ«ËOÔ4‹£¨mÑ–-¾±F¡mqšˆÁ†E°Xì´ïRbˆ¼mÊœ˜O6J„Gq?í5øÝã„É[Šóù‡1eÅìM÷jà…^*¶±*DƒÂû —8¢¦Ã¡-ÁMw¡ui8mB†ÆÇ»'¥Òö·$!Ù4Pz5¯¸"©óvhh Ø@}T¯ G[´Ÿ )k')$…=‹E¬Ÿçr[ý«›f^A½ïÌ÷L(T*ÇYð–® ùm]L•ŸòõÝŽyؽmôßñ»»%8dP¨?Êt ÷–ôóÔ‚¿Å4ôýá$uþŒðÍÆ÷µUCö7*æzü˜*,Õ¡/pz÷Ì°sÉyaKr›—ðö¨c'ô 2}T¥>>U@pÌÅÙ½îou)ˆn©E{⪛{0HÅdh¦m6™ä3¥_ O$h›ôV…DoˆÊcºMëÂðbì¬ó[u¥“Zö¦®Wº c‘ »f‘¬A¡é?ÞyÄ)»ØN¹³«_×<Éo|Ö‰CÀ)qf`Óí à ©[è—äÚrF^¾¼MUqz~CoÉÞŽT@G÷ûž®çªós8Ã/‚wéË›>Ÿ=¬züÀíµFô{»Gë§ò}¦+Øo  u¥šd¢C¢"ÖËþµÑgÃü²™ø )|òžª°cØQ¤ôš}(]u¡dë¯:$í›»‡Ÿú979¹ý#LòÔ# a™Gãzç-ï c_[rC!Ð4æ{½ŸyÏŽ§«Íö'çUº]ùò\°dêü6ßcÒ’vúµ¤cÈ4ÑkºãN4Ò©æãó0/L—|“Y´ ó©Ãü­Ä¼«+baý[|¬ÞYóR‡ø}.œ·ÚÞ ’†¾¬¤_®Iu•ÀÛmÖÕÉ xÜJǤ›R3C¼ÒÝú2ʾµ³´–ŽŠ”%^mÙ¯]À¯UfDjøôB¾ˆë᪻`â?;‚w¸3‰×™?·NK~îöåÌ&Ð×aÇ5Õ6ŠtÎooõš¢lAr‘êǼéz:ž¼¨È“Åø¤Æl—5Ûï8G‘Ö_~EbÂcÂ|Óy }Ð×vÚ3ÀàoC¸D{¯YÎÞßÂù·™.Eá›eÌ&ù°bÌÇk(ñxsØm*š<7ªÂæÔ0ØZÒ«­pR±4RÔ_³¢yC",Ì$6䮄Åx={R³T{\^²“)âl\É<óè ‰Axèw±D53®óå¾õ%7a™ +‹˜>cîÕ‡¬òš¢úcÓÕVAcB8‰à–à3†(¿Ÿ->2$§‰#ϲf~µÉOR¢}Ì^Ô*ëT¦9Ï^°Q¦òÌ0Ò@§…×õ™Û¡f}O†kÞÜ9ìFÄ«òwÛÍbµËØq„ÂL™§ÇÙ宕NÔuKJL:˜Ü õÚšöÀÎßMS“cãs~qÐeÅXYŒMੳAªeU BEãöíOWN¸’€9tê´«TÏ ›¡ùñd2ñ²ëó6ýmP_;¥Ò?n³ s;}\E¿×|ؘщ`‡Z§œ˜²®@r[éëó ¿‰ÊúR…Kðþ¢B‰|Æ—;*g–ýI´U’yÊл¯•D\ÄR­½›œ¨ŽGPlÀÿÒ³ïŒlÒ×6ïX®Ýe<”0D´ËŠBÖEžõ!ûŽ¶QËVnG±~ñTËóS\|Á â­1–ZœFyÒâXývЩVéÅ_Òö”>§ò¤9AÜ%'–Fÿq>£f.ίN7^š"Á(ßxZê”Þä:§íw^üçúCgRNKܼvØKƒ»ª7håu7¬cîœ3úª³$!gÌÚÙ£h‚ŽMàBµÌú.ôÛ{ª±\+ƒ½íüTqhGÉWÈx§Ý?X¿ +--˜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¥>£âÎ9sÄK’èe—©p¦ÑÌuqzžî-/”íÞÇyCO’V¶u˜n¼ø‘LȘãmí]…’aÛþ­FP´¶Õ…ØÚ7æwźôˆ%=³ÁÆ’m±UŧØÌýÔ†Çæ™Yne[BcÚ£´ºê« €šAB¶N —ýRÖµ`0¨¾Ö¬§Üx±±Õ\e äêò&½£Êixá>*ñ>:¡»_ /P-Báé57# Ck¨ym¯”KO=áÒ[-9o${ ÅÊQ™Uß›³ôQßü³¿iyÜÇ Ê `è“ÚP’ž{EÔ¦+çéÛo}ÙCC=ÑÒqÉu¯b¬Çæî¼@T``¥Ùݼ¼8Ô•z—Ó“Ênº¥OJðËOÔ5¨)!?ax}qç“,Šc¬éHbè¨éÇ­î7?ß ƒ[~Ãõ…žQf¬dÜ;i |›PjPJ­ô±n9øwÅ÷÷|·Õ+ÑíÔ˜Kdž˜„KŒÍ ^§s|ÔS°@Ã?åÝŠãeÙùÖ™õC©¢70c5ò¥Ò5Ÿ¼irù:ÂçXJ&d8݉²ý:ͨƒ]À„¯W"é&Õ3Kß/ͽìü1˜5Î#bŸfÌØ7ñ$ú#ב¾_öfÌfÍÅ›-”í=ò{Óqó/ êsTDõùù¢ïÆÖ_ÍÏPHŸÍVÜÓ ûŨãú{Úë ì†4Ó Ç}K«bÙ“¾ 'Ï+Ó¬;=A÷ßéZq<ª_6§VsL{Óë£?$£\ëY 1XHB« Å8Ç÷ÏD¥)Å„ëù¨àAb ’¦„ê7­È‚F8Âhï[ž±wœèßsÃ|H{ÒÊ6kô¡gKE÷ÂU‚?ÍâÍÁì«o¹mHl8‰bÆ©Dú£ð8p]áâzÒ#y\²JØÃ÷@yÊŃeŽYIi1ù°Íù×û=°ÕØÁN0Vn#ΦŠ{qšpX²dãûÁÐuƒû®§tD‰ëš½¤&â4Nü8ë»&\uþf«ÑOì_õbÊ8Ûb0pÏòkÃÀwÈJ±£ßÀ·¹$±ñk'o gà©È½£ÿ™Nù|:ŽÕ€¨Ö2ß,ßÆX@§¶ò‹@¯‘“<; aQ§*¢êŒmš' Ò +«ñ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€kU3P"¢÷ÇÇ‚“\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«¬¾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¶ôËñdË&æfƒicÕÆð+wŸzH_e«ï?ž†éw¿*¦‡½þbž_’‰OÁiÏ‘+nRÛLžy‹TÏ}ƒö¿‡§#k=|œµÉ?£òønž:¯ž;]ÚâõPÐ2™¬ ÓxØêì4ÕLGõFöŽv2ÄШó$œ²í«!¿¯û[¦9Ó}ÝhHç8E7õÙÖË];#tø³;ÚçQ¤ÉTà¹BKÈhHËœ¦}3è¨.F˜Q8)IO ‡ùÿòûÿþ?`b 4rt¶³1r´‚ûÃdzendstream +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¬¬nnn +€¨ƒ£§³•…¥ €Z]E“†ŽŽþ¿,ÿ„L<ÿ§çïN•…=€òï‹ÐÖÁÑhïòâÿz£*p±Ì­lQE%miIµ¤‚:@ht6¶(¹šØZ™ä¬Lö ÀÜÁ`ûïÀÔÁÞÌêŸÒ@Œ±„AcÈhjõwÐÃèø‹àt¶³þ¾¬@ gc{—¿=pqXÙ›ÚºšýCà¯ÝÜá_„þFØýõýSr¹€L­]³*‰Iü›§‹¥±Ë?¹AVÝó¿‘f¦®ÿ”ô/ß_˜¿^c+{ÀèáòO. ÀÌ +ähkìù7÷_0Gg«ÑpYÙ[üz€3ÐÂØÙÌý…ù‹ýOwþ«NÀÿV½±££­ç¿v;ü+êq°rmÍXXÿæ4uù›ÛÂÊéŸA‘¶7w°0ÿÛnæêø?}n@ç5ˆúŸ™¡ùKÂØÌÁÞÖ`4G`Rppù›@ý§2ãŸÈÿ ÿ·üß"ïÿ?qÿS£ÿíÿÿ=Ïÿ -ájk«`l÷wþ}ÁþÞ09À?wŒ­±óÿ+ÜØÎÊÖóÿ°á?5ÿ&ùÿ#íbü·Âöafdþ·Ñ +$aå4S²r1µ˜ÛþíÔ¿ìêöf@g[+{à_EÿÕL 3óøÔ,­Lmìÿi=û¿]@{³ÿ$ÿW¤Qg’PPW—¥ûÏ;õ_QJµwQótüKì”"ï`ö¿ÿ`ˆˆ8x¼þž@ÖoœŽ¿ ¹XX|ÿÙþÃò_kycg+€îß’™YþUøÿxþk¥ÿ0âö¦fÿÌŠª‹±½Ùßñú_†ܦ®ÎÎUý׉ÿ[ðÿ\ÿkÐ@ )Âê’ƒ)o°uzV†K-ÎáI1Ýþ^ÈáÇÒµ¢‚€Ÿ=þéáÛÜ•Fo5!ŒS<mž‹'Žï{2´û£½Ø¶T=©À‹|_2š¾ô ÊNºýïL¥È§šÑÞ— r[P:Ìû&•U JÞ`§:¾9Ã]>Ò¹|!pDñ3M«ÃêDkè-<9¥L:z| 깆îÛç˃§àuƒB¦Œ +pÊÅÔQ¯ôŽ ÉhB¿n¿ü Öìö6È£ Ç#´“{Q²È_³o—{K†ÎhäK’w–jÝ«Ò¾š›ŠâNšâžýñ¹îJ!Âák"øÔ3cC4[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áñã*ds÷wtð¤¦%? 5fÎçÈB*²?³†´OWl¤Ó5ëN‘¿ˆ÷·§³šãæpï>?¸-¶«­cúR?éuº¤ŸÅÑ' :­E7™À2BWæ¿¡/õj +jýÊDAD›oʺ´ÆdüË”zj.ÃZ8^KïJ9xí–j-`Ûcõ1ÎzÉÀ¨cw]Û ¶mžÇ£HB²‘¼{™™Û +Ç¡¢ßÇ +Ÿ¯‚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'µ6ðx(\¹ËÕÆŠè"†L`ªP®‘Åí“/Ä‘ ‡1ÍÌ *Ç@_ªD)´(f'yÜ_L{qŸ›v‘ø‚ß ÜÏ/5>EÃ.5“Ü ûà4™­t6?#(ºÖN!  ÿ„È,pLÊ^¬ù@|7=›âïFUCñ“£2^^ƒ ãwضrë¡—9ÔÿÞ$ɾ٩ÅRqÐ Ui +þ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Á/³íõ3é SúÔ»&ŒvÊô«Òî¯ÓkQÓðêF¬6}» Š„üíÞÈÕ¼û£í>d ;ˆ›¶j¨š)æñ1š}16§¢rzsµ™i\—áˆ(6½iLÚö¼«ÜˆK,ÓCƒåP"ÓjŸŽ@S½þìÚ‰°øߤ3i¿¤ å:‹û0$ý`U1¡…í-µ.„S |èUD)ÿ ›fOxëÑ¡[§¤aE{z)¹ŠJf^–ánÎðD¬sŸs4…zÀl òŸ\Ì¢&<ÔêÙGkÙ+^®Ÿ~§í‹Ú‘žÄªd =ˆ[÷ê옧€‰Éf‰®ºùH«Ûq†¼÷€¹–Ws³—Üéu»Oç’Æ —`,*öóN B“#ýbƒ…E͆þ¶+ÝÒåÏUûZ·"zŠþõÚÈ-w5XV²¬`.o‡D”a­ n°D¿ÙXrcr†¾†ïíuMmŒ OM§QŽõ©T,Î:¼“ôéÇ*¨|Ó'~Â줪ÓØ`Ú,&£»Gs] odˆ¿|-5Ë +ðóOÈÌ€ºö3ÊòsFdÐàÏêþÀ öïÎtº[ëqõŒQ v$yÖÙbw +_Õ'ÙW/t¥)³Bkl@ÒuoY‘$žÆybP¤ÉˆÑinµdè—ô{Uþ6ÕËôÁ½¸ðLǼ«‰ð¯™ÄmÐFZ¯Ôçt5ìÁÉjqTWeec±²¯nB=´ŽÚÍkV7pê¬IÄu=ø€}~ µ}–ò%UUz&á꬯ræ^…+"£‹8ízƶ õìù4Þ‡ºq’ÎŽqÈêA1jäáŠU  Ai<)釭“ïÓÉ3ëÂSU#ìœdÅçsÄò17ÛbÉøÙ÷ 5°®;ºì’L•z]õ»ð…)}—Ä4FÛ 8bV”a0cÃËŸVB–_]Ýh…ÓT?Øžl V‰\ hHЯ™õÜ¡½17kOËb"É×[“À‹øY]¹5¸·ã#„ ÁßÃüû ?ô='9«Ê³4$Sƒ¨ØáNr4r[b’BœÍû–ÇÈ-2R5u*¢÷ý^¨Âu¼%=MùP.J2:Uò…bíÎùg°CÏ&Î!SkÈ..ï%Ë~/»ð×>A +3_^ ‡¶š. ’‚…)Éç Šá£ùbK§„pNšÿ ˜®Øø±md»›0 Ñ¥Fîa¦ÿOVèsÜ/$ùT~©I–ß¿@:À»R(¸¯“µ ð=Kì Å]A0Àµ‹µùµë­†+â#ëàîIFQŒÃêBúBO—ï" %Òe׈Ub©¯œcªm½yFš ¤åJòm +9’þ!î8IÑ›C r-ÿs[{œP–óe›&~b«I¨/÷­cG@X«â}Q%´ÚkV{=¼{°Ð$á#ú®gìÖ艇䅻Õµs8_0.ÃÕuáDœ>üfœ#RêEu`5¿)Q‡Ù1D{›pcª¶ÄÌÙâÎ#ö°Ô?§9lS£j|+/ŽTa*ŸláB™%奱û©67×"ãÑŽ[,èà¹*q5UáAa‰«1Ÿl;`8]‘iñ1vlð &›\)Gü-æ~)G c€é§Ç²éä$béeà C‰5Ô!Wõüs>l-Ã7&“OA&ü¯p§ßï M¦ú3¢9/I<˳!XÑo¿Žo¬}£qysàuŠ‹â¥UD |(’*ø“zÖÖdÃ14õòc‰‰»íúMSÞ—ä•4`­ÌãQ¸fšºƒ³Ql‹9þˆƒZ›Ož°¾[c—œ·G.&"Ñ„ÿ´beM*Då¤ïýJf\f‹`ˆp·•>ƒìñ…Û]®»ÐˆSÀ{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ÃùUpgŒ-}-§¼~`[ ç=BbW;’«š)FâuÆ,D9ýÂ4ZÅæÈúü±ËêŠ_5¾ó¥£74ª™ö4M¯w#íçNW51ª-?îÅò†Ÿ£+ߎ!±iëêxÐIUñôvdBYB½‰”× +,°ãzy—øg;Šy¹}ÂÿÌø±UûF¥’­k'Ú¤#È3¾^*üLçÐ9$¬¬=Tð›6‹|Ö|üÓe$}ær€~øá«’Ê]=ï¼þ‚ÙÙðÇiߧ_‰´@€+Ê~Ž ±sè3Ú¤5yÖ^í8ÅÏ,ˆßVω;ú IK1ÿÉÍ+:0Ç6-˜úv[6©Oì{)®+vÕ,¿ûi4 ‘¼[”aýÁ—+QÏ8yç3ÓZ¨Í]Îñ0!8¡bÓ) ©uqc™fT& ‡ë²,•kçâÛ‹¡„»e~]Xß¡c঻äÛ§ÂÈŠ_­òYÁ;Ï6ÔÜ]Qb›g{Cæb0äxc{vFy×T"ïÌÉS +•W½Š1W\ÁMÞ7ì’)Ò”Èã=ß›¥Ùµ ·`º¬e  ŠAÿú‡g¬µ¥ê˜'(¯Æ¨¼H¿ V€zà´a€|³É*g¥)Lè÷`{º3ZYhâ 㛠0ÛB嗊᧠ÉYŠÓ÷k;ÜÔjÜ“E×n,KËÔ.¤E͘Þç»)©…Hå´ç8v¶\~ä/É2Yˆ"Ým/™üËGøé’™]8¼)²;<#…}âbW–lüݥМINì¬IÔ²yDV’Ô±UqVV/Ü2åvÏÞŒ‡CGG²EúèR7!'ƒ…¯-mÝ~¶_[OëýŽ$¥§X^¾‹DHžkÈãL/K… ù>Õ£áKyBýñâÌÉÚY„iÿå SÉ”› þ§X »¨ÿµò&É7 ¸†oÓ™þºŽƒE5î<× ÷‹¶ÖÄô'ÑíÀgå\¹<2Yü’˜Oü»dO®õç¹xØAychIx?ó°¥h༲„Ý6šEÕìÞ¢ªµ ÏOej{C%„=|à~ì°®ÂW⢎t>jœîµï +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$¾‘ËV­d|¼’{‡äZ©¬ÐðSÿ;Ü®Ý9îÒc)»âÁ|Qžn^KLæBuîû¬£Òî–“0ü,¤Ðï‚›¹ŸòJÍ^½¬} ÁÅL"wEV+*…–:óohåZ—àøÛ;Òl„Éñ£½zŸY åŒ¼«}Ñ¡ç–‰¨O†xBùQŽºÏÅ*‡Ö+µ÷—¯ž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÷m¥[5êÊžŠÕÍ5ik’VÔ©°¼G^jpo]äZ, +½ÉA=Å‚¤Ë‰x4EkêÐ36_ÃÊš½¬CH¹¼ ÆÑÞû1•öÎ4+W@Êå`Š0\Ñ’¯7GŸ”À0Äô×òä&$‚zT½j¨ÂsùsYX‘ý†FÿçRsØ|Ië•)Û¨æ¨þ²À–·º1‹çƒUÇÛžÏtqêÄs;ä%S´‰NRÅàèŒ>vÂ)Áàw× Ž>ïöH¨ˆ®&¼è?Ä©ÈÇðæmß#Dåp NW½Z^ΕCrÐB©„(JµîLÑ3¤š4á¦}¼™™NÜt-÷s꧋ + sE]©‰`ò6™=>î8é%ÂÐs>N´žô08òî~ÿµûcUð¤¾Á.5ÆÄ*¬ó8/¤zWt÷Æœ~×>uöRméÞ¨£a?±U~"rNÄzë`~³†¸}Òþ–9Ys0d}H v?’bœž¤±Îc¶3$,c÷Ž±6ù9CÀÉ”‡—;k˜Ú‹Á²Ë¢\¥ÓEÓ.ƒmPè¶wµ~Ž”­ðþböõÃË}rû.“¸#jdFTèS(<†þQz_´%„àË#˜fô¹bÂõ‘”^Ó?œÐå‡ÍÇ0›JÆŠÉEÀ&I™¶{)Ó8]#ÃLìÁ£qÔDƒÈ„Ì™úØ™8Ö0ê!7ûy•y4wZl}»›p‚ÃËf·ê +}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¿$Ý#ˆ&9ôôù³–”–ÄmûIÿ¼¥×W©3L%‡ù’Pa+Ò²ÛÑd-†{=*?4`\‡öÞó\1‘q¤¡lkø³`³IƒG×øõ‡Λgºe)¨˜xÎï>PFS¯y’¢>l„" QÅQIåáÕT{5û³&ì™wá/yÙšŸ|ž~S`ëð+á“>òθf53·P 3ĭʺ¥uOJÌre¯0ßÆ-pÑVvÑ8hs )§Zõ­1ß{d˜Ü àÁ˜^=ƒ«zu âhV¼Ýh|{õr‚‡€}$6'2Œ;K§¯;¡ÂoµeÕ¶í\ô4ŸŸ1Ãxæ£ÇóXT»V4Ê›ªiÔÑ‚“æ®›'Áº73þ*onœͪRÏ\ET/¸ OkÒ]0EJ[JD%()gŸ¾“’<$úíGˆù¶—gûGõ9N­¤Ë,©ˆBú媧§ÂBÙCÛ¢1‘#)ÌpäæÙªÕžP+ +Û{Í6˜«¾·í'ÍÇ°8ÿšŠèKOå¬eŠ3«Ñ[s …¡Áà<‰–Ï´œt`Húýëu¯ÜØÊ_kŠ Ñaöç{­ ²\óJ$¢ÀmáþùKÒÁ†×~×ïâ¬H,ã§d.ý‘Þê÷ÉË%ú¤™s Öµû+uJõšÐÓ@×^#;¸r„ TÔ…šÝ¸?†sˆ«2ã`ñIÏIŠêܯ^va‚¸pMEçÙîܺýCÖ& +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¤­û~­?…ÖÛ½2q´ûº 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[( ]Ú&ø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È=®ûêšmjæj³'ø‰²•ždZí|ø.²$Õ@=‰ùå–ˆÌwÁr8 3<ëUu)‘VkŒ4Š®]7¤JS‹ + ØÚÝ®-ñ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 #NJ¾Oy½‰s)¼àèÉ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üÅá’ès]¬ä¾rcÒH²axGFW;Äîðþ{á +¤òøïlÑ×ù>Tq­@»È:…~Öõ2Ry”ά­Ù÷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¥¦1ERÍçŠ}-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£ªŠQ]gó+Ò•‹9ñí÷øÊïŽ7æ Ÿ¼ˆRYoîɧ|ÓVéiñy³ÛnÙx=§|“3/Ôm=ÿ¢S«ÊRVj¨_«WØàÙRÛÒ‚E9[DÚI’ù¤Žq­ø0išŽÅ/ ròoK’'câÛKáïÍ•mTdl]M+OšSu·àŽ›Ì¬‰Ó·^ñ‚J”uÚ³ˆªÁå!žôÚ[í¤DÚ=#% ©OÔ8À̼Âì$HÕeÝgÐ)¨ÆÎv¤¥ºL!Ý A^zV7¨E¯L§"KÙGç‰.ìvpÃW´Ç Ùn[Âð|¿€Ž%Ë[ßN€T2".É+®U hu%äë›ç¡’ÎJʳâúB½Ö- ûJp‡Z÷6Þ´æT† Ëû<G×Ã~ñŸÁιf²â8œò犊šâÄâ鈦èŒXk.VIŠ åE¹.„µÐX¾ôp§Šæ AÁ¥“2TOkÓ‘˜?Կ¹y3˜R‹ke,Ìl.­jaˆXáÜÐÝ`ü|D#id“ê¹J×@ýÈ0ðÏÔ”½ÇrUêMK‘µ6%(¸•—²2ÇÜ/¯Q`³~¼—•¢ëPYì”LJ±››¦—ñ@?9óñ‡YxÀ›CÔÊ^Œáb©o\"è„ææÓ¡‰-:(_NUù&Ç^ ñ‰'gD8]¤“¿™c782‡ƒr¡û ¥3 ÈßyàÜØôõ¨c76)áypRæ“\óJÁAØÀÔºîȾŠõâå0’R†›Ð$Öþ94Ý׊¤jxÈc®¤,÷X„~]ðöÂ_ÞI$¤h)M ‚ûê;¸WN¹È¨½v ™äGizøÂÙóÄÖŒ"ï¹¢ «,=Ónù{MQÇ19"oÉð¹åLâÐ%2 NŽ¢ Ígšw%CÿŸ,¦iôè•´«Í«ÇC¾Ù¡b™8‘¸'?D¥&äg½Q_™ŸÎ•!b¨ Y×ÈÓ;6i¢škfQ7œ¯á÷£Fáç6ÂEççž®gx^­bq´ýŽÐA˜I &±Äþö¢±”–Ù<ÿ«Çåt=äÊi]Hf+ô£ÖkGA¬Ð ÷û»J1’“´¦lB0ÅHRÊ•ê["—£O"ÙYs[g&-Âs´è“Û,;Ì6¸îÙV»,ŒŸPÜþ&Fâ¼e½Dt-É ”o1½GæÖL[]I¶±®¹Ñ…v•]ƒ4ÓgV²AQG¿KÎÞ”Øì¿Í¸ÀÍu}…Jfûê s²(X6:É¿y•®Õ€œm +çK±le‡MD¥ú¦—ƒG!úÇu5Wå’,:µöùÒÉk6ßx %LÑ·'ëœt/ÄCç䜿râ!•Ò-Á—:–ío£3mg±F8E<>pÂkÜâHn[yÖ€‚Œ=«zÅÙ©êg=:$bÛ&°§Œ.•·{ÌsL7 è;MKæ\°Ç”l’9yÝÆL†/:’ +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¯Ù‰Úµ·õ¢ÎRœÌd×X­­ßuMké°êäQzF–·\h…õmŒ_¸N©ßUÞôæÃl ~kçË]Í¢ù¾ +Ï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"ÖÕ+À¾Fz‘@\æCȃyèȹì ïŠd[…=ßõCÓb ®™Ø@<¸ºñ;*Í’Ug ›.h"+DÜýJ +¿®îÁùª]=þð>+û§ tEŒ%üQ8v$3 ;øüñÍ¡0 Ÿ(%ã¨ÑóGßõ#~ˆ?ef ò½Óù=EoGKñ=™ÆQ\ëFöA¸w¨Ÿåаӈßü-3ªBò‹°çl¸yV–ˆŒ…_èˇ¹Þ6i=íÓqŒt¦pTD1C…ƒõF—ë ôl™Áak•Ÿs»å¿ð]z5g§]?T^ë#žoa>›‡‰á²y °ob£p"dŠ^‰Å­ëô›6“±ŽÂÍó]hX-nõš^¼Ë‚ ²g6«iím?w`?Œû[Ae¥´¦0C-QÌRÈp\ëŽòž½fÜÊîJGõØ›h¿½r•§£ªh(£ˆìøÝßEÏhÜ×»4Íb¹ã.Õñ 5wÚÌ_ížD°½Eß-Èuà £hÚY˜d¦on-¨£q{5Gíg!AÔžÊü©ú×(ÓN½%°U„ üö‘‰³°)¸7ÈÑ!/Þ¨rF¶8»)¡ØdétlR Œ›× F¾1Î*K$vº²•»¬;2mæÎæßK~×  Õ¢Ûœœ#=¦o(þ¼‘rŽ´‹{K™ÅK¹)`áuqç]M,P¦È,½*a¡øÍÂ1¾4ø{ɱ¾¢µ©¹K: ÀùÆ–˜pHv3Ó{NË3)€]âì¥jÇÊêMs\É”u²žÇ½m9‚!h)㪩!R¤Äç’«êAu/ ¬„oÁûl’&§AðdÙÞ.Ðè¢Ç.QèBÊáÁcƒ²$‡ÜS§DP¦(½ö¼Û×C@/¼.Œ|Òfɵ\’£¾µd€‹¡Ât²Îí ’ˆ†"}ÑJôb­"j'‘Ú“æ‚0f»‡Ì8¢ŒgÇZǬoÙ†U.BV½|Z¯èœ… x2`’ãÍȧäe™!OñÑ}Õ`VmÐ9ïŽònxètIçÓ€ÂÄiz¬‚¥Múù)³y¡ñ(7w÷’«<ß5îƒ=c6.Re™íõœï˜XÖ€]ƒ£˜rœ«ýfôxëh)ÉR"A1¼÷iÎœ‹•´ÈNS¬ +¥Bõ&ä"ÝûipÈ[9l{6¨C˜•*ݳ¸wõÙ?hÜææUç Tê#²ðZˆŒlŒÉAÙ_í`GBþ‚+7MyEÜ…Ò"J?éÝ%Fiß{AËÖ“WÁs¯ 6 –¢Gl9—×k—ÖàEùËÆèîѤ’G«[‚Ì£K™Á°ýˆ8·XIíÚöá-õjU"ð*{€»ÛOÓ¼ÕÅÂPÂ\ µj¦8ëîVæ÷Œ<¥ûïwç— +é&»ÜÂ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Þ:ë×(¤ =ô!üˆ ímpéçö+Â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,®^.škÓöèuœuʽ¤q”’3ˆ=>¯–«˜“Z$œ®9Û¾êNQÓÃì"ô³}œ?ÔÒˆ½ 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ÃtGÓh¥ìÈJUSÉU°Kˆ+.´By`Ö-ŠQ3gföÄêüQCp +c21Þ×G0G¬%C iÈ‘Ãmr-}o2·©lÆË`Ûù?ègâÝØäû¬¶ÊšKÐ…g=ÃEÚa‚"8ß)ݸ”.ßØ´Õp¬w&>ëŽÞ#û÷ £üàäfᓦ÷HìgüÌïÊLˆHEç3ÏcÎ×/q&^+zÀÚÒ¼ Ö«ïmA,¸5m­  +øJGT˜âÿ§:ÿgÂa8nr®¯YÈMî(ÇHr4)WÈ}¤œsÌ5·±„fî#Ç\sŸ™HjµÜzr$Gî›æ˜„,+Öêyþ‡ç·çõ|þ€÷ŸYGR•Á7í?[ɶ؂À…‰‡`è=†„AÑ+pìßv«ÚeA L¡Í,&&v‚»Ac«; kðð;Ù-ìmø88y%õX½‰Æ€W‡s†)ün¯w±ƒœå'…H‡üƒâ~MW¢¤¿’ŠÔA¼–¦A¿"ßÍÞþz$CžB9;Ž‡í‹jtÙw΃ ¹é“.ÒñíŠÁã9Õ:(ÐO¯âŽ…¢º!cÏÍ÷A­ÖÝW&©!JT fþ’ã”ú±á1G}¡2Pi´¼:ÙÙ«xZÑÔb§§žçè`¬·Ê=Zˆí…‡;·›&Ä^΄2S$vÞ`­ÜœÒ´dñnbïóUdùzô%„ + œÝ£Àá²&<"ê¶v| `PÐr‡•þÉï(*È?$ºÁt÷ùG¦Ò=“®ÿŒ·õ:Ã,]9Π,2wAÛÍýGu¤Vä{ÿɉÝ…NÂRWÒF­¯;ÙߣˆiϤUqÕyymõtÐЌ͘‘F¿}ÑFÀÛÁ‡J¹º’|µÖ¿¸ðZ»l݇\šµr­ü!NTã“LW +wZéðÑwuɾ{Á÷Ü< Ëb¼ÖÅÇ'Iª0÷&´;’~ô|<àú+Y„;Z/§<œ1µüµn¬úUÞc£LyÏ^ý7=¨}ŠV§÷wH>9¼¡ù¾ÚŦ4Û;Xó©HcÀvKä4Ò*ª…ã¹c +?å¶ ÷Ð9ì,ó +Žµa‚BØÇ)“VÝíµl +Cp?zõ ú+¾¬P\þE8v¿DœÇ<ѪñqNš`wÍÑüûkàC¡QP]š°_œ'ðaÛA<è£ykÕ¦ sûÿŒ–Á¿ˆöꮪ={mÃÅyÁc~ÿ¶`ÙséÉø9´œßçÀ©2™uIžµ7ˆ á¶Êu‘ôÜ/c"çí~_OIïk8{µ¢¤:¸Ýô‡²(š÷\QßZå5(²îÿr¿óÒÆÈÄf4¢yÜòNºŽðåjŠãu +Q´Oè!Yè…¸‰ý©‹øžÌzA4`(õm —R¾_üÞãW6µÇA:1<à#EY’‚vª­ÿŠ“ÆlâÁ[–n&ñÇm̱ QO·K7ÿðÖ&0ËázH»/s»éZÄ +„ 0`I™4#pvXY…ĈA/\ÚKŽpFqfBô†[çN¿ö‰2Ê_Ô¦jÁ†Á/,ÓÄŽÔkŽi›5?=ÜuôK8$¬tæ³·\íû¡Ü “ü!»Ï ÐMUI‹ñ‚~þ•º |î"’Œ£QÜ3 …éµ/³S°ñLTßàò¡.Vê²­1ä-Ûž-ýy¢¤„ÐE¿T#ûiU¯D£ùq¬!¹|á†Ô¢w¹;”½öº…û‚frÕÒðµ®ÆStÁ¬Ë=‚ÊK|j€Þd«‹˜oX+j2üÜØ¢ê[8!qÑ%RøV<‹üLjH/Úx÷ì§HÕ§šJ,ýzÉ›´þ«¦ÜË\õ#v¸ÜTÇv¸Is.+áݨ4q•_9!ÏÕ‚8;¢Ëhe ]52g‡ö—•jOs»E #ToÈÖÐgÁë>““ØÓ‰Šö÷-Õó[¦n´èìOÌY½¯>âS©I9Hpƒ‘Ä æßx#8%ÃGðÛ¹<ˆ€\~tNæ»d/Ò}# RûœùJàcAÃ÷Ö«5yšÊÁa ÞÖv š­)R<þÌn¥ +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|Àú[ÅGp!»ù;Ô28ISå\zðA1O©ÄŒ} ד7«ât•ì–Û&3Á"Â7´ +]Aîú26ûZSQûuR‡èᲘ¦)95¹¥#²B=S\Ƽõ v·CW×¢)&wÉíâÙY]>Fª¤º0F (Sûu’gD¶GåÍ)ÃÈûïöK– +üòãVaï‚-Â}‘#Ô–oÞ>ã·8'…SJ6¨î£’s¹5Bùè,͈®x®*·‘|â¶\T˲PÝ0 œB}±n{ïËPò#í½·/¬o‰.4Vz´cš×ÌÐû_t§ô–¼’ßÉspãMüƒîýlA—Kç?Rˆ¾ß¼zji›©®¬ÙÒ.‰¶ÎQORÇ» V.¨ +Âý,š«»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\U%uCkkC ;zIgCkÀ_3,9¹°#ÐÐÙÂÎVÄÐÈPšD€Æ3''',9@ØÎÞÃÑÂÌÜ@õ—ƒš––î?-ÿ¸Œ<þùédaf  øûà +´¶³·Ú:ÿ¥øTÎæ@€©…5 ,¯ ))' —SˆmŽ›Pp1²¶0ÈXm€ÔS;G€õ¿c;[‹ZsbøË%è08Ù-þ†Ýöÿ@t{ £…“Óßg€…ÀÌÑÐÖùï œí¶ÆÖ.&ÿð×nj÷¯‚ìíþzØüÅþ’)Ø99;;ZØ;þfUûwÎæ†Îÿäv²ø ìLÿzšØ»üÓÒ¿°¿4QgC ['€3ÐÝùŸ\F@€‰…“½µ¡ÇßÜÉì-þU†‹“…­ÙV@pš:šXœþÒüåþg:ÿÙ'àëÞÐÞÞÚã_Ñvÿòú_5X8;­M`™Yþæ4vþ›ÛÌ–ñŸ­"ikj`fú·ÝÄÅþ?0W ã¿DõÏž¡þ[„¡‰­µÀh +Ë(gçü7%€êÿMe†ÿ>‘ÿ$þoø¿EÞÿ?qÿ«FÿÛ!þÿ=Ïÿ•ZÌÅÚZÎÐø¯ ÀÜ1À?—Œ…ñÿánhcaíñ ø¯žêÀW©4s±6tü¯ð¿émÍþ*BÏÉÀöo«…“˜…;ÐDÁÂÙØ`jhýwVÿ²«Úš­-l5ý×8ôÌLLÿS1·0¶²ýgølÿ†€¶&ÿµü¿2ý«xF5q5%IÚÿó^ý—ŸÂ_ýU<ì€ÿ™D]ÖÎä-þa²sxÑ3s0èY™Øþ»¿ó;³Ïÿ%㿈˜ÿs-kèìháÐfb`bbüýþÏ®tÿ ¨­±É?;FÙÙÐÖäï&û_†`cGÇ¿ÚþëÜÿmú?ÖÿÚî@ ;ÐveÑΘ;Ø2=+ù+ohBD»¿—|(ÄþWƒJq¡µ]_zø6g…Á{MCã×g›ÇŸSû})šƒ‘^LkÊžTàe¾)u_!ÊEíA £Þ/„Œ3õh¯«™--v&µƒ E%½ŸïPS¬Ž0WOÔþ¤®…þèdöˆ¾ÆiõqÈ ¨µE§gIÇO”¿G‡‡{n ûöñhs㾑s»B PDù;äâñk©–‹V6½8mN¨Œ Ávìòø›½ ä´“[¬{[Ëû^ ¬jÄî Öæð¡'¦E½à3õ%­µK$cÿŒæ^55`wzý´æ]ŠÛê{ÌFx9].òn1[Em™QBÏ•[ï¹öضé3MºÔí¡v»ùV¹\¢ ³*2m jVöˆ¨pz/’]6r w™ÇR‚I%Poýpc75ÈÔ'¶ÈhÀƒ W7JUϳ`K¡$¥ÀsÎ<Ä7:^ƒÉXÖë}†¿?Gæ;¦D»Ëc|y´—GðCK”Ï?eñ!AÊ¥c£VÖnPW±6HãÊQ9+–hh8©SfŠŸ0gÒËÑÍÁýh7F(Í¡7öؽŽa¸Z®/„y®I­1‚ÐÖÊ®kZºíRø»ÓÐð±‰ÌN²NNÆnôâT7%ÿÑ'ϳ7i"Å +HkÑò¶ xÀΙsTºÜºí F¥$_2à¤ÝéØæú¢úÆÒ†êéÓ÷j%ôÜvk†Êœæ%¢d` ;ÝSêdù/áÉ]‘¶S¡¼ÀËÒKa÷Ï ëö³‘#&[K^˜µ+»UTƒdak¦“Ÿ–fUX©u¢¸5ÐJçCL8KÔR®<‚öwm.¦LË‚&ØwLCœ¾a!~6]íeîkZ77º?ž†,˜ˆÁóñ0a£%Æà + +\P3ÏØ©®â%ª«Q¶°sy1*õŸƒð3›Wž®õ;7 K³y²mÇZÉh\HÐçãîäÑ|Àÿ´_˜D®á!)?¬oöër$q0>°±ÏO„ª±‹©4äCo¼úfZK|Øþ΢¯®Ý¯÷²`&™^Œ!‘‡XcÁuæú§‘üY?Ÿ¯Pû …œó‘¯7 â%@·y°aøò¢®¯3×)ƒ” ÌâΟYèÚó³Ö|}úêv 2Ñ *-SÙ´K3n¯­¡ÇèR;MXL5z–I×M¬SÂQÅp,>»iäæ–¡§ &*ÃÂí>åXÂ8ÒüàíÊ =ó ‚S€ä¯ºÏ“þbÝDACëeY‡I÷œÑ•–¬þ©B7Ï*î'Âë¡~QéM³bÔ-ôˆæ±@uQIÆó”jåÄiD5Izlx}Œr-îºÕ±zC)ë_n²~¼Î©½%•¡ýjúcsæà8掉;ºì4}£xe/¨Õõú(”ôeQÄìùdŸD€Ké +É{<D¶¤ }[DY¶¤T­±ê-úcØ'Ÿ[z‘.J(›ôb#Ö¹_{—Újå1ãysœÃ +-0ñö® ˆ(É0fö‡óÁ0–\Â9Šüµn3ÿ>J¾™Êöw +Sò¹ °žô9w:%x?RŒ¾÷å9:…œÖÄáöýŠÞ‰Mb*x:lô -1Y+„ -0ÃÂâÒ +Ú8äWó <'Æ–©läÍM*iÞ3E2 +r &Õ}Yðù0qLW*€2V:ãJÙ™³œ +9O¥Ýò“O.2&ÀŒp&'¼(5­™âo`¾«Ïð¸>‹e ÔB6?c:º(®…‡˜õõ9ø„À©9n}Š-Ól8'H §#‹S$—Íòò^fë³ó—›ê‘3×DË€„„¶-bP‘3r$|R\o'3Â6ß|2¯s‡—rΊd„ŽJxéÇx;7©GbîKÇ–«dž/ŠŸÔÂ?@E8ïë`N;5Ð’ïx…¾d¯ÿ`¯‰Kšj8'áØVDtÜóÚe’`“X‹PL—§=ù¢xŒ¦ø¨G°v}3N“ySºª5¹ #OH(Âþ£»PîV‹ !sÉlË»ÿX¡å´!VøÛ$Éò9û;x?ZHíèSôŒ¸õåäÖç?°ö°ÇÓÈ}ŒhÇ{š×n„6“rÑB+¥‘™G[?˜öÏJ6vO*G]¶M€ﲆ‚—yåx=S¯j¨·¿øÈd±ù\}¡UÙ5H8Â$|gji6N*ÄSE ¯†öÞ{{Äó:ÖÏŒ]¸Mñˆˆ×•À×͵Q‰`s™uür9ûqŽêê«Ò<»ÅŸ.îüß +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)²Èì†f²¢Ÿ»8.8 D½ TÑÖ²%‰œôð ©ó<8‘`>@žj—ÆÀG •“”»NOzþŽhˆ_qÌáì(ªSŽµ!ì´þÝm>ɨG@`!hJ„à4/Û¬zOšrŒõþA:®á–{–Í®Çw,ð›\í°÷}.åù/H+*Œê»/7í¸ij¬cƒÎ\šV{ ¤ný_ã:̦‚jÈÉ-sktŽVÛo ¼gGÈ$\¨–ËòÁÓIÅËÍ÷hgií…å$v–šñÊœÓKéYjãë¤j¬ožßÀ ƒÓèÖè·¤TÈdáX^I·LfÑ&Ú<~Üm£ÖLÎ"‡Í×í²Šÿº]ŠP(}qkTûÐl‘ÁyüÙ©q Éî¾Ô¥]»¡¤f^XB64Û†|õÏÙdÆÃÔ}'¨Y®©*w„eg¶ó~OÌÃúc¤ÉÄHÝ +À”ö¢+ˆÞ)Á÷Ð?Ž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Ê:`$#Ì'¶*xí‘J,®ò7«rví]í¹]÷›íäô÷NŽ²é„¡(*HâKÜŽ—£} qBßÜÛòÍ@OâVVOs6pÁÓ8Ö˜šªBËts$ㆤ¼ Æ•"4²Dô|<å9wM‘L›ý-§ÌD0¤†bwÓàMÚEoU>¸zÝš¼Q ø?c'=<ÖF–ëä¶x`ù³‚dÕÇ||¿8ù@§lîŽççfÛÑ‹EÎûKGxfX®$tÍõ2$g½òÛg´TŒCÍŠYmÅã}Öð@´9ǵŸ†vÈì7奧œ¯ +Wi7í”rU¾µ;a‘Ÿw³þ @Ÿâ6¤îÂÎkqRç„c}ÌWãÈRùS„ûÞyYØx–Ì¥ð™ ùÛº 6òB/R`×<%©‘ÛF›É ú÷:Ëc`Õì\ÐÛ6m½Å¾ï%œbq·Ùôçµk›ÐÅ¿ÞIÕ‰"ßvÚJ' +ž¾\’’‡†@™´DÍ_7w[}æ˜ã£1™dªÓfGÑïÙä’e¸¡cî–\‘Aú”÷G¨ùøã¿ÇØs£â‚|cˆ¶zÅr}¿¡5oÅ_¯ÞðP­2þ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^¦È¥Þ#©ì­·»…N®r7—eršéA`6?År¾“Do (ßœ-gœòˆ‚ &zvŽd»€TÓåÀw¾úl;‡<;e†DÊ^©ãV ¹°×Ѐvšp$ñ¼ c‘ëšïÞ™îíÆñgpfÂñ ÷bý¼“ø´™—¦ìðÿ­¨ Öú¦NàLØìÍ3ô¡ÁË ÿòsf‡Òl7pL‹`øÖæeÂÈ^|P>n‹©I*E‘ç7ù¹=EÅg=¯]šðÇoL¹áJy±\Gÿ"u¥d­·¼%·%ÕÜqÄþ*E Ñ‹>^žÙ9öÎÐ +ºR…ÒBnÖÂϾîÆ¿k<³÷1Ë@ +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¾¢ú;“ý—=À¥M¦ðøæGàør9±§v4ŠSr¼XáÕ¼]–ÍÌu5A‘Fw5GdYû÷)e×úeRÊÔC¯®aȹaj°/*ú>ã&}‘v‡¬}áìéÈ‚õâw7SíÝŒXªµÎü·˜¿Yë©$ÓÅrËŠTø:Ô§ +ÒµªòåP’'m±„ew2„mèi3"ÿÄRj?³¯rs&±†¢™Z}oº’TîÃœ ¥Ä5½»ÕüñD[µÔàÏ´âùð¬‘t´Í*Ř£ÏFðb.ƘgI&ª£Pð‹tDr-¨û×Å©Çdâñ«Ê% ¢®¹Œ¨ÅŽ<1 øHˆîueÉ’Xì•`H„÷A†Ì5$D$Å:N‹&'°s~n¬p<ã×ÀÍø +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š:®Ý~ì½´›”wã+šÚpðòlª=ܘÅ;°W' ¼ÉGOoʬ‚ÚÎÕÇÌû=5‘ýÀÂ"*Þ§£Ç´¥ê +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\»¿½äY°öŸóµÐ”üK=©4Ø=ÚÑBÎ.óbE7„12úÊA`tBüÔÏî¶]Ôg¡›Å¶ +á ·ó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¬·foFâb!äÜü²/’CbQÝÂ8Ô–òw%[‰‘SØ:™õï¹€ü‹$!ùdókÊ îÝßX'Ž–Œ~ãìä%/<®ÄêzA™\‡âÉ‚Š´[`ÁÓ þDPñ5­çïLìì:.㊌J~çñù®Ý•3ן|=TiŒB“н ++ý¯Ü—Û¦@¼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¹"ï£Ã?âî#H&ʧsÑÇ/ úÙ{½¡«¹ «Ë_\y”9Óœéxï +‘XE†™xð†Itò ö~›sóUúˆ£©Ç“µäÍC]0𬼕”„€¢ ƒÇ‰?§×N®ÎA Nš±D¢¸Á1ø=Ði!íø'(ßMêá—ï­RbøÚá²áCPþ(¾8Lµ:$PøÍ¥×èX;—Ý­1'?¶dUou±K…wõÔˆ“x4êºÓ»Ÿ*Ä·"+ìiÎUk|º;ÀÄZ2۽̹ºz×óä€ÍÍÄø0]*bí ¹àżòªìš16}…Ì#^å[}õZRØ-«ç43â1H·ø•ŸSqRìïq‘y7q¡£ºÊ?$H*0±•_<&BL#oœ]ùÄ«æŠÐ%ÎzÞй…¶ ÏGú¶VÂê'éÚæ,*]­Àì$SXq³ÀÁí=fdò½ÈÑêY’fæ@xÕÞÞIS”^Û]+`ê{=Ë­³SW;…xâ1d€<”±~–ö¼>ŽÉ+Xõ}~H&#//tCàCÄ4Ý‘Úï ,u Nþþ_®D?‹8¯+¿ž&£l©à"de +¾9¡¶çÜ@Oƒ+'ÔÝ{Us~Íxeoèí×}ÔûhµÙ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–ãÒÊÓûSÅŸ¡3qq¤ +é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š7‘¨Ë® Æp*®½C%D>íÅbê¨S°ÊrÐs¥¬fPß[‡8äî»MÕª?kºŒXÓü|ãw0¨®Ç {uæåªP›–"¢Ä9«qËN‚w7¨‡‡’ÝÞ!ó ùX XžõzÓR5a¤Yi’¾g?®)eY°y9%0<*+LòÑï¸YÆÖ|{JD\§W9îMóß—]È‹1‰#¨@˜V]aÏG!ÚvqÑãÒÃƧü&rf_":ãPßfížZȾÄ'´s m:<œº#˜m6¶LÔ±ôh°A6¬“¤£$²9Í0De—½;`Ý8w‚#ÅFû¡¿(OÑYЪ_¼>morÔ«Õ€!ÑáÁkÚYÓZJö ­m;Þv!LÃБvÀ WFè{y¬þl. ,ŠD<Ó¿~µËÊ0y&›}{)ž^|‰  bgî?µlî—"†fAå/¾ÎI×ä½ @ÚgS8óWšãrFÉÕ^yJFvt€„W Q)xhtt@¢ž†Dx® 2ýlÚfŒAsr˜:ª]ã ÚÖN:>INâ$VÝ‹¦\ôå–Tinôrʳ¯ò­×ÃûLJC‡¬*Ťp[71a†4—9ÉÛf<ðl¶ñتŠ”9; +[‰Wèûáù©>«OæI¾¶C‡KV;%Œä¨ðò%rÚàŠ™"ßj@d+ËÔ5z¢fvrÃÕ¿uõzÆ‘¼Å–=]çÿ êÌ ikðšv)ÝrrÊJ¸‚0öò}oß‘lÝÐoqiqéÌ<  —`"Ù ¤+0;ŠÏr5”Â?š;·±n4!ç +¥¼¢ÏÉyÓ½¼Þ2Ÿeþhê ƒ£»Oðšqù¢I:Žô;KòWUÐDL´a®œ8•Ê +,ÏsË(ÙÁ½Á.(s8…›oAΖ¤*êæî¶}‰ý'·—õ*ÈQðUXëjúé›úŸ8æ!õ5*|÷,ÚÜ­GïËopŒˆz´¾¹øãGRê òù«M³t³”–ŸLæ At,­c…Èc¾7]Aèùù¶£ÉN€ºÉ +(‰ª¢û.tHe-KLt8¿ös¤£#1íÞŽGwíoöº·Œ¶@÷fáך¡×sìØ!^ùï2tW- ÂOD4:ACzêýÅö¾³)PÒSËïzpJL ô¯c×U®Á÷¡&ˆ8YÝ[ËÄÆÖ”Ãß¼5gRn~j›o¼yƒ_jvzYÀØaz»q·ê©áêAÝWå!Iò¤2z[5løxõ}øïàÆB-M”4Í?À!è=Ù7"L’Õ½Éi“x·ÎÛ_Á:Ù3ñþÀ ôƒ| +¶LS× Êi %S“­¨Œ¼`IqJü™4~F™\·¡xëêiõŒ[ÀtTdÁ7aïðyfï§~@–-+þÁ‚¢,æ³…à?ù±³Šë®^ºÁ¶2^Ÿ«(¦¹°6(ýœ_p%æ°c´á‘…@e:‡ñ'ÕŸ¬ŽÀ™X2öFíG“œ¹f;ö¿E:W, ÁÌ'5ö?ÒvhÓÉäåò“\O ÖíÆònoÓLPCÒ}B›DŸgʈˆ‡Ü(°ŒÝN¸`àb:o<ÇÉñMˆ7O‰Œ· GnY PMŒÒ^ÖzØѹE ) ¤`èT0#…È—uæé’óxSX"áÅÿã]œCRølå%­Fh3Óq£Xt0#¯7scEfPwj†(¹P÷M~Gý«¨ø°ßA$°ZCaÅU}¿&ïC–gÑJ=;çÝZ -zºL[ P ¸`Ç`ꩃIî¿Sû ¢ Êøë"&¤Œ7n·³f¾GÃGáÄk†,õ‘±Ö-À ½®™DÜïð;ë:öQ§Óžï±jnMí4ŸÆŽÌ;?ZyÜäW~½$,>zÇA=³5 D‹&}¨3…–¸7T6‘šŸçDÉÎë ô°“ÀáÅ5–c½.¡cȺ_h©ø×&I£Þë_m’nPÒ3 +Žìdh +´D¨1a2(iégµ;x{‚7\©A0‚’yyáóäVv¾ªÙ Dâû:MTƒÔ’í)‘rrê7׋?, {œt˜O3q‡©r¥…Û”çÎÕÂLéÄ*ÝûÌò¦°Ã³·¥À1`äuÔ›¹$pÔ…RûmJ +‚¶=ÆŽÍÉnù-4­0 +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ë%¶Ub.cføÅ™xY:BšðarŠ½)l4[ÈGŠÏ +EU¸ò€d+uQꞥz²™j#™f‰«¶8‰ÏPPiq]3ïÍ›}êV»æYÒ•¤´Ø™½ß¤éúÆO’Uêí÷-ÙòÍÌϳߔÈ:qN ÔÁBk¤`P|ìÉLƒhYÖÃßx¸’Ïy1Ô¿š2íp¡g o~-“‘t—ǺŠëûéá:™¬TèÑp òÙ¸ÿTüÚî ]¯cíôa¼FÅ Û!g'œAQBK§?µÈeXƒë¬7ÿü„-àZ,sb]g#ùÈ´Š…µr~ ~XȤȼ`2cCÐÀÈõΧ´œ º™·ÝgòQȃQÛì/t^,å~ûæ³ u_å1ùШJÎf@꘎>@˜:’L!íUÁ¸C'þÛÜm„N£tç‡þrÊû°GM¸dùÚÛÃ.hÀùÙÅ/ õ7ðŒ]W"#P¢-½÷Y´¸IÞV¿¼¸³0ºèüo™$S Ðse.ë +ÊË'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(ˆL&·pÒ˜){ìÝTøÐhĸV #‹ùuQ?‘*á„ÌIMËZjKûx(£ e±ºm}°F0ëX—19i¤ÅŠöô$X~×U*Ú±-ߧvœÙQïÖ¸ëç?§?Oç@ÕêÝļ{Š ‰ŸÝÒ 0©EßÎÿtÞðQPN¬ºY2ažEåE$Í‹‚£ösɆdiIfÔ…N<¾?ÒÄrd’~ hà>¥QÂÞvâ‰ðdÉrÔÒ¬ûu ÄL6’2/´`ã»÷›ö[Ѥ¬µè’!ð­ÊžVZB¸Ÿð«€*"næì#¤Ð‡ŽâOÛ\è·ßk›lU#±æ' øú-SOؘ«-eó2(Ñy•_­¥½lÙkQ€í¯-CÛ-œÚLq`Òºg.v:)m‰F1ep±ìû0¢dcô;ÄpŸqѦB-z¿:ÙýW– ÊW‹;_ºdð° «&µ#h™8†ÊŠ®Išëmw÷ Xg =sSi§ÅÄ5ãÈôÓKB?Ó›µTÉÌ]~ð l{ü(Œs`.¦¼o]çè_“3x¼ê_’o9å÷×Z•“ÒêȨd6Ê +$bðê0eN½™•â­ÉŽÓG2f*Um‡}÷WEySV8!#CŠØ§¯é(¥½óÁ9¿;-Z[3ù*³ôVžüzãa¬ïÆPcÑ™°êz£ ¯vfõpl&³Ý³ý‚Øsû+rF43K0Qž¢Ð„¥*p½§®Òìêœ +‡À/Ä‚u‚’í|£.襡=͋¼ÉÄ38:¢•¡j-rç· Ã(¬¨ L8;çFû>´P]bð®NX1ZÅy.Ê°>®®ªŠ³F7”åõÒ÷ý!ù†’½²ú®Y ±¨Ñã?S×ü‹žÃÛ¡)ì­(­ý&GÔ‰]¾27t‡{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ó¨è©~°ëõM(·‘y8ÎÊ΋F;>Ó²swÄv8•ÀÙjAu½\H‡"nF²3y×j•.;r<ÚÄc·ÑøáS4EÔ9qCÛþfúN-nâ©1•[j=Êê?¼™èè²òõS !ñ.Žœò•ý¶1û.ü¥|Ä’çg»éq<ŸÂ[€MÐ8c¡ñLÌÔ»6/„9ëÕTÒi&Õ%ƒœã©”§¾F7fVtzÛoÅ1±H“á ®º4'·¡˜ö‹öqÁ=†žú¹·fgO„Š¤La•²Œ®Ì‡hyî ÂÙ³ ô½Tô1 rš„Ïz¾Çž}½Q3R ÓÑèõÌT†O«™àU¶fÙÂ?E!× æö¦‰!ÿ,é» èBVWÞÒ:›âC_ý(ü¹Õq=‚+žìá±rn€©{¨xþÉ ijƒƒ”Ä¢›zBRjÚµ(aâv¼ÇìËË‚·Úùpex–²EÄoš„oaR¯} ›G•¥ó ïF}Ÿ7)WGÚuø8Éë×9Ð΀*ñÈ0íèJÚÈCÛ6„§òU¯j Ï{’{ñǦpøL(¤*ÊïÜ)u"Ôn4»ëýêÅPžf>=ôFJX‹êz¡ÁÀt{& IYè‹/­u˜ƒi‰ê4£±‡ÙƒÖ[føà ñ%5UŸµF@5ôÛŽ –&ø|;>ÃkÊlü01lήÉFox˜-Û¢Ø0vˆY¨6̘A;Ö Æm­÷ìæºÚž•·ØiY·û§cZɲa£ñÍ£ÞB„î<~–ñ†€ŒüBÀn÷ŠÞ™ÿN3öªBÊ¿#Ön•o„lLæù˜¢h¯Yìzîk +ýqž\Q\²Ã‹±ûÍ—˜lËûâ¸æ­p h]ß,‚Üžúòš¿Â6Í%•¢ð“;‚)¬¼*¡¹ÀÜ'{‡Éõ(ÍÜö\CÈWýÈîƾýÂÓËÚ‰ .ãå“›)œ ¢ ‹Ý¶Ì½&;}%^Ž3›­‹{Z塵ҨøÕáÕLûæ—צ*!¯.‰Ô%Þ‰‰»sw˜K¨¾o:B€oëÊTCê”TÄ.Ð5ðNã=Nùç9+ħ)®Ûd}[+TN<¯ µt…o¨½CŒ9s½G!ÅJXBçZyùsGë8ÁâîL‚ÉÆÆ(ß1eݽOͤá`ôTFý6€*´btk6§ªÌ®bó¼"†wDÈ ð¸uŒ‹äæô4þ‡)ê1& +†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¹¸LNüÒÇÀÍБ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Вü­gúLjvbÜ7ÕôF™„[.èÉž1„øVï}ÂóÇ•9Ì]¸û†§é¡X×+ô\§1€¬6ú$mu܃t˜=,8pA1QÌNu¶Ö…ôD/°à¡ r?Ū-ŸÑîá&릊˜ÅöHƒÔ’Øx¡ ^ù‹K[FÆe‡ÚØû6÷#sn…@© “=Ö‡M·—ùæügŠÓ‘U…tL9$îšþ!§ãC!Ö«2tE&›•ÄM½·è‰{TîMe¤na9Ь«ÆߣÏÂé®6\D…I~µÒ(¼¬¦,pÝ]j/·6«,\Ï­Šc*-~iÔ<¸Ú,Ô2©0ÈfíǺcY…7° é¹É…§‚.®\3N¨sÏ7Lœ(€w¬XÙÜ+÷l‹ ð•·$±l{Ÿÿ}ã}.Ð"ÑÔ9Ec›.:Õ +¤ê¸‡g¿ Õ½†ÇËßí]kìjÜù?e¬“e5H º£Æ,q¾Æì3zñµXk)p…«ˆÄkrK‡{ßiT±P¢”O×Õ«ÔM¬¸,p¶0p +¾Õ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‡õ(.&{>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Àõðœ{û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öÞÎ&ãì¬d22Î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­@ ™˜À­Ò„rÖ:«Í·ä—ˆ•Ö’"îJìK4åäNϲN^U©çuÃ̼ß!¿|gbTM‡H³™¢" 1WK‹pr)*Ó:ô}øù&X}¿³¼åð¡øúùDÊ’‰‰à†£/ÿ©“€óD-z°,¢L“4G{¨îwNÍÌħ[¡™õ¿”_h\'ÃJ€ôZˆþøñÑ°ÖÑT h…¤/ˆ)«Ìbð‡ËÚˆ··XìÚù‡®[Û€Øy†ÚG‚¹’I` õzàž±ŒÑ-¼B—&atü~­Ï `€‡jçyò‰ªqýÌ÷>%ÒÚµgŽþ*øôé§Q ?§@Û¼ ÉÂmz=)”§[ðiª YêªóÚ +Ã磵E˜±Ÿºùxünôqb ßd˜[<ÇfÎ@ߤ»Pª p§vŠ,à ÈY·“›Úˆg”þ½#©Ø¦”üëÈ`…>—âI¼¤®;p»ï“‚ºúÈÞ˜Ôm}*Ð÷î7zžôCDuQÒé”c§„Ë/οcÖ”N~?¾¨À¦Œâ~ Ò®QR__èeýrå(ð6ù_²â²­B‘õy耣½ñ,º‡Í|«AvfjlP9|!á&ØŽ\½{j7{sHáûæ÷— cýpŠU/Ï5‡k˜ vx°£ºCY‡D¹>Ãcû§&ጂÂCÛÈ{Ó¯¹ˆ{'1Ýçy¸ìr•€NéB6ºC«>»•k§ ±7=Ô ˆ•prhlGŒÃÆ>RÑþ9Aê>(Sgãr[‡¿Wþ(g‘ñrn.J½«#¸ì¡7Â{¥™þ \ï¢:'¥&¾sÏÛn±^Z(¦¢âë˜ ¯ÏaY•3Žšpz”þœºYŒ77_,é™%¤ŒXú kúæ>zÇ…d͇tud®£ûNÜ4ÂÇÿDÕ<›­¿V;°ž½_¤ÑhBÒž¦Wå:OOF§ò¾ÚV}Þ÷—õø³»jór½2¥í™«ÍÂ9öÞ’LÜ™¡fÕiM yƈ¿B#Yѹ˜‘{BÂä_xܲª÷HÛÎdQ ö »ã9å״ܺúTŒE{O`±9I:Øq;š›9Öp7DzÉë:£Ì²”­´|d{¹á-ð†9–O‰X6GK›4’G§k…X90–”¥DªãN·5š¢øK è”0U-VâË\fKÙÂM‰%VNý +@¤õÃo_U¡;¤¢æªe?Z*½¿ÚOæËͦcZ¢6zÓ*î2FFi oPdö]ã UýöÜNr‰—ùÖ›¯s“_Í€«ÐêõÉ?º,å)}¬å„ ÁñÍ®Qñ~®8Ü_®ö?DR>…£b{m㔿/£HŽç,Û»MEr2ï©Åèg(ãw„†Ó¤,DûJ.pW£?W؃ð›'HÂMcÕ‹~[5 j´iÝ "£õëÈbýN¿”òà–`˜ä§×ÛÉ™ÍeÒÔ“Ç먄lŸyú¿ýw¬ª±›ä»~¤J!“A=ÐÃé8êâ N1&ƒ¨8#vŠ:ÚQ™¡ù 0 RÛ¤T(þ×ût„Í$þbwF˜ß® 7)ÒZ¥ëî±´X¾;dãQ¡ÅC…sNÏÚ‘!jCù‚#XÎäüÃ_Ä÷ +€mK1”£»ãß:¹Õ˜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‚»pR¸ÿÍ‹°E²(oh~÷ƒ¸hkå……DÛ–‡[ÒÆ¥oÖ™ziUèɉ±-Ïòk^Mï•ôÌ,öêf¬”ñx” ŸGS6 »æÐ>²+5XÛ•½åfìÔm·ë×®þv*¦Øp ëÔ,ÆêWàÅ{+"‹ÜV¦Å—iÂÿÆ6ë,Y¶ÍSßl£ÐãìÖH”þœÙ¶‚;»£:Jb†öÿcÂ2üâ' í½dn”»†õ¥ÂJz]è°^kSâ…v‡Æ¤>fÊýQÌ’Ñ飺˜N•½º%ÞAäÙiÁO…Ûoñ­¢/ÝvÙŸHMpÿdÓ.š8yиæâ<·ûÌTêüÈÏöé]øÝYØzÔ0óYJöÊVêôøÿ¦/=¢W"ýÓ:Cè¡Êà^+ósZ…íôqÜvOø$ÕiÚøVýq${zìxŽÊ«Q‘c²ârÞQ¨Uz™F`Ô4ùjþ1gæ\xEŠ „ûɘÄEÕ¬«‰~*U;³Ù ¿É› +Ô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®©YGŽ¿¸éí s¬zÖÃÔcü„Xnú°à¬KNT‡E}Í®¶ˆjYMr5†Ò™NgeƒËÝ Ë ªòÒ •õ¼š3÷1¨vypæËj6µ}åI_ói­EÅÎq¸'½ šþñ+„žb2ä÷R…‚¶~UÞci„eù‹Pz©k!ïÊ×2oˆáûv)³!> ­ZJ®‰ÙGj]ÙîWðH:‘”·Y«äMŽ˜‚Ïéì©qîmuëO#/3K®ÈíöiEpë×3ä‡ÔO@â0¡á‹5!³ÑŒ¯ Ü8ßï;*UbÊS”ßÖq—2,Â#h=ÕM x'üÁROª…ÙB!É<Áq ݘ87¥3üB$ò:ÿÕzÆOE:óP¶%õŠkÄ´{@æÿíÿ€ÿ +ÀÝÏó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 §'°”QH¨ &ʤ3N€«Æ(±pöùdFÄXRC ð‡bXŠ÷@  °BMX 8³BÂrÛ É„ˆ@DÂQˆŒ@™qÄ‘‰P€ñ +*cßP;`LŽ›œq“Ÿ¸E!*“¨!,"PP|/wòß0õns_¥DIgÚϦô’"õk*U*` ðG…0&{W +¿2ç ¥ô]–£€$ˆ€%‹’À t'SÝè¯D`!QÄ€’ÈáY– ßµ‚Ç7k„ +憆¸¾žë,Ƀ™b³:¨oÕ³5ø¶ÆSÂN%S© .Äß7_üw6ûL&@…ˆ, + Ñ=à 5?AxE@‘ a«pDz UàK<š]€Å3cÝŠÁX035Å ûŠ ”H+Í”« ›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•{Å@‰±¸÷ŠbUY¯œ5iˆ)ýôhrmk¯wª]™_[œ =O͹_Š–„5¹[”K:NË;ÁñvÍçjù×ÿžá½³}ÁÄ›pÆ…#ša?ÃœÓnËm¾eC–MÏÏ ×5^òŽîg]4SFJšMz®ÙZÏI[C ³L'Ü¥ ùYü‘ŽâUÖ¶ òì6PD’pblý4ñ>ýÎäòM}#󘬢úm©î~TÂq‡¾Žßn Ÿ7ôsw£µ¡¦fû¶ö´ÐD?Ç©UúAýãÅkZ:H{×æqïqöuÎö;hÒ3¥5››Zž(l¾àŽ%mQvîÊ 4éÒˆ‹çGtTˆÞ³ þ‡áÿ þ'àW7„)P)„ÅþE¥þ}endstream +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–æ.Š¿”ÔÔ4ÿ%ùÇ`äùŸš¿žÎ–æv²¿/n¦6ö¶¦v.!þ¯•MM.¦3KS€°¼‚¦¤œ8€B\N njgêdhPp5²±4ÈX›Ú9›RÌì6ÿqÛÛ™XþSš3Ý_,Ag€!ÀÙÁÔØò¯›©‡±©Ã?*€ƒ©“­¥³óßw€¥3ÀÜÉÐÎåo\ì–vÆ6®&ÿ$ðWnfÿoBNö-lÿêþ‚)Ø;»8;Y:¸þFUû<], ]þ‰ílùW °7ûkiboìúOIÿêþÂüÕºZÚ9\L=\þ‰ed +0±tv°1ôüû/˜ƒ“å¿i¸:[Ú™ÿW4'SsC'Sgç¿0±ÿéÎÕ ø_ª7tp°ñü×Ûþ_«ÿ™ƒ¥‹³©4#ÓߘÆ.c›[ÚAÓÿ3*’vföF†ÿ›¸:ü§ÎÍÔéßQü33”“04±·³ñ˜˜šAÓËÙ»ü  ø¿c™îÿÉÿ(þBðÿzÿÿ‘ûß9ú_.ñÿßûüß¡Å\mlä mMÿuüçŽÈþY2vÿ›µ¡­¥çÿÉþ¿[ª›þG’ÿGIÿ­´3ÿKÃ-Å,=LM,]Œ-f†6ûô¯\ÕÎÄÔÉÆÒÎô/Ÿÿ¶@ËÈÀðßt*–ÆÖvÿ4žõ?T¦v&ÿ=÷¿ý›9½–²ˆ¼° +õÿ¾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Êb·ÂT’'x?ã´Æx´nÄf äú¢³s²¤“ç'ò¡ñÑ‘á¾[°_8Ô¹ñP¤Ün pdÑŽ¹8üZª•¢Õmjí{}ÚìF~b¿?¥ä]°C³ZžWGýG+S¯¬ÆyÀ'‚²¿÷i5G¶ú¸m¦txS7ÃæPÃo¢Z-žÔ¦×âÚÑk·ðßÄoP¿5ã<Æ=v0_ž ÔYqÆ­%~hÝýÉåc P>U:­`ï½züôTSÓö{¿4NKªeu„0Š¿m$æõü‹â êóT•EÖQaQe®ÿ²%Jg‡õPÁ÷ø½Ìçƒm˜•@¨õ‡ôÍPç#ó·ˆkûy6¯e§‹ÕÜT%hÁÁ:Ø¿Ä%Ð*âwâ§Ç­±ÆYHa\üëu*¡‰ËäWGy‘ýÆ÷:â|“J*”•Cö8 +å< (&.ÕÃè25)hTbp§bâßVv*—èTï/o;eÚ0&±º¥Œ¤8FOX5Éávדñ9Ä– ªA àÊü·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œ9p-¡BÝÕŸ—þBÐ9’ÐÇ1#ÄÙ€‹ —i&®¼Úß= Ň’—cú²LcDvØ·÷GüS >*²)œ&ü9?·»b“Ä);âxˆðpÆò÷«AtãSZøx®Ñ‘k˜Í˜û°3!‰¨M$nò…4¯k< ±ÅÛGw¢­šÁ©uš`›n] `ð½VÏ.q>Á¦d¯ëžÏAd@rwir?¤ûQ·éEÐ#¦7,Ký[y¶»}å5:}¡\ƒOÆ͵z4«[®×2KO­z¹ÝBr•§§N— …ÛM♊»0xÒ]¿[•ƒf—<#’¼uë9ÿŠT1~¤+.ïwù.ŸB➥^Iì²—Üv–•à…=rÿ­¼ÆIçcLª¨+ÚTŽÐ©f{ëøoyHëu2ÊØhÚŸcJxPå]âÌW0¿§YוÀLð³ÆÀ´È µ4€£Šô2ÀWO#ÛüIiv%R‘,rØìk$™Ž.ëì câ¡´åj›ß\!†¨ª—ÌoéšÈ¼á¤Ž \(ù jv rx±1½gòaÐr_ù¦Âðõéhyô¸ñ +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>¯·åíF½Ì½3H/L2A$D†—„çYw2ýä•_M„çi­-cp\¸“ƒk=प4çÙqUÏ^™ÔÉþD?Ç›ýCúö±¨-/pØ<'ž³”Ù‚äžûa‰¶ÀâÝPÿ]ßÂcÛìË~úsph +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~+ À¤ãTÏ91ê‘m] Ûoq¦p´#­!ÓÒ¤20 f9–ºHŒÎ¬¡)[!ˆƒ‘‹m +3ï•r¤Ü×\¹û Hj±Z9ôÛšWò0R1öë<üëJÃBU²æ©6.Èj¯¥SB?ú%ig-š ô" Ózõg- +»µmF È÷06úgûFíÊ%;'iòºó°0`Í0“s*aÙ¨6 xcAˆðÄW»Û_‡’è{õÖ¬þÔÐ…1‰’6j† +­ñJñ¶LöP£4R'Ç¡rkuÌ [Xñ1H'°à‘ñ£Û¤Ÿ"‘m¼LÐAÈ{~íë£Q§³Î•‡\%"ÞÔn¿ƒKZÖÕxKiߣƒEÁÅ-\´!ˆ|’ w§©ÊB> +âœ]qO%¦Ÿ™¼^–ÖiÆ¡²Þ-ËÔHZr«ûÿq£ýº‹)CÁn‰ð²Ìf„J¸W¿ÍÕRýýâk[f5*ÂÎKýB É{œläã]» ÄTdõô1€Oë#Š’<‰p²…)Œ™Í©—ÍcL æãà%–´§’ˆ»{™.²=2ôr-*ýk» +éæÉçz¸ùëS%¸ªB(\ɤP›<î‚jßuäF4gºË »©_}VÞoJ ¶Œ[†óOLÊaYë)¨vZÏÛR"ó†ôµ4¥%)eÈöüDÁ¥‚˜û ;Ïhúg(—óÏ>’Å“àýßYÝó±‹<¾l¨1y-i•éö`ãx­3ú Ø_š±ÚúÖí÷‚ï…(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éûdzJãâ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÷Ìí,ŠFi=«ï`ÈB£Ú‰­€a¸³ÄEnfYQ‡íÎ3ZCr#¿RŠÖþ4G—-Å°§Ôr%ø¹‡WC‚ +v<Ò„O·Â¸‘óÓ¼”I ÿ´õ™6ŸÜ(Œ¡ˆ|lc`kÖ‰àøûÅ1õ”¾JK¾àÕ¶e8KœÛBTÿíü  ”«>ÏüoD2‚‰Žtý¯üW ßéZFTJ +ú=úCÓÜYMÑÕÇÓ#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…ÀD0N°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 Bs þãÍ[ã)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˜šÇÄ_°¿#Ö=£÷#ªÒ›»"ž/×ïͬävUÅ­oÈÃê`WI3wï[õ<;,¹X¬š£}y¨^%±¤õ©5µˆ]ôO®ej¯¯·a"­›LáÜ]¿Ä8ÀnÕ¨dà©PÏ[œ¢Auï9]m´~sÀŒËó°¬&¹¬Ú{Éóû™¥‚4£¡GÜë µxôár‚î¸)üX*î û’™ãì’ žÜëصåY—Áûp.µ0E«bŠ v[Ów'I7[­…ÑFut°ÂÂ,åƒp¡Oô×ÅäX_⹓SÔ;¹!—ƒA‚ «rí‘<îc{<'Uù¿H½ògÓe +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±gVV­S´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µËà<¾í¿oD÷"é†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]_¤¹¢ÅBe¦â:æc§Ø騋vÁ„äܦæû_©×µ)¦beÿø×/*ãš"m#æݹ©ÅóS)x äÝTßBã<óê´0î âqe h´>ëj™­ÌWDOÆÉa†³üKã›jLLŸL" +¼Á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‚?×Éb%˜$1£€8:&ëg‘%PöŸXû—±Á¬ì˜%þS¹KT;½k·¢sq,yS‰ïŠ¢Çßš?˜TM~þû×1z€l¦=sÂvÙ$ÙRñ s¡û§}Lz½´ç„UüCÉê¥2Ÿ&bŒ*tÛKLèÄôýd³…:©oñI†¥cWXÖ‰dÐÍÏ”§ØѤÜÀuóü¨ìè¬$÷ð¾s¿÷d»ûËó0ߟ Zìè¦LwÐ4#Š¬ˆßó¢,cÜŠË©ä&?â +øE«µÉØó Ê\Þ°f¼Ê쾑²3‚ ü׬؅é+±&—€q ¼¤§Ù:ª²³ \²ü™ýIݦ³e.©ÍìLO%T£{èeEvqÂêµ1l3n,!ŽÎZˆâÚÄØS%"øêÔ  Ð‹Ÿ;Öl FËŸ\ŽJ±²k.ߘµ¯ì*œo»±ÊTŸgº?²"6ì$~¢÷™n¸…>¨º²¡ë›=gs_÷ÎnÀÀ‰AÓU´E^ºšZlj5¤¤7îîSÉÐ ¨ Çõ¶OÈäQµ¸t)HDúîj)ÝÇí­&-Íb[ prG¦Ú‚Ÿ‰E%¸/8ø Ôã;DÁ·-Ý^-,[äxÆd°¸HÃØb…ÁQFK¦…ßH—ULñm¼N#–…¨ð›Eá²5éÖ¿?1½Ò‡¡¼î“] þ–ø¥sŠÿd2¸.ä=æ†L?Ë l¦ÚŽºðÚ¶L÷YV._’)”Ñ9öÀ(#ž¤pi/Òb;¦= cèªÙq±î Ü=xº!ËN,‹i›(×Y©gtX¤ @¡€›D|Y]'(Ý?¾Å{Dj²®½VÌË¿»[‚}KaO rI¯ WðJ-›º!H§¿õĪÛ=ûlóHWÍ•„5lHÏ˦‹ëá¥ld7lèéøXì2Þvç ÂòÔêOµ–áu–hrî§ûâü|½t\:@KWEÚÓÓ{$Záû¸ZAGêŽkèþ>#gû1B ‘i!±Wœæ¢Žå +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ð{]ÉF׋|¤pÕÑ¡M +$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šåZXø»z4×Zul=Ñ6»p né´¿–KN +‘IÜ11‡yÔÞ·k—J؉÷…Êy~Úµá*'t†&.{^åÜùÉuö×ßW_wûeð{2?X%KûN›ÏÈ‚œ={T;‡d}5ËŽœ¼uo{µÓæ®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œÒò†…&'²›1C‰L‡°EÜðL´SØмïô½zÆòR©âs¦]ÆF§IaY#„Iö(ɵs3\Ø ÐËêFÊôÉ©kWê½ÀµX%öý’W€oÓó{À–„œîJוâÊ_màó3îñ^R ì°¿=ÔÛ¹øñ ¥òs£?èÐ3ÿÒ¥­_ |J:Y£™O²ª¼ ž•lV•d’ú606Ö^ŠAé] N‰V™Ìˆ/‚:ëÝjæ`0…f“f¹ðÝ^eëãnÃÈQ@¾kÕ4Þú©‚ÔŽCtyé#|°H’ζ+EÃïÒ*`Ëh÷]\ê2 –>àOÉfêäNšqjuVÞ2©Žï$Ûˆ©5ŸñÎO©T–Š,S6ª:“\ìÐ¥Wå r¯# D}»D/ßx ûfç\ÚÜX˜,árßÎ9¤!IP™<,IßÊ?ëøzT©0|妑¤8Ód‹PµHüj ŸK(X¡szº"ÙØX;~´_ñˆ½à_Ëä< ?]Ö¨½Á,[£X}Ëe +§ŠçÍ%Vš›)|CÓîÏ9vÉÓôpXRH.…]ÃÌ ò›øþTu{¾zÖÚ9p†a«hÿ Ž©æµ¨󞽘Q\5KñíÀعQòJØysé±–W?yj,S=¦¥¾jCÃYd…ÂNˆ£¶YHzŠ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î +t­Q:ÔÄ|éòýÞ~¾Ÿ/:Øü  U` ì(›ËwzæÖÃÚS3dú@xN%jFîjüÚcZÂè) 8\"}Gˆö—}×ì0!ñÃ/ñŠFÙqhÕL`è_ +†ÊµßhÂĺ3Þ#4RÀ© “ì×›Q&êI([êtÚ¬—ægCVÆÀ_‰aΆY: „Ô‡É2ÖQ¾×]ìù¶³QœzQ¥íûI¿„Hù·ÚP¢aÑ‘X‰Dfk"&G¦Ü­ª +‡Û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ÂÛ9­Üq é ÏÃ$ ‹,ˆ''Ä8íæ.ÏO¢û7…~Ù,“ÏtÄírã¦EH•±×Œ¤—79—Á²iÁ£giÖ‹úC–8Lí3£sžºaâã XÿhœBù 2äüa"òê›þ6»qrUãô•~{GRkÍ è%©Á*‹6…zAáwÝHˆ×ñ˜i߉’šþ§£Mxòx‡ÓØ +=%?“Ž·ðV‰üì?´ë|ÜúHä/§ _«IæˆrCÒioìÓ€±•£ò¢€<'¤tuÌΖÌdÕ«eM~Æ4"žôüO= hTQà xT ^,6§EÈ'C’|“à—-ЗŸA4ˆ#Ì %ŽIù.e›Ò“ŽòYžÞd¶tvó]³ß Dóßã­ø®åtÉÁÚœ1qHo²#^ØšÀ&šÅÞÏÐç÷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Þ\ ] ¬äÀº©–•ùh´GÉh¯úr¯PGáÒªÚ(_aœSå‹a‰·ê0Ù|ýP_v$kø£Yù%ùœ~‚:\á‚‚É–~NÖCIÂAíÕ]˜¯¿n0» «'‚pu”¢é·|õõ /@ҸȊ{]Ðt”v&_ Ô~8u‡îªfîX§‡µø´“Íî”5Öž+- À=‹™ˆnü0 î¸:ߊ]ÔÚ?ëïÅ»÷0MRƒñ?mª¼P°U¨'/:ÖŠ½TZŠ2„!Ĭ½%û¸,pÅÛÁbÙüÒhÖr\:ýÜ™Œô[éï×y¯^аçu¡íe*öë•.øntY"|­ÈåŠ †4V¹RH¯áæ¾á¡· >[/ éú?”3^Þ‘f±Æ<ÈÄðD{àçÂ5?ß9sôbð4ôTssGbh6 +¥³mÈ*¤tZ®œf‘k™Qr‚ŸiµYéJ–“ríÃ;¶˜”æŽ×uqµlŽ/Í£ëûñQò3ÆNQé[!›`SJ9†v/ú9ï1ѹ¶qã~‘—:‹^º¨˜Q¥žcsö²¹¶tÃò³™AÎmé9tüpP¦ úµ•E’Åég·³‡»?>c2ÒVvýƒŠª“C§ý#¯Èu}·Yµ¢é9ù J™åáoXLV¾#]LxÄS»6’ËÍo˜³ÛŒ‰# +«ó/¶õ<øvçsK³~¨’mxÒ£€'´…ðîðRûPȆÏé‰= ¢6X7º +å‚3Ÿ»¶¥+FL{‘¥™É¸Ê{¦›d wE<Ûðöuª¡b~$.› o1PYyà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™/>Ý ×ÚÊ H2†>Å3¡ª_?ã…îÅr8ç½…Šu6³é±*K6ݱ +ÍÔ¼¦³ÂØ´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_[¡3³MWÂWmÎ +¼Ÿ'Ïû¨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ƒÚ }U^æbôžK N˜‹1¤åÎo ]½§½X&îŒÃJl±s§‹hÙÕü† +’!c«ý”ý¢F)0ÀðJXÜ|—Y«N¯ÛØ¡ O1:ï¢f2˜³ë¡»ž ï¦Ì+‘L,xÂ9¢Þ¸rQÒ'䘞ˆ˜lÏF~‚æ—Ã?a¾Ý0YZùCÀQ/Èk ã4G“ç+Ž´,´õÔ§‰ÎŠ[ Š€‡Ø× S&s áïF¦¡÷2ܳ™ û„K¶‚m÷Ä)þqêÔÜnpæÂ.¬¢6Û‰±št +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æÂcr›zö96 Ï—9²uD¿†nEÓ;†#YƒwA+ÎIíš×çyéAcÖ£ÝUTýR óJïk„Á GY”#JŽÔÈr: ËA¨µÕúÆßÇa6 2œ­Êò›€ÄŸêÖuXÄ}û9—º€X›æ) K­]¸8å¡5·ʼ«„Ë$Yµ,6z—±íHþúÙa“šËþ:8eš‡ÀoŸÏ0‚CONY˜L°-Â)ùúc s_±Þ w‘‰‰PÕõî +sìm<ßò“ûöüàÏû@n6“$ZÿbáÌóå•h +ßÄCù  6#11ß7ÎQb­Üc󨮎ê*„QÖżÿ°H¾ tü˜á±Oá\jz£Ï)v;<’)›Ûù;•a ò>å5`Zæ?µ»qòŸhš¨—Æš—jäž +–|Ú–¨ZjVሠ¡~ü;È»¬«ójoœ ¸Ö’@·Î§,1ؾ~hW2Ѻ¦“sËRsIÛ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<¬ÞÀÏl$Þ‚ˆgY\î·e]ø‡·‰í¤LH¨V_àó-AhRah—JéÂ2­ÍX\L/ê [ºÚ1qNd„Ì@­µÏÛ÷ +¨ë cR÷aƒ>½x™&¥\—Kº>VG—Gá·oT&Íe'\¥«Ð"9kƒ^´•÷ûq™qà£|I“¢·ÉÌ)‰ò¿l8lM©”iìc^$]ý-¬h^¿3:Uؘa¤ËÏübA¥J:Mn¥ó‚,L{µF }rÝ}æÉz¦2;!{„U-zE­¨*ñ†ÄðP +÷¿Ï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^“€“8U³æ1xâºòq³ÛÆïw …:×=€%¦¥¶äÄF·)–Ê]&$©†‚9vaDËiŽù¶­¿ÈF v_íó\ä]]W bãSGЬ>1­ßæ\ϬÏÏ¿àðÓÒ,؃H_T$$Ý“¿\¯†q¶Mk~7…ÒNA¹'a\버Æ-Ÿš©÷ †®$ÊdáFä(·—¾9Wí®‹ºièÀZ†¤•zÐáÈ=Ê ±÷Q¡Þ`^SâQ©¸ôŠgòJFñ¯Ë±ƒpr~|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´ZmbÉÒ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 ̃.ÊÏË7NFðeÆ»‰¥É]±•è ×¬ý©·qÇjKÎèùÑs/Ki(OÙëÅkpI]Ô~© +×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šÔCSQ¬?{÷Õn‚Å©"¦R꟢âLJ­ÿYz–œÁã5¡4dÁ/* Þ÷ÊJïYÁ³ož–yh\Y< ¼&ÊoKqÐfÜÚüà xÙµµÓÝO…+åb|ìý­Þ·â˜¸ :$eÂ]ä‹[}"{µËq:V¬yšèBA ¨äì¨Ú‚þÚVNF¼ÃÚ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ý£Ö,}$ú릷;Úã5ÒÌZQø$k»o^ËòøC@„Çlª Zƒ]TÐá·[îHâf(Š|ìKçê1ŽæÀYÞøæFÄû‡6ÕÈb7ì9ôêýq³ŒG¿ìn¿7jù¯£ænØÁ”Wç^•VVÑY‚dXh.‚Ë“gà oRåB¦´H§VÿQ-Qú×Ilìeì§wçYýäÊJý§cµò'(ûŸ\.ó<~ž'Ä +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¸‹¥{1ƒA'’‡É{²&šðS›çaÁ¤õ÷r7ÿ>‚Gª4:9êi*§ö‚–îÛ0¡ëõõû¼§{m-O:ÁO­Â\Q·„+›Á+ÝÛöbwDù­ f ³N$™½€’祼¡‡Ä\Ä?D%Ç”æD/ú°èÅFqàx·0‚ŒuùÁÿšgCp=R“±‡‰D•M¤³¾Çƒ:ûÆ“Q{J6_GR'ÀÓCÇvæŸØÔÞöI¼ax9³•ðDaDÖòÔü$«GóÅ ç:SÌáI1«^žÀõpFbJ³v*Æý™“`ú=þ÷…ÄߤÒÔj–†´k“Èû­[=*¤Q+ÔCµ‹âüdŒ?Ö é¤7Ýò±FÌ(¶¼+h6bslhïIÀÁ#ËšnjGôqH‰²‹9VjLÅÉ£pñSŠRñ¢Ô†„Ñî”su0LÄø”M¬õ ^oÙ±§9‡ÆcL$:? ðˆKIÐâÉ.û¼…˜Ýhöª“-ëªx? é¼±ÙœJ–Ë]©\ß1ÖB LqOcZ8pWMt×÷S«åKJ DSõ¡™üM®R}»çc;”uÂ:¬~×gkwlš]òVÆ/}Å¢K”ƒXƒaïŸyÇ‚yårÞ¸›5Jš ±urç;@…¿¸£Î  ­.ïƒüvZ›@W}˹RÙ†4˜½wU±ÉžÒn$N4NŸ3©{Wç&cMû%”¨>Ö#.µûQœ1sò1‚ÌTäêy“¥d4'l +Ð]ŸXêy‘ß²oÓ€$ð ;ñ^¯ $bМǒƒeR¨õJQ°~ð’½¢h•ƒöjtÁð’£ Aš–ÝHFþŒßæ¦>ù~~ÛŽÂÒ“]Ž3 Îk¥@\-`y-Œì|Šòg.3÷–ÑÇhEw²ê0þö•¹¦4ȹœÅVL_呧 ‰=ÙÒ­µ,¾ø‘ø°ÁLn$c‘_½ŒGÙ<üJ âcÌ”Mi/Ó¥¯œ7ƽ -o<Ã;…‘ÇØÙLGAPýª‡”W&ÙŽÂù¡›Ù"—¾(9Û¿ºµw¾óÞ¦˜‘Šl ]uÁDRpñuwAU.—Õg±ç=ÙŽj‚’ÄMkAAÄ´ì* â™"æg×äjwr:Ó-*å<çéZ<·ïuŸXD,’%E±È—VÍN¬JoÙ˜U®ã ,¥#ˆk„å9„ÕÄܼ'ºàv}é%©@Ûµ;¯1/ò5¶T_/B£uÄEŽÛK,: +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-u’E'ÛS«ßñ£»ýàœVqóô‚à׉’§NŒÆ€ÓL\”b¶Ààhö‡6T‰ Ëÿâÿÿ'3{ 7G;Äÿ\tÀendstream +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"¦Æff @ØÞÁÓÉÒÜÂ@ùƒŠ††ö¿,ÿ„Œ<ÿÃów§³¥¹€üï‹›©½ƒ­©Ë_ˆÿçʦ¦ S€™¥)@X^ASRN@).§ +7µ3u2´(¸ÙXd,MíœM©föN›[ŒííL,ÿ)Í™þ/– 3Ààì`jlùw›©‡±©Ã?.Z€ƒ©“­¥³óßw€¥3ÀÜÉÐÎåo\ì–vÆ6®&ÿøk7³ÿ!'û¿¶}Áì]œ,\³*ˆˆýO C—r;[þuìÍþFšØ»þSÒ¿|aþz] -íœ.¦.ÿä22˜X:;ØzþÍýÌÁÉò_4\-íÌÿ‹-ÀÉÔÜÐÉÄÆÔÙù/Ì_ìºó_uþ·ê l<ÿµÛþ_QÿÉÁÒÅÙÔÆŒ†‰ùoNc—¿¹Í-í`þI;3{ã¿ÙM\þÃçfêô¯Qþ33TIšØÛÙxLLÍ`äì]þ¦Pþ¿©Lÿ?'òÿ€Äÿ#ÿÈûÿ'î×è;Äÿ¿çù¿C‹¹ÚØÈÚšþkà?î€ àŸKæÿ6´µ´ñü¿…ÿ÷HuÓãøC‘t1üÛA;ó¿b0Ò3þ›ÑÒYÌÒÃÔDÁÒÅØ`fhó·Kÿ²«Ú™˜:ÙXÚ™þUó_Ð112þ7ŸŠ…¥±µÝ?mgû7—©É§þW g—•¤ù?oÔÅ)üUÞEÅÓá/µ¯DÖÞä?ÿ  Ù{¼é˜Ø˜t,ŒLÜ_>\,l¾ÿ—Œÿbú¯µ¬¡‹“¥@ûoÙwþSü¿?ÿµÒýo0¢vÆö&ÿÌŠ²‹¡ÉßñúOÃ?ncW'§¿ªþëÄÿ-ú?ÖÿtSSSc˜U{cž«ŒŸ™.õ˜y£Ó"ÚƒýL £¡eM*Å…µö}þû\Uu¡ôͳÜ_ž+¿>¥¨OÆû1l(úÒLo +ð|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ÝÝÝÜÝé&èJtfRÅÝEÇN ¦÷å»Íਠx'YÓŸ6töà‡­ã•c7éË#ÖñJÝ5ÛÁ+cÃú:v{y)ŽË4øö¢·—ÇØé½V,ã³Î3ê + "+0TjêkÉ™”“Œ†yF¶6mœæ ¹{¯ òÙ¼¾žÐbâB¥} ÁŒn’Eötµ•tqx‰xͤ¡"„³úï¯È÷ñ#£Àó©hÆ<‚Ê&1¥útö¦I0ÕˆT¦YR0ÐC²åôÉz‘g‘Ú¢ö!¯9dÌnžîƒƒ³úëg0.›™c˜ Šöh‘ïZd¡{yz©J‰™™I‡\®\ñù¿¹ +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`q¸2'Ô÷éöu3GLiÖÌP‹!Œ ²ý}Æ>$íég“œáœ·íç‚ÖU½½˜.ˆU-”Y2„bIi—Iª@Vóàï¢ø=ú/÷!ÁÈϹ5ä`¨xÏb¨ðrŽeA¸ìö˜:0µ.m¦¸.#3 Ù\ˆc­t”àŒ´Ñ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©]ºü}ír² {•j6b„[£ uh*pÅP2TÄ̵vŸ 11 Y÷2xiú—‹VkaŠý¯ª«^QÇ× Â…ˆT±rk³û ”ý¨ËÂÏ2ÿZ€9b“*‚Zpe¡¡l fSɃ“ÖÊ&Žte +.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Û/æž@ûTn|«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½}„BU °À˜öÙÃ!ïúx,ðz¡á3 2y÷î(B 'PÖ2’©Ìo«)<€Lb†£JqÛõñKÿüŠ»j³tDïL«¬«’;åBÑ2«G¬eCõMô'[’½®'êª(@¯ÿ!—LÊ*~Â2ØòQLyü¡ºüå(&ßJf†³Æ²ä”6{€ t}(ñ«á9j[*$C©”·CÆŽ‚!Gî,WH%s«Ëê˜u¹¬ûxK4…ƒ0 ÒÇÛwÅ9£RÐz¬ÿ~‡5Ê5k›^t‡çîa“À¨aÌ|m‚‘ìuô'ž<:Còói Dˆ*®‰ˆùˆ)prŒZ’}iô³®[Ȧ®ëå¼éç†q™¤åP´’ +þ£Á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É8vJvd;~­ë½cæ,²3ŒÙŶçŸ] ÊÞDx‘¸¯ˆpt¶n3õy(ƒ[øô¼}!µ}IDM /@ã¾#Á‹1éósùÉ©õZ˜F©bÓÄ$²>th mpÇÖ´i QgdË÷¯„â–œý”'÷t‰jP +¨a§ÎßÿñóÅ,ÿÓÄ‹‡îRmÍAšMžbã÷Dý0ɤATédEü~܆¾Ë@¦KØjv¸ÉâU—xêÚ¢ÆhÉã\a.rÈãoÊ™;&㩉I·xnÂ8AgÔ¢ÐÖQŵfäÓ—»~èJ(¦äDÜR¢R¸k³”;2vúÁ}‰džZò³ØJ›œàÔ±Û˾0â!›q“‰æCÿ”8:Ú¤K¢Jä‡Ô+Œ[ +Y +?ž®Ëm´¢˜^ÝkB°gmpŸÇhAÁ›ã+’½ ¦´ùCºìÛ* ¶‘ÊÌèmiÔYHjÈêo‘©ma¥î¨ÆŸ­´ºÁtPäšP¥i¢‰Ã Gö] Û,[wdbÕ8ì`Hj•¬F(!2"L<ý蔸ÙÌvØä_C8Z¢=|„Àh[œ_sbN~•–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‚לä¥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°]á#e­pÝÚB[NÖ©Ìì9ôŠ~+CK¹’´5vôÏ”¿§Åû$‚rq|xØÃñz˜¥-`)®þÙšî(‚–ÂPªã4·Áq…e•Š©™.\Æ)¥÷Ð×åø@·_ÈK‹ÆÁs;;/ÅÓaQ(Á&µV‰Wî0C¥žXág)Ÿfº…k|¹½•l7¿Vp´Š0žH8ùÔÊWÒd2F-xL:Ff* ±Þú {jgã2÷Øè÷çÚÜG’h«ÿûo;(©â[ G N½¼Ø)M-§³šÁ0[ƒz 7ŒÅÍײ¼šŠÈÛ”=Z¶ËG7ï«û9|£jY¶Tr}Чր¿%P‘Ó汶}ºéÍ=^|{‹’ì’4f©Þ·(I¡ÖÄGHµT× µ\’ÒV½קâИÛ<¢gÐ;5ÂÊ÷Êû3bƒáØqø'1“~X»5^!dšô©ÙÂvÊÓß×¼?%Š^e剱Á›ƒS53AŸY¸í¦¨ºØæ0Q$®¼$»¯@} t}',ýõ‡®aKjw*lY/öÍ ˜1,KÉëEø5ÉÉÝœÍ Gƒíéš—Àîëò]IVÖÇewËØ®uCº`Rtk«ðZ?Þ»WM ?ï²DPë>WíÝ·Û‘c‡w’Å*zÅÅ ÚÝÝloL[!ù;‘“€'÷‚?0' Ÿ>¼õšÎåJº+Ë"ˆÙ¶ÜšÇ%=ôÎrÆ…Xô&çŽÒ¢vÍ…­ ©±ã I¯Á•5þpy$„ý’>VýÐÿ.Á×.Æ7üôUn€ÞuM´éî¶j–&……¶QÏÂý|Øô}bÚý€ÊWz„¸ë iâ—®ƒ“z¯ùt.Iû3V'ìµüp¯tâ“<òŒqf8!V*áÍ..¢Ô¾QA4±P‘ÂÊ­..=s¹ò¢‡ÉXÈØa 7—Ð"áð²)òèåÁ^·a?âïe¸çr”‘ëò >'Êxcà¦ÀtÄtžÔ£~RÚ´]Ò"å(¹ë•³šÈ™©üº¼~Œ bà¿uv• ÿõÊ–*õŽ…/èyÇG8Ý]Üóó:áSI6ãè` 8„ +·ò4«4é5Tò÷¢uv¶GÜL܈%Z š tÏÆY²éw*žw6Ÿ+¿ m;ÆèfûºlA“]^™òÒ6§)gÛç4([é`¦Š¶°¥eO‹[ÌUЭ e|÷Å[nÌKÆXkˆ2³æÛzÒÔ‘1È ØÍNgûhU}†‡Y¤V/ƒ`ç®r»üÅ•wŽk²ˆU©Z +OcòÖ†›k<²8ÞCà8táÑ£µ¾l,Ỹ‡þKLP§FuéÈFÊï†ìÔxaÇÆr96ÊÚv W¸E^òÍk¿…æ\áàdG• çg¼T>§Î*Ùà‚O…¡1‚úmKD÷y™8­¦¹H*Ê°Û¡”|c\,M{]áÝ°ó­ëx¢ „Á÷âÌz®†¤¦W+cXgbÑP«VËŠ™ûRÁ®.›ÂãÓ¨"¬È"§û놡R «6ùèù+“£E‡ßu¦ÊÙÊÕT?ýÞCž3š eè=&º Bå˜AÈWòª7ò ”û—¶Ê’‰ž äé~Å$UŠvXÿa¼ñž ÁÖZ×yÍP¤ß™gÒöÄb›Â+ÕùêÝ ¨ú³Ce,º,:øy áà:ÿцh¾ÿèp>åõó«q+Ø2Ц¢›¼;œWË|¦qÖ¹ŠåâÀ{íPRí~=Ðø7‚Z RûÔfx†Ä2ËÙ¯«xë9$¬y!íL>É„QÊvŠùpðp‡L.};ÏÓ­‘Ó*ƒ‹‡d( ”m"4Å6Â$káäü{àDSZ«”jåý_¯»l@I8XïL!áe(Óý7¹ú´K¼‘Å?Ã!ÒVÏ×Â̶þD¢*|.zâò‰jI†^[æ/Í0˶KŸÕpoÛ8³Ø]‰á¶£ÄåÞÛŒÏнÔ(ìÌñùhŸ¦²¹N‡PÝh-> 8F ®¦š]…AIø½=z]eßWfR£& i8=iÀ:&@Iuãµf÷‹l €³ ¹øWÈûô%¼f‹~etZœRÏÔ—¡ƒ¼¶ßGPÜhB)¦Ž8±•ëÂ0 céìÊ/2ª5U´+s íÉA¬¸ZûáÑ%_ðwÐ&]6L¬8v=:ÁŸFöÜg³N”F¨€.Ä`Öê“~î…/jiÝñägï•^î¾Oûù€¬)eÄo²©»#ô±Þ¢;Ûȸ)yU8§Z¬rzV«¬alÎ>Ícà“݇`¼l}=Àj—GEݬ4ıð'|£6‡Ó¡ÇEÜðkB#vü½R®K<"On9$êð›è·×p%f:ÁrêŽn{ʶ (ëòéh¸7@ý‘Ø&x*®Ñ|ÐTÔÓ™ìŸYJb€"gºCŽÍp÷f™ BÈ9 Ïx~N«Û4'È*˱ oË1Ú—b843Á›× \åŠ*7ù}TÉ­ š:¯ã*æ$9jf´Šú_;QG­0/§óÛCf"3Ú€Uß ±kÿñ¬òˆ¨ +? +©çœ.Ñ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Ž» vp9t#ûÎvCkÏToòÏĦ.ÚÒ Åp¥Øð*ÞÅAšàal.‹Òj¨BNš®)s\¬AØ(-¾Â‚`}¢þ•¿¹t€ƒ'ÚÞÇØç¦Á ¥‹i†Ö«nµðý“kf—P.Ye8ÚF‚Hôóž‚^AÅô“͉a'Ô0Ñú||{†aÑSOKn§ a·¯dŸ‘æjlšTŸxCbyŒÔí£ÝñÔMÊuÇiYðr‚ÐurÚëxªnø˜n©œ0’Ýø$^´' J#æ›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”-Ϩ,ùï“Û³É ?O„"_PÃm  :Q0tÓœƒIsCBg(Ÿa²ÝHz–Þ§×@­“Ø;²üQÞ}‰6„¿½£„Yf¾6Ìû£ÉœÄ(Éuy{ +×ÝÀýr2`cÑ•:ï_ï6ësˆBª/ù43°±Ð¡;cÒuݽ‘H^ñ—¥™hÁŽJKýfc)§˜*˃RsžËÄw ¶˜­¼‹ú…{î''!¦9¸ªÄ«7:·™‚ÿϬ9ÅÝV8â÷ÕB9oÁËuõÕf{7_w†,pÒ‘:;Î3®÷ªn¦½ò1¸ S,²©ßÙ³`¡Ì_²#ûËAfdøæíô—Ææð³„׬–'£Ogòµ\N`8Ú¥¸’¹ˆ‘î •£ÀEò"äÕ0î„!HÐêýˆ¼ Ô4cW’ë¿£d?Ò/VÁµ©ïJ[+z óiHOûè~yÍÀN‰²Fù„ðWKÔR‡\¶ëZòz[®ÈÞ6Ê2¨4§¼vèõ/À‘7³²Ü´=0%Ç‹ÕkDµ*–¼%#§Ù—Eœ”TÇ]!LxÝV“lÍÀ–mä¬ +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ûineç°ùØW4N|ËþU§ +˜¥^nè ”íêç•âÎ,ÅŽÓ²:$!¨5]š¼ úuØÍÿò´¢·8“å‹ W"°ˆý¡VN +Z„1Û÷ ÿêséGeÉ8rœHºŽˆ²ÙÌl8 æi€Ì%„ÆPüe7û4\‰Ó|¹y <ž1+dÃîuZà²û¯]€‘+ ÿ~_ª†BAÊc¿.õ–B›ƒnŸ¡\n¦Ñ’ØÏ=Fe@ÛjiöAËÛ9è¢ôN vVÔc»ºîf{]²ÆýÈ"žÈA^poæÝDçÅ*Å/¾~U%{Á̓¢8¡Á[á\?‘Ø¡S µšá¸£³¾’!!\¡»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Òûà<óÐYZoor¡›š+µKòj`ѼÉ(šLÙ«µž¥ºª¾°6ê€ÚQmù_ã†S ûÌלä¾Z핾RøóóMÅT °…ñOPâÉuß…t!kX™À¿î¬e°¼ˆ»Ç ÿ|£`ÌÉ$B‰Q˜².ÌÍÖuŽ’Æ6iF©Í–ÌI%ð ùK(¬‘í„HÀðaï Êym“g&”(¸1"‚ßµ×&ÕO5:ÁjD-Ä+¼TóîZ÷‹ciÏÑ._T®™Ï¨47Gå2ö³/¡Okέ-òoÜËú]Þ¬RIµYÊ;1;D.žsÏ/~„÷ÑÔµ±)4ûè—øf"‘FOx“0on‡¼a­¶Ð}|ø—|LÏf_ùëuÓëÿDë% ¥9…¯™Ð¡ÃÝy.YÚ>:Á i`‡½@|‘P»tSæÃN7o 1^lMôF,:=ýu†`/‚$ÈU±]ÿ»§üà@Ža¨‡‹úÁËÑ äÕL#€ðÈKô¹ÍûËϲ‰ŽRX%$ÑÏ/Œ‡ ( ‹ :QdiiÌ`{9šÎºü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«'ý–~õ™î!;Þžù ߦvoª~.§±h½sMlS¤’èÇšË6ÍÌ0ç'5VL‚f¸!D@_ΗžŠ{…šñÃ嘙 Ã{êk)™½¼‚Yòl±ÝSðØõLˆÞ±Ó¹wÓ>pl©”B¤”åUn¤²¼]Mº0ÏÍõ®:™ºAXugOÒ <}†Ãþ +Åñ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>æ$ü¿ÁpnNÌðªÌ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Û'å‰ë˜Er’\o¯õ»‘QòL™B¼Ów@ZÂsÜ3|Ø2ó b¥0š!D'Æ0 „4„›<뚌D&yÅÎà©~”:Èt7¢º¼õQ©QúƆ䰄ôë·6D)¨•ž-E3 MÇÂ#ùáÙƒ¬§f”Õmꑞī|:d¢ Å 9ÔÀì—ª$纓ÀŸKHªyn|©s‡Œ Þc{¯ÙO$0B¯«OÌxCôtþdyCF%Ö–oy6”9¼DG&ŽîÕx,aÉzV–#aQä±ø|øŽkê»èLQÓå´öWÕZ•‚ŸÕ€ýÒ¦ñl¢AöL‹8Já}è]¸T +|Éû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=fw÷ëãmÂ-\ƒßuñ(ƒ€ñwzJ°/_n•¯™ŒM°6â=(Ï>æ°û@Ç}²¨w¢¤†±(oE?Œº€wÎÚƒ%É +wÔ84<õòN!…OÑÑ5%:Šjªª Ì Ÿ—ý×GzÛÊL.ß ÜS ¥¤ô¦a¾ˆõFÙú¨˺11[?7¬âÊ‘àU ¡FWópñóý‚O$ âHeP÷{+_-Kë­\)"¹j·Û2{ÃAÌ|¿d¿ûOa«ŽmÇÂøGœúy_°n$ßÖ, ŒB茟k ^'2bO·oHêú6ó=Ò¢€Ïö™=×PÉ*Ýg¾ŽAKßýZG§ù#«†[¢)­§]ª%ñóü­½=îו˜Áž05b…h@ |ë4Gp”‰“¨Ò5z“Úzž oŸYÂ’|f½‘s*š±¹°’zŽqðÅKC`ÉÅÎÌ…)¨à<3¾C}M‡2V|öψ6v|’»¸Àñšûˆ×K3ÿ¯¶Ú½V±í­£óÍJêh.·ø"ž³ßú´¥+Jó8L!sµ~Ë@Õ¡›Ä»Ùs$C–¡@Ú3Àž%WE/èFKKÜeprœ½]’@Nœù™ú&é8ŠE²q3 ”™\☄K“¯ÂÓO¥ú¿`f< &=õì­gN¸ã2|Dq;9Á„èÞAê€òªÀÒ”Eô :¼Ø” I«ïk/×p×$êר·~h®Ç–êGÇ +•m›;ÆÖ‚N‘šI‰Ì>0åœ\×ÔÁrÁ–~¿ß¦Wp—|@(’ý$&hdž–mGë¿L‹a1Dx,}ŠÊ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ÚOX=BÆ'ûÎSÈá§ùÀíï—¹!ŒéÇÞÙÏI`HÈVŸ±ç‰À2KàN׈½ý7cÄ3"'Ýxm˜N°~I»Ëz +³š}±ô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^bUʾü·?ìõn}æ.çG®!ü–/|c²OQ0Þn"uÌ"Î{o±Ò+rÓ9cD[ø"r¦8"°‡2°¯ŒÈH… â¯ÛeÉ¿–™êÞ×Ζœ«QzV»ëß„ypÙ›aòòØvƒÕ…³ñ3’î÷»eäB¨hQ!K¦Éȱ\oÞG)VàÁà‚9²¸3üAî×›9w;—¼¯i~WgÞÎV¼¬õš®«vÎé ÓsÌÚM‚þº‚`=|˜ >ïæÖGW=ÁöÙ7.¼Vª— ]m(2o•`×Mäƒeí2y^ӢˎêçÆFƒ<é>Ñjí!ϳ3¬ÕhÞÕÖ>þYÊýñYî·Ö +.@ ü,ñ“`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[Ïe2rÃ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Þ¢óëöæE¢!V§Ôëig„_›0ˆ²eÅš¸ƒÎä¬ø™FÈÞ»nš—4;¯Ò¦}B‘¹ªNÊgeoX™Ú|ãÂ&÷ó_Ñ.‡`…ZPBÐïV-Ïdp-Þ ÷ôu¿VjÒé³-‚núR?uC².Vstã øu $]du=ÉæéFtâ¼}ÀCË›“›:æû¾˜𓿺± câ2Ià‡—„-Ü<Ì´•’[k+¸êÇQy—©Öÿc¡ŽCˆeŒ¼Ôÿ²áÔÓ; Ý מ %ÍOD5Ñ™C¹ì*Þ–yßq. ÆÏ'›oãê¼ ™æ>ç´,Œæñ³-yÉß«Œ'D¶u]v Î­âQ8ŒF÷Ùî>Áß e´âÔItŽfsX;†Ýõ/‚)rž +|dà3E¹Æ:[qáÚ™£ò|Q²îî +¦A½­! V™Ñ«ô¸õ!UÖ‘»¿ûZì´àž÷¼ˆ_Éx ºËEµz™ãŸæ`ߎµ1BT5¢S.t´ÕãGéÓª›Jfƒ@áƒüZ~9:מÊF&–es×A·„^_Òj:Š54e°ñ2ZÅ[»É8=–èlÂÑßøè\ÓÒØø³h!Y@ÁÓý_¦ñµÊh1Û áu7\°’¥Äå{ÆR=úGn2ÜF«ä¿+ÛþäôzK×î=_B¥¶4o®ñ‹Tœ‘6\¾±TéT3]‹jÚatØŒ~‰Ì d…ú;ÁxÄïÌ_¡ñÕÀoˆÜ*@ÆÜ©ç9ã—®£=h@ä8Öþ"%™ü—7¸3»óùÜêe: ­ Á¦a‘À=“ùTý îO”5¨84W@â‘Íx§²MÂõAU¤×yZl +ï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â4óË ë×b Ó>Fõ´í+ï…3w¹ü Üú¾r•M0Л͇ü™Œ(Zʽ‡è ÖÝJth¼Ž¥FP¹o#¢€ù‹i»½×Ç ¾™vôS5ñú''Xieûµ¨ÔØÇá…ü–JjMB¡Öx0ïtKY¿îJôÁ¤ø9ÐYe³ä\NxúVȵôzØŸBËLL«?sRÙíŒ1`¸O egƒêWØþR¨ªðHú&š¹‚V;ØTz°7Œ25»[àÿ8˜ ªg·t½ÿ™P¥bü§‡ØP "ªM}ÇìÒÇh“÷þèÒ‚]ž+™„¨c•ñ× +ƒË[ÓôÚ¯^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'÷W@LÓL7ô˜Ù×Ê4Gz™·j±RÑv·WX¯ eÑæÓ˜¬>îcçE[(Œ4ÒÝãÄ6æ«wadX.ì‹ÖõI&b3%™Î|Ä„£• µ€MÛƆYýS1­\Q­{ô"²ôvq¿qJáænTPXšß~ó™*¨0D6_d ðvû—Ïä"SE¾2å¹ì– cÅ:ßíx:?>þ´Ì\û¯ÕuËi-kÅá·eájAŽö´­€Pª÷,û“x+ñ–N³WyÞ%I'µ¯²NŽã¼õç!ªÞg÷º˜°Û—ÇÎ{ó;j’k˜',ž¼Á9@d¶ÇŒyßúsèìÊÀăԱî“æ_Æ·é«œP8 GÝýÞÌi<úyÈ°2«0$įoUiPÌ3+Pdñ:K Ñº–%‘\·ÓœA³nL™=ôø~ØsP sé¾ìEí$³Ô›†i2 Î1‚‰"þiaùøj¾U¢0@‚³ÜóEnˆk“¡ýAßèŒ0¯±¶è3‘éStCÜ3¡…NðöÞ°QOè/ +Ÿ–YBAí¿†ÒŒê§äkÖÁ[„Xé„5ÔOBÌåçŒ;ç0NGGw¶;è‹qJ¤:„ËIñÃ`’&§ +~êŸch]8-ož¨­`¤÷3oi>ýß" C¸ð*$4üÊVÊÇà-L>?´<²èl7“xxÞŠâƒsÌ™ú sŠÒµÅG +‹I: "0²sŠ|¯ÕÁí›góij§6W]˜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_‚)(ƒ+ |õ÷±íàõ§¼Õæ÷ãæGT 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‡[Úýoóçu¹Òè™ÒN´¦7¢5LvFN”‡…ZäöüäØ Ó•"ÇoÓpšm®“° +.òvŒÆ›ãWa°r՜ܔ`Ÿ}ö¿¯ÂýÛwq¹ÙïÖ”‚·0®„i‘%Áüwþ!W¤Ìëe²Ó +¿£JÄäôÀÈ~ ïbþCñ÷a¼™V£;Ò9Dáö$hGSú‰]À¼#A97±§ãÈ*Á¡atìm}¶—†mK•8ù6T«Ç}þÖåãÜxò`žüyþÕ\ÈqïN51FA1Â'Œ‘uôÐÅ42î²8ݕ沊° Fô„«Ô¬àCøb&åûlÅ +.ô.!¯ ùŒl}‹²-ꦚ!Î(®dìQl’ç0(oih7»"âØS ~M¹û¶%úÇõ+°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:‰»M¸²Åˆ§Ÿ·ö!4sBúmU¨ëˆ€è¾ ˆ¥g? à*TÚŸ®¦„ñ½>3V ð +…¯oÏà’X³`G ÊŸMjâVQ̼ó{?#ü{¨ +ÿ†%ôAn÷«Et_I^}Ü<&ì°ÄªäcY:/‹Èš 7Ôöyvcªð, +´Âpmê_oS´±KR*\ÍeãzÜ­ bfú0óz30s–ÙXsø1ðniȹ‡"/]vºrÊO‚0Ð4.²'‚çàž³ÖVŠ¢2ðm+ø«Ö°ÎhP_  P^ÉòâRý;ÐÄ“œjÒ Ë&Oæng•Ûlý0kôÂ7¢mWÌçO5RŒ0 +ŠÇ½Íè÷å/‘:Ìé5b"=žOæýÕ0Z꛳Ùø¹'sä3âçDç&EÇ]ñO¶>Ä®ÉoœíáQO˜­¤zêY`úü˜´Í¬Ž5íh'^oýHÑPbìPŽzÝñ)aþtgÚÓ€'ÁÀêÂß8$æ K&ßçÁ[NÖøü¡—ýÕv³-Aõ£qž«ÙæwC…ú‹† Ø”Šÿrlç×–„rjÓäŸõ[N1Ij’âú˜¢^…æ‚pBÆ×}# ¹Ùʇ†êQuÆÚï2K/Q}äŠñþB–å^Kðo£ò‰PÌ •ÔZ³]pð |"XöPìv(Èœ•!»–AC†²ÜÈ飤QB$ÐÄg™¶T7ä;ß²'¿¼ÒOѪ^ß -ƒA’/˜|ËÝFÊšVqÝ¿ˆi7Ü/Ko›S¬š«©1 +‘ƒú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÷VýgÜÌ?Ù_øö'jœÙ‰Ìk@Ì•›é™fÐñŒï·ÂvÍã™'ð”ÚÖ¦E;¾SôŸÕÂoÍQ±‡å*ÄÚT`~ª0¤®1æ; û³?Ø^ùM›DÃ%‹†ÚÉ {:õ ̓XP°"ù5DØbÁvZÃÞûµäB•,º ¿›´üÅ\‡)W©+±UÐKü€FY²{çU¾‚Š'2èB),éÉ ‚ã$W’îÏ°=w>ÒT› +ª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[/ÎtS> üÆ3Ý[מ¢ÿ}×yáõ1&—(~Ÿ(â¹]èÖà_Bæ»L \òÆDša×+ù›>•§:Χ¡I‡: cº¡NƒU‹SôÓÉt<þŒP¦_kt(­Ìkß#þv&1‰oJ£ +êä;ã¶,¤ R††§t«É–¯Îo$–Nžù˜ªÏÍê;~6owAõÁf=c³½ŒÎF[Å„æù–¢ k¦ƒùœrÏ%ǨTá…äé ~BÖ|®âËGbÏîå ȲÆà|RMì^ï6QÌHè6 jRjôäßÄËè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ù´i½TªWÂW’œÃ9“? &µ=,³J.Ÿ!½ˆq·¥ÄŽb½«<.]—æ|2Çy¨²¿äfþ¸p›­0ÐÜõ‹´ÙC“žî¤ðš'M`\•xºrAÚ\WQol¾EîßgîI"wÛæÔ×¢B‹ŠJ4H ‰¤½1—hòK»ß diG!áÅ~Aðö†ÞßÁ½â ¿ZoGÝ. P×£h?¡j3BáëÖ׬s‰cëØš&æÕpzð8Æ9Ùw;ž ‡YQ”«®ô¹?XA¢j#(О)Ù5¬4*ÉþGˆ#_hX +‘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·Ðò¹…ž $ênúŠ–ööÃdq…K¹Æ}¦…k'Í^ó` +ØNB†@–·üa`laø¯"kÝ =“¿'pryÄWæV(ªŸö_š_ЪeÆ?±÷Áž–Lô]Í„ ~=³_PHã7HPͲü§.÷àÚG â“™•o…–ÃÅÎÙ‚–¥kD˜°ùÓïÎ,€Ý¶ =ÏkßWÁ¢°™mNž«Ô­I­š^ØG1߬þ?ÌÝkœ ({¼L”<Èà+3¼$S¥I¬L`h9Ä÷}6·b'º^» +3c]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¨ãLF37öÐkKã 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”™þ¡±šç©‰Øô:î»:·€·^Ϩ„¯¶qzº QVàD~Í‘6‰KÞY[ÑÛ"•y'$˼Р;w%˜ÐqàÆ9æuµ4Œ H”iX± +Æ94£ë Fsf‡U…ÞpÃxò¯*N.sžuÒ7#0÷Óc‚HÕ˜ –âYph9ÅUG— Þ¿¯çÖëY:/¾=¶'·2€ùµG³<~ª:™HJë¸p”£0L;µ/$I@ÁW» |8ú‚¹>ú¦êd,xTjè4q +ŠÝØ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šöùsCì¶G’Ð!YŠ WaðŠ +·Yà¾]ˆh‘!{â#iŽ»¤"”¯ùù4bwËZ¨X à2&£‘.¿l=b, ¢,ÙlÔúAœ¦Gôì©5W0!ÒãBîV\Êå6ÔÔëߥåíýŽá;RЭ$øžv(Ó@ÃICM«Çv¹Ì_§/# È +ÙÌÑ‚§õ±Á¿2å 6ôw’ä{0ëó¬+/6A3C¿X ¬Ÿ?ö¹¤Ñ<ÛˆUëœ"¸¢R2ìú6ÉOôi¦Æ·:+tÝ•;¯–fnÎÇ +¥0©j T™¶„qÚ]¡ÁÂ'DY¸ ö.g¬Âñ¨û ;AJÒ´á¿ÔÍ­[ßÇHûaA@Ôñ ?ÍJµAì»tI•%[Ø­$ Òð³"ɾs™ÿ?÷€ÿS;sc7G{c[¸ÿ£kendstream +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/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in index ede9342535d..88a54e30a54 100644 --- a/contrib/bind9/doc/arm/Makefile.in +++ b/contrib/bind9/doc/arm/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001, 2002 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.8.2.2.8.3 2004/03/08 09:04:24 marka Exp $ +# $Id: Makefile.in,v 1.8.2.2.8.5 2005/05/13 01:22:35 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -23,47 +23,41 @@ top_srcdir = @top_srcdir@ MANOBJS = Bv9ARM.html +PDFOBJS = Bv9ARM.pdf + distclean:: rm -f validate.sh rm -f nominum-docbook-html.dsl nominum-docbook-print.dsl rm -f HTML.index HTML.manifest -doc man:: ${MANOBJS} +doc man:: ${MANOBJS} ${PDFOBJS} -docclean manclean maintainer-clean:: - rm -f *.html +clean:: + rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx + rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp -Bv9ARM.html: Bv9ARM-book.xml nominum-docbook-html.dsl - ${OPENJADE} -v \ - -c ${SGMLCATALOG} \ - -t sgml \ - -d ./nominum-docbook-html.dsl \ - ${XMLDCL} ./Bv9ARM-book.xml - rm -f HTML.index HTML.manifest +docclean manclean maintainer-clean:: clean + rm -f *.html *.pdf -Bv9ARM-book.rtf: Bv9ARM-book.xml nominum-docbook-print.dsl - ${OPENJADE} -v \ - -c ${SGMLCATALOG} \ - -t rtf \ - -d ./nominum-docbook-print.dsl \ - ${XMLDCL} ./Bv9ARM-book.xml +Bv9ARM.html: Bv9ARM-book.xml + ${XSLTPROC} --stringparam root.filename Bv9ARM \ + ${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl \ + Bv9ARM-book.xml -Bv9ARM-book.tex: Bv9ARM-book.xml nominum-docbook-print.dsl - ${OPENJADE} -v \ - -c ${SGMLCATALOG} \ - -d ./nominum-docbook-print.dsl \ - -t tex \ - ${XMLDCL} ./Bv9ARM-book.xml +Bv9ARM.tex: Bv9ARM-book.xml + ${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl Bv9ARM-book.xml | \ + ${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \ + @PERL@ latex-fixup.pl >$@.tmp + if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi -Bv9ARM-book.dvi: Bv9ARM-book.tex +Bv9ARM.dvi: Bv9ARM.tex rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log - ${JADETEX} ./Bv9ARM-book.tex || true - ${JADETEX} ./Bv9ARM-book.tex || true - ${JADETEX} ./Bv9ARM-book.tex || true + ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ + ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ + ${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ -Bv9ARM-book.pdf: Bv9ARM-book.tex +Bv9ARM.pdf: Bv9ARM.tex rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log - ${PDFJADETEX} ./Bv9ARM-book.tex || true - ${PDFJADETEX} ./Bv9ARM-book.tex || true - ${PDFJADETEX} ./Bv9ARM-book.tex || true - + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@ 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 00000000000..fa41e7635e2 --- /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 + ------ ---- ------ ----- ---- -------------- + + + + +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 . + + 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 + . + + "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 00000000000..2cd972473d0 --- /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) + + +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 00000000000..438e8008a4c --- /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 00000000000..3a800f98880 --- /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 00000000000..ee03583a130 --- /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 00000000000..f7abddc43e4 --- /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 00000000000..17e28e8286e --- /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 00000000000..dd8cbf0682e --- /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 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 00000000000..2cdcdb16c92 --- /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 + -------- ----- ---- -- --- --- + + + 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 . + + 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 00000000000..1c4c3f635e3 --- /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 + ------ ---- ------ ----- ---- ------------- ------------- + + + 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", + . + + + + + + + +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 00000000000..160afc356a0 --- /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 00000000000..5de6e85ecf6 --- /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 + 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 00000000000..cc3c276b99a --- /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 00000000000..5b6d655297e --- /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 + --- ------ --- --------- ----------- -- --- --- + + 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 + . + + 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 00000000000..2ec9dbec512 --- /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 . 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 ". 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 ". 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 + 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 00000000000..5e6cb1d09e2 --- /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 + ------- -- -------------- ------ ----------- -- --- --- + + + + +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 + . + + 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 00000000000..0af13c616f9 --- /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 00000000000..9c73c68befd --- /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 + ".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 00000000000..b5aaad2b859 --- /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 00000000000..df702b41ec9 --- /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 00000000000..a59595f5901 --- /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 + ---- --- ---- --------- ----------- + + + +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 . + + 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 00000000000..fad88aedaba --- /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 "*.", where is any domain name. +# 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 + 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 + _ssh._tcp.host2.example. 3600 SRV + 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: + .. + 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 + 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 00000000000..a56969e57f6 --- /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 () 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 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] + + +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 00000000000..a5d0d6079a7 --- /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 00000000000..bcd0d14e4b5 --- /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 00000000000..bf2afcdfb3a --- /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 00000000000..1276f9f91d6 --- /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 00000000000..6bece56182c --- /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 00000000000..63fe2de521a --- /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 + 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 00000000000..242aa9ea629 --- /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/misc/options b/contrib/bind9/doc/misc/options index c746e498f36..01546b72644 100644 --- a/contrib/bind9/doc/misc/options +++ b/contrib/bind9/doc/misc/options @@ -49,6 +49,7 @@ options { use-id-pool ; // obsolete use-ixfr ; version ( | none ); + flush-zones-on-shutdown ; allow-recursion { ; ... }; allow-v6-synthesis { ; ... }; // obsolete sortlist { ; ... }; diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index index fb72ccc314d..5c588db9301 100644 --- a/contrib/bind9/doc/rfc/index +++ b/contrib/bind9/doc/rfc/index @@ -76,9 +76,9 @@ Addresses in the Domain Name System (DNS) 3364: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) -3390: Internationalizing Domain Names In Applications (IDNA) 3425: Obsoleting IQUERY 3445: Limiting the Scope of the KEY Resource Record (RR) +3490: Internationalizing Domain Names In Applications (IDNA) 3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) 3492: Punycode:A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) @@ -90,5 +90,14 @@ Secret Key Transaction Authentication for DNS (GSS-TSIG) 3655: Redefinition of DNS Authenticated Data (AD) bit 3658: Delegation Signer (DS) Resource Record (RR) +3757: Domain Name System KEY (DNSKEY) Resource Record (RR) + Secure Entry Point (SEP) Flag 3833: Threat Analysis of the Domain Name System (DNS) 3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format +3901: DNS IPv6 Transport Operational Guidelines +4025: A Method for Storing IPsec Keying Material in DNS +4033: DNS Security Introduction and Requirements +4034: Resource Records for the DNS Security Extensions +4035: Protocol Modifications for the DNS Security Extensions +4074: Common Misbehavior Against DNS Queries for IPv6 Addresses +4159: Deprecation of "ip6.int" diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt new file mode 100644 index 00000000000..31890a4bcbe --- /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 00000000000..43b7356e6ad --- /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 00000000000..92e7f400795 --- /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 00000000000..7f0a4647731 --- /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 : An 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 00000000000..6a12c6b8efc --- /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 00000000000..b701cd2f235 --- /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 + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match and does contain one or more RRsets that + match via wildcard name expansion, but does not + contain any RRsets that match 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 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 but contains no + RRset matching , then the name server MUST + include the NSEC RR for 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 + 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 . + + o An NSEC RR proving that the zone contains no RRsets that would + match 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 but does contain an RRset that matches + 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 . 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 , and although the zone + does contain RRsets that match 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 via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for . + + 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 , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + + 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 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 00000000000..d9252b39eb5 --- /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, . + +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 00000000000..1ab4bd1ae34 --- /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/Makefile.in b/contrib/bind9/lib/bind/Makefile.in index 0a2a1a0fac7..5c34c1a1842 100644 --- a/contrib/bind9/lib/bind/Makefile.in +++ b/contrib/bind9/lib/bind/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.12.2.5.2.7 2004/12/09 04:07:14 marka Exp $ +# $Id: Makefile.in,v 1.12.2.5.2.9 2005/07/29 00:13:08 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -85,10 +85,11 @@ NAMESEROBJS= nameser/ns_date.@O@ nameser/ns_name.@O@ nameser/ns_netint.@O@ \ nameser/ns_parse.@O@ nameser/ns_print.@O@ nameser/ns_samedomain.@O@ \ nameser/ns_sign.@O@ nameser/ns_ttl.@O@ nameser/ns_verify.@O@ -RESOLVOBJS= resolv/herror.@O@ resolv/res_comp.@O@ resolv/res_data.@O@ \ - resolv/res_debug.@O@ resolv/res_findzonecut.@O@ resolv/res_init.@O@ \ - resolv/res_mkquery.@O@ resolv/res_mkupdate.@O@ resolv/res_query.@O@ \ - resolv/res_send.@O@ resolv/res_sendsigned.@O@ resolv/res_update.@O@ +RESOLVOBJS= resolv/herror.@O@ resolv/mtctxres.@O@ resolv/res_comp.@O@ \ + resolv/res_data.@O@ resolv/res_debug.@O@ resolv/res_findzonecut.@O@ \ + resolv/res_init.@O@ resolv/res_mkquery.@O@ resolv/res_mkupdate.@O@ \ + resolv/res_query.@O@ resolv/res_send.@O@ resolv/res_sendsigned.@O@ \ + resolv/res_update.@O@ SUBDIRS = bsd dst include inet irs isc nameser resolv @PORT_INCLUDE@ diff --git a/contrib/bind9/lib/bind/api b/contrib/bind9/lib/bind/api index acc853bbf2a..dcc846ea527 100644 --- a/contrib/bind9/lib/bind/api +++ b/contrib/bind9/lib/bind/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 3 -LIBREVISION = 8 +LIBINTERFACE = 4 +LIBREVISION = 2 LIBAGE = 0 diff --git a/contrib/bind9/lib/bind/config.h.in b/contrib/bind9/lib/bind/config.h.in index 6c86b4deed2..82a1560d1fd 100644 --- a/contrib/bind9/lib/bind/config.h.in +++ b/contrib/bind9/lib/bind/config.h.in @@ -1,6 +1,8 @@ #undef _SOCKADDR_LEN #undef HAVE_FCNTL_H #undef HAVE_PATHS_H +#undef HAVE_INTTYPES_H +#undef HAVE_STROPTS_H #undef HAVE_SYS_TIMERS_H #undef SYS_CDEFS_H #undef _POSIX_PTHREAD_SEMANTICS @@ -35,6 +37,8 @@ #undef HAS_PW_CLASS +#undef uintptr_t + /* Shut up warnings about sputaux in stdio.h on BSD/OS pre-4.1 */ #undef SHUTUP_SPUTAUX #ifdef SHUTUP_SPUTAUX diff --git a/contrib/bind9/lib/bind/configure b/contrib/bind9/lib/bind/configure index 1baa91eeafd..8f12621650b 100755 --- a/contrib/bind9/lib/bind/configure +++ b/contrib/bind9/lib/bind/configure @@ -1,5 +1,5 @@ #! /bin/sh -# From configure.in Revision: 1.83.2.5.2.10 . +# From configure.in Revision: 1.83.2.5.2.22 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -464,7 +464,7 @@ ac_includes_default="\ # include #endif" -ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS WANT_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS' +ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS WANT_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_NONBLOCK PORT_DIR USE_POLL HAVE_MD5 SOLARIS2 PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS' ac_subst_files='BIND9_INCLUDES BIND9_MAKE_RULES LIBBIND_API' # Initialize some variables set by options. @@ -1019,7 +1019,7 @@ if test -n "$ac_init_help"; then Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] - --disable-threads disable multithreading + --enable-threads enable multithreading --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] @@ -3472,7 +3472,8 @@ done -for ac_header in fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h + +for ac_header in fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h stropts.h do as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh` if eval "test \"\${$as_ac_Header+set}\" = set"; then @@ -3622,7 +3623,6 @@ fi done - echo "$as_me:$LINENO: checking for an ANSI C-conforming const" >&5 echo $ECHO_N "checking for an ANSI C-conforming const... $ECHO_C" >&6 if test "${ac_cv_c_const+set}" = set; then @@ -3867,6 +3867,72 @@ _ACEOF fi +echo "$as_me:$LINENO: checking for uintptr_t" >&5 +echo $ECHO_N "checking for uintptr_t... $ECHO_C" >&6 +if test "${ac_cv_type_uintptr_t+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +$ac_includes_default +int +main () +{ +if ((uintptr_t *) 0) + return 0; +if (sizeof (uintptr_t)) + return 0; + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_type_uintptr_t=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_type_uintptr_t=no +fi +rm -f conftest.err conftest.$ac_objext conftest.$ac_ext +fi +echo "$as_me:$LINENO: result: $ac_cv_type_uintptr_t" >&5 +echo "${ECHO_T}$ac_cv_type_uintptr_t" >&6 +if test $ac_cv_type_uintptr_t = yes; then + : +else + +cat >>confdefs.h <<_ACEOF +#define uintptr_t unsigned long +_ACEOF + +fi + echo "$as_me:$LINENO: checking whether time.h and sys/time.h may both be included" >&5 echo $ECHO_N "checking whether time.h and sys/time.h may both be included... $ECHO_C" >&6 if test "${ac_cv_header_time+set}" = set; then @@ -4435,24 +4501,81 @@ esac # # First, decide whether to use multithreading or not. # -echo "$as_me:$LINENO: checking whether to look for thread support" >&5 -echo $ECHO_N "checking whether to look for thread support... $ECHO_C" >&6 +# Enable multithreading by default on systems where it is known +# to work well, and where debugging of multithreaded programs +# is supported. +# + +echo "$as_me:$LINENO: checking whether to build with thread support" >&5 +echo $ECHO_N "checking whether to build with thread support... $ECHO_C" >&6 + +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 ;; +*-bsdi234*) + # 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 + # Check whether --enable-threads or --disable-threads was given. if test "${enable_threads+set}" = set; then enableval="$enable_threads" fi; case "$enable_threads" in - yes|'') - echo "$as_me:$LINENO: result: yes" >&5 -echo "${ECHO_T}yes" >&6 + yes) use_threads=true ;; no) - echo "$as_me:$LINENO: result: no" >&5 -echo "${ECHO_T}no" >&6 use_threads=false ;; + '') + # Use system-dependent default + ;; *) { { echo "$as_me:$LINENO: error: --enable-threads takes yes or no" >&5 echo "$as_me: error: --enable-threads takes yes or no" >&2;} @@ -4460,6 +4583,15 @@ echo "$as_me: error: --enable-threads takes yes or no" >&2;} ;; esac +if $use_threads +then + echo "$as_me:$LINENO: result: yes" >&5 +echo "${ECHO_T}yes" >&6 +else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 +fi + if $use_threads then # @@ -4497,23 +4629,32 @@ echo "${ECHO_T}PTL2" >&6 echo "$as_me: WARNING: linking with PTL2 is highly experimental and not expected to work" >&2;} CC=ptlgcc else - if test ! -d $LOCALBASE/pthreads + if test -r /usr/lib/libpthread.so then - echo "$as_me:$LINENO: result: none" >&5 + echo "$as_me:$LINENO: result: native" >&5 +echo "${ECHO_T}native" >&6 + LIBS="-lpthread $LIBS" + else + if test ! -d $LOCALBASE/pthreads + then + echo "$as_me:$LINENO: result: none" >&5 echo "${ECHO_T}none" >&6 - use_threads=false - fi + { { echo "$as_me:$LINENO: error: \"could not find thread libraries\"" >&5 +echo "$as_me: error: \"could not find thread libraries\"" >&2;} + { (exit 1); exit 1; }; } + fi - if $use_threads - then - echo "$as_me:$LINENO: result: mit-pthreads/unproven-pthreads" >&5 + if $use_threads + then + echo "$as_me:$LINENO: result: mit-pthreads/unproven-pthreads" >&5 echo "${ECHO_T}mit-pthreads/unproven-pthreads" >&6 - 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" + 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 ;; @@ -4883,7 +5024,9 @@ _ACEOF LIBS="-lc $LIBS" else - use_threads=false + { { echo "$as_me:$LINENO: error: \"could not find thread libraries\"" >&5 +echo "$as_me: error: \"could not find thread libraries\"" >&2;} + { (exit 1); exit 1; }; } fi fi @@ -5443,6 +5586,10 @@ _ACEOF ;; *hpux11*) + cat >>confdefs.h <<\_ACEOF +#define NEED_ENDNETGRENT_R 1 +_ACEOF + cat >>confdefs.h <<\_ACEOF #define _PTHREADS_DRAFT4 1 _ACEOF @@ -5597,11 +5744,20 @@ fi ;; esac fi + cat >>confdefs.h <<\_ACEOF +#define _REENTRANT 1 +_ACEOF + ALWAYS_DEFINES="-D_REENTRANT" DO_PTHREADS="#define DO_PTHREADS 1" WANT_IRS_THREADSGR_OBJS="\${WANT_IRS_THREADSGR_OBJS}" WANT_IRS_THREADSPW_OBJS="\${WANT_IRS_THREADSPW_OBJS}" - WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}" + case $host in + ia64-hp-hpux11.*) + WANT_IRS_THREADS_OBJS="";; + *) + WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}";; + esac WANT_THREADS_OBJS="\${WANT_THREADS_OBJS}" thread_dir=pthreads else @@ -5614,6 +5770,13 @@ else thread_dir=nothreads fi + + + + + + + echo "$as_me:$LINENO: checking for strlcat" >&5 echo $ECHO_N "checking for strlcat... $ECHO_C" >&6 if test "${ac_cv_func_strlcat+set}" = set; then @@ -5712,13 +5875,6 @@ _ACEOF fi - - - - - - - echo "$as_me:$LINENO: checking for if_nametoindex" >&5 echo $ECHO_N "checking for if_nametoindex... $ECHO_C" >&6 if test "${ac_cv_func_if_nametoindex+set}" = set; then @@ -6267,7 +6423,7 @@ else ;; *) # Turn off the pointlessly noisy warnings. - STD_CWARNINGS="+w1 +W 474,530" + STD_CWARNINGS="+w1 +W 474,530,2193,2236" ;; esac CCOPT="$CCOPT -Ae -z" @@ -6423,6 +6579,156 @@ fi # case "$host" in mips-sgi-irix*) + ;; + ia64-hp-hpux11.*) + +echo "$as_me:$LINENO: checking for socket in -lsocket" >&5 +echo $ECHO_N "checking for socket in -lsocket... $ECHO_C" >&6 +if test "${ac_cv_lib_socket_socket+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS +LIBS="-lsocket $LIBS" +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ + +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char socket (); +int +main () +{ +socket (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_socket_socket=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_lib_socket_socket=no +fi +rm -f conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS +fi +echo "$as_me:$LINENO: result: $ac_cv_lib_socket_socket" >&5 +echo "${ECHO_T}$ac_cv_lib_socket_socket" >&6 +if test $ac_cv_lib_socket_socket = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBSOCKET 1 +_ACEOF + + LIBS="-lsocket $LIBS" + +fi + + +echo "$as_me:$LINENO: checking for inet_ntoa in -lnsl" >&5 +echo $ECHO_N "checking for inet_ntoa in -lnsl... $ECHO_C" >&6 +if test "${ac_cv_lib_nsl_inet_ntoa+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS +LIBS="-lnsl $LIBS" +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ + +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char inet_ntoa (); +int +main () +{ +inet_ntoa (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_nsl_inet_ntoa=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_lib_nsl_inet_ntoa=no +fi +rm -f conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS +fi +echo "$as_me:$LINENO: result: $ac_cv_lib_nsl_inet_ntoa" >&5 +echo "${ECHO_T}$ac_cv_lib_nsl_inet_ntoa" >&6 +if test $ac_cv_lib_nsl_inet_ntoa = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBNSL 1 +_ACEOF + + LIBS="-lnsl $LIBS" + +fi + ;; *) @@ -7296,7 +7602,7 @@ ia64-*-hpux*) ;; *-*-irix6*) # Find out which ABI we are using. - echo '#line 7299 "configure"' > conftest.$ac_ext + echo '#line 7605 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -8293,7 +8599,7 @@ fi # Provide some information about the compiler. -echo "$as_me:8296:" \ +echo "$as_me:8602:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version &5\"") >&5 @@ -9354,11 +9660,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9357: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9663: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9361: \$? = $ac_status" >&5 + echo "$as_me:9667: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -9597,11 +9903,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9600: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9906: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9604: \$? = $ac_status" >&5 + echo "$as_me:9910: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -9657,11 +9963,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9660: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9966: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:9664: \$? = $ac_status" >&5 + echo "$as_me:9970: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -11842,7 +12148,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5) + (eval echo "\"\$as_me:14446: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:14144: \$? = $ac_status" >&5 + echo "$as_me:14450: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -14197,11 +14503,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14200: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14506: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:14204: \$? = $ac_status" >&5 + echo "$as_me:14510: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -15558,7 +15864,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5) + (eval echo "\"\$as_me:16802: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:16500: \$? = $ac_status" >&5 + echo "$as_me:16806: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -16553,11 +16859,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16556: $lt_compile\"" >&5) + (eval echo "\"\$as_me:16862: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:16560: \$? = $ac_status" >&5 + echo "$as_me:16866: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -18592,11 +18898,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18595: $lt_compile\"" >&5) + (eval echo "\"\$as_me:18901: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:18599: \$? = $ac_status" >&5 + echo "$as_me:18905: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -18835,11 +19141,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18838: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19144: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:18842: \$? = $ac_status" >&5 + echo "$as_me:19148: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -18895,11 +19201,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:18898: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19204: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:18902: \$? = $ac_status" >&5 + echo "$as_me:19208: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -21080,7 +21386,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext < conftest.$ac_ext <&5 echo $ECHO_N "checking for getnetbyaddr_r... $ECHO_C" >&6 if test "${ac_cv_func_getnetbyaddr_r+set}" = set; then @@ -25518,6 +25850,66 @@ else echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#undef __USE_MISC +#define __USE_MISC +#include +int getnetbyaddr_r (uint32_t, int, struct netent *, + char *, size_t, struct netent **, int *); + +int +main () +{ +return (0) + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + +NET_R_ARGS="#define NET_R_ARGS char *buf, size_t buflen, struct netent **answerp, int *h_errnop" +NET_R_BAD="#define NET_R_BAD ERANGE" +NET_R_COPY="#define NET_R_COPY buf, buflen" +NET_R_COPY_ARGS="#define NET_R_COPY_ARGS char *buf, size_t buflen" +NET_R_OK="#define NET_R_OK 0" +NET_R_SETANSWER="#define NET_R_SETANSWER 1" +NET_R_RETURN="#define NET_R_RETURN int" +GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T unsigned long int" +NETENT_DATA="#undef NETENT_DATA" + +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +fi +rm -f conftest.err conftest.$ac_objext conftest.$ac_ext + fi rm -f conftest.err conftest.$ac_objext conftest.$ac_ext @@ -25543,6 +25935,8 @@ NETENT_DATA="#undef NETENT_DATA" fi +esac + case "$host" in *dec-osf*) GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T int" ;; esac @@ -25767,6 +26161,11 @@ fi + +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for endnetent_r" >&5 echo $ECHO_N "checking for endnetent_r... $ECHO_C" >&6 if test "${ac_cv_func_endnetent_r+set}" = set; then @@ -26029,6 +26428,7 @@ NET_R_END_RETURN="#define NET_R_END_RETURN void" fi +esac @@ -26606,6 +27006,10 @@ fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for gethostbyname_r" >&5 echo $ECHO_N "checking for gethostbyname_r... $ECHO_C" >&6 if test "${ac_cv_func_gethostbyname_r+set}" = set; then @@ -26805,7 +27209,7 @@ HOST_R_ARGS="#define HOST_R_ARGS struct hostent_data *hdptr" HOST_R_BAD="#define HOST_R_BAD (-1)" HOST_R_COPY="#define HOST_R_COPY hdptr" HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS HOST_R_ARGS" -HOST_R_ERRNO="#define HOST_R_ERRNO NULL" +HOST_R_ERRNO="#undef HOST_R_ERRNO" HOST_R_OK="#define HOST_R_OK 0" HOST_R_RETURN="#define HOST_R_RETURN int" HOST_R_SETANSWER="#undef HOST_R_SETANSWER" @@ -26896,6 +27300,7 @@ HOSTENT_DATA="#undef HOSTENT_DATA" fi +esac @@ -26906,6 +27311,10 @@ fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for endhostent_r" >&5 echo $ECHO_N "checking for endhostent_r... $ECHO_C" >&6 if test "${ac_cv_func_endhostent_r+set}" = set; then @@ -27171,10 +27580,15 @@ HOST_R_ENT_ARGS="#undef HOST_R_ENT_ARGS /*empty*/" fi +esac; +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for sethostent_r" >&5 echo $ECHO_N "checking for sethostent_r... $ECHO_C" >&6 if test "${ac_cv_func_sethostent_r+set}" = set; then @@ -27428,6 +27842,7 @@ HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void" fi +esac @@ -27599,6 +28014,10 @@ fi rm -f conftest.err conftest.$ac_objext conftest.$ac_ext +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for getnetgrent_r" >&5 echo $ECHO_N "checking for getnetgrent_r... $ECHO_C" >&6 if test "${ac_cv_func_getnetgrent_r+set}" = set; then @@ -27878,6 +28297,7 @@ NGR_R_RETURN="#define NGR_R_RETURN int" fi +esac @@ -28209,6 +28629,10 @@ _ACEOF fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for getprotoent_r" >&5 echo $ECHO_N "checking for getprotoent_r... $ECHO_C" >&6 if test "${ac_cv_func_getprotoent_r+set}" = set; then @@ -28435,6 +28859,7 @@ PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *" fi +esac @@ -28443,6 +28868,10 @@ fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for endprotoent_r" >&5 echo $ECHO_N "checking for endprotoent_r... $ECHO_C" >&6 if test "${ac_cv_func_endprotoent_r+set}" = set; then @@ -28599,10 +29028,15 @@ PROTO_R_ENT_ARGS="#undef PROTO_R_ENT_ARGS /*empty*/" fi +esac +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for setprotoent_r" >&5 echo $ECHO_N "checking for setprotoent_r... $ECHO_C" >&6 if test "${ac_cv_func_setprotoent_r+set}" = set; then @@ -28754,6 +29188,7 @@ PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void" fi +esac @@ -29685,6 +30120,10 @@ _ACEOF fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for getservent_r" >&5 echo $ECHO_N "checking for getservent_r... $ECHO_C" >&6 if test "${ac_cv_func_getservent_r+set}" = set; then @@ -29907,6 +30346,7 @@ SERV_R_RETURN="#define SERV_R_RETURN struct servent *" fi +esac @@ -29915,6 +30355,10 @@ fi +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for endservent_r" >&5 echo $ECHO_N "checking for endservent_r... $ECHO_C" >&6 if test "${ac_cv_func_endservent_r+set}" = set; then @@ -30071,10 +30515,15 @@ SERV_R_ENT_ARGS="#undef SERV_R_ENT_ARGS /*empty*/" fi +esac +case $host in +ia64-hp-hpux11.*) +;; +*) echo "$as_me:$LINENO: checking for setservent_r" >&5 echo $ECHO_N "checking for setservent_r... $ECHO_C" >&6 if test "${ac_cv_func_setservent_r+set}" = set; then @@ -30229,6 +30678,7 @@ SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void" fi +esac @@ -30489,7 +30939,6 @@ case "$host" in hack_shutup_in6addr_init_macros=yes ;; *-solaris2.8) - hack_shutup_pthreadmutexinit=yes hack_shutup_in6addr_init_macros=yes ;; *-solaris2.9) @@ -31304,7 +31753,11 @@ s,@HAVE_MINIMUM_IFREQ@,$HAVE_MINIMUM_IFREQ,;t t s,@BSD_COMP@,$BSD_COMP,;t t s,@SOLARIS_BITTYPES@,$SOLARIS_BITTYPES,;t t s,@USE_FIONBIO_IOCTL@,$USE_FIONBIO_IOCTL,;t t +s,@PORT_NONBLOCK@,$PORT_NONBLOCK,;t t s,@PORT_DIR@,$PORT_DIR,;t t +s,@USE_POLL@,$USE_POLL,;t t +s,@HAVE_MD5@,$HAVE_MD5,;t t +s,@SOLARIS2@,$SOLARIS2,;t t s,@PORT_INCLUDE@,$PORT_INCLUDE,;t t s,@ISC_PLATFORM_MSGHDRFLAVOR@,$ISC_PLATFORM_MSGHDRFLAVOR,;t t s,@ISC_PLATFORM_NEEDPORTT@,$ISC_PLATFORM_NEEDPORTT,;t t diff --git a/contrib/bind9/lib/bind/configure.in b/contrib/bind9/lib/bind/configure.in index 74c18704f56..50ffe82ab18 100644 --- a/contrib/bind9/lib/bind/configure.in +++ b/contrib/bind9/lib/bind/configure.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -AC_REVISION($Revision: 1.83.2.5.2.10 $) +AC_REVISION($Revision: 1.83.2.5.2.22 $) AC_INIT(resolv/herror.c) AC_PREREQ(2.13) @@ -169,12 +169,12 @@ AC_PROG_CC AC_HEADER_STDC -AC_CHECK_HEADERS(fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h) - +AC_CHECK_HEADERS(fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h stropts.h) AC_C_CONST AC_C_INLINE AC_TYPE_SIZE_T +AC_CHECK_TYPE(uintptr_t,unsigned long) AC_HEADER_TIME # # check if we need to #include sys/select.h explicitly @@ -315,86 +315,7 @@ case "$use_randomdev" in ;; esac -# -# Begin pthreads checking. -# -# First, decide whether to use multithreading or not. -# -AC_MSG_CHECKING(whether to look for thread support) -AC_ARG_ENABLE(threads, - [ --disable-threads disable multithreading]) -case "$enable_threads" in - yes|'') - AC_MSG_RESULT(yes) - use_threads=true - ;; - no) - AC_MSG_RESULT(no) - use_threads=false - ;; - *) - AC_MSG_ERROR([--enable-threads takes yes or no]) - ;; -esac - -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 ! -d $LOCALBASE/pthreads - then - AC_MSG_RESULT(none) - use_threads=false - 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 - ;; - *) - 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,, - use_threads=false))))) - ;; - esac -fi +sinclude(../../config.threads.in)dnl if $use_threads then @@ -451,6 +372,7 @@ then AC_DEFINE(POSIX_GETGRNAM_R) ;; *hpux11*) + AC_DEFINE(NEED_ENDNETGRENT_R) AC_DEFINE(_PTHREADS_DRAFT4) ;; # @@ -503,11 +425,17 @@ then ;; esac fi + AC_DEFINE(_REENTRANT) ALWAYS_DEFINES="-D_REENTRANT" DO_PTHREADS="#define DO_PTHREADS 1" WANT_IRS_THREADSGR_OBJS="\${WANT_IRS_THREADSGR_OBJS}" WANT_IRS_THREADSPW_OBJS="\${WANT_IRS_THREADSPW_OBJS}" - WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}" + case $host in + ia64-hp-hpux11.*) + WANT_IRS_THREADS_OBJS="";; + *) + WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}";; + esac WANT_THREADS_OBJS="\${WANT_THREADS_OBJS}" thread_dir=pthreads else @@ -520,8 +448,6 @@ else thread_dir=nothreads fi -AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT)) - AC_SUBST(ALWAYS_DEFINES) AC_SUBST(DO_PTHREADS) AC_SUBST(WANT_IRS_THREADSGR_OBJS) @@ -529,6 +455,8 @@ AC_SUBST(WANT_IRS_THREADSPW_OBJS) AC_SUBST(WANT_IRS_THREADS_OBJS) AC_SUBST(WANT_THREADS_OBJS) +AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT)) + AC_CHECK_FUNC(if_nametoindex, [USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"], [USE_IFNAMELINKID="#undef USE_IFNAMELINKID"]) @@ -605,7 +533,7 @@ else ;; *) # Turn off the pointlessly noisy warnings. - STD_CWARNINGS="+w1 +W 474,530" + STD_CWARNINGS="+w1 +W 474,530,2193,2236" ;; esac CCOPT="$CCOPT -Ae -z" @@ -666,6 +594,10 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),) case "$host" in mips-sgi-irix*) ;; + ia64-hp-hpux11.*) + AC_CHECK_LIB(socket, socket) + AC_CHECK_LIB(nsl, inet_ntoa) + ;; *) AC_CHECK_LIB(d4r, gethostbyname_r) AC_CHECK_LIB(socket, socket) @@ -1075,6 +1007,10 @@ PORT_DIR=port/unknown SOLARIS_BITTYPES="#undef NEED_SOLARIS_BITTYPES" BSD_COMP="#undef BSD_COMP" USE_FIONBIO_IOCTL="#undef USE_FIONBIO_IOCTL" +PORT_NONBLOCK="#define PORT_NONBLOCK O_NONBLOCK" +HAVE_MD5="#undef HAVE_MD5" +USE_POLL="#undef HAVE_POLL" +SOLARIS2="#undef SOLARIS2" case "$host" in *aix3.2*) PORT_DIR="port/aix32";; *aix4*) PORT_DIR="port/aix4";; @@ -1082,7 +1018,9 @@ case "$host" in *aux3*) PORT_DIR="port/aux3";; *-bsdi2*) PORT_DIR="port/bsdos2";; *-bsdi*) PORT_DIR="port/bsdos";; - *-cygwin*) PORT_DIR="port/cygwin";; + *-cygwin*) + PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY" + PORT_DIR="port/cygwin";; *-darwin*) PORT_DIR="port/darwin";; *-osf*) PORT_DIR="port/decunix";; *-freebsd*) PORT_DIR="port/freebsd";; @@ -1098,30 +1036,46 @@ case "$host" in *-openbsd*) PORT_DIR="port/openbsd";; *-qnx*) PORT_DIR="port/qnx";; *-rhapsody*) PORT_DIR="port/rhapsody";; - *-solaris2.[[01234]]*) + *-sunos4*) + PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY" + PORT_DIR="port/sunos";; + *-solaris2.[[01234]]) BSD_COMP="#define BSD_COMP 1" SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1" USE_FIONBIO_IOCTL="#define USE_FIONBIO_IOCTL 1" + SOLARIS2="#define SOLARIS2 1" PORT_DIR="port/solaris";; - *-solaris2.5*) + *-solaris2.5) BSD_COMP="#define BSD_COMP 1" SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1" + SOLARIS2="#define SOLARIS2 1" + PORT_DIR="port/solaris";; + *-solaris2.[[67]]) + BSD_COMP="#define BSD_COMP 1" + SOLARIS2="#define SOLARIS2 1" PORT_DIR="port/solaris";; *-solaris2*) BSD_COMP="#define BSD_COMP 1" + USE_POLL="#define USE_POLL 1" + HAVE_MD5="#define HAVE_MD5 1" + SOLARIS2="#define SOLARIS2 1" PORT_DIR="port/solaris";; *-ultrix*) PORT_DIR="port/ultrix";; *-sco-sysv*uw2.0*) PORT_DIR="port/unixware20";; *-sco-sysv*uw2.1.2*) PORT_DIR="port/unixware212";; *-sco-sysv*uw7*) PORT_DIR="port/unixware7";; esac + AC_SUBST(BSD_COMP) AC_SUBST(SOLARIS_BITTYPES) AC_SUBST(USE_FIONBIO_IOCTL) +AC_SUBST(PORT_NONBLOCK) AC_SUBST(PORT_DIR) +AC_SUBST(USE_POLL) +AC_SUBST(HAVE_MD5) +AC_SUBST(SOLARIS2) PORT_INCLUDE=${PORT_DIR}/include AC_SUBST(PORT_INCLUDE) - # # Look for a 4.4BSD or 4.3BSD struct msghdr # @@ -1365,6 +1319,10 @@ AC_SUBST(GETGROUPLIST_ARGS) AC_CHECK_FUNC(setgroupent,,AC_DEFINE(NEED_SETGROUPENT)) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(getnetbyaddr_r, AC_TRY_COMPILE( [ @@ -1453,6 +1411,26 @@ NET_R_RETURN="#define NET_R_RETURN int" GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T long" NETENT_DATA="#define NETENT_DATA 1" ], +AC_TRY_COMPILE( +#undef __USE_MISC +#define __USE_MISC +[#include +int getnetbyaddr_r (uint32_t, int, struct netent *, + char *, size_t, struct netent **, int *); +], +[return (0)], +[ +NET_R_ARGS="#define NET_R_ARGS char *buf, size_t buflen, struct netent **answerp, int *h_errnop" +NET_R_BAD="#define NET_R_BAD ERANGE" +NET_R_COPY="#define NET_R_COPY buf, buflen" +NET_R_COPY_ARGS="#define NET_R_COPY_ARGS char *buf, size_t buflen" +NET_R_OK="#define NET_R_OK 0" +NET_R_SETANSWER="#define NET_R_SETANSWER 1" +NET_R_RETURN="#define NET_R_RETURN int" +GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T unsigned long int" +NETENT_DATA="#undef NETENT_DATA" +], +) ) ) ) @@ -1468,6 +1446,8 @@ NET_R_RETURN="#define NET_R_RETURN struct netent *" GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T long" NETENT_DATA="#undef NETENT_DATA" ) +esac + case "$host" in *dec-osf*) GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T int" ;; esac @@ -1516,6 +1496,11 @@ AC_SUBST(NET_R_ENT_ARGS) AC_SUBST(NET_R_SET_RESULT) AC_SUBST(NET_R_SET_RETURN) + +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(endnetent_r, AC_TRY_COMPILE( [ @@ -1560,6 +1545,7 @@ NET_R_END_RETURN="#define NET_R_END_RETURN void" NET_R_END_RESULT="#define NET_R_END_RESULT(x) /*empty*/" NET_R_END_RETURN="#define NET_R_END_RETURN void" ) +esac AC_SUBST(NET_R_END_RESULT) AC_SUBST(NET_R_END_RETURN) @@ -1612,6 +1598,10 @@ AC_SUBST(GROUP_R_SET_RESULT) AC_SUBST(GROUP_R_SET_RETURN) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(gethostbyname_r, AC_TRY_COMPILE( [ @@ -1646,7 +1636,7 @@ HOST_R_ARGS="#define HOST_R_ARGS struct hostent_data *hdptr" HOST_R_BAD="#define HOST_R_BAD (-1)" HOST_R_COPY="#define HOST_R_COPY hdptr" HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS HOST_R_ARGS" -HOST_R_ERRNO="#define HOST_R_ERRNO NULL" +HOST_R_ERRNO="#undef HOST_R_ERRNO" HOST_R_OK="#define HOST_R_OK 0" HOST_R_RETURN="#define HOST_R_RETURN int" HOST_R_SETANSWER="#undef HOST_R_SETANSWER" @@ -1684,6 +1674,7 @@ HOST_R_RETURN="#define HOST_R_RETURN struct hostent *" HOST_R_SETANSWER="#undef HOST_R_SETANSWER" HOSTENT_DATA="#undef HOSTENT_DATA" ) +esac AC_SUBST(HOST_R_ARGS) AC_SUBST(HOST_R_BAD) AC_SUBST(HOST_R_COPY) @@ -1694,6 +1685,10 @@ AC_SUBST(HOST_R_RETURN) AC_SUBST(HOST_R_SETANSWER) AC_SUBST(HOSTENT_DATA) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(endhostent_r, AC_TRY_COMPILE([ #undef _REENTRANT @@ -1739,10 +1734,15 @@ HOST_R_END_RESULT="#define HOST_R_END_RESULT(x) /*empty*/" HOST_R_END_RETURN="#define HOST_R_END_RETURN void" HOST_R_ENT_ARGS="#undef HOST_R_ENT_ARGS /*empty*/" ) +esac; AC_SUBST(HOST_R_END_RESULT) AC_SUBST(HOST_R_END_RETURN) AC_SUBST(HOST_R_ENT_ARGS) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(sethostent_r, AC_TRY_COMPILE([ #undef _REENTRANT @@ -1778,6 +1778,7 @@ HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void"], HOST_R_SET_RESULT="#undef HOST_R_SET_RESULT" HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void" ) +esac AC_SUBST(HOST_R_SET_RESULT) AC_SUBST(HOST_R_SET_RETURN) @@ -1819,6 +1820,10 @@ SETGRENT_VOID="#undef SETGRENT_VOID" ) AC_SUBST(SETGRENT_VOID) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(getnetgrent_r, AC_TRY_COMPILE( [ @@ -1886,6 +1891,7 @@ NGR_R_COPY_ARGS="#define NGR_R_COPY_ARGS NGR_R_ARGS" NGR_R_OK="#define NGR_R_OK 1" NGR_R_RETURN="#define NGR_R_RETURN int" ) +esac AC_SUBST(NGR_R_ARGS) AC_SUBST(NGR_R_BAD) AC_SUBST(NGR_R_COPY) @@ -1930,6 +1936,10 @@ AC_SUBST(NGR_R_SET_RETURN) AC_CHECK_FUNC(innetgr_r,,AC_DEFINE(NEED_INNETGR_R)) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(getprotoent_r, AC_TRY_COMPILE( [ @@ -1984,6 +1994,7 @@ PROTO_R_OK="#define PROTO_R_OK pptr" PROTO_R_SETANSWER="#undef PROTO_R_SETANSWER" PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *" ) +esac AC_SUBST(PROTO_R_ARGS) AC_SUBST(PROTO_R_BAD) AC_SUBST(PROTO_R_COPY) @@ -1992,6 +2003,10 @@ AC_SUBST(PROTO_R_OK) AC_SUBST(PROTO_R_SETANSWER) AC_SUBST(PROTO_R_RETURN) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(endprotoent_r, AC_TRY_COMPILE( [ @@ -2015,10 +2030,15 @@ PROTO_R_END_RESULT="#define PROTO_R_END_RESULT(x) /*empty*/" PROTO_R_END_RETURN="#define PROTO_R_END_RETURN void" PROTO_R_ENT_ARGS="#undef PROTO_R_ENT_ARGS /*empty*/" ) +esac AC_SUBST(PROTO_R_END_RESULT) AC_SUBST(PROTO_R_END_RETURN) AC_SUBST(PROTO_R_ENT_ARGS) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(setprotoent_r, AC_TRY_COMPILE( [ @@ -2037,6 +2057,7 @@ PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void" PROTO_R_SET_RESULT="#undef PROTO_R_SET_RESULT" PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void" ) +esac AC_SUBST(PROTO_R_SET_RESULT) AC_SUBST(PROTO_R_SET_RETURN) @@ -2126,6 +2147,10 @@ AC_SUBST(PASS_R_SET_RETURN) AC_CHECK_FUNC(getpwnam_r,,AC_DEFINE(NEED_GETPWNAM_R)) AC_CHECK_FUNC(getpwuid_r,,AC_DEFINE(NEED_GETPWUID_R)) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(getservent_r, AC_TRY_COMPILE([ #undef __USE_MISC @@ -2172,6 +2197,7 @@ SERV_R_OK="#define SERV_R_OK sptr" SERV_R_SETANSWER="#undef SERV_R_SETANSWER" SERV_R_RETURN="#define SERV_R_RETURN struct servent *" ) +esac AC_SUBST(SERV_R_ARGS) AC_SUBST(SERV_R_BAD) AC_SUBST(SERV_R_COPY) @@ -2180,6 +2206,10 @@ AC_SUBST(SERV_R_OK) AC_SUBST(SERV_R_SETANSWER) AC_SUBST(SERV_R_RETURN) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(endservent_r, AC_TRY_COMPILE( [ @@ -2204,10 +2234,15 @@ SERV_R_END_RESULT="#define SERV_R_END_RESULT(x) /*empty*/" SERV_R_END_RETURN="#define SERV_R_END_RETURN void " SERV_R_ENT_ARGS="#undef SERV_R_ENT_ARGS /*empty*/" ) +esac AC_SUBST(SERV_R_END_RESULT) AC_SUBST(SERV_R_END_RETURN) AC_SUBST(SERV_R_ENT_ARGS) +case $host in +ia64-hp-hpux11.*) +;; +*) AC_CHECK_FUNC(setservent_r, AC_TRY_COMPILE( [ @@ -2229,6 +2264,7 @@ SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void" SERV_R_SET_RESULT="#undef SERV_R_SET_RESULT" SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void" ) +esac AC_SUBST(SERV_R_SET_RESULT) AC_SUBST(SERV_R_SET_RETURN) @@ -2327,7 +2363,6 @@ case "$host" in hack_shutup_in6addr_init_macros=yes ;; *-solaris2.8) - hack_shutup_pthreadmutexinit=yes hack_shutup_in6addr_init_macros=yes ;; *-solaris2.9) diff --git a/contrib/bind9/lib/bind/dst/dst_api.c b/contrib/bind9/lib/bind/dst/dst_api.c index 5f67bd9568c..51dfd0b8910 100644 --- a/contrib/bind9/lib/bind/dst/dst_api.c +++ b/contrib/bind9/lib/bind/dst/dst_api.c @@ -1,5 +1,5 @@ #ifndef LINT -static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/dst_api.c,v 1.4.2.6.8.1 2004/09/16 00:57:33 marka Exp $"; +static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/dst_api.c,v 1.4.2.6.8.3 2005/10/11 00:48:14 marka Exp $"; #endif /* @@ -336,7 +336,10 @@ dst_read_key(const char *in_keyname, const u_int16_t in_id, if (in_keyname == NULL) { EREPORT(("dst_read_private_key(): Null key name passed in\n")); return (NULL); - } else + } else if (strlen(in_keyname) >= sizeof(keyname)) { + EREPORT(("dst_read_private_key(): keyname too big\n")); + return (NULL); + } else strcpy(keyname, in_keyname); /* before I read in the public key, check if it is allowed to sign */ @@ -347,7 +350,7 @@ dst_read_key(const char *in_keyname, const u_int16_t in_id, return pubkey; if (!(dg_key = dst_s_get_key_struct(keyname, pubkey->dk_alg, - pubkey->dk_flags, pubkey->dk_proto, + pubkey->dk_flags, pubkey->dk_proto, 0))) return (dg_key); /* Fill in private key and some fields in the general key structure */ @@ -953,7 +956,6 @@ dst_generate_key(const char *name, const int bits, const int exp, const int flags, const int protocol, const int alg) { DST_KEY *new_key = NULL; - int res; int dnslen; u_char dns[2048]; @@ -975,7 +977,7 @@ dst_generate_key(const char *name, const int bits, const int exp, alg)); return (dst_free_key(new_key)); } - if ((res = new_key->dk_func->generate(new_key, exp)) <= 0) { + if (new_key->dk_func->generate(new_key, exp) <= 0) { EREPORT(("dst_generate_key_pair(): Key generation failure %s %d %d %d\n", new_key->dk_key_name, new_key->dk_alg, new_key->dk_key_size, exp)); diff --git a/contrib/bind9/lib/bind/dst/hmac_link.c b/contrib/bind9/lib/bind/dst/hmac_link.c index 8a641d0bf96..aa66c80ec0d 100644 --- a/contrib/bind9/lib/bind/dst/hmac_link.c +++ b/contrib/bind9/lib/bind/dst/hmac_link.c @@ -1,6 +1,6 @@ #ifdef HMAC_MD5 #ifndef LINT -static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_link.c,v 1.2.2.1 2003/06/27 03:51:36 marka Exp $"; +static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_link.c,v 1.2.2.1.4.1 2005/07/28 07:43:16 marka Exp $"; #endif /* * Portions Copyright (c) 1995-1998 by Trusted Information Systems, Inc. @@ -36,8 +36,15 @@ static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_lin #include #include "dst_internal.h" + #ifdef USE_MD5 -# include "md5.h" +# ifndef HAVE_MD5 +# include "md5.h" +# else +# ifdef SOLARIS2 +# include +# endif +# endif # ifndef _MD5_H_ # define _MD5_H_ 1 /* make sure we do not include rsaref md5.h file */ # endif @@ -438,7 +445,11 @@ dst_hmac_md5_generate_key(DST_KEY *key, const int nothing) * related functions */ int +#ifdef SUNW_LIBMD5 +dst_md5_hmac_init() +#else dst_hmac_md5_init() +#endif { if (dst_t_func[KEY_HMAC_MD5] != NULL) return (1); diff --git a/contrib/bind9/lib/bind/dst/md5.h b/contrib/bind9/lib/bind/dst/md5.h index c886d17bb00..6525662b67f 100644 --- a/contrib/bind9/lib/bind/dst/md5.h +++ b/contrib/bind9/lib/bind/dst/md5.h @@ -59,6 +59,8 @@ #ifndef HEADER_MD5_H #define HEADER_MD5_H +#ifndef HAVE_MD5 + #ifdef __cplusplus extern "C" { #endif @@ -99,3 +101,6 @@ unsigned char *MD5(); #endif #endif +#else +#include +#endif /* HAVE_MD5 */ diff --git a/contrib/bind9/lib/bind/dst/md5_dgst.c b/contrib/bind9/lib/bind/dst/md5_dgst.c index 48c327eac34..ba0a5a13db3 100644 --- a/contrib/bind9/lib/bind/dst/md5_dgst.c +++ b/contrib/bind9/lib/bind/dst/md5_dgst.c @@ -58,6 +58,7 @@ #ifdef USE_MD5 /* Added by ogud@tis.com 1998/1/26 */ #include +#ifndef HAVE_MD5 #include #include "md5_locl.h" #include @@ -367,4 +368,5 @@ unsigned long *l; } } #endif +#endif /* HAVE_MD5 */ #endif /* USE_MD5 */ diff --git a/contrib/bind9/lib/bind/dst/support.c b/contrib/bind9/lib/bind/dst/support.c index 7b86ea98d3d..8fe3cdb4780 100644 --- a/contrib/bind9/lib/bind/dst/support.c +++ b/contrib/bind9/lib/bind/dst/support.c @@ -1,4 +1,4 @@ -static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/support.c,v 1.2.2.1 2001/11/02 22:25:29 gson Exp $"; +static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/support.c,v 1.2.2.1.10.2 2005/10/11 00:48:14 marka Exp $"; /* @@ -103,7 +103,7 @@ dst_s_id_calc(const u_char *key, const int keysize) int size = keysize; if (!key || (keysize <= 0)) - return (-1); + return (0xffffU); for (ac = 0; size > 1; size -= 2, kp += 2) ac += ((*kp) << 8) + *(kp + 1); @@ -311,19 +311,15 @@ dst_s_fopen(const char *filename, const char *mode, int perm) { FILE *fp; char pathname[PATH_MAX]; - size_t plen = sizeof(pathname); + + if (strlen(filename) + strlen(dst_path) >= sizeof(pathname)) + return (NULL); if (*dst_path != '\0') { strcpy(pathname, dst_path); - plen -= strlen(pathname); - } - else - pathname[0] = '\0'; - - if (plen > strlen(filename)) - strncpy(&pathname[PATH_MAX - plen], filename, plen-1); - else - return (NULL); + strcat(pathname, filename); + } else + strcpy(pathname, filename); fp = fopen(pathname, mode); if (perm) diff --git a/contrib/bind9/lib/bind/include/isc/eventlib.h b/contrib/bind9/lib/bind/include/isc/eventlib.h index 6750e4d2160..033b3123d7c 100644 --- a/contrib/bind9/lib/bind/include/isc/eventlib.h +++ b/contrib/bind9/lib/bind/include/isc/eventlib.h @@ -18,7 +18,7 @@ /* eventlib.h - exported interfaces for eventlib * vix 09sep95 [initial] * - * $Id: eventlib.h,v 1.1.2.1.4.1 2004/03/09 08:33:31 marka Exp $ + * $Id: eventlib.h,v 1.1.2.1.4.2 2005/07/28 07:43:18 marka Exp $ */ #ifndef _EVENTLIB_H @@ -76,6 +76,8 @@ typedef struct { unsigned char mask[256/8]; } evByteMask; #define EV_WRITE 2 #define EV_EXCEPT 4 +#define EV_WASNONBLOCKING 8 /* Internal library use. */ + /* eventlib.c */ #define evCreate __evCreate #define evSetDebug __evSetDebug diff --git a/contrib/bind9/lib/bind/include/resolv.h b/contrib/bind9/lib/bind/include/resolv.h index f4f3fa47a48..87a95200bb9 100644 --- a/contrib/bind9/lib/bind/include/resolv.h +++ b/contrib/bind9/lib/bind/include/resolv.h @@ -50,7 +50,7 @@ /* * @(#)resolv.h 8.1 (Berkeley) 6/2/93 - * $Id: resolv.h,v 1.7.2.11.4.2 2004/06/25 00:41:05 marka Exp $ + * $Id: resolv.h,v 1.7.2.11.4.3 2005/08/25 04:44:13 marka Exp $ */ #ifndef _RESOLV_H_ @@ -291,6 +291,11 @@ extern struct __res_state *__res_state(void); __END_DECLS #define _res (*__res_state()) #else +#ifdef __linux +__BEGIN_DECLS +extern struct __res_state * __res_state(void); +__END_DECLS +#endif #ifndef __BIND_NOSTATIC extern struct __res_state _res; #endif 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 00000000000..27963a12077 --- /dev/null +++ b/contrib/bind9/lib/bind/include/resolv_mt.h @@ -0,0 +1,47 @@ +#ifndef _RESOLV_MT_H +#define _RESOLV_MT_H + +#include +#include +#include +#include + +/* 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/inet/inet_cidr_ntop.c b/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c index 184ad7c580c..192cf1e752e 100644 --- a/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c +++ b/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: inet_cidr_ntop.c,v 1.1.2.1.8.2 2004/03/17 00:29:46 marka Exp $"; +static const char rcsid[] = "$Id: inet_cidr_ntop.c,v 1.1.2.1.8.3 2005/11/03 23:08:40 marka Exp $"; #endif #include "port_before.h" @@ -178,7 +178,9 @@ inet_cidr_ntop_ipv6(const u_char *src, int bits, char *dst, size_t size) { for (i = 0; i < NS_IN6ADDRSZ; i++) words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3)); best.base = -1; + best.len = 0; cur.base = -1; + cur.len = 0; for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) { if (words[i] == 0) { if (cur.base == -1) diff --git a/contrib/bind9/lib/bind/inet/inet_ntop.c b/contrib/bind9/lib/bind/inet/inet_ntop.c index 6141407fe4a..cd502ab7586 100644 --- a/contrib/bind9/lib/bind/inet/inet_ntop.c +++ b/contrib/bind9/lib/bind/inet/inet_ntop.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: inet_ntop.c,v 1.1.2.1.8.1 2004/03/09 08:33:33 marka Exp $"; +static const char rcsid[] = "$Id: inet_ntop.c,v 1.1.2.1.8.2 2005/11/03 23:08:40 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -137,7 +137,9 @@ inet_ntop6(src, dst, size) for (i = 0; i < NS_IN6ADDRSZ; i++) words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3)); best.base = -1; + best.len = 0; cur.base = -1; + cur.len = 0; for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) { if (words[i] == 0) { if (cur.base == -1) diff --git a/contrib/bind9/lib/bind/inet/inet_pton.c b/contrib/bind9/lib/bind/inet/inet_pton.c index c7813f83cd0..f18a7b64fde 100644 --- a/contrib/bind9/lib/bind/inet/inet_pton.c +++ b/contrib/bind9/lib/bind/inet/inet_pton.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: inet_pton.c,v 1.2.206.1 2004/03/09 08:33:33 marka Exp $"; +static const char rcsid[] = "$Id: inet_pton.c,v 1.2.206.2 2005/07/28 07:43:18 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -141,7 +141,7 @@ inet_pton6(src, dst) xdigits_u[] = "0123456789ABCDEF"; u_char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp; const char *xdigits, *curtok; - int ch, saw_xdigit; + int ch, seen_xdigits; u_int val; memset((tp = tmp), '\0', NS_IN6ADDRSZ); @@ -152,7 +152,7 @@ inet_pton6(src, dst) if (*++src != ':') return (0); curtok = src; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; while ((ch = *src++) != '\0') { const char *pch; @@ -162,14 +162,13 @@ inet_pton6(src, dst) if (pch != NULL) { val <<= 4; val |= (pch - xdigits); - if (val > 0xffff) + if (++seen_xdigits > 4) return (0); - saw_xdigit = 1; continue; } if (ch == ':') { curtok = src; - if (!saw_xdigit) { + if (!seen_xdigits) { if (colonp) return (0); colonp = tp; @@ -181,19 +180,19 @@ inet_pton6(src, dst) return (0); *tp++ = (u_char) (val >> 8) & 0xff; *tp++ = (u_char) val & 0xff; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; continue; } if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) && inet_pton4(curtok, tp) > 0) { tp += NS_INADDRSZ; - saw_xdigit = 0; + seen_xdigits = 0; break; /* '\0' was seen by inet_pton4(). */ } return (0); } - if (saw_xdigit) { + if (seen_xdigits) { if (tp + NS_INT16SZ > endp) return (0); *tp++ = (u_char) (val >> 8) & 0xff; diff --git a/contrib/bind9/lib/bind/inet/nsap_addr.c b/contrib/bind9/lib/bind/inet/nsap_addr.c index 0b9108a92f8..a4b98e7c4a0 100644 --- a/contrib/bind9/lib/bind/inet/nsap_addr.c +++ b/contrib/bind9/lib/bind/inet/nsap_addr.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.1 2004/03/09 08:33:33 marka Exp $"; +static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.2 2005/07/28 07:43:18 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -31,6 +31,7 @@ static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.1 2004/03/09 08:33:33 ma #include #include +#include #include "port_after.h" @@ -79,7 +80,7 @@ char * inet_nsap_ntoa(int binlen, const u_char *binary, char *ascii) { int nib; int i; - static char tmpbuf[2+255*3]; + char *tmpbuf = inet_nsap_ntoa_tmpbuf; char *start; if (ascii) diff --git a/contrib/bind9/lib/bind/irs/dns_ho.c b/contrib/bind9/lib/bind/irs/dns_ho.c index 69b4b4f2c3b..e8da61a0c1a 100644 --- a/contrib/bind9/lib/bind/irs/dns_ho.c +++ b/contrib/bind9/lib/bind/irs/dns_ho.c @@ -52,7 +52,7 @@ /* BIND Id: gethnamaddr.c,v 8.15 1996/05/22 04:56:30 vixie Exp $ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: dns_ho.c,v 1.5.2.7.4.5 2004/08/24 00:32:15 marka Exp $"; +static const char rcsid[] = "$Id: dns_ho.c,v 1.5.2.7.4.6 2005/10/11 00:48:14 marka Exp $"; #endif /* LIBC_SCCS and not lint */ /* Imports. */ @@ -688,7 +688,7 @@ gethostans(struct irs_ho *this, { struct pvt *pvt = (struct pvt *)this->private; int type, class, ancount, qdcount, n, haveanswer, had_error; - int error = NETDB_SUCCESS, arcount; + int error = NETDB_SUCCESS; int (*name_ok)(const char *); const HEADER *hp; const u_char *eom; @@ -735,7 +735,6 @@ gethostans(struct irs_ho *this, hp = (const HEADER *)ansbuf; ancount = ntohs(hp->ancount); qdcount = ntohs(hp->qdcount); - arcount = ntohs(hp->arcount); bp = pvt->hostbuf; ep = pvt->hostbuf + sizeof(pvt->hostbuf); cp = ansbuf + HFIXEDSZ; diff --git a/contrib/bind9/lib/bind/irs/getaddrinfo.c b/contrib/bind9/lib/bind/irs/getaddrinfo.c index e08cf78424b..4f741a8e7de 100644 --- a/contrib/bind9/lib/bind/irs/getaddrinfo.c +++ b/contrib/bind9/lib/bind/irs/getaddrinfo.c @@ -244,6 +244,7 @@ do { \ goto free; \ } while (/*CONSTCOND*/0) +#ifndef SOLARIS2 #define ERR(err) \ do { \ /* external reference: error, and label bad */ \ @@ -251,6 +252,16 @@ do { \ goto bad; \ /*NOTREACHED*/ \ } while (/*CONSTCOND*/0) +#else +#define ERR(err) \ +do { \ + /* external reference: error, and label bad */ \ + error = (err); \ + if (error == error) \ + goto bad; \ +} while (/*CONSTCOND*/0) +#endif + #define MATCH_FAMILY(x, y, w) \ ((x) == (y) || (/*CONSTCOND*/(w) && ((x) == PF_UNSPEC || (y) == PF_UNSPEC))) @@ -321,6 +332,15 @@ getaddrinfo(hostname, servname, hints, res) pai->ai_family = PF_UNSPEC; pai->ai_socktype = ANY; pai->ai_protocol = ANY; +#ifdef __sparcv9 + /* + * clear _ai_pad to preserve binary + * compatibility with previously compiled 64-bit + * applications in a pre-SUSv3 environment by + * guaranteeing the upper 32-bits are empty. + */ + pai->_ai_pad = 0; +#endif /* __sparcv9 */ pai->ai_addrlen = 0; pai->ai_canonname = NULL; pai->ai_addr = NULL; @@ -345,6 +365,13 @@ getaddrinfo(hostname, servname, hints, res) } memcpy(pai, hints, sizeof(*pai)); +#ifdef __sparcv9 + /* + * We need to clear _ai_pad to preserve binary + * compatibility. See prior comment. + */ + pai->_ai_pad = 0; +#endif /* * if both socktype/protocol are specified, check if they * are meaningful combination. diff --git a/contrib/bind9/lib/bind/irs/gethostent_r.c b/contrib/bind9/lib/bind/irs/gethostent_r.c index 28f1a7f7cdf..8a7cff06fe0 100644 --- a/contrib/bind9/lib/bind/irs/gethostent_r.c +++ b/contrib/bind9/lib/bind/irs/gethostent_r.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: gethostent_r.c,v 1.4.206.3 2004/09/01 02:03:07 marka Exp $"; +static const char rcsid[] = "$Id: gethostent_r.c,v 1.4.206.4 2005/09/03 12:47:38 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -44,7 +44,9 @@ gethostbyname_r(const char *name, struct hostent *hptr, HOST_R_ARGS) { int n = 0; #endif +#ifdef HOST_R_ERRNO HOST_R_ERRNO; +#endif #ifdef HOST_R_SETANSWER if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) @@ -69,7 +71,9 @@ gethostbyaddr_r(const char *addr, int len, int type, int n = 0; #endif +#ifdef HOST_R_ERRNO HOST_R_ERRNO; +#endif #ifdef HOST_R_SETANSWER if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) @@ -99,7 +103,9 @@ gethostent_r(struct hostent *hptr, HOST_R_ARGS) { int n = 0; #endif +#ifdef HOST_R_ERRNO HOST_R_ERRNO; +#endif #ifdef HOST_R_SETANSWER if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0) @@ -123,6 +129,9 @@ sethostent_r(int stay_open, HOST_R_ENT_ARGS) sethostent_r(int stay_open) #endif { +#ifdef HOST_R_ENT_ARGS + UNUSED(hdptr); +#endif sethostent(stay_open); #ifdef HOST_R_SET_RESULT return (HOST_R_SET_RESULT); @@ -136,6 +145,9 @@ endhostent_r(HOST_R_ENT_ARGS) endhostent_r(void) #endif { +#ifdef HOST_R_ENT_ARGS + UNUSED(hdptr); +#endif endhostent(); HOST_R_END_RESULT(HOST_R_OK); } diff --git a/contrib/bind9/lib/bind/irs/getnetent_r.c b/contrib/bind9/lib/bind/irs/getnetent_r.c index 0b540b00b3d..1f8290d1714 100644 --- a/contrib/bind9/lib/bind/irs/getnetent_r.c +++ b/contrib/bind9/lib/bind/irs/getnetent_r.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: getnetent_r.c,v 1.3.206.1 2004/03/09 08:33:36 marka Exp $"; +static const char rcsid[] = "$Id: getnetent_r.c,v 1.3.206.2 2005/09/03 12:47:38 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -118,6 +118,9 @@ setnetent_r(int stay_open, NET_R_ENT_ARGS) setnetent_r(int stay_open) #endif { +#ifdef NET_R_ENT_ARGS + UNUSED(ndptr); +#endif setnetent(stay_open); #ifdef NET_R_SET_RESULT return (NET_R_SET_RESULT); @@ -131,6 +134,9 @@ endnetent_r(NET_R_ENT_ARGS) endnetent_r() #endif { +#ifdef NET_R_ENT_ARGS + UNUSED(ndptr); +#endif endnetent(); NET_R_END_RESULT(NET_R_OK); } diff --git a/contrib/bind9/lib/bind/irs/getnetgrent_r.c b/contrib/bind9/lib/bind/irs/getnetgrent_r.c index bb78b5622f9..b5d9bb167d1 100644 --- a/contrib/bind9/lib/bind/irs/getnetgrent_r.c +++ b/contrib/bind9/lib/bind/irs/getnetgrent_r.c @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: getnetgrent_r.c,v 1.5.2.1.4.3 2004/11/30 01:15:43 marka Exp $"; +static const char rcsid[] = "$Id: getnetgrent_r.c,v 1.5.2.1.4.4 2005/09/03 12:47:38 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -77,8 +77,14 @@ setnetgrent_r(const char *netgroup) #endif { char *tmp; +#if defined(NGR_R_ENT_ARGS) && !defined(NGR_R_PRIVATE) + UNUSED(buf); + UNUSED(buflen); +#endif + DE_CONST(netgroup, tmp); setnetgrent(tmp); + #ifdef NGR_R_PRIVATE *buf = NULL; #endif @@ -94,6 +100,11 @@ endnetgrent_r(NGR_R_ENT_ARGS) endnetgrent_r(void) #endif { +#if defined(NGR_R_ENT_ARGS) && !defined(NGR_R_PRIVATE) + UNUSED(buf); + UNUSED(buflen); +#endif + endnetgrent(); #ifdef NGR_R_PRIVATE if (*buf != NULL) diff --git a/contrib/bind9/lib/bind/irs/hesiod.c b/contrib/bind9/lib/bind/irs/hesiod.c index 9b0efeb81db..618c592249b 100644 --- a/contrib/bind9/lib/bind/irs/hesiod.c +++ b/contrib/bind9/lib/bind/irs/hesiod.c @@ -1,5 +1,5 @@ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: hesiod.c,v 1.1.2.1.4.3 2004/05/17 07:48:56 marka Exp $"; +static const char rcsid[] = "$Id: hesiod.c,v 1.1.2.1.4.4 2005/07/28 07:43:19 marka Exp $"; #endif /* @@ -83,9 +83,7 @@ hesiod_init(void **context) { return (-1); } - ctx->LHS = NULL; - ctx->RHS = NULL; - ctx->res = NULL; + memset(ctx, 0, sizeof (*ctx)); if (parse_config_file(ctx, _PATH_HESIOD_CONF) < 0) { #ifdef DEF_RHS diff --git a/contrib/bind9/lib/bind/isc/ev_connects.c b/contrib/bind9/lib/bind/isc/ev_connects.c index 043e5f497ca..4b0dd2222a0 100644 --- a/contrib/bind9/lib/bind/isc/ev_connects.c +++ b/contrib/bind9/lib/bind/isc/ev_connects.c @@ -20,7 +20,7 @@ */ #if !defined(LINT) && !defined(CODECENTER) -static const char rcsid[] = "$Id: ev_connects.c,v 1.4.206.1 2004/03/09 08:33:40 marka Exp $"; +static const char rcsid[] = "$Id: ev_connects.c,v 1.4.206.2 2005/07/08 04:52:54 marka Exp $"; #endif /* Import. */ @@ -168,10 +168,10 @@ evCancelConn(evContext opaqueCtx, evConnID id) { return (-1); } else { #ifdef USE_FIONBIO_IOCTL - int on = 1; - OK(ioctl(this->fd, FIONBIO, (char *)&on)); + int off = 0; + OK(ioctl(this->fd, FIONBIO, (char *)&off)); #else - OK(fcntl(this->fd, F_SETFL, mode | PORT_NONBLOCK)); + OK(fcntl(this->fd, F_SETFL, mode & ~PORT_NONBLOCK)); #endif } } diff --git a/contrib/bind9/lib/bind/isc/ev_files.c b/contrib/bind9/lib/bind/isc/ev_files.c index 4d5eb55ad8d..1f95ed04c99 100644 --- a/contrib/bind9/lib/bind/isc/ev_files.c +++ b/contrib/bind9/lib/bind/isc/ev_files.c @@ -20,7 +20,7 @@ */ #if !defined(LINT) && !defined(CODECENTER) -static const char rcsid[] = "$Id: ev_files.c,v 1.3.2.1.4.1 2004/03/09 08:33:42 marka Exp $"; +static const char rcsid[] = "$Id: ev_files.c,v 1.3.2.1.4.3 2005/07/28 07:43:19 marka Exp $"; #endif #include "port_before.h" @@ -58,8 +58,10 @@ evSelectFD(evContext opaqueCtx, ctx, fd, eventmask, func, uap); if (eventmask == 0 || (eventmask & ~EV_MASK_ALL) != 0) EV_ERR(EINVAL); +#ifndef USE_POLL if (fd > ctx->highestFD) EV_ERR(EINVAL); +#endif OK(mode = fcntl(fd, F_GETFL, NULL)); /* side effect: validate fd. */ /* @@ -68,6 +70,11 @@ evSelectFD(evContext opaqueCtx, * of our deselect()'s have to leave it in O_NONBLOCK. If not, then * all but our last deselect() has to leave it in O_NONBLOCK. */ +#ifdef USE_POLL + /* Make sure both ctx->pollfds[] and ctx->fdTable[] are large enough */ + if (fd >= ctx->maxnfds && evPollfdRealloc(ctx, 1, fd) != 0) + EV_ERR(ENOMEM); +#endif /* USE_POLL */ id = FindFD(ctx, fd, EV_MASK_ALL); if (id == NULL) { if (mode & PORT_NONBLOCK) @@ -143,13 +150,6 @@ evSelectFD(evContext opaqueCtx, if (opaqueID) opaqueID->opaque = id; - evPrintf(ctx, 5, - "evSelectFD(fd %d, mask 0x%x): new masks: 0x%lx 0x%lx 0x%lx\n", - fd, eventmask, - (u_long)ctx->rdNext.fds_bits[0], - (u_long)ctx->wrNext.fds_bits[0], - (u_long)ctx->exNext.fds_bits[0]); - return (0); } @@ -204,7 +204,7 @@ evDeselectFD(evContext opaqueCtx, evFileID opaqueID) { * and (b) the caller didn't ask us anything about O_NONBLOCK. */ #ifdef USE_FIONBIO_IOCTL - int off = 1; + int off = 0; (void) ioctl(del->fd, FIONBIO, (char *)&off); #else (void) fcntl(del->fd, F_SETFL, mode & ~PORT_NONBLOCK); @@ -259,13 +259,6 @@ evDeselectFD(evContext opaqueCtx, evFileID opaqueID) { if (del == ctx->fdNext) ctx->fdNext = del->next; - evPrintf(ctx, 5, - "evDeselectFD(fd %d, mask 0x%x): new masks: 0x%lx 0x%lx 0x%lx\n", - del->fd, eventmask, - (u_long)ctx->rdNext.fds_bits[0], - (u_long)ctx->wrNext.fds_bits[0], - (u_long)ctx->exNext.fds_bits[0]); - /* Couldn't free it before now since we were using fields out of it. */ FREE(del); diff --git a/contrib/bind9/lib/bind/isc/eventlib.c b/contrib/bind9/lib/bind/isc/eventlib.c index 06d791e0c11..77b14144b97 100644 --- a/contrib/bind9/lib/bind/isc/eventlib.c +++ b/contrib/bind9/lib/bind/isc/eventlib.c @@ -20,7 +20,7 @@ */ #if !defined(LINT) && !defined(CODECENTER) -static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 marka Exp $"; +static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.5 2005/07/28 07:43:20 marka Exp $"; #endif #include "port_before.h" @@ -29,6 +29,9 @@ static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 m #include #include #include +#ifdef SOLARIS2 +#include +#endif /* SOLARIS2 */ #include #include @@ -44,9 +47,13 @@ static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 m int __evOptMonoTime; +#ifdef USE_POLL +#define pselect Pselect +#endif /* USE_POLL */ + /* Forward. */ -#ifdef NEED_PSELECT +#if defined(NEED_PSELECT) || defined(USE_POLL) static int pselect(int, void *, void *, void *, struct timespec *, const sigset_t *); @@ -78,6 +85,18 @@ evCreate(evContext *opaqueCtx) { INIT_LIST(ctx->accepts); /* Files. */ +#ifdef USE_POLL + ctx->pollfds = NULL; + ctx->maxnfds = 0; + ctx->firstfd = 0; + emulMaskInit(ctx, rdLast, EV_READ, 1); + emulMaskInit(ctx, rdNext, EV_READ, 0); + emulMaskInit(ctx, wrLast, EV_WRITE, 1); + emulMaskInit(ctx, wrNext, EV_WRITE, 0); + emulMaskInit(ctx, exLast, EV_EXCEPT, 1); + emulMaskInit(ctx, exNext, EV_EXCEPT, 0); + emulMaskInit(ctx, nonblockBefore, EV_WASNONBLOCKING, 0); +#endif /* USE_POLL */ ctx->files = NULL; FD_ZERO(&ctx->rdNext); FD_ZERO(&ctx->wrNext); @@ -86,11 +105,16 @@ evCreate(evContext *opaqueCtx) { ctx->fdMax = -1; ctx->fdNext = NULL; ctx->fdCount = 0; /* Invalidate {rd,wr,ex}Last. */ +#ifndef USE_POLL ctx->highestFD = FD_SETSIZE - 1; + memset(ctx->fdTable, 0, sizeof ctx->fdTable); +#else + ctx->highestFD = INT_MAX / sizeof(struct pollfd); + ctx->fdTable = NULL; +#endif #ifdef EVENTLIB_TIME_CHECKS ctx->lastFdCount = 0; #endif - memset(ctx->fdTable, 0, sizeof ctx->fdTable); /* Streams. */ ctx->streams = NULL; @@ -284,34 +308,37 @@ evGetNext(evContext opaqueCtx, evEvent *opaqueEv, int options) { } #endif do { +#ifndef USE_POLL /* XXX need to copy only the bits we are using. */ ctx->rdLast = ctx->rdNext; ctx->wrLast = ctx->wrNext; ctx->exLast = ctx->exNext; - +#else + /* + * The pollfd structure uses separate fields for + * the input and output events (corresponding to + * the ??Next and ??Last fd sets), so there's no + * need to copy one to the other. + */ +#endif /* USE_POLL */ if (m == Timer) { INSIST(tp == &t); t = evSubTime(nextTime, ctx->lastEventTime); } - evPrintf(ctx, 4, - "pselect(%d, 0x%lx, 0x%lx, 0x%lx, %ld.%09ld)\n", - ctx->fdMax+1, - (u_long)ctx->rdLast.fds_bits[0], - (u_long)ctx->wrLast.fds_bits[0], - (u_long)ctx->exLast.fds_bits[0], - tp ? (long)tp->tv_sec : -1L, - tp ? tp->tv_nsec : -1); - /* XXX should predict system's earliness and adjust. */ x = pselect(ctx->fdMax+1, &ctx->rdLast, &ctx->wrLast, &ctx->exLast, tp, NULL); pselect_errno = errno; +#ifndef USE_POLL evPrintf(ctx, 4, "select() returns %d (err: %s)\n", x, (x == -1) ? strerror(errno) : "none"); - +#else + evPrintf(ctx, 4, "poll() returns %d (err: %s)\n", + x, (x == -1) ? strerror(errno) : "none"); +#endif /* USE_POLL */ /* Anything but a poll can change the time. */ if (m != JustPoll) ctx->lastEventTime = evNowTime(); @@ -704,7 +731,7 @@ evGetOption(evContext *opaqueCtx, const char *option, int *value) { return (-1); } -#ifdef NEED_PSELECT +#if defined(NEED_PSELECT) || defined(USE_POLL) /* XXX needs to move to the porting library. */ static int pselect(int nfds, void *rfds, void *wfds, void *efds, @@ -714,15 +741,69 @@ pselect(int nfds, void *rfds, void *wfds, void *efds, struct timeval tv, *tvp; sigset_t sigs; int n; +#ifdef USE_POLL + int polltimeout = INFTIM; + evContext_p *ctx; + struct pollfd *fds; + nfds_t pnfds; + + UNUSED(nfds); +#endif /* USE_POLL */ if (tsp) { tvp = &tv; tv = evTimeVal(*tsp); +#ifdef USE_POLL + polltimeout = 1000 * tv.tv_sec + tv.tv_usec / 1000; +#endif /* USE_POLL */ } else tvp = NULL; if (sigmask) sigprocmask(SIG_SETMASK, sigmask, &sigs); +#ifndef USE_POLL n = select(nfds, rfds, wfds, efds, tvp); +#else + /* + * rfds, wfds, and efds should all be from the same evContext_p, + * so any of them will do. If they're all NULL, the caller is + * presumably calling us to block. + */ + if (rfds != NULL) + ctx = ((__evEmulMask *)rfds)->ctx; + else if (wfds != NULL) + ctx = ((__evEmulMask *)wfds)->ctx; + else if (efds != NULL) + ctx = ((__evEmulMask *)efds)->ctx; + else + ctx = NULL; + if (ctx != NULL && ctx->fdMax != -1) { + fds = &(ctx->pollfds[ctx->firstfd]); + pnfds = ctx->fdMax - ctx->firstfd + 1; + } else { + fds = NULL; + pnfds = 0; + } + n = poll(fds, pnfds, polltimeout); + /* + * pselect() should return the total number of events on the file + * desriptors, not just the count of fd:s with activity. Hence, + * traverse the pollfds array and count the events. + */ + if (n > 0) { + int i, e; + for (e = 0, i = ctx->firstfd; i <= ctx->fdMax; i++) { + if (ctx->pollfds[i].fd < 0) + continue; + if (FD_ISSET(i, &ctx->rdLast)) + e++; + if (FD_ISSET(i, &ctx->wrLast)) + e++; + if (FD_ISSET(i, &ctx->exLast)) + e++; + } + n = e; + } +#endif /* USE_POLL */ if (sigmask) sigprocmask(SIG_SETMASK, &sigs, NULL); if (tsp) @@ -730,3 +811,127 @@ pselect(int nfds, void *rfds, void *wfds, void *efds, return (n); } #endif + +#ifdef USE_POLL +int +evPollfdRealloc(evContext_p *ctx, int pollfd_chunk_size, int fd) { + + int i, maxnfds; + void *pollfds, *fdTable; + + if (fd < ctx->maxnfds) + return (0); + + /* Don't allow ridiculously small values for pollfd_chunk_size */ + if (pollfd_chunk_size < 20) + pollfd_chunk_size = 20; + + maxnfds = (1 + (fd/pollfd_chunk_size)) * pollfd_chunk_size; + + pollfds = realloc(ctx->pollfds, maxnfds * sizeof(*ctx->pollfds)); + if (pollfds != NULL) + ctx->pollfds = pollfds; + fdTable = realloc(ctx->fdTable, maxnfds * sizeof(*ctx->fdTable)); + if (fdTable != NULL) + ctx->fdTable = fdTable; + + if (pollfds == NULL || fdTable == NULL) { + evPrintf(ctx, 2, "pollfd() realloc (%ld) failed\n", + (long)maxnfds*sizeof(struct pollfd)); + return (-1); + } + + for (i = ctx->maxnfds; i < maxnfds; i++) { + ctx->pollfds[i].fd = -1; + ctx->pollfds[i].events = 0; + ctx->fdTable[i] = 0; + } + + ctx->maxnfds = maxnfds; + + return (0); +} + +/* Find the appropriate 'events' or 'revents' field in the pollfds array */ +short * +__fd_eventfield(int fd, __evEmulMask *maskp) { + + evContext_p *ctx = (evContext_p *)maskp->ctx; + + if (!maskp->result || maskp->type == EV_WASNONBLOCKING) + return (&(ctx->pollfds[fd].events)); + else + return (&(ctx->pollfds[fd].revents)); +} + +/* Translate to poll(2) event */ +short +__poll_event(__evEmulMask *maskp) { + + switch ((maskp)->type) { + case EV_READ: + return (POLLRDNORM); + case EV_WRITE: + return (POLLWRNORM); + case EV_EXCEPT: + return (POLLRDBAND | POLLPRI | POLLWRBAND); + case EV_WASNONBLOCKING: + return (POLLHUP); + default: + return (0); + } +} + +/* + * Clear the events corresponding to the specified mask. If this leaves + * the events mask empty (apart from the POLLHUP bit), set the fd field + * to -1 so that poll(2) will ignore this fd. + */ +void +__fd_clr(int fd, __evEmulMask *maskp) { + + evContext_p *ctx = maskp->ctx; + + *__fd_eventfield(fd, maskp) &= ~__poll_event(maskp); + if ((ctx->pollfds[fd].events & ~POLLHUP) == 0) { + ctx->pollfds[fd].fd = -1; + if (fd == ctx->fdMax) + while (ctx->fdMax > ctx->firstfd && + ctx->pollfds[ctx->fdMax].fd < 0) + ctx->fdMax--; + if (fd == ctx->firstfd) + while (ctx->firstfd <= ctx->fdMax && + ctx->pollfds[ctx->firstfd].fd < 0) + ctx->firstfd++; + /* + * Do we have a empty set of descriptors? + */ + if (ctx->firstfd > ctx->fdMax) { + ctx->fdMax = -1; + ctx->firstfd = 0; + } + } +} + +/* + * Set the events bit(s) corresponding to the specified mask. If the events + * field has any other bits than POLLHUP set, also set the fd field so that + * poll(2) will watch this fd. + */ +void +__fd_set(int fd, __evEmulMask *maskp) { + + evContext_p *ctx = maskp->ctx; + + *__fd_eventfield(fd, maskp) |= __poll_event(maskp); + if ((ctx->pollfds[fd].events & ~POLLHUP) != 0) { + ctx->pollfds[fd].fd = fd; + if (fd < ctx->firstfd || ctx->fdMax == -1) + ctx->firstfd = fd; + if (fd > ctx->fdMax) + ctx->fdMax = fd; + } +} +#endif /* USE_POLL */ + +/*! \file */ diff --git a/contrib/bind9/lib/bind/isc/eventlib_p.h b/contrib/bind9/lib/bind/isc/eventlib_p.h index 8c58c7fd6ef..b95741d7aff 100644 --- a/contrib/bind9/lib/bind/isc/eventlib_p.h +++ b/contrib/bind9/lib/bind/isc/eventlib_p.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") + * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC") * Copyright (c) 1995-1999 by Internet Software Consortium * * Permission to use, copy, modify, and distribute this software for any @@ -18,7 +18,7 @@ /* eventlib_p.h - private interfaces for eventlib * vix 09sep95 [initial] * - * $Id: eventlib_p.h,v 1.3.2.1.4.2 2004/12/05 22:38:43 marka Exp $ + * $Id: eventlib_p.h,v 1.3.2.1.4.3 2005/07/28 07:43:20 marka Exp $ */ #ifndef _EVENTLIB_P_H @@ -63,6 +63,13 @@ #define FILL(p) #endif +#ifdef USE_POLL +#ifdef HAVE_STROPTS_H +#include +#endif +#include +#endif /* USE_POLL */ + typedef struct evConn { evConnFunc func; void * uap; @@ -166,6 +173,40 @@ typedef struct evEvent_p { } u; } evEvent_p; +#ifdef USE_POLL +typedef struct { + void *ctx; /* pointer to the evContext_p */ + uint32_t type; /* READ, WRITE, EXCEPT, nonblk */ + uint32_t result; /* 1 => revents, 0 => events */ +} __evEmulMask; + +#define emulMaskInit(ctx, field, ev, lastnext) \ + ctx->field.ctx = ctx; \ + ctx->field.type = ev; \ + ctx->field.result = lastnext; + +extern short *__fd_eventfield(int fd, __evEmulMask *maskp); +extern short __poll_event(__evEmulMask *maskp); +extern void __fd_clr(int fd, __evEmulMask *maskp); +extern void __fd_set(int fd, __evEmulMask *maskp); + +#undef FD_ZERO +#define FD_ZERO(maskp) + +#undef FD_SET +#define FD_SET(fd, maskp) \ + __fd_set(fd, maskp) + +#undef FD_CLR +#define FD_CLR(fd, maskp) \ + __fd_clr(fd, maskp) + +#undef FD_ISSET +#define FD_ISSET(fd, maskp) \ + ((*__fd_eventfield(fd, maskp) & __poll_event(maskp)) != 0) + +#endif /* USE_POLL */ + typedef struct { /* Global. */ const evEvent_p *cur; @@ -177,12 +218,26 @@ typedef struct { LIST(evAccept) accepts; /* Files. */ evFile *files, *fdNext; +#ifndef USE_POLL fd_set rdLast, rdNext; fd_set wrLast, wrNext; fd_set exLast, exNext; fd_set nonblockBefore; int fdMax, fdCount, highestFD; evFile *fdTable[FD_SETSIZE]; +#else + struct pollfd *pollfds; /* Allocated as needed */ + evFile **fdTable; /* Ditto */ + int maxnfds; /* # elements in above */ + int firstfd; /* First active fd */ + int fdMax; /* Last active fd */ + int fdCount; /* # fd:s with I/O */ + int highestFD; /* max fd allowed by OS */ + __evEmulMask rdLast, rdNext; + __evEmulMask wrLast, wrNext; + __evEmulMask exLast, exNext; + __evEmulMask nonblockBefore; +#endif /* USE_POLL */ #ifdef EVENTLIB_TIME_CHECKS struct timespec lastSelectTime; int lastFdCount; @@ -203,6 +258,10 @@ typedef struct { void evPrintf(const evContext_p *ctx, int level, const char *fmt, ...) ISC_FORMAT_PRINTF(3, 4); +#ifdef USE_POLL +extern int evPollfdRealloc(evContext_p *ctx, int pollfd_chunk_size, int fd); +#endif /* USE_POLL */ + /* ev_timers.c */ #define evCreateTimers __evCreateTimers heap_context evCreateTimers(const evContext_p *); diff --git a/contrib/bind9/lib/bind/isc/memcluster.c b/contrib/bind9/lib/bind/isc/memcluster.c index 0632ec7d701..c5b7202817c 100644 --- a/contrib/bind9/lib/bind/isc/memcluster.c +++ b/contrib/bind9/lib/bind/isc/memcluster.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") + * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC") * Copyright (c) 1997,1999 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -24,7 +24,7 @@ #if !defined(LINT) && !defined(CODECENTER) -static const char rcsid[] = "$Id: memcluster.c,v 1.3.206.4 2004/09/16 00:57:34 marka Exp $"; +static const char rcsid[] = "$Id: memcluster.c,v 1.3.206.7 2005/10/11 00:48:15 marka Exp $"; #endif /* not lint */ #include "port_before.h" @@ -90,12 +90,28 @@ struct stats { u_long freefrags; }; +#ifdef DO_PTHREADS +#include +static pthread_mutex_t memlock = PTHREAD_MUTEX_INITIALIZER; +#define MEMLOCK (void)pthread_mutex_lock(&memlock) +#define MEMUNLOCK (void)pthread_mutex_unlock(&memlock) +#else +/* + * Catch bad lock usage in non threaded build. + */ +static unsigned int memlock = 0; +#define MEMLOCK do { INSIST(memlock == 0); memlock = 1; } while (0) +#define MEMUNLOCK do { INSIST(memlock == 1); memlock = 0; } while (0) +#endif /* DO_PTHEADS */ + /* Private data. */ static size_t max_size; static size_t mem_target; +#ifndef MEMCLUSTER_BIG_MALLOC static size_t mem_target_half; static size_t mem_target_fudge; +#endif static memcluster_element ** freelists; #ifdef MEMCLUSTER_RECORD static memcluster_element ** activelists; @@ -132,8 +148,10 @@ meminit(size_t init_max_size, size_t target_size) { mem_target = DEF_MEM_TARGET; else mem_target = target_size; +#ifndef MEMCLUSTER_BIG_MALLOC mem_target_half = mem_target / 2; mem_target_fudge = mem_target + mem_target / 4; +#endif freelists = malloc(max_size * sizeof (memcluster_element *)); stats = malloc((max_size+1) * sizeof (struct stats)); if (freelists == NULL || stats == NULL) { @@ -173,14 +191,20 @@ __memget_record(size_t size, const char *file, int line) { #endif void *ret; + MEMLOCK; + #if !defined(MEMCLUSTER_RECORD) UNUSED(file); UNUSED(line); #endif - if (freelists == NULL) - if (meminit(0, 0) == -1) + if (freelists == NULL) { + if (meminit(0, 0) == -1) { + MEMUNLOCK; return (NULL); + } + } if (size == 0U) { + MEMUNLOCK; errno = EINVAL; return (NULL); } @@ -191,6 +215,7 @@ __memget_record(size_t size, const char *file, int line) { #if defined(DEBUGGING_MEMCLUSTER) e = malloc(new_size); if (e == NULL) { + MEMUNLOCK; errno = ENOMEM; return (NULL); } @@ -202,11 +227,13 @@ __memget_record(size_t size, const char *file, int line) { e->next = activelists[max_size]; activelists[max_size] = e; #endif + MEMUNLOCK; e->fencepost = FRONT_FENCEPOST; p = (char *)e + sizeof *e + size; memcpy(p, &fp, sizeof fp); return ((char *)e + sizeof *e); #else + MEMUNLOCK; return (malloc(size)); #endif } @@ -226,6 +253,7 @@ __memget_record(size_t size, const char *file, int line) { if (basic_blocks == NULL) { new = malloc(NUM_BASIC_BLOCKS * mem_target); if (new == NULL) { + MEMUNLOCK; errno = ENOMEM; return (NULL); } @@ -253,6 +281,7 @@ __memget_record(size_t size, const char *file, int line) { total_size = mem_target; new = malloc(total_size); if (new == NULL) { + MEMUNLOCK; errno = ENOMEM; return (NULL); } @@ -318,6 +347,7 @@ __memget_record(size_t size, const char *file, int line) { stats[size].gets++; stats[size].totalgets++; stats[new_size].freefrags--; + MEMUNLOCK; #if defined(DEBUGGING_MEMCLUSTER) return ((char *)e + sizeof *e); #else @@ -347,6 +377,8 @@ __memput_record(void *mem, size_t size, const char *file, int line) { char *p; #endif + MEMLOCK; + #if !defined (MEMCLUSTER_RECORD) UNUSED(file); UNUSED(line); @@ -355,6 +387,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) { REQUIRE(freelists != NULL); if (size == 0U) { + MEMUNLOCK; errno = EINVAL; return; } @@ -398,6 +431,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) { INSIST(stats[max_size].gets != 0U); stats[max_size].gets--; + MEMUNLOCK; return; } @@ -436,6 +470,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) { INSIST(stats[size].gets != 0U); stats[size].gets--; stats[new_size].freefrags++; + MEMUNLOCK; } void * @@ -464,8 +499,12 @@ memstats(FILE *out) { memcluster_element *e; #endif - if (freelists == NULL) + MEMLOCK; + + if (freelists == NULL) { + MEMUNLOCK; return; + } for (i = 1; i <= max_size; i++) { const struct stats *s = &stats[i]; @@ -492,6 +531,7 @@ memstats(FILE *out) { } } #endif + MEMUNLOCK; } int diff --git a/contrib/bind9/lib/bind/nameser/ns_parse.c b/contrib/bind9/lib/bind/nameser/ns_parse.c index 34ebd3de848..19a6f51b2db 100644 --- a/contrib/bind9/lib/bind/nameser/ns_parse.c +++ b/contrib/bind9/lib/bind/nameser/ns_parse.c @@ -16,7 +16,7 @@ */ #ifndef lint -static const char rcsid[] = "$Id: ns_parse.c,v 1.3.2.1.4.1 2004/03/09 08:33:44 marka Exp $"; +static const char rcsid[] = "$Id: ns_parse.c,v 1.3.2.1.4.3 2005/10/11 00:48:16 marka Exp $"; #endif /* Import. */ @@ -40,7 +40,12 @@ static void setsection(ns_msg *msg, ns_sect sect); /* Macros. */ +#ifndef SOLARIS2 #define RETERR(err) do { errno = (err); return (-1); } while (0) +#else +#define RETERR(err) \ + do { errno = (err); if (errno == errno) return (-1); } while (0) +#endif /* Public. */ @@ -135,7 +140,8 @@ ns_parserr(ns_msg *handle, ns_sect section, int rrnum, ns_rr *rr) { int tmp; /* Make section right. */ - if ((tmp = section) < 0 || section >= ns_s_max) + tmp = section; + if (tmp < 0 || section >= ns_s_max) RETERR(ENODEV); if (section != handle->_sect) setsection(handle, section); diff --git a/contrib/bind9/lib/bind/nameser/ns_ttl.c b/contrib/bind9/lib/bind/nameser/ns_ttl.c index 368b05a3a22..4d18d3f281d 100644 --- a/contrib/bind9/lib/bind/nameser/ns_ttl.c +++ b/contrib/bind9/lib/bind/nameser/ns_ttl.c @@ -16,7 +16,7 @@ */ #ifndef lint -static const char rcsid[] = "$Id: ns_ttl.c,v 1.1.206.1 2004/03/09 08:33:45 marka Exp $"; +static const char rcsid[] = "$Id: ns_ttl.c,v 1.1.206.2 2005/07/28 07:43:21 marka Exp $"; #endif /* Import. */ @@ -133,7 +133,8 @@ ns_parse_ttl(const char *src, u_long *dst) { goto einval; else ttl += tmp; - } + } else if (!dirty) + goto einval; *dst = ttl; return (0); diff --git a/contrib/bind9/lib/bind/nameser/ns_verify.c b/contrib/bind9/lib/bind/nameser/ns_verify.c index 7ee00a610ba..adda249bb4c 100644 --- a/contrib/bind9/lib/bind/nameser/ns_verify.c +++ b/contrib/bind9/lib/bind/nameser/ns_verify.c @@ -16,7 +16,7 @@ */ #ifndef lint -static const char rcsid[] = "$Id: ns_verify.c,v 1.1.206.1 2004/03/09 08:33:45 marka Exp $"; +static const char rcsid[] = "$Id: ns_verify.c,v 1.1.206.2 2005/10/11 00:48:16 marka Exp $"; #endif /* Import. */ @@ -144,7 +144,7 @@ ns_verify(u_char *msg, int *msglen, void *k, int n; int error; u_int16_t type, length; - u_int16_t fudge, sigfieldlen, id, otherfieldlen; + u_int16_t fudge, sigfieldlen, otherfieldlen; dst_init(); if (msg == NULL || msglen == NULL || *msglen < 0) @@ -198,9 +198,9 @@ ns_verify(u_char *msg, int *msglen, void *k, sigstart = cp; cp += sigfieldlen; - /* Read the original id and error. */ + /* Skip id and read error. */ BOUNDS_CHECK(cp, 2*INT16SZ); - GETSHORT(id, cp); + cp += INT16SZ; GETSHORT(error, cp); /* Parse the other data. */ @@ -341,12 +341,12 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state, int required) { HEADER *hp = (HEADER *)msg; - u_char *recstart, *rdatastart, *sigstart; + u_char *recstart, *sigstart; unsigned int sigfieldlen, otherfieldlen; u_char *cp, *eom = msg + *msglen, *cp2; char name[MAXDNAME], alg[MAXDNAME]; u_char buf[MAXDNAME]; - int n, type, length, fudge, id, error; + int n, type, length, fudge, error; time_t timesigned; if (msg == NULL || msglen == NULL || state == NULL) @@ -403,7 +403,6 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state, return (NS_TSIG_ERROR_FORMERR); /* Read the algorithm name. */ - rdatastart = cp; n = dn_expand(msg, eom, cp, alg, MAXDNAME); if (n < 0) return (NS_TSIG_ERROR_FORMERR); @@ -429,9 +428,9 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state, sigstart = cp; cp += sigfieldlen; - /* Read the original id and error. */ + /* Skip id and read error. */ BOUNDS_CHECK(cp, 2*INT16SZ); - GETSHORT(id, cp); + cp += INT16SZ; GETSHORT(error, cp); /* Parse the other data. */ diff --git a/contrib/bind9/lib/bind/port_after.h.in b/contrib/bind9/lib/bind/port_after.h.in index c043561b16a..0c956b71ed0 100644 --- a/contrib/bind9/lib/bind/port_after.h.in +++ b/contrib/bind9/lib/bind/port_after.h.in @@ -8,6 +8,9 @@ #if (!defined(BSD)) || (BSD < 199306) #include #endif +#ifdef HAVE_INTTYPES_H +#include +#endif @NEED_PSELECT@ @HAVE_SA_LEN@ @@ -27,9 +30,7 @@ @INNETGR_ARGS@ @SETNETGRENT_ARGS@ @USE_IFNAMELINKID@ - -/* XXX sunos and cygwin needs O_NDELAY */ -#define PORT_NONBLOCK O_NONBLOCK +@PORT_NONBLOCK@ /* * We need to know the IPv6 address family number even on IPv4-only systems. @@ -255,7 +256,7 @@ char * strsep(char **stringp, const char *delim); #endif #ifndef ALIGN -#define ALIGN(p) (((unsigned int)(p) + (sizeof(int) - 1)) & ~(sizeof(int) - 1)) +#define ALIGN(p) (((uintptr_t)(p) + (sizeof(long) - 1)) & ~(sizeof(long) - 1)) #endif #ifdef NEED_SETGROUPENT @@ -298,7 +299,7 @@ GROUP_R_SET_RETURN setgrent_r(GROUP_R_ENT_ARGS); GROUP_R_END_RETURN endgrent_r(GROUP_R_ENT_ARGS); #endif -#ifdef NEED_INNETGR_R +#if defined(NEED_INNETGR_R) && defined(NGR_R_RETURN) NGR_R_RETURN innetgr_r(const char *, const char *, const char *, const char *); #endif @@ -381,7 +382,9 @@ int isc__gettimeofday(struct timeval *tp, struct timezone *tzp); int getnetgrent(char **machinep, char **userp, char **domainp); +#ifdef NGR_R_ARGS int getnetgrent_r(char **machinep, char **userp, char **domainp, NGR_R_ARGS); +#endif #ifdef SETNETGRENT_ARGS void setnetgrent(SETNETGRENT_ARGS); diff --git a/contrib/bind9/lib/bind/port_before.h.in b/contrib/bind9/lib/bind/port_before.h.in index d6fbe86ac1e..c754efd2b03 100644 --- a/contrib/bind9/lib/bind/port_before.h.in +++ b/contrib/bind9/lib/bind/port_before.h.in @@ -18,6 +18,9 @@ struct timezone; /* silence warning */ @WANT_IRS_PW@ @BSD_COMP@ +@USE_POLL@ +@HAVE_MD5@ +@SOLARIS2@ @DO_PTHREADS@ @GETGROUPLIST_ARGS@ @@ -135,4 +138,9 @@ struct timezone; /* silence warning */ #define ISC_FORMAT_PRINTF(fmt, args) #endif +/* Pull in host order macros when _XOPEN_SOURCE_EXTENDED is defined. */ +#if defined(__hpux) && defined(_XOPEN_SOURCE_EXTENDED) +#include +#endif + #endif diff --git a/contrib/bind9/lib/bind/resolv/Makefile.in b/contrib/bind9/lib/bind/resolv/Makefile.in index 74a20e74fe3..a235fbc7a5e 100644 --- a/contrib/bind9/lib/bind/resolv/Makefile.in +++ b/contrib/bind9/lib/bind/resolv/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2001 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,16 +13,16 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.3.206.1 2004/03/15 01:02:54 marka Exp $ +# $Id: Makefile.in,v 1.3.206.3 2005/07/29 00:13:09 marka Exp $ srcdir= @srcdir@ VPATH = @srcdir@ -OBJS= herror.@O@ res_comp.@O@ res_data.@O@ res_debug.@O@ \ +OBJS= herror.@O@ mtctxres.@O@ res_comp.@O@ res_data.@O@ res_debug.@O@ \ res_findzonecut.@O@ res_init.@O@ res_mkquery.@O@ res_mkupdate.@O@ \ res_query.@O@ res_send.@O@ res_sendsigned.@O@ res_update.@O@ -SRCS= herror.c res_comp.c res_data.c res_debug.c \ +SRCS= herror.c mtctxres.c res_comp.c res_data.c res_debug.c \ res_findzonecut.c res_init.c res_mkquery.c res_mkupdate.c \ res_query.c res_send.c res_sendsigned.c res_update.c diff --git a/contrib/bind9/lib/bind/resolv/mtctxres.c b/contrib/bind9/lib/bind/resolv/mtctxres.c new file mode 100644 index 00000000000..f33cf11e3f4 --- /dev/null +++ b/contrib/bind9/lib/bind/resolv/mtctxres.c @@ -0,0 +1,128 @@ +#include +#ifdef DO_PTHREADS +#include +#endif +#include +#include +#include +#include +#include +#include +#include + +#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/bind/resolv/res_comp.c b/contrib/bind9/lib/bind/resolv/res_comp.c index 6468dbc2218..8cc99a76288 100644 --- a/contrib/bind9/lib/bind/resolv/res_comp.c +++ b/contrib/bind9/lib/bind/resolv/res_comp.c @@ -70,7 +70,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_comp.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "$Id: res_comp.c,v 1.1.2.1.4.1 2004/03/09 08:33:54 marka Exp $"; +static const char rcsid[] = "$Id: res_comp.c,v 1.1.2.1.4.2 2005/07/28 07:43:22 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -242,6 +242,18 @@ res_dnok(const char *dn) { * __getshort * Note that one _ comes from C and the others come from us. */ + +#ifdef SOLARIS2 +#ifdef __putlong +#undef __putlong +#endif +#ifdef __putshort +#undef __putshort +#endif +#pragma weak putlong = __putlong +#pragma weak putshort = __putshort +#endif /* SOLARIS2 */ + void __putlong(u_int32_t src, u_char *dst) { ns_put32(src, dst); } void __putshort(u_int16_t src, u_char *dst) { ns_put16(src, dst); } #ifndef __ultrix__ diff --git a/contrib/bind9/lib/bind/resolv/res_debug.c b/contrib/bind9/lib/bind/resolv/res_debug.c index 1e228be5e62..8dda12c5e81 100644 --- a/contrib/bind9/lib/bind/resolv/res_debug.c +++ b/contrib/bind9/lib/bind/resolv/res_debug.c @@ -95,7 +95,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_debug.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.5 2004/07/28 20:16:46 marka Exp $"; +static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.6 2005/07/28 07:43:22 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -113,6 +113,7 @@ static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.5 2004/07/28 20:16:46 #include #include #include +#include #include #include #include @@ -504,7 +505,7 @@ sym_ston(const struct res_sym *syms, const char *name, int *success) { const char * sym_ntos(const struct res_sym *syms, int number, int *success) { - static char unname[20]; + char *unname = sym_ntos_unname; for ((void)NULL; syms->name != 0; syms++) { if (number == syms->number) { @@ -522,7 +523,7 @@ sym_ntos(const struct res_sym *syms, int number, int *success) { const char * sym_ntop(const struct res_sym *syms, int number, int *success) { - static char unname[20]; + char *unname = sym_ntop_unname; for ((void)NULL; syms->name != 0; syms++) { if (number == syms->number) { @@ -596,7 +597,7 @@ p_class(int class) { */ const char * p_option(u_long option) { - static char nbuf[40]; + char *nbuf = p_option_nbuf; switch (option) { case RES_INIT: return "init"; @@ -639,7 +640,7 @@ p_option(u_long option) { */ const char * p_time(u_int32_t value) { - static char nbuf[40]; /* XXX nonreentrant */ + char *nbuf = p_time_nbuf; if (ns_format_ttl(value, nbuf, sizeof nbuf) < 0) sprintf(nbuf, "%u", value); @@ -695,7 +696,7 @@ static const char * precsize_ntoa(prec) u_int8_t prec; { - static char retbuf[sizeof "90000000.00"]; /* XXX nonreentrant */ + char *retbuf = precsize_ntoa_retbuf; unsigned long val; int mantissa, exponent; @@ -1097,8 +1098,7 @@ dn_count_labels(const char *name) { */ char * p_secstodate (u_long secs) { - /* XXX nonreentrant */ - static char output[15]; /* YYYYMMDDHHMMSS and null */ + char *output = p_secstodate_output; time_t clock = secs; struct tm *time; #ifdef HAVE_TIME_R diff --git a/contrib/bind9/lib/bind/resolv/res_findzonecut.c b/contrib/bind9/lib/bind/resolv/res_findzonecut.c index 154babde22b..804beb64746 100644 --- a/contrib/bind9/lib/bind/resolv/res_findzonecut.c +++ b/contrib/bind9/lib/bind/resolv/res_findzonecut.c @@ -1,5 +1,5 @@ #if !defined(lint) && !defined(SABER) -static const char rcsid[] = "$Id: res_findzonecut.c,v 1.2.2.3.4.3 2004/09/16 07:06:11 marka Exp $"; +static const char rcsid[] = "$Id: res_findzonecut.c,v 1.2.2.3.4.4 2005/10/11 00:48:16 marka Exp $"; #endif /* not lint */ /* @@ -319,7 +319,6 @@ get_soa(res_state statp, const char *dname, ns_class class, int opts, for (i = 0; i < n; i++) { const char *t; const u_char *rdata; - int rdlen; ns_rr rr; if (ns_parserr(&msg, sect, i, &rr) < 0) { @@ -368,7 +367,6 @@ get_soa(res_state statp, const char *dname, ns_class class, int opts, } strcpy(zname, t); rdata = ns_rr_rdata(rr); - rdlen = ns_rr_rdlen(rr); if (ns_name_uncompress(resp, ns_msg_end(msg), rdata, mname, msize) < 0) { DPRINTF(("get_soa: ns_name_uncompress failed") @@ -526,7 +524,6 @@ save_ns(res_state statp, ns_msg *msg, ns_sect sect, const u_char *rdata; rr_ns *nsrr; ns_rr rr; - int rdlen; if (ns_parserr(msg, sect, i, &rr) < 0) { DPRINTF(("save_ns: ns_parserr(%s, %d) failed", @@ -545,7 +542,6 @@ save_ns(res_state statp, ns_msg *msg, ns_sect sect, return (-1); } rdata = ns_rr_rdata(rr); - rdlen = ns_rr_rdlen(rr); if (ns_name_uncompress(ns_msg_base(*msg), ns_msg_end(*msg), rdata, tname, sizeof tname) < 0) { diff --git a/contrib/bind9/lib/bind/resolv/res_init.c b/contrib/bind9/lib/bind/resolv/res_init.c index 241f5f7cbf3..28a3ebd088e 100644 --- a/contrib/bind9/lib/bind/resolv/res_init.c +++ b/contrib/bind9/lib/bind/resolv/res_init.c @@ -70,7 +70,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_init.c 8.1 (Berkeley) 6/7/93"; -static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.2 2004/03/16 12:34:18 marka Exp $"; +static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.5 2005/11/03 00:00:52 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -102,6 +102,10 @@ static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.2 2004/03/16 12:34:18 m #define RESOLVSORT #define DEBUG +#ifdef SOLARIS2 +#include +#endif + static void res_setoptions __P((res_state, const char *, const char *)); #ifdef RESOLVSORT @@ -163,6 +167,9 @@ __res_vinit(res_state statp, int preinit) { int dots; union res_sockaddr_union u[2]; + if (statp->_u._ext.ext != NULL) + res_ndestroy(statp); + if (!preinit) { statp->retrans = RES_TIMEOUT; statp->retry = RES_DFLRETRY; @@ -170,9 +177,6 @@ __res_vinit(res_state statp, int preinit) { statp->id = res_randomid(); } - if ((statp->options & RES_INIT) != 0U) - res_ndestroy(statp); - memset(u, 0, sizeof(u)); #ifdef USELOOPBACK u[nserv].sin.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); @@ -212,12 +216,42 @@ __res_vinit(res_state statp, int preinit) { statp->_u._ext.ext->nsaddrs[0].sin = statp->nsaddr; strcpy(statp->_u._ext.ext->nsuffix, "ip6.arpa"); strcpy(statp->_u._ext.ext->nsuffix2, "ip6.int"); - } + } else + return (-1); #ifdef RESOLVSORT statp->nsort = 0; #endif res_setservers(statp, u, nserv); +#ifdef SOLARIS2 + /* + * The old libresolv derived the defaultdomain from NIS/NIS+. + * We want to keep this behaviour + */ + { + char buf[sizeof(statp->defdname)], *cp; + int ret; + + if ((ret = sysinfo(SI_SRPC_DOMAIN, buf, sizeof(buf))) > 0 && + (unsigned int)ret <= sizeof(buf)) { + if (buf[0] == '+') + buf[0] = '.'; + cp = strchr(buf, '.'); + if (cp == NULL) { + if (strlcpy(statp->defdname, buf, + sizeof(statp->defdname)) + >= sizeof(statp->defdname)) + goto freedata; + } else { + if (strlcpy(statp->defdname, cp+1, + sizeof(statp->defdname)) + >= sizeof(statp->defdname)) + goto freedata; + } + } + } +#endif /* SOLARIS2 */ + /* Allow user to override the local domain definition */ if ((cp = getenv("LOCALDOMAIN")) != NULL) { (void)strncpy(statp->defdname, cp, sizeof(statp->defdname) - 1); @@ -456,6 +490,15 @@ __res_vinit(res_state statp, int preinit) { res_setoptions(statp, cp, "env"); statp->options |= RES_INIT; return (0); + +#ifdef SOLARIS2 + freedata: + if (statp->_u._ext.ext != NULL) { + free(statp->_u._ext.ext); + statp->_u._ext.ext = NULL; + } + return (-1); +#endif } static void @@ -495,6 +538,22 @@ res_setoptions(res_state statp, const char *options, const char *source) if (statp->options & RES_DEBUG) printf(";;\ttimeout=%d\n", statp->retrans); #endif +#ifdef SOLARIS2 + } else if (!strncmp(cp, "retrans:", sizeof("retrans:") - 1)) { + /* + * For backward compatibility, 'retrans' is + * supported as an alias for 'timeout', though + * without an imposed maximum. + */ + statp->retrans = atoi(cp + sizeof("retrans:") - 1); + } else if (!strncmp(cp, "retry:", sizeof("retry:") - 1)){ + /* + * For backward compatibility, 'retry' is + * supported as an alias for 'attempts', though + * without an imposed maximum. + */ + statp->retry = atoi(cp + sizeof("retry:") - 1); +#endif /* SOLARIS2 */ } else if (!strncmp(cp, "attempts:", sizeof("attempts:") - 1)){ i = atoi(cp + sizeof("attempts:") - 1); if (i <= RES_MAXRETRY) diff --git a/contrib/bind9/lib/bind/resolv/res_mkupdate.c b/contrib/bind9/lib/bind/resolv/res_mkupdate.c index aac95e5907e..01078f1a51a 100644 --- a/contrib/bind9/lib/bind/resolv/res_mkupdate.c +++ b/contrib/bind9/lib/bind/resolv/res_mkupdate.c @@ -21,7 +21,7 @@ */ #if !defined(lint) && !defined(SABER) -static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.3 2004/06/03 04:44:48 marka Exp $"; +static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.5 2005/10/14 05:43:47 marka Exp $"; #endif /* not lint */ #include "port_before.h" @@ -78,7 +78,7 @@ int res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) { ns_updrec *rrecp_start = rrecp_in; HEADER *hp; - u_char *cp, *sp1, *sp2, *startp, *endp; + u_char *cp, *sp2, *startp, *endp; int n, i, soanum, multiline; ns_updrec *rrecp; struct in_addr ina; @@ -101,7 +101,6 @@ res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) { hp->id = htons(++statp->id); hp->opcode = ns_o_update; hp->rcode = NOERROR; - sp1 = buf + 2*INT16SZ; /* save pointer to zocount */ cp = buf + HFIXEDSZ; buflen -= HFIXEDSZ; dpp = dnptrs; @@ -922,10 +921,10 @@ res_mkupdrec(int section, const char *dname, } INIT_LINK(rrecp, r_link); INIT_LINK(rrecp, r_glink); - rrecp->r_class = class; - rrecp->r_type = type; + rrecp->r_class = (ns_class)class; + rrecp->r_type = (ns_type)type; rrecp->r_ttl = ttl; - rrecp->r_section = section; + rrecp->r_section = (ns_sect)section; return (rrecp); } diff --git a/contrib/bind9/lib/bind/resolv/res_send.c b/contrib/bind9/lib/bind/resolv/res_send.c index 81c24258920..5be24893259 100644 --- a/contrib/bind9/lib/bind/resolv/res_send.c +++ b/contrib/bind9/lib/bind/resolv/res_send.c @@ -52,7 +52,7 @@ */ /* - * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") + * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC") * Portions Copyright (c) 1996-1999 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -70,7 +70,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_send.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 marka Exp $"; +static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.7 2005/08/15 02:04:41 marka Exp $"; #endif /* LIBC_SCCS and not lint */ /* @@ -103,6 +103,13 @@ static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 m #include "port_after.h" +#ifdef USE_POLL +#ifdef HAVE_STROPTS_H +#include +#endif +#include +#endif /* USE_POLL */ + /* Options. Leave them on. */ #define DEBUG #include "res_debug.h" @@ -110,7 +117,11 @@ static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 m #define EXT(res) ((res)->_u._ext) +#ifndef USE_POLL static const int highestFD = FD_SETSIZE - 1; +#else +static int highestFD = 0; +#endif /* Forward. */ @@ -125,7 +136,7 @@ static void Aerror(const res_state, FILE *, const char *, int, const struct sockaddr *, int); static void Perror(const res_state, FILE *, const char *, int); static int sock_eq(struct sockaddr *, struct sockaddr *); -#ifdef NEED_PSELECT +#if defined(NEED_PSELECT) && !defined(USE_POLL) static int pselect(int, void *, void *, void *, struct timespec *, const sigset_t *); @@ -280,6 +291,10 @@ res_nsend(res_state statp, int gotsomewhere, terrno, try, v_circuit, resplen, ns, n; char abuf[NI_MAXHOST]; +#ifdef USE_POLL + highestFD = sysconf(_SC_OPEN_MAX) - 1; +#endif + if (statp->nscount == 0) { errno = ESRCH; return (-1); @@ -760,10 +775,15 @@ send_dg(res_state statp, const struct sockaddr *nsap; int nsaplen; struct timespec now, timeout, finish; - fd_set dsmask; struct sockaddr_storage from; ISC_SOCKLEN_T fromlen; int resplen, seconds, n, s; +#ifdef USE_POLL + int polltimeout; + struct pollfd pollfd; +#else + fd_set dsmask; +#endif nsap = get_nsaddr(statp, ns); nsaplen = get_salen(nsap); @@ -841,6 +861,7 @@ send_dg(res_state statp, wait: now = evNowTime(); nonow: +#ifndef USE_POLL FD_ZERO(&dsmask); FD_SET(s, &dsmask); if (evCmpTime(finish, now) > 0) @@ -848,6 +869,17 @@ send_dg(res_state statp, else timeout = evConsTime(0, 0); n = pselect(s + 1, &dsmask, NULL, NULL, &timeout, NULL); +#else + timeout = evSubTime(finish, now); + if (timeout.tv_sec < 0) + timeout = evConsTime(0, 0); + polltimeout = 1000*timeout.tv_sec + + timeout.tv_nsec/1000000; + pollfd.fd = s; + pollfd.events = POLLRDNORM; + n = poll(&pollfd, 1, polltimeout); +#endif /* USE_POLL */ + if (n == 0) { Dprint(statp->options & RES_DEBUG, (stdout, ";; timeout\n")); *gotsomewhere = 1; @@ -856,7 +888,11 @@ send_dg(res_state statp, if (n < 0) { if (errno == EINTR) goto wait; +#ifndef USE_POLL Perror(statp, stderr, "select", errno); +#else + Perror(statp, stderr, "poll", errno); +#endif /* USE_POLL */ res_nclose(statp); return (0); } @@ -1025,7 +1061,7 @@ sock_eq(struct sockaddr *a, struct sockaddr *b) { } } -#ifdef NEED_PSELECT +#if defined(NEED_PSELECT) && !defined(USE_POLL) /* XXX needs to move to the porting library. */ static int pselect(int nfds, void *rfds, void *wfds, void *efds, diff --git a/contrib/bind9/lib/bind/resolv/res_sendsigned.c b/contrib/bind9/lib/bind/resolv/res_sendsigned.c index 1984377ab12..d1d22745756 100644 --- a/contrib/bind9/lib/bind/resolv/res_sendsigned.c +++ b/contrib/bind9/lib/bind/resolv/res_sendsigned.c @@ -122,8 +122,16 @@ retry: (stdout, "%s", ""), answer, (anslen > len) ? len : anslen); - Dprint(statp->pfcode & RES_PRF_REPLY, - (stdout, ";; TSIG invalid (%s)\n", p_rcode(ret))); + if (ret > 0) { + Dprint(statp->pfcode & RES_PRF_REPLY, + (stdout, ";; server rejected TSIG (%s)\n", + p_rcode(ret))); + } else { + Dprint(statp->pfcode & RES_PRF_REPLY, + (stdout, ";; TSIG invalid (%s)\n", + p_rcode(-ret))); + } + free (nstatp); free (newmsg); dst_free_key(dstkey); diff --git a/contrib/bind9/lib/bind9/api b/contrib/bind9/lib/bind9/api index b4cd78b7474..0a12b5e852c 100644 --- a/contrib/bind9/lib/bind9/api +++ b/contrib/bind9/lib/bind9/api @@ -1,3 +1,3 @@ LIBINTERFACE = 0 -LIBREVISION = 5 +LIBREVISION = 7 LIBAGE = 0 diff --git a/contrib/bind9/lib/bind9/check.c b/contrib/bind9/lib/bind9/check.c index 0cf1e75627b..e6e86fd14df 100644 --- a/contrib/bind9/lib/bind9/check.c +++ b/contrib/bind9/lib/bind9/check.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.37.6.29 2004/11/22 05:02:41 marka Exp $ */ +/* $Id: check.c,v 1.37.6.32 2005/11/03 23:08:41 marka Exp $ */ #include @@ -119,7 +119,7 @@ check_orderent(cfg_obj_t *ent, isc_log_t *logctx) { result = ISC_R_FAILURE; } else if (strcasecmp(cfg_obj_asstring(obj), "fixed") == 0) { cfg_obj_log(obj, logctx, ISC_LOG_WARNING, - "rrset-order: order 'fixed' not implemented"); + "rrset-order: order 'fixed' not fully implemented"); } else if (/* strcasecmp(cfg_obj_asstring(obj), "fixed") != 0 && */ strcasecmp(cfg_obj_asstring(obj), "random") != 0 && strcasecmp(cfg_obj_asstring(obj), "cyclic") != 0) { @@ -598,8 +598,10 @@ validate_masters(cfg_obj_t *obj, cfg_obj_t *config, isc_uint32_t *countp, REQUIRE(countp != NULL); result = isc_symtab_create(mctx, 100, NULL, NULL, ISC_FALSE, &symtab); - if (result != ISC_R_SUCCESS) + if (result != ISC_R_SUCCESS) { + *countp = count; return (result); + } newlist: list = cfg_tuple_get(obj, "addresses"); diff --git a/contrib/bind9/lib/bind9/getaddresses.c b/contrib/bind9/lib/bind9/getaddresses.c index fafc0a6df29..02d110478cc 100644 --- a/contrib/bind9/lib/bind9/getaddresses.c +++ b/contrib/bind9/lib/bind9/getaddresses.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001, 2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: getaddresses.c,v 1.13.126.6 2004/09/16 01:00:58 marka Exp $ */ +/* $Id: getaddresses.c,v 1.13.126.8 2005/10/14 02:13:06 marka Exp $ */ #include #include @@ -65,8 +65,8 @@ bind9_getaddresses(const char *hostname, in_port_t port, REQUIRE(addrcount != NULL); REQUIRE(addrsize > 0); - have_ipv4 = (isc_net_probeipv4() == ISC_R_SUCCESS); - have_ipv6 = (isc_net_probeipv6() == ISC_R_SUCCESS); + have_ipv4 = ISC_TF((isc_net_probeipv4() == ISC_R_SUCCESS)); + have_ipv6 = ISC_TF((isc_net_probeipv6() == ISC_R_SUCCESS)); /* * Try IPv4, then IPv6. In order to handle the extended format diff --git a/contrib/bind9/lib/dns/adb.c b/contrib/bind9/lib/dns/adb.c index 9c8d4d5b4ac..c0b31db1129 100644 --- a/contrib/bind9/lib/dns/adb.c +++ b/contrib/bind9/lib/dns/adb.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: adb.c,v 1.181.2.11.2.20 2004/11/10 22:32:40 marka Exp $ */ +/* $Id: adb.c,v 1.181.2.11.2.24 2005/10/14 05:19:00 marka Exp $ */ /* * Implementation notes @@ -1784,7 +1784,7 @@ shutdown_task(isc_task_t *task, isc_event_t *ev) { static isc_boolean_t check_expire_name(dns_adbname_t **namep, isc_stdtime_t now) { dns_adbname_t *name; - isc_result_t result = ISC_FALSE; + isc_boolean_t result = ISC_FALSE; INSIST(namep != NULL && DNS_ADBNAME_VALID(*namep)); name = *namep; @@ -1861,7 +1861,7 @@ static isc_boolean_t cleanup_names(dns_adb_t *adb, int bucket, isc_stdtime_t now) { dns_adbname_t *name; dns_adbname_t *next_name; - isc_result_t result = ISC_FALSE; + isc_boolean_t result = ISC_FALSE; DP(CLEAN_LEVEL, "cleaning name bucket %d", bucket); @@ -3347,7 +3347,7 @@ dns_adb_marklame(dns_adb_t *adb, dns_adbaddrinfo_t *addr, dns_name_t *zone, bucket = addr->entry->lock_bucket; LOCK(&adb->entrylocks[bucket]); zi = ISC_LIST_HEAD(addr->entry->zoneinfo); - while (zi != NULL && dns_name_equal(zone, &zi->zone)) + while (zi != NULL && !dns_name_equal(zone, &zi->zone)) zi = ISC_LIST_NEXT(zi, plink); if (zi != NULL) { if (expire_time > zi->lame_timer) @@ -3366,7 +3366,7 @@ dns_adb_marklame(dns_adb_t *adb, dns_adbaddrinfo_t *addr, dns_name_t *zone, unlock: UNLOCK(&adb->entrylocks[bucket]); - return (ISC_R_SUCCESS); + return (result); } void diff --git a/contrib/bind9/lib/dns/api b/contrib/bind9/lib/dns/api index c06a62ec803..7df81573fd7 100644 --- a/contrib/bind9/lib/dns/api +++ b/contrib/bind9/lib/dns/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 20 -LIBREVISION = 2 +LIBINTERFACE = 21 +LIBREVISION = 1 LIBAGE = 0 diff --git a/contrib/bind9/lib/dns/cache.c b/contrib/bind9/lib/dns/cache.c index b148f6021df..0e17a957d17 100644 --- a/contrib/bind9/lib/dns/cache.c +++ b/contrib/bind9/lib/dns/cache.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: cache.c,v 1.45.2.4.8.7 2004/03/08 02:07:52 marka Exp $ */ +/* $Id: cache.c,v 1.45.2.4.8.9 2005/03/17 03:58:30 marka Exp $ */ #include @@ -1021,27 +1021,10 @@ dns_cache_flushname(dns_cache_t *cache, dns_name_t *name) { dns_rdataset_init(&rdataset); dns_rdatasetiter_current(iter, &rdataset); - - for (result = dns_rdataset_first(&rdataset); - result == ISC_R_SUCCESS; - result = dns_rdataset_next(&rdataset)) - { - dns_rdata_t rdata = DNS_RDATA_INIT; - dns_rdatatype_t covers; - - dns_rdataset_current(&rdataset, &rdata); - if (rdata.type == dns_rdatatype_rrsig) - covers = dns_rdata_covers(&rdata); - else - covers = 0; - result = dns_db_deleterdataset(cache->db, node, NULL, - rdata.type, covers); - if (result != ISC_R_SUCCESS && - result != DNS_R_UNCHANGED) - break; - } + result = dns_db_deleterdataset(cache->db, node, NULL, + rdataset.type, rdataset.covers); dns_rdataset_disassociate(&rdataset); - if (result != ISC_R_NOMORE) + if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED) break; } if (result == ISC_R_NOMORE) diff --git a/contrib/bind9/lib/dns/forward.c b/contrib/bind9/lib/dns/forward.c index f94abfe114f..1455fbad43c 100644 --- a/contrib/bind9/lib/dns/forward.c +++ b/contrib/bind9/lib/dns/forward.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: forward.c,v 1.5.206.1 2004/03/06 08:13:38 marka Exp $ */ +/* $Id: forward.c,v 1.5.206.3 2005/03/17 03:58:30 marka Exp $ */ #include @@ -138,6 +138,13 @@ dns_fwdtable_add(dns_fwdtable_t *fwdtable, dns_name_t *name, isc_result_t dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name, dns_forwarders_t **forwardersp) +{ + return (dns_fwdtable_find2(fwdtable, name, NULL, forwardersp)); +} + +isc_result_t +dns_fwdtable_find2(dns_fwdtable_t *fwdtable, dns_name_t *name, + dns_name_t *foundname, dns_forwarders_t **forwardersp) { isc_result_t result; @@ -145,7 +152,7 @@ dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name, RWLOCK(&fwdtable->rwlock, isc_rwlocktype_read); - result = dns_rbt_findname(fwdtable->table, name, 0, NULL, + result = dns_rbt_findname(fwdtable->table, name, 0, foundname, (void **)forwardersp); if (result == DNS_R_PARTIALMATCH) result = ISC_R_SUCCESS; diff --git a/contrib/bind9/lib/dns/gen-unix.h b/contrib/bind9/lib/dns/gen-unix.h index 8c1818dd6d6..bd007c4541f 100644 --- a/contrib/bind9/lib/dns/gen-unix.h +++ b/contrib/bind9/lib/dns/gen-unix.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: gen-unix.h,v 1.12.12.3 2004/03/08 09:04:29 marka Exp $ */ +/* $Id: gen-unix.h,v 1.12.12.5 2005/06/09 23:54:29 marka Exp $ */ /* * This file is responsible for defining two operations that are not @@ -40,6 +40,10 @@ #include #include +#ifdef NEED_OPTARG +extern char *optarg; +#endif + #define isc_commandline_parse getopt #define isc_commandline_argument optarg diff --git a/contrib/bind9/lib/dns/include/dns/forward.h b/contrib/bind9/lib/dns/include/dns/forward.h index f1bf5abf017..1eb62d2a99d 100644 --- a/contrib/bind9/lib/dns/include/dns/forward.h +++ b/contrib/bind9/lib/dns/include/dns/forward.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: forward.h,v 1.2.206.1 2004/03/06 08:13:56 marka Exp $ */ +/* $Id: forward.h,v 1.2.206.3 2005/03/17 03:58:31 marka Exp $ */ #ifndef DNS_FORWARD_H #define DNS_FORWARD_H 1 @@ -67,6 +67,10 @@ dns_fwdtable_add(dns_fwdtable_t *fwdtable, dns_name_t *name, isc_result_t dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name, dns_forwarders_t **forwardersp); + +isc_result_t +dns_fwdtable_find2(dns_fwdtable_t *fwdtable, dns_name_t *name, + dns_name_t *foundname, dns_forwarders_t **forwardersp); /* * Finds a domain in the forwarding table. The closest matching parent * domain is returned. @@ -75,6 +79,7 @@ dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name, * fwdtable is a valid forwarding table. * name is a valid name * forwardersp != NULL && *forwardersp == NULL + * foundname to be NULL or a valid name with buffer. * * Returns: * ISC_R_SUCCESS diff --git a/contrib/bind9/lib/dns/include/dns/masterdump.h b/contrib/bind9/lib/dns/include/dns/masterdump.h index 5058945403b..888c588f3b6 100644 --- a/contrib/bind9/lib/dns/include/dns/masterdump.h +++ b/contrib/bind9/lib/dns/include/dns/masterdump.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: masterdump.h,v 1.22.12.8 2004/03/19 05:00:49 marka Exp $ */ +/* $Id: masterdump.h,v 1.22.12.10 2005/09/06 02:12:41 marka Exp $ */ #ifndef DNS_MASTERDUMP_H #define DNS_MASTERDUMP_H 1 @@ -122,7 +122,7 @@ LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_full; * stop of its own, but the class and type share one. */ LIBDNS_EXTERNAL_DATA extern const dns_master_style_t - dns_master_style_explicitttl; + dns_master_style_explicitttl; /* * A master style format designed for cache files. It prints explicit TTL diff --git a/contrib/bind9/lib/dns/include/dns/rdataset.h b/contrib/bind9/lib/dns/include/dns/rdataset.h index e2b0753a998..d856784c3e8 100644 --- a/contrib/bind9/lib/dns/include/dns/rdataset.h +++ b/contrib/bind9/lib/dns/include/dns/rdataset.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdataset.h,v 1.41.2.5.2.6 2004/03/08 02:08:01 marka Exp $ */ +/* $Id: rdataset.h,v 1.41.2.5.2.8 2005/03/17 03:58:31 marka Exp $ */ #ifndef DNS_RDATASET_H #define DNS_RDATASET_H 1 @@ -130,22 +130,23 @@ struct dns_rdataset { * Used by message.c to indicate that the rdataset's rdata had differing * TTL values, and the rdataset->ttl holds the smallest. */ -#define DNS_RDATASETATTR_QUESTION 0x0001 -#define DNS_RDATASETATTR_RENDERED 0x0002 /* Used by message.c */ -#define DNS_RDATASETATTR_ANSWERED 0x0004 /* Used by server. */ -#define DNS_RDATASETATTR_CACHE 0x0008 /* Used by resolver. */ -#define DNS_RDATASETATTR_ANSWER 0x0010 /* Used by resolver. */ -#define DNS_RDATASETATTR_ANSWERSIG 0x0020 /* Used by resolver. */ -#define DNS_RDATASETATTR_EXTERNAL 0x0040 /* Used by resolver. */ -#define DNS_RDATASETATTR_NCACHE 0x0080 /* Used by resolver. */ -#define DNS_RDATASETATTR_CHAINING 0x0100 /* Used by resolver. */ -#define DNS_RDATASETATTR_TTLADJUSTED 0x0200 /* Used by message.c */ -#define DNS_RDATASETATTR_FIXEDORDER 0x0400 -#define DNS_RDATASETATTR_RANDOMIZE 0x0800 -#define DNS_RDATASETATTR_CHASE 0x1000 /* Used by resolver. */ -#define DNS_RDATASETATTR_NXDOMAIN 0x2000 -#define DNS_RDATASETATTR_NOQNAME 0x4000 -#define DNS_RDATASETATTR_CHECKNAMES 0x8000 /* Used by resolver. */ +#define DNS_RDATASETATTR_QUESTION 0x00000001 +#define DNS_RDATASETATTR_RENDERED 0x00000002 /* Used by message.c */ +#define DNS_RDATASETATTR_ANSWERED 0x00000004 /* Used by server. */ +#define DNS_RDATASETATTR_CACHE 0x00000008 /* Used by resolver. */ +#define DNS_RDATASETATTR_ANSWER 0x00000010 /* Used by resolver. */ +#define DNS_RDATASETATTR_ANSWERSIG 0x00000020 /* Used by resolver. */ +#define DNS_RDATASETATTR_EXTERNAL 0x00000040 /* Used by resolver. */ +#define DNS_RDATASETATTR_NCACHE 0x00000080 /* Used by resolver. */ +#define DNS_RDATASETATTR_CHAINING 0x00000100 /* Used by resolver. */ +#define DNS_RDATASETATTR_TTLADJUSTED 0x00000200 /* Used by message.c */ +#define DNS_RDATASETATTR_FIXEDORDER 0x00000400 +#define DNS_RDATASETATTR_RANDOMIZE 0x00000800 +#define DNS_RDATASETATTR_CHASE 0x00001000 /* Used by resolver. */ +#define DNS_RDATASETATTR_NXDOMAIN 0x00002000 +#define DNS_RDATASETATTR_NOQNAME 0x00004000 +#define DNS_RDATASETATTR_CHECKNAMES 0x00008000 /* Used by resolver. */ +#define DNS_RDATASETATTR_REQUIREDGLUE 0x00010000 /* * _OMITDNSSEC: diff --git a/contrib/bind9/lib/dns/include/dns/validator.h b/contrib/bind9/lib/dns/include/dns/validator.h index c405fbb427f..24769f3c88a 100644 --- a/contrib/bind9/lib/dns/include/dns/validator.h +++ b/contrib/bind9/lib/dns/include/dns/validator.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.h,v 1.18.12.7 2004/05/14 05:06:41 marka Exp $ */ +/* $Id: validator.h,v 1.18.12.9 2005/09/06 02:12:41 marka Exp $ */ #ifndef DNS_VALIDATOR_H #define DNS_VALIDATOR_H 1 @@ -120,12 +120,16 @@ struct dns_validator { dns_fixedname_t fname; dns_fixedname_t wild; ISC_LINK(dns_validator_t) link; - dns_rdataset_t * dlv; + dns_rdataset_t dlv; dns_fixedname_t dlvsep; isc_boolean_t havedlvsep; isc_boolean_t mustbesecure; + unsigned int dlvlabels; + unsigned int depth; }; +#define DNS_VALIDATOR_DLV 1 + ISC_LANG_BEGINDECLS isc_result_t diff --git a/contrib/bind9/lib/dns/journal.c b/contrib/bind9/lib/dns/journal.c index 13fbdeef70f..536416d931a 100644 --- a/contrib/bind9/lib/dns/journal.c +++ b/contrib/bind9/lib/dns/journal.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,11 +15,12 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: journal.c,v 1.77.2.1.10.9 2004/09/16 04:57:02 marka Exp $ */ +/* $Id: journal.c,v 1.77.2.1.10.13 2005/11/03 23:08:41 marka Exp $ */ #include #include +#include #include #include @@ -1564,7 +1565,7 @@ read_one_rr(dns_journal_t *j) { /* * Read an RR. */ - result = journal_read_rrhdr(j, &rrhdr); + CHECK(journal_read_rrhdr(j, &rrhdr)); /* * Perform a sanity check on the journal RR size. * The smallest possible RR has a 1-byte owner name @@ -1750,6 +1751,8 @@ dns_diff_subtract(dns_diff_t diff[2], dns_diff_t *r) { isc_result_t result; dns_difftuple_t *p[2]; int i, t; + isc_boolean_t append; + CHECK(dns_diff_sort(&diff[0], rdata_order)); CHECK(dns_diff_sort(&diff[1], rdata_order)); @@ -1778,11 +1781,17 @@ dns_diff_subtract(dns_diff_t diff[2], dns_diff_t *r) { } INSIST(t == 0); /* - * Identical RRs in both databases; skip them both. + * Identical RRs in both databases; skip them both + * if the ttl differs. */ + append = ISC_TF(p[0]->ttl != p[1]->ttl); for (i = 0; i < 2; i++) { ISC_LIST_UNLINK(diff[i].tuples, p[i], link); - dns_difftuple_free(&p[i]); + if (append) { + ISC_LIST_APPEND(r->tuples, p[i], link); + } else { + dns_difftuple_free(&p[i]); + } } next: ; } diff --git a/contrib/bind9/lib/dns/key.c b/contrib/bind9/lib/dns/key.c index 7abb2d7f6e9..97d970ed5e7 100644 --- a/contrib/bind9/lib/dns/key.c +++ b/contrib/bind9/lib/dns/key.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,10 +15,11 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: key.c,v 1.1.4.1 2004/12/09 04:07:18 marka Exp $ */ +/* $Id: key.c,v 1.1.4.3 2005/06/09 23:54:29 marka Exp $ */ #include +#include #include #include diff --git a/contrib/bind9/lib/dns/message.c b/contrib/bind9/lib/dns/message.c index badde6ee71b..d4b2e1962f9 100644 --- a/contrib/bind9/lib/dns/message.c +++ b/contrib/bind9/lib/dns/message.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: message.c,v 1.194.2.10.2.17 2004/05/05 01:32:16 marka Exp $ */ +/* $Id: message.c,v 1.194.2.10.2.20 2005/06/07 01:42:23 marka Exp $ */ /*** *** Imports @@ -1476,6 +1476,13 @@ getsection(isc_buffer_t *source, dns_message_t *msg, dns_decompress_t *dctx, free_name = ISC_FALSE; } + if (seen_problem) { + if (free_name) + isc_mempool_put(msg->namepool, name); + if (free_rdataset) + isc_mempool_put(msg->rdspool, rdataset); + free_name = free_rdataset = ISC_FALSE; + } INSIST(free_name == ISC_FALSE); INSIST(free_rdataset == ISC_FALSE); } @@ -1783,6 +1790,57 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid, if (msg->reserved == 0 && (options & DNS_MESSAGERENDER_PARTIAL) != 0) partial = ISC_TRUE; + /* + * Render required glue first. Set TC if it won't fit. + */ + name = ISC_LIST_HEAD(*section); + if (name != NULL) { + rdataset = ISC_LIST_HEAD(name->list); + if (rdataset != NULL && + (rdataset->attributes & DNS_RDATASETATTR_REQUIREDGLUE) != 0 && + (rdataset->attributes & DNS_RDATASETATTR_RENDERED) == 0) { + void *order_arg = msg->order_arg; + st = *(msg->buffer); + count = 0; + if (partial) + result = dns_rdataset_towirepartial(rdataset, + name, + msg->cctx, + msg->buffer, + msg->order, + order_arg, + rd_options, + &count, + NULL); + else + result = dns_rdataset_towiresorted(rdataset, + name, + msg->cctx, + msg->buffer, + msg->order, + order_arg, + rd_options, + &count); + total += count; + if (partial && result == ISC_R_NOSPACE) { + msg->flags |= DNS_MESSAGEFLAG_TC; + msg->buffer->length += msg->reserved; + msg->counts[sectionid] += total; + return (result); + } + if (result != ISC_R_SUCCESS) { + INSIST(st.used < 65536); + dns_compress_rollback(msg->cctx, + (isc_uint16_t)st.used); + *(msg->buffer) = st; /* rollback */ + msg->buffer->length += msg->reserved; + msg->counts[sectionid] += total; + return (result); + } + rdataset->attributes |= DNS_RDATASETATTR_RENDERED; + } + } + do { name = ISC_LIST_HEAD(*section); if (name == NULL) { diff --git a/contrib/bind9/lib/dns/name.c b/contrib/bind9/lib/dns/name.c index 37a5f4e8126..116a56a8186 100644 --- a/contrib/bind9/lib/dns/name.c +++ b/contrib/bind9/lib/dns/name.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: name.c,v 1.127.2.7.2.11 2004/09/01 05:19:59 marka Exp $ */ +/* $Id: name.c,v 1.127.2.7.2.14 2005/10/14 01:38:48 marka Exp $ */ #include @@ -945,9 +945,9 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source, unsigned char *ndata, *label; char *tdata; char c; - ft_state state, kind; - unsigned int value, count, tbcount, bitlength, maxlength; - unsigned int n1, n2, vlen, tlen, nrem, nused, digits, labels, tused; + ft_state state; + unsigned int value, count; + unsigned int n1, n2, tlen, nrem, nused, digits, labels, tused; isc_boolean_t done; unsigned char *offsets; dns_offsets_t odata; @@ -985,15 +985,10 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source, */ n1 = 0; n2 = 0; - vlen = 0; label = NULL; digits = 0; value = 0; count = 0; - tbcount = 0; - bitlength = 0; - maxlength = 0; - kind = ft_init; /* * Make 'name' empty in case of failure. @@ -1051,7 +1046,6 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source, state = ft_initialescape; break; } - kind = ft_ordinary; state = ft_ordinary; if (nrem == 0) return (ISC_R_NOSPACE); @@ -1094,7 +1088,6 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source, */ return (DNS_R_BADLABELTYPE); } - kind = ft_ordinary; state = ft_escape; /* FALLTHROUGH */ case ft_escape: @@ -1305,13 +1298,14 @@ dns_name_totext(dns_name_t *name, isc_boolean_t omit_final_dot, trem--; nlen--; } else { - char buf[5]; if (trem < 4) return (ISC_R_NOSPACE); - snprintf(buf, sizeof(buf), - "\\%03u", c); - memcpy(tdata, buf, 4); - tdata += 4; + *tdata++ = 0x5c; + *tdata++ = 0x30 + + ((c / 100) % 10); + *tdata++ = 0x30 + + ((c / 10) % 10); + *tdata++ = 0x30 + (c % 10); trem -= 4; ndata++; nlen--; diff --git a/contrib/bind9/lib/dns/rbt.c b/contrib/bind9/lib/dns/rbt.c index cb43858069f..ecff783724b 100644 --- a/contrib/bind9/lib/dns/rbt.c +++ b/contrib/bind9/lib/dns/rbt.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rbt.c,v 1.115.2.2.2.11 2004/10/25 01:36:07 marka Exp $ */ +/* $Id: rbt.c,v 1.115.2.2.2.13 2005/06/18 01:03:24 marka Exp $ */ /* Principal Authors: DCL */ @@ -2060,7 +2060,10 @@ dns_rbt_deletetreeflat(dns_rbt_t *rbt, unsigned int quantum, if (DATA(node) != NULL && rbt->data_deleter != NULL) rbt->data_deleter(DATA(node), rbt->deleter_arg); - unhash_node(rbt, node); + /* + * Note: we don't call unhash_node() here as we are destroying + * the complete rbt tree. + */ #if DNS_RBT_USEMAGIC node->magic = 0; #endif diff --git a/contrib/bind9/lib/dns/rbtdb.c b/contrib/bind9/lib/dns/rbtdb.c index a0e5ab51f31..f399dd17bce 100644 --- a/contrib/bind9/lib/dns/rbtdb.c +++ b/contrib/bind9/lib/dns/rbtdb.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rbtdb.c,v 1.168.2.11.2.16 2004/05/23 11:07:23 marka Exp $ */ +/* $Id: rbtdb.c,v 1.168.2.11.2.22 2005/10/14 01:38:48 marka Exp $ */ /* * Principal Author: Bob Halley @@ -97,6 +97,12 @@ typedef isc_uint32_t rbtdb_rdatatype_t; #define RBTDB_RDATATYPE_NCACHEANY \ RBTDB_RDATATYPE_VALUE(0, dns_rdatatype_any) +/* + * Allow clients with a virtual time of upto 5 minutes in the past to see + * records that would have otherwise have expired. + */ +#define RBTDB_VIRTUAL 300 + struct noqname { dns_name_t name; void * nsec; @@ -413,7 +419,7 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) { again: if (rbtdb->tree != NULL) { result = dns_rbt_destroy2(&rbtdb->tree, - (rbtdb->task != NULL) ? 5 : 0); + (rbtdb->task != NULL) ? 1000 : 0); if (result == ISC_R_QUOTA) { INSIST(rbtdb->task != NULL); if (event == NULL) @@ -2752,10 +2758,9 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep, isc_result_t result; dns_fixedname_t fname, forigin; dns_name_t *name, *origin; - rbtdb_rdatatype_t matchtype, sigmatchtype, nsectype; + rbtdb_rdatatype_t matchtype, sigmatchtype; matchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_nsec, 0); - nsectype = RBTDB_RDATATYPE_VALUE(0, dns_rdatatype_nsec); sigmatchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, dns_rdatatype_nsec); @@ -2786,7 +2791,9 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep, * node as dirty, so it will get cleaned up * later. */ - if (node->references == 0) { + if (header->ttl > search->now - RBTDB_VIRTUAL) + header_prev = header; + else if (node->references == 0) { INSIST(header->down == NULL); if (header_prev != NULL) header_prev->next = @@ -2943,7 +2950,9 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, * mark it as stale, and the node as dirty, so it will * get cleaned up later. */ - if (node->references == 0) { + if (header->ttl > now - RBTDB_VIRTUAL) + header_prev = header; + else if (node->references == 0) { INSIST(header->down == NULL); if (header_prev != NULL) header_prev->next = header->next; @@ -3210,7 +3219,9 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options, * mark it as stale, and the node as dirty, so it will * get cleaned up later. */ - if (node->references == 0) { + if (header->ttl > now - RBTDB_VIRTUAL) + header_prev = header; + else if (node->references == 0) { INSIST(header->down == NULL); if (header_prev != NULL) header_prev->next = header->next; @@ -3398,7 +3409,7 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) { LOCK(&rbtdb->node_locks[rbtnode->locknum].lock); for (header = rbtnode->data; header != NULL; header = header->next) - if (header->ttl <= now) { + if (header->ttl <= now - RBTDB_VIRTUAL) { /* * We don't check if rbtnode->references == 0 and try * to free like we do in cache_find(), because @@ -3640,8 +3651,10 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, * rbtnode->references must be non-zero. This is so * because 'node' is an argument to the function. */ - header->attributes |= RDATASET_ATTR_STALE; - rbtnode->dirty = 1; + if (header->ttl <= now - RBTDB_VIRTUAL) { + header->attributes |= RDATASET_ATTR_STALE; + rbtnode->dirty = 1; + } } else if (EXISTS(header)) { if (header->type == matchtype) found = header; @@ -4344,6 +4357,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version, changed = add_changed(rbtdb, rbtversion, rbtnode); if (changed == NULL) { free_rdataset(rbtdb->common.mctx, newheader); + UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock); return (ISC_R_NOMEMORY); } @@ -4908,6 +4922,11 @@ dns_rbtdb_create */ isc_mem_attach(mctx, &rbtdb->common.mctx); + /* + * Must be initalized before free_rbtdb() is called. + */ + isc_ondestroy_init(&rbtdb->common.ondest); + /* * Make a copy of the origin name. */ @@ -4986,8 +5005,6 @@ dns_rbtdb_create rbtdb->future_version = NULL; ISC_LIST_INIT(rbtdb->open_versions); - isc_ondestroy_init(&rbtdb->common.ondest); - rbtdb->common.magic = DNS_DB_MAGIC; rbtdb->common.impmagic = RBTDB_MAGIC; diff --git a/contrib/bind9/lib/dns/rdata.c b/contrib/bind9/lib/dns/rdata.c index 6d4c098698a..1b3f2a51c13 100644 --- a/contrib/bind9/lib/dns/rdata.c +++ b/contrib/bind9/lib/dns/rdata.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdata.c,v 1.147.2.11.2.16 2004/10/06 05:37:40 marka Exp $ */ +/* $Id: rdata.c,v 1.147.2.11.2.20 2005/07/22 05:27:52 marka Exp $ */ #include #include @@ -986,11 +986,15 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { if (*sp < 0x20 || *sp >= 0x7f) { if (tl < 4) return (ISC_R_NOSPACE); - snprintf(tp, 5, "\\%03u", *sp++); - tp += 4; + *tp++ = 0x5c; + *tp++ = 0x30 + ((*sp / 100) % 10); + *tp++ = 0x30 + ((*sp / 10) % 10); + *tp++ = 0x30 + (*sp % 10); + sp++; tl -= 4; continue; } + /* double quote, semi-colon, backslash */ if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c) { if (tl < 2) return (ISC_R_NOSPACE); @@ -1213,7 +1217,7 @@ name_tobuffer(dns_name_t *name, isc_buffer_t *target) { static isc_uint32_t uint32_fromregion(isc_region_t *region) { - unsigned long value; + isc_uint32_t value; REQUIRE(region->length >= 4); value = region->base[0] << 24; diff --git a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c index 6943d8243ea..c9b52c7e78b 100644 --- a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c +++ b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: tsig_250.c,v 1.52.2.1.2.6 2004/03/08 09:04:40 marka Exp $ */ +/* $Id: tsig_250.c,v 1.52.2.1.2.8 2005/03/20 22:34:01 marka Exp $ */ /* Reviewed: Thu Mar 16 13:39:43 PST 2000 by gson */ @@ -162,8 +162,10 @@ totext_any_tsig(ARGS_TOTEXT) { */ sigtime = ((isc_uint64_t)sr.base[0] << 40) | ((isc_uint64_t)sr.base[1] << 32) | - (sr.base[2] << 24) | (sr.base[3] << 16) | - (sr.base[4] << 8) | sr.base[5]; + ((isc_uint64_t)sr.base[2] << 24) | + ((isc_uint64_t)sr.base[3] << 16) | + ((isc_uint64_t)sr.base[4] << 8) | + (isc_uint64_t)sr.base[5]; isc_region_consume(&sr, 6); bufp = &buf[sizeof(buf) - 1]; *bufp-- = 0; @@ -457,8 +459,10 @@ tostruct_any_tsig(ARGS_TOSTRUCT) { INSIST(sr.length >= 6); tsig->timesigned = ((isc_uint64_t)sr.base[0] << 40) | ((isc_uint64_t)sr.base[1] << 32) | - (sr.base[2] << 24) | (sr.base[3] << 16) | - (sr.base[4] << 8) | sr.base[5]; + ((isc_uint64_t)sr.base[2] << 24) | + ((isc_uint64_t)sr.base[3] << 16) | + ((isc_uint64_t)sr.base[4] << 8) | + (isc_uint64_t)sr.base[5]; isc_region_consume(&sr, 6); /* diff --git a/contrib/bind9/lib/dns/rdata/generic/ds_43.c b/contrib/bind9/lib/dns/rdata/generic/ds_43.c index 538f86571d8..0206b6f06c2 100644 --- a/contrib/bind9/lib/dns/rdata/generic/ds_43.c +++ b/contrib/bind9/lib/dns/rdata/generic/ds_43.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ds_43.c,v 1.6.2.2 2004/03/16 12:38:14 marka Exp $ */ +/* $Id: ds_43.c,v 1.6.2.4 2005/09/06 07:29:31 marka Exp $ */ /* draft-ietf-dnsext-delegation-signer-05.txt */ @@ -28,6 +28,7 @@ static inline isc_result_t fromtext_ds(ARGS_FROMTEXT) { isc_token_t token; + unsigned char c; REQUIRE(type == 43); @@ -49,11 +50,10 @@ fromtext_ds(ARGS_FROMTEXT) { /* * Algorithm. */ - RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, ISC_FALSE)); - if (token.value.as_ulong > 0xffU) - RETTOK(ISC_R_RANGE); - RETERR(uint8_tobuffer(token.value.as_ulong, target)); + RETTOK(dns_secalg_fromtext(&c, &token.value.as_textregion)); + RETERR(mem_tobuffer(target, &c, 1)); /* * Digest type. diff --git a/contrib/bind9/lib/dns/rdata/generic/rt_21.c b/contrib/bind9/lib/dns/rdata/generic/rt_21.c index 0f568e3bdfd..daf9756ff98 100644 --- a/contrib/bind9/lib/dns/rdata/generic/rt_21.c +++ b/contrib/bind9/lib/dns/rdata/generic/rt_21.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rt_21.c,v 1.37.2.1.2.3 2004/03/06 08:14:11 marka Exp $ */ +/* $Id: rt_21.c,v 1.37.2.1.2.5 2005/03/17 03:58:31 marka Exp $ */ /* reviewed: Thu Mar 16 15:02:31 PST 2000 by brister */ @@ -300,7 +300,7 @@ checknames_rt(ARGS_CHECKNAMES) { isc_region_consume(®ion, 2); dns_name_init(&name, NULL); dns_name_fromregion(&name, ®ion); - if (dns_name_ishostname(&name, ISC_FALSE)) { + if (!dns_name_ishostname(&name, ISC_FALSE)) { if (bad != NULL) dns_name_clone(&name, bad); return (ISC_FALSE); diff --git a/contrib/bind9/lib/dns/resolver.c b/contrib/bind9/lib/dns/resolver.c index 790a2f41686..6f803eb192f 100644 --- a/contrib/bind9/lib/dns/resolver.c +++ b/contrib/bind9/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.218.2.18.4.51 2005/02/08 23:59:44 marka Exp $ */ +/* $Id: resolver.c,v 1.218.2.18.4.56 2005/10/14 01:38:48 marka Exp $ */ #include @@ -244,6 +244,11 @@ struct fetchctx { #define TRIEDFIND(f) (((f)->attributes & FCTX_ATTR_TRIEDFIND) != 0) #define TRIEDALT(f) (((f)->attributes & FCTX_ATTR_TRIEDALT) != 0) +typedef struct { + dns_adbaddrinfo_t * addrinfo; + fetchctx_t * fctx; +} dns_valarg_t; + struct dns_fetch { unsigned int magic; fetchctx_t * private; @@ -342,6 +347,35 @@ static isc_result_t ncache_adderesult(dns_message_t *message, isc_stdtime_t now, dns_ttl_t maxttl, dns_rdataset_t *ardataset, isc_result_t *eresultp); +static void validated(isc_task_t *task, isc_event_t *event); + +static isc_result_t +valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name, + dns_rdatatype_t type, dns_rdataset_t *rdataset, + dns_rdataset_t *sigrdataset, unsigned int valoptions, + isc_task_t *task) +{ + dns_validator_t *validator = NULL; + dns_valarg_t *valarg; + isc_result_t result; + + valarg = isc_mem_get(fctx->res->mctx, sizeof(*valarg)); + if (valarg == NULL) + return (ISC_R_NOMEMORY); + + valarg->fctx = fctx; + valarg->addrinfo = addrinfo; + + result = dns_validator_create(fctx->res->view, name, type, rdataset, + sigrdataset, fctx->rmessage, + valoptions, task, validated, valarg, + &validator); + if (result == ISC_R_SUCCESS) + ISC_LIST_APPEND(fctx->validators, validator, link); + else + isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg)); + return (result); +} static isc_boolean_t fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) { @@ -1424,6 +1458,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) { case ISC_R_CONNREFUSED: case ISC_R_NOPERM: case ISC_R_ADDRNOTAVAIL: + case ISC_R_CONNECTIONRESET: /* * No route to remote. */ @@ -1855,7 +1890,6 @@ fctx_getaddresses(fetchctx_t *fctx) { isc_boolean_t pruned, all_bad; dns_rdata_ns_t ns; isc_boolean_t need_alternate = ISC_FALSE; - isc_boolean_t unshared; FCTXTRACE("getaddresses"); @@ -1871,7 +1905,6 @@ fctx_getaddresses(fetchctx_t *fctx) { res = fctx->res; pruned = ISC_FALSE; stdoptions = 0; /* Keep compiler happy. */ - unshared = ISC_TF((fctx->options | DNS_FETCHOPT_UNSHARED) != 0); /* * Forwarders. @@ -2668,7 +2701,7 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, isc_result_t result; isc_result_t iresult; isc_interval_t interval; - dns_fixedname_t qdomain; + dns_fixedname_t fixed; unsigned int findoptions = 0; char buf[DNS_NAME_FORMATSIZE + DNS_RDATATYPE_FORMATSIZE]; char typebuf[DNS_RDATATYPE_FORMATSIZE]; @@ -2747,8 +2780,10 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, dns_name_getlabelsequence(name, 1, labels - 1, &suffix); name = &suffix; } - result = dns_fwdtable_find(fctx->res->view->fwdtable, name, - &forwarders); + dns_fixedname_init(&fixed); + domain = dns_fixedname_name(&fixed); + result = dns_fwdtable_find2(fctx->res->view->fwdtable, name, + domain, &forwarders); if (result == ISC_R_SUCCESS) fctx->fwdpolicy = forwarders->fwdpolicy; @@ -2760,27 +2795,22 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type, */ if (dns_rdatatype_atparent(type)) findoptions |= DNS_DBFIND_NOEXACT; - dns_fixedname_init(&qdomain); - result = dns_view_findzonecut(res->view, name, - dns_fixedname_name(&qdomain), 0, - findoptions, ISC_TRUE, + result = dns_view_findzonecut(res->view, name, domain, + 0, findoptions, ISC_TRUE, &fctx->nameservers, NULL); if (result != ISC_R_SUCCESS) goto cleanup_name; - result = dns_name_dup(dns_fixedname_name(&qdomain), - res->mctx, &fctx->domain); + result = dns_name_dup(domain, res->mctx, &fctx->domain); if (result != ISC_R_SUCCESS) { dns_rdataset_disassociate(&fctx->nameservers); goto cleanup_name; } } else { /* - * We're in forward-only mode. Set the query domain - * to ".". + * We're in forward-only mode. Set the query domain. */ - result = dns_name_dup(dns_rootname, res->mctx, - &fctx->domain); + result = dns_name_dup(domain, res->mctx, &fctx->domain); if (result != ISC_R_SUCCESS) goto cleanup_name; } @@ -3090,11 +3120,15 @@ validated(isc_task_t *task, isc_event_t *event) { dns_name_t *name; dns_rdataset_t *rdataset; dns_rdataset_t *sigrdataset; + dns_valarg_t *valarg; + dns_adbaddrinfo_t *addrinfo; UNUSED(task); /* for now */ REQUIRE(event->ev_type == DNS_EVENT_VALIDATORDONE); - fctx = event->ev_arg; + valarg = event->ev_arg; + fctx = valarg->fctx; + addrinfo = valarg->addrinfo; REQUIRE(VALID_FCTX(fctx)); REQUIRE(!ISC_LIST_EMPTY(fctx->validators)); @@ -3109,6 +3143,7 @@ validated(isc_task_t *task, isc_event_t *event) { * destroy the fctx if necessary. */ dns_validator_destroy(&vevent->validator); + isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg)); negative = ISC_TF(vevent->rdataset == NULL); @@ -3166,21 +3201,27 @@ validated(isc_task_t *task, isc_event_t *event) { if (vevent->result != ISC_R_SUCCESS) { FCTXTRACE("validation failed"); - if (vevent->rdataset != NULL) { + result = ISC_R_NOTFOUND; + if (vevent->rdataset != NULL) result = dns_db_findnode(fctx->cache, vevent->name, ISC_TRUE, &node); - if (result != ISC_R_SUCCESS) - goto noanswer_response; + if (result == ISC_R_SUCCESS) (void)dns_db_deleterdataset(fctx->cache, node, NULL, vevent->type, 0); - if (vevent->sigrdataset != NULL) - (void)dns_db_deleterdataset(fctx->cache, - node, NULL, - dns_rdatatype_rrsig, - vevent->type); - } + if (result == ISC_R_SUCCESS && vevent->sigrdataset != NULL) + (void)dns_db_deleterdataset(fctx->cache, node, NULL, + dns_rdatatype_rrsig, + vevent->type); + if (result == ISC_R_SUCCESS) + dns_db_detachnode(fctx->cache, &node); result = vevent->result; - goto noanswer_response; + add_bad(fctx, &addrinfo->sockaddr, result); + isc_event_free(&event); + if (sentresponse) + fctx_done(fctx, result); + else + fctx_try(fctx); + return; } isc_stdtime_get(&now); @@ -3350,7 +3391,8 @@ validated(isc_task_t *task, isc_event_t *event) { } static inline isc_result_t -cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { +cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo, + isc_stdtime_t now) { dns_rdataset_t *rdataset, *sigrdataset; dns_rdataset_t *addedrdataset, *ardataset, *asigrdataset; dns_rdataset_t *valrdataset = NULL, *valsigrdataset = NULL; @@ -3363,8 +3405,8 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { dns_fetchevent_t *event; unsigned int options; isc_task_t *task; - dns_validator_t *validator; isc_boolean_t fail; + unsigned int valoptions = 0; /* * The appropriate bucket lock must be held. @@ -3385,8 +3427,10 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { if (result != ISC_R_SUCCESS) return (result); - if (res->view->dlv != NULL) + if (!secure_domain && res->view->dlv != NULL) { + valoptions = DNS_VALIDATOR_DLV; secure_domain = ISC_TRUE; + } if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0) need_validation = ISC_FALSE; @@ -3437,7 +3481,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { /* * Cache or validate each cacheable rdataset. */ - fail = (fctx->res->options & DNS_RESOLVER_CHECKNAMESFAIL) != 0; + fail = ISC_TF((fctx->res->options & DNS_RESOLVER_CHECKNAMESFAIL) != 0); for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL; rdataset = ISC_LIST_NEXT(rdataset, link)) { @@ -3569,23 +3613,11 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { * having to remember which * rdatasets needed validation. */ - validator = NULL; - result = dns_validator_create( - res->view, - name, - rdataset->type, - rdataset, - sigrdataset, - fctx->rmessage, - 0, - task, - validated, - fctx, - &validator); - if (result == ISC_R_SUCCESS) - ISC_LIST_APPEND( - fctx->validators, - validator, link); + result = valcreate(fctx, addrinfo, + name, rdataset->type, + rdataset, + sigrdataset, + valoptions, task); } } else if (CHAINING(rdataset)) { if (rdataset->type == dns_rdatatype_cname) @@ -3660,22 +3692,10 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { } } - if (valrdataset != NULL) { - validator = NULL; - result = dns_validator_create(res->view, - name, - fctx->type, - valrdataset, - valsigrdataset, - fctx->rmessage, - 0, - task, - validated, - fctx, - &validator); - if (result == ISC_R_SUCCESS) - ISC_LIST_APPEND(fctx->validators, validator, link); - } + if (valrdataset != NULL) + result = valcreate(fctx, addrinfo, name, fctx->type, + valrdataset, valsigrdataset, valoptions, + task); if (result == ISC_R_SUCCESS && have_answer) { fctx->attributes |= FCTX_ATTR_HAVEANSWER; @@ -3695,7 +3715,8 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) { } static inline isc_result_t -cache_message(fetchctx_t *fctx, isc_stdtime_t now) { +cache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_stdtime_t now) +{ isc_result_t result; dns_section_t section; dns_name_t *name; @@ -3715,7 +3736,7 @@ cache_message(fetchctx_t *fctx, isc_stdtime_t now) { dns_message_currentname(fctx->rmessage, section, &name); if ((name->attributes & DNS_NAMEATTR_CACHE) != 0) { - result = cache_name(fctx, name, now); + result = cache_name(fctx, name, addrinfo, now); if (result != ISC_R_SUCCESS) break; } @@ -3783,7 +3804,9 @@ ncache_adderesult(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node, } static inline isc_result_t -ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) { +ncache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, + dns_rdatatype_t covers, isc_stdtime_t now) +{ isc_result_t result, eresult; dns_name_t *name; dns_resolver_t *res; @@ -3794,6 +3817,7 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) { dns_name_t *aname; dns_fetchevent_t *event; isc_uint32_t ttl; + unsigned int valoptions = 0; FCTXTRACE("ncache_message"); @@ -3820,8 +3844,10 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) { if (result != ISC_R_SUCCESS) return (result); - if (res->view->dlv != NULL) + if (!secure_domain && res->view->dlv != NULL) { + valoptions = DNS_VALIDATOR_DLV; secure_domain = ISC_TRUE; + } if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0) need_validation = ISC_FALSE; @@ -3858,23 +3884,15 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) { /* * Do negative response validation. */ - dns_validator_t *validator = NULL; - isc_task_t *task = res->buckets[fctx->bucketnum].task; - - result = dns_validator_create(res->view, name, fctx->type, - NULL, NULL, - fctx->rmessage, 0, task, - validated, fctx, - &validator); - if (result != ISC_R_SUCCESS) - return (result); - ISC_LIST_APPEND(fctx->validators, validator, link); + result = valcreate(fctx, addrinfo, name, fctx->type, + NULL, NULL, valoptions, + res->buckets[fctx->bucketnum].task); /* * If validation is necessary, return now. Otherwise continue * to process the message, letting the validation complete * in its own good time. */ - return (ISC_R_SUCCESS); + return (result); } LOCK(&res->buckets[fctx->bucketnum].lock); @@ -4991,6 +5009,43 @@ checknames(dns_message_t *message) { checknamessection(message, DNS_SECTION_ADDITIONAL); } +static void +log_packet(dns_message_t *message, int level, isc_mem_t *mctx) { + isc_buffer_t buffer; + char *buf = NULL; + int len = 1024; + isc_result_t result; + + if (! isc_log_wouldlog(dns_lctx, level)) + return; + + /* + * Note that these are multiline debug messages. We want a newline + * to appear in the log after each message. + */ + + do { + buf = isc_mem_get(mctx, len); + if (buf == NULL) + break; + isc_buffer_init(&buffer, buf, len); + result = dns_message_totext(message, &dns_master_style_debug, + 0, &buffer); + if (result == ISC_R_NOSPACE) { + isc_mem_put(mctx, buf, len); + len += 1024; + } else if (result == ISC_R_SUCCESS) + isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER, + DNS_LOGMODULE_RESOLVER, level, + "received packet:\n%.*s", + (int)isc_buffer_usedlength(&buffer), + buf); + } while (result == ISC_R_NOSPACE); + + if (buf != NULL) + isc_mem_put(mctx, buf, len); +} + static void resquery_response(isc_task_t *task, isc_event_t *event) { isc_result_t result = ISC_R_SUCCESS; @@ -5159,6 +5214,11 @@ resquery_response(isc_task_t *task, isc_event_t *event) { } } + /* + * Log the incoming packet. + */ + log_packet(message, ISC_LOG_DEBUG(10), fctx->res->mctx); + /* * If the message is signed, check the signature. If not, this * returns success anyway. @@ -5427,7 +5487,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) { * work to be queued to the DNSSEC validator. */ if (WANTCACHE(fctx)) { - result = cache_message(fctx, now); + result = cache_message(fctx, query->addrinfo, now); if (result != ISC_R_SUCCESS) goto done; } @@ -5446,7 +5506,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) { /* * Cache any negative cache entries in the message. */ - result = ncache_message(fctx, covers, now); + result = ncache_message(fctx, query->addrinfo, covers, now); } done: diff --git a/contrib/bind9/lib/dns/tkey.c b/contrib/bind9/lib/dns/tkey.c index dc49a337ad3..43c8db0e57c 100644 --- a/contrib/bind9/lib/dns/tkey.c +++ b/contrib/bind9/lib/dns/tkey.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -16,7 +16,7 @@ */ /* - * $Id: tkey.c,v 1.71.2.1.10.5 2004/06/11 00:30:54 marka Exp $ + * $Id: tkey.c,v 1.71.2.1.10.7 2005/06/12 00:02:26 marka Exp $ */ #include @@ -356,7 +356,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, isc_buffer_init(&secret, secretdata, sizeof(secretdata)); - randomdata = isc_mem_get(tctx->mctx, TKEY_RANDOM_AMOUNT); + randomdata = isc_mem_get(tkeyout->mctx, TKEY_RANDOM_AMOUNT); if (randomdata == NULL) goto failure; @@ -397,8 +397,8 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, isc_buffer_free(&shared); if (pubkey != NULL) dst_key_free(&pubkey); - if (randomdata == NULL) - isc_mem_put(tctx->mctx, randomdata, TKEY_RANDOM_AMOUNT); + if (randomdata != NULL) + isc_mem_put(tkeyout->mctx, randomdata, TKEY_RANDOM_AMOUNT); return (result); } diff --git a/contrib/bind9/lib/dns/tsig.c b/contrib/bind9/lib/dns/tsig.c index fb1ac823eac..6a8d774a270 100644 --- a/contrib/bind9/lib/dns/tsig.c +++ b/contrib/bind9/lib/dns/tsig.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -16,7 +16,7 @@ */ /* - * $Id: tsig.c,v 1.112.2.3.8.4 2004/03/08 09:04:32 marka Exp $ + * $Id: tsig.c,v 1.112.2.3.8.6 2005/03/17 03:58:31 marka Exp $ */ #include @@ -167,7 +167,7 @@ dns_tsigkey_createfromkey(dns_name_t *name, dns_name_t *algorithm, goto cleanup_name; } } else { - if (key != NULL) { + if (dstkey != NULL) { ret = DNS_R_BADALG; goto cleanup_name; } diff --git a/contrib/bind9/lib/dns/validator.c b/contrib/bind9/lib/dns/validator.c index 069b9c228f9..a62db341376 100644 --- a/contrib/bind9/lib/dns/validator.c +++ b/contrib/bind9/lib/dns/validator.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.c,v 1.91.2.5.8.15 2005/02/09 05:13:02 marka Exp $ */ +/* $Id: validator.c,v 1.91.2.5.8.21 2005/11/02 02:07:47 marka Exp $ */ #include @@ -51,9 +51,7 @@ #define VALATTR_TRIEDVERIFY 0x0004 #define VALATTR_NEGATIVE 0x0008 #define VALATTR_INSECURITY 0x0010 -#define VALATTR_DLV 0x0020 -#define VALATTR_DLVTRIED 0x0040 -#define VALATTR_DLVSEPTRIED 0x0080 +#define VALATTR_DLVTRIED 0x0020 #define VALATTR_NEEDNOQNAME 0x0100 #define VALATTR_NEEDNOWILDCARD 0x0200 @@ -63,13 +61,10 @@ #define VALATTR_FOUNDNOWILDCARD 0x2000 #define VALATTR_FOUNDNODATA 0x4000 - #define NEEDNODATA(val) ((val->attributes & VALATTR_NEEDNODATA) != 0) #define NEEDNOQNAME(val) ((val->attributes & VALATTR_NEEDNOQNAME) != 0) #define NEEDNOWILDCARD(val) ((val->attributes & VALATTR_NEEDNOWILDCARD) != 0) -#define DLV(val) ((val->attributes & VALATTR_DLV) != 0) #define DLVTRIED(val) ((val->attributes & VALATTR_DLVTRIED) != 0) -#define DLVSEPTRIED(val) ((val->attributes & VALATTR_DLVSEPTRIED) != 0) #define SHUTDOWN(v) (((v)->attributes & VALATTR_SHUTDOWN) != 0) @@ -109,9 +104,21 @@ validator_logcreate(dns_validator_t *val, static isc_result_t dlv_validatezonekey(dns_validator_t *val); +static isc_result_t +dlv_validator_start(dns_validator_t *val); + static isc_result_t finddlvsep(dns_validator_t *val, isc_boolean_t resume); +static inline void +markanswer(dns_validator_t *val) { + validator_log(val, ISC_LOG_DEBUG(3), "marking as answer"); + if (val->event->rdataset) + val->event->rdataset->trust = dns_trust_answer; + if (val->event->sigrdataset) + val->event->sigrdataset->trust = dns_trust_answer; +} + static void validator_done(dns_validator_t *val, isc_result_t result) { isc_task_t *task; @@ -219,6 +226,13 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) { rdataset = &val->frdataset; eresult = devent->result; + /* Free resources which are not of interest. */ + if (devent->node != NULL) + dns_db_detachnode(devent->db, &devent->node); + if (devent->db != NULL) + dns_db_detach(&devent->db); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); isc_event_free(&event); dns_resolver_destroyfetch(&val->fetch); @@ -271,6 +285,13 @@ dsfetched(isc_task_t *task, isc_event_t *event) { rdataset = &val->frdataset; eresult = devent->result; + /* Free resources which are not of interest. */ + if (devent->node != NULL) + dns_db_detachnode(devent->db, &devent->node); + if (devent->db != NULL) + dns_db_detach(&devent->db); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); isc_event_free(&event); dns_resolver_destroyfetch(&val->fetch); @@ -285,18 +306,6 @@ dsfetched(isc_task_t *task, isc_event_t *event) { result = validatezonekey(val); if (result != DNS_R_WAIT) validator_done(val, result); - } else if (val->view->dlv != NULL && !DLVTRIED(val) && - (eresult == DNS_R_NXRRSET || - eresult == DNS_R_NCACHENXRRSET) && - !dns_name_issubdomain(val->event->name, - val->view->dlv)) - { - validator_log(val, ISC_LOG_DEBUG(2), - "no DS record: looking for DLV"); - - result = dlv_validatezonekey(val); - if (result != DNS_R_WAIT) - validator_done(val, result); } else if (eresult == DNS_R_NXRRSET || eresult == DNS_R_NCACHENXRRSET) { @@ -328,7 +337,6 @@ static void dsfetched2(isc_task_t *task, isc_event_t *event) { dns_fetchevent_t *devent; dns_validator_t *val; - dns_rdataset_t *rdataset; dns_name_t *tname; isc_boolean_t want_destroy; isc_result_t result; @@ -338,9 +346,15 @@ dsfetched2(isc_task_t *task, isc_event_t *event) { INSIST(event->ev_type == DNS_EVENT_FETCHDONE); devent = (dns_fetchevent_t *)event; val = devent->ev_arg; - rdataset = &val->frdataset; eresult = devent->result; + /* Free resources which are not of interest. */ + if (devent->node != NULL) + dns_db_detachnode(devent->db, &devent->node); + if (devent->db != NULL) + dns_db_detach(&devent->db); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); dns_resolver_destroyfetch(&val->fetch); INSIST(val->event != NULL); @@ -358,7 +372,7 @@ dsfetched2(isc_task_t *task, isc_event_t *event) { "must be secure failure"); validator_done(val, DNS_R_MUSTBESECURE); } else { - val->event->rdataset->trust = dns_trust_answer; + markanswer(val); validator_done(val, ISC_R_SUCCESS); } } else { @@ -553,7 +567,7 @@ nsecnoexistnodata(dns_validator_t *val, dns_name_t* name, dns_name_t *nsecname, "nsec proves name exists (owner) data=%d", *data); return (ISC_R_SUCCESS); - } + } if (relation == dns_namereln_subdomain && dns_nsec_typepresent(&rdata, dns_rdatatype_ns) && @@ -627,7 +641,7 @@ static void authvalidated(isc_task_t *task, isc_event_t *event) { dns_validatorevent_t *devent; dns_validator_t *val; - dns_rdataset_t *rdataset, *sigrdataset; + dns_rdataset_t *rdataset; isc_boolean_t want_destroy; isc_result_t result; isc_boolean_t exists, data; @@ -637,7 +651,6 @@ authvalidated(isc_task_t *task, isc_event_t *event) { devent = (dns_validatorevent_t *)event; rdataset = devent->rdataset; - sigrdataset = devent->sigrdataset; val = devent->ev_arg; result = devent->result; dns_validator_destroy(&val->subvalidator); @@ -916,8 +929,10 @@ create_validator(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type, rdataset, sigrdataset, NULL, 0, val->task, action, val, &val->subvalidator); - if (result == ISC_R_SUCCESS) + if (result == ISC_R_SUCCESS) { val->subvalidator->parent = val; + val->subvalidator->depth = val->depth + 1; + } return (result); } @@ -1252,10 +1267,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) { "must be secure failure"); return (DNS_R_MUSTBESECURE); } - event->rdataset->trust = dns_trust_answer; - event->sigrdataset->trust = dns_trust_answer; - validator_log(val, ISC_LOG_DEBUG(3), - "marking as answer"); + markanswer(val); return (ISC_R_SUCCESS); } @@ -1344,110 +1356,9 @@ validate(dns_validator_t *val, isc_boolean_t resume) { return (DNS_R_NOVALIDSIG); } - -static void -dlv_validated(isc_task_t *task, isc_event_t *event) { - dns_validatorevent_t *devent; - dns_validator_t *val; - isc_boolean_t want_destroy; - isc_result_t result; - isc_result_t eresult; - - UNUSED(task); - INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE); - - devent = (dns_validatorevent_t *)event; - val = devent->ev_arg; - eresult = devent->result; - - isc_event_free(&event); - dns_validator_destroy(&val->subvalidator); - - INSIST(val->event != NULL); - - validator_log(val, ISC_LOG_DEBUG(3), "in dsvalidated"); - LOCK(&val->lock); - if (eresult == ISC_R_SUCCESS) { - validator_log(val, ISC_LOG_DEBUG(3), - "dlv with trust %d", val->frdataset.trust); - if ((val->attributes & VALATTR_INSECURITY) != 0) - result = proveunsecure(val, ISC_TRUE); - else - result = validatezonekey(val); - if (result != DNS_R_WAIT) - validator_done(val, result); - } else { - validator_log(val, ISC_LOG_DEBUG(3), - "dlv_validated: got %s", - isc_result_totext(eresult)); - validator_done(val, eresult); - } - want_destroy = exit_check(val); - UNLOCK(&val->lock); - if (want_destroy) - destroy(val); -} - -static void -dlv_fetched(isc_task_t *task, isc_event_t *event) { - dns_fetchevent_t *devent; - dns_validator_t *val; - dns_rdataset_t *rdataset; - isc_boolean_t want_destroy; - isc_result_t result; - isc_result_t eresult; - - UNUSED(task); - INSIST(event->ev_type == DNS_EVENT_FETCHDONE); - devent = (dns_fetchevent_t *)event; - val = devent->ev_arg; - rdataset = &val->frdataset; - eresult = devent->result; - - isc_event_free(&event); - dns_resolver_destroyfetch(&val->fetch); - - INSIST(val->event != NULL); - - validator_log(val, ISC_LOG_DEBUG(3), "in dlv_fetched"); - LOCK(&val->lock); - if (eresult == ISC_R_SUCCESS) { - validator_log(val, ISC_LOG_DEBUG(3), - "dlv set with trust %d", rdataset->trust); - val->dlv = &val->frdataset; - result = dlv_validatezonekey(val); - if (result != DNS_R_WAIT) - validator_done(val, result); - } else if (eresult == DNS_R_NXRRSET || - eresult == DNS_R_NCACHENXRRSET) - { - validator_log(val, ISC_LOG_DEBUG(3), - "falling back to insecurity proof"); - val->attributes |= VALATTR_INSECURITY; - result = proveunsecure(val, ISC_FALSE); - if (result != DNS_R_WAIT) - validator_done(val, result); - } else { - validator_log(val, ISC_LOG_DEBUG(3), - "dlv_fetched: got %s", - isc_result_totext(eresult)); - if (eresult == ISC_R_CANCELED) - validator_done(val, eresult); - else - validator_done(val, DNS_R_NOVALIDDS); - } - want_destroy = exit_check(val); - UNLOCK(&val->lock); - if (want_destroy) - destroy(val); -} - static isc_result_t dlv_validatezonekey(dns_validator_t *val) { - dns_fixedname_t fixed; dns_keytag_t keytag; - dns_name_t *name; - dns_name_t tname; dns_rdata_dlv_t dlv; dns_rdata_dnskey_t key; dns_rdata_rrsig_t sig; @@ -1460,91 +1371,8 @@ dlv_validatezonekey(dns_validator_t *val) { isc_boolean_t supported_algorithm; isc_result_t result; unsigned char dsbuf[DNS_DS_BUFFERSIZE]; - unsigned int labels; - - val->attributes |= VALATTR_DLVTRIED; - - dns_name_init(&tname, NULL); - dns_fixedname_init(&fixed); - name = dns_fixedname_name(&fixed); - labels = dns_name_countlabels(val->event->name); - dns_name_getlabelsequence(val->event->name, 0, labels - 1, &tname); - result = dns_name_concatenate(&tname, val->view->dlv, name, NULL); - if (result != ISC_R_SUCCESS) { - validator_log(val, ISC_LOG_DEBUG(2), - "DLV concatenate failed"); - return (DNS_R_NOVALIDSIG); - } - if (val->dlv == NULL) { - result = view_find(val, name, dns_rdatatype_dlv); - if (result == ISC_R_SUCCESS) { - /* - * We have DLV records. - */ - val->dsset = &val->frdataset; - if (val->frdataset.trust == dns_trust_pending && - dns_rdataset_isassociated(&val->fsigrdataset)) - { - result = create_validator(val, - val->event->name, - dns_rdatatype_ds, - &val->frdataset, - &val->fsigrdataset, - dlv_validated, - "dlv_validatezonekey"); - if (result != ISC_R_SUCCESS) - return (result); - return (DNS_R_WAIT); - } else if (val->frdataset.trust == dns_trust_pending) { - /* - * There should never be an unsigned DLV. - */ - dns_rdataset_disassociate(&val->frdataset); - validator_log(val, ISC_LOG_DEBUG(2), - "unsigned DLV record"); - return (DNS_R_NOVALIDSIG); - } else - result = ISC_R_SUCCESS; - } else if (result == ISC_R_NOTFOUND) { - result = create_fetch(val, name, dns_rdatatype_dlv, - dlv_fetched, - "dlv_validatezonekey"); - if (result != ISC_R_SUCCESS) - return (result); - return (DNS_R_WAIT); - } else if (result == DNS_R_NCACHENXDOMAIN || - result == DNS_R_NCACHENXRRSET || - result == DNS_R_NXDOMAIN || - result == DNS_R_NXRRSET) - { - /* - * The DS does not exist. - */ - if (dns_rdataset_isassociated(&val->frdataset)) - dns_rdataset_disassociate(&val->frdataset); - if (dns_rdataset_isassociated(&val->fsigrdataset)) - dns_rdataset_disassociate(&val->fsigrdataset); - validator_log(val, ISC_LOG_DEBUG(2), "no DLV record"); - return (DNS_R_NOVALIDSIG); - } - } - - /* - * We have a DLV set. - */ - INSIST(val->dlv != NULL); - - if (val->dlv->trust < dns_trust_secure) { - if (val->mustbesecure) { - validator_log(val, ISC_LOG_WARNING, - "must be secure failure"); - return (DNS_R_MUSTBESECURE); - } - val->event->rdataset->trust = dns_trust_answer; - val->event->sigrdataset->trust = dns_trust_answer; - return (ISC_R_SUCCESS); - } + validator_log(val, ISC_LOG_DEBUG(3), "dlv_validatezonekey"); /* * Look through the DLV record and find the keys that can sign the * key set and the matching signature. For each such key, attempt @@ -1553,15 +1381,16 @@ dlv_validatezonekey(dns_validator_t *val) { supported_algorithm = ISC_FALSE; - for (result = dns_rdataset_first(val->dlv); + for (result = dns_rdataset_first(&val->dlv); result == ISC_R_SUCCESS; - result = dns_rdataset_next(val->dlv)) + result = dns_rdataset_next(&val->dlv)) { dns_rdata_reset(&dlvrdata); - dns_rdataset_current(val->dlv, &dlvrdata); + dns_rdataset_current(&val->dlv, &dlvrdata); (void)dns_rdata_tostruct(&dlvrdata, &dlv, NULL); - if (!dns_resolver_algorithm_supported(val->view->resolver, + if (dlv.digest_type != DNS_DSDIGEST_SHA1 || + !dns_resolver_algorithm_supported(val->view->resolver, val->event->name, dlv.algorithm)) continue; @@ -1586,8 +1415,12 @@ dlv_validatezonekey(dns_validator_t *val) { result = dns_ds_buildrdata(val->event->name, &keyrdata, dlv.digest_type, dsbuf, &newdsrdata); - if (result != ISC_R_SUCCESS) + if (result != ISC_R_SUCCESS) { + validator_log(val, ISC_LOG_DEBUG(3), + "dns_ds_buildrdata() -> %s", + dns_result_totext(result)); continue; + } /* Covert to DLV */ newdsrdata.type = dns_rdatatype_dlv; if (dns_rdata_compare(&dlvrdata, &newdsrdata) == 0) @@ -1598,7 +1431,9 @@ dlv_validatezonekey(dns_validator_t *val) { "no DNSKEY matching DLV"); continue; } - + validator_log(val, ISC_LOG_DEBUG(3), + "Found matching DLV record: checking for signature"); + for (result = dns_rdataset_first(val->event->sigrdataset); result == ISC_R_SUCCESS; result = dns_rdataset_next(val->event->sigrdataset)) @@ -1610,7 +1445,6 @@ dlv_validatezonekey(dns_validator_t *val) { if (dlv.key_tag != sig.keyid && dlv.algorithm != sig.algorithm) continue; - dstkey = NULL; result = dns_dnssec_keyfromrdata(val->event->name, &keyrdata, @@ -1644,10 +1478,9 @@ dlv_validatezonekey(dns_validator_t *val) { "must be secure failure"); return (DNS_R_MUSTBESECURE); } - val->event->rdataset->trust = dns_trust_answer; - val->event->sigrdataset->trust = dns_trust_answer; validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (dlv)"); + "no supported algorithm/digest (dlv)"); + markanswer(val); return (ISC_R_SUCCESS); } else return (DNS_R_NOVALIDSIG); @@ -1685,6 +1518,10 @@ validatezonekey(dns_validator_t *val) { event = val->event; + if (val->havedlvsep && val->dlv.trust >= dns_trust_secure && + dns_name_equal(event->name, dns_fixedname_name(&val->dlvsep))) + return (dlv_validatezonekey(val)); + if (val->dsset == NULL) { /* * First, see if this key was signed by a trusted key. @@ -1783,22 +1620,6 @@ validatezonekey(dns_validator_t *val) { if (result != ISC_R_SUCCESS) return (result); return (DNS_R_WAIT); - } else if (val->view->dlv != NULL && !DLVTRIED(val) && - (result == DNS_R_NCACHENXRRSET || - result == DNS_R_NXRRSET) && - !dns_name_issubdomain(val->event->name, - val->view->dlv)) - { - - if (dns_rdataset_isassociated(&val->frdataset)) - dns_rdataset_disassociate(&val->frdataset); - if (dns_rdataset_isassociated(&val->fsigrdataset)) - dns_rdataset_disassociate(&val->fsigrdataset); - - validator_log(val, ISC_LOG_DEBUG(2), - "no DS record: looking for DLV"); - - return (dlv_validatezonekey(val)); } else if (result == DNS_R_NCACHENXDOMAIN || result == DNS_R_NCACHENXRRSET || result == DNS_R_NXDOMAIN || @@ -1827,8 +1648,7 @@ validatezonekey(dns_validator_t *val) { "must be secure failure"); return (DNS_R_MUSTBESECURE); } - val->event->rdataset->trust = dns_trust_answer; - val->event->sigrdataset->trust = dns_trust_answer; + markanswer(val); return (ISC_R_SUCCESS); } @@ -1848,6 +1668,8 @@ validatezonekey(dns_validator_t *val) { dns_rdataset_current(val->dsset, &dsrdata); (void)dns_rdata_tostruct(&dsrdata, &ds, NULL); + if (ds.digest_type != DNS_DSDIGEST_SHA1) + continue; if (!dns_resolver_algorithm_supported(val->view->resolver, val->event->name, ds.algorithm)) @@ -1923,24 +1745,15 @@ validatezonekey(dns_validator_t *val) { event->sigrdataset->trust = dns_trust_secure; validator_log(val, ISC_LOG_DEBUG(3), "marking as secure"); return (result); - } else if (result == ISC_R_NOMORE && val->view->dlv != NULL && - !DLVTRIED(val) && !dns_name_issubdomain(val->event->name, - val->view->dlv)) - { - validator_log(val, ISC_LOG_DEBUG(2), - "no DS/DNSKEY pair: looking for DLV"); - - return (dlv_validatezonekey(val)); } else if (result == ISC_R_NOMORE && !supported_algorithm) { if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, "must be secure failure"); return (DNS_R_MUSTBESECURE); } - val->event->rdataset->trust = dns_trust_answer; - val->event->sigrdataset->trust = dns_trust_answer; validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); + "no supported algorithm/digest (DS)"); + markanswer(val); return (ISC_R_SUCCESS); } else return (DNS_R_NOVALIDSIG); @@ -2174,7 +1987,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) { if ((val->attributes & VALATTR_FOUNDNONEXISTENCE) == 0) { if (!val->seensig && val->soaset != NULL) { - result = create_validator(val, name, dns_rdatatype_soa, + result = create_validator(val, val->soaname, + dns_rdatatype_soa, val->soaset, NULL, negauthvalidated, "nsecvalidate"); @@ -2193,8 +2007,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) { } static isc_boolean_t -check_ds_algorithm(dns_validator_t *val, dns_name_t *name, - dns_rdataset_t *rdataset) { +check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) { dns_rdata_t dsrdata = DNS_RDATA_INIT; dns_rdata_ds_t ds; isc_result_t result; @@ -2205,16 +2018,20 @@ check_ds_algorithm(dns_validator_t *val, dns_name_t *name, dns_rdataset_current(rdataset, &dsrdata); (void)dns_rdata_tostruct(&dsrdata, &ds, NULL); - if (dns_resolver_algorithm_supported(val->view->resolver, - name, ds.algorithm)) + if (ds.digest_type == DNS_DSDIGEST_SHA1 && + dns_resolver_algorithm_supported(val->view->resolver, + name, ds.algorithm)) { + dns_rdata_reset(&dsrdata); return (ISC_TRUE); + } dns_rdata_reset(&dsrdata); } return (ISC_FALSE); } static void -dlv_fetched2(isc_task_t *task, isc_event_t *event) { +dlvfetched(isc_task_t *task, isc_event_t *event) { + char namebuf[DNS_NAME_FORMATSIZE]; dns_fetchevent_t *devent; dns_validator_t *val; isc_boolean_t want_destroy; @@ -2226,18 +2043,29 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) { devent = (dns_fetchevent_t *)event; val = devent->ev_arg; eresult = devent->result; - + + /* Free resources which are not of interest. */ + if (devent->node != NULL) + dns_db_detachnode(devent->db, &devent->node); + if (devent->db != NULL) + dns_db_detach(&devent->db); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); isc_event_free(&event); dns_resolver_destroyfetch(&val->fetch); - + INSIST(val->event != NULL); - validator_log(val, ISC_LOG_DEBUG(3), "in dlv_fetched2: %s", + validator_log(val, ISC_LOG_DEBUG(3), "in dlvfetched: %s", dns_result_totext(eresult)); LOCK(&val->lock); if (eresult == ISC_R_SUCCESS) { + dns_name_format(dns_fixedname_name(&val->dlvsep), namebuf, + sizeof(namebuf)); + dns_rdataset_clone(&val->frdataset, &val->dlv); val->havedlvsep = ISC_TRUE; - result = proveunsecure(val, ISC_FALSE); + validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf); + result = dlv_validator_start(val); if (result != DNS_R_WAIT) validator_done(val, result); } else if (eresult == DNS_R_NXRRSET || @@ -2246,13 +2074,26 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) { eresult == DNS_R_NCACHENXDOMAIN) { result = finddlvsep(val, ISC_TRUE); if (result == ISC_R_SUCCESS) { - result = proveunsecure(val, ISC_FALSE); + dns_name_format(dns_fixedname_name(&val->dlvsep), + namebuf, sizeof(namebuf)); + validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", + namebuf); + result = dlv_validator_start(val); if (result != DNS_R_WAIT) validator_done(val, result); } else if (result == ISC_R_NOTFOUND) { + validator_log(val, ISC_LOG_DEBUG(3), "DLV not found"); + markanswer(val); validator_done(val, ISC_R_SUCCESS); - } else if (result != DNS_R_WAIT) - validator_done(val, result); + } else { + validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s", + dns_result_totext(result)); + if (result != DNS_R_WAIT) + validator_done(val, result); + } + } else { + validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s", + dns_result_totext(eresult)); } want_destroy = exit_check(val); UNLOCK(&val->lock); @@ -2260,20 +2101,73 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) { destroy(val); } +static isc_result_t +startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) { + char namebuf[DNS_NAME_FORMATSIZE]; + isc_result_t result; + + INSIST(!DLVTRIED(val)); + + val->attributes |= VALATTR_DLVTRIED; + + dns_name_format(unsecure, namebuf, sizeof(namebuf)); + validator_log(val, ISC_LOG_DEBUG(3), + "plain DNSSEC returns unsecure (%s): looking for DLV", + namebuf); + + if (dns_name_issubdomain(val->event->name, val->view->dlv)) { + validator_log(val, ISC_LOG_WARNING, "must be secure failure"); + return (DNS_R_MUSTBESECURE); + } + + val->dlvlabels = dns_name_countlabels(unsecure) - 1; + result = finddlvsep(val, ISC_FALSE); + if (result == ISC_R_NOTFOUND) { + validator_log(val, ISC_LOG_DEBUG(3), "DLV not found"); + markanswer(val); + return (ISC_R_SUCCESS); + } + if (result != ISC_R_SUCCESS) { + validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s", + dns_result_totext(result)); + return (result); + } + dns_name_format(dns_fixedname_name(&val->dlvsep), namebuf, + sizeof(namebuf)); + validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf); + return (dlv_validator_start(val)); +} + static isc_result_t finddlvsep(dns_validator_t *val, isc_boolean_t resume) { + char namebuf[DNS_NAME_FORMATSIZE]; dns_fixedname_t dlvfixed; dns_name_t *dlvname; dns_name_t *dlvsep; dns_name_t noroot; isc_result_t result; unsigned int labels; + + INSIST(val->view->dlv != NULL); if (!resume) { + + if (dns_name_issubdomain(val->event->name, val->view->dlv)) { + validator_log(val, ISC_LOG_WARNING, + "must be secure failure"); + return (DNS_R_MUSTBESECURE); + } + dns_fixedname_init(&val->dlvsep); dlvsep = dns_fixedname_name(&val->dlvsep); dns_name_copy(val->event->name, dlvsep, NULL); - val->attributes |= VALATTR_DLVSEPTRIED; + if (val->event->type == dns_rdatatype_ds) { + labels = dns_name_countlabels(dlvsep); + if (labels == 0) + return (ISC_R_NOTFOUND); + dns_name_getlabelsequence(dlvsep, 1, labels - 1, + dlvsep); + } } else { dlvsep = dns_fixedname_name(&val->dlvsep); labels = dns_name_countlabels(dlvsep); @@ -2283,6 +2177,8 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) { dns_fixedname_init(&dlvfixed); dlvname = dns_fixedname_name(&dlvfixed); labels = dns_name_countlabels(dlvsep); + if (labels == 0) + return (ISC_R_NOTFOUND); dns_name_getlabelsequence(dlvsep, 0, labels - 1, &noroot); result = dns_name_concatenate(&noroot, val->view->dlv, dlvname, NULL); while (result == ISC_R_NOSPACE) { @@ -2297,32 +2193,37 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) { return (DNS_R_NOVALIDSIG); } - while (dns_name_countlabels(dlvname) > - dns_name_countlabels(val->view->dlv)) - { + while (dns_name_countlabels(dlvname) >= + dns_name_countlabels(val->view->dlv) + val->dlvlabels) { + dns_name_format(dlvname, namebuf, sizeof(namebuf)); + validator_log(val, ISC_LOG_DEBUG(3), "looking for DLV %s", + namebuf); result = view_find(val, dlvname, dns_rdatatype_dlv); if (result == ISC_R_SUCCESS) { if (val->frdataset.trust < dns_trust_secure) return (DNS_R_NOVALIDSIG); val->havedlvsep = ISC_TRUE; + dns_rdataset_clone(&val->frdataset, &val->dlv); return (ISC_R_SUCCESS); } if (result == ISC_R_NOTFOUND) { - result = create_fetch(val, dlvname, dns_rdatatype_dlv, - dlv_fetched2, "finddlvsep"); - if (result != ISC_R_SUCCESS) - return (result); - return (DNS_R_WAIT); + result = create_fetch(val, dlvname, dns_rdatatype_dlv, + dlvfetched, "finddlvsep"); + if (result != ISC_R_SUCCESS) + return (result); + return (DNS_R_WAIT); } if (result != DNS_R_NXRRSET && result != DNS_R_NXDOMAIN && result != DNS_R_NCACHENXRRSET && - result != DNS_R_NCACHENXDOMAIN) + result != DNS_R_NCACHENXDOMAIN) return (result); /* * Strip first labels from both dlvsep and dlvname. */ labels = dns_name_countlabels(dlvsep); + if (labels == 0) + break; dns_name_getlabelsequence(dlvsep, 1, labels - 1, dlvsep); labels = dns_name_countlabels(dlvname); dns_name_getlabelsequence(dlvname, 1, labels - 1, dlvname); @@ -2330,73 +2231,76 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) { return (ISC_R_NOTFOUND); } +/* + * proveunsecure walks down from the SEP looking for a break in the + * chain of trust. That occurs when we can prove the DS record does + * not exist at a delegation point or the DS exists at a delegation + * but we don't support the algorithm/digest. + */ static isc_result_t proveunsecure(dns_validator_t *val, isc_boolean_t resume) { isc_result_t result; - isc_result_t tresult; - dns_fixedname_t secroot; + dns_fixedname_t fixedsecroot; + dns_name_t *secroot; dns_name_t *tname; + char namebuf[DNS_NAME_FORMATSIZE]; - dns_fixedname_init(&secroot); - result = dns_keytable_finddeepestmatch(val->keytable, - val->event->name, - dns_fixedname_name(&secroot)); - /* - * If the name is not under a security root, it must be insecure. - */ - if (val->view->dlv != NULL && !DLVSEPTRIED(val) && - !dns_name_issubdomain(val->event->name, val->view->dlv)) { - tresult = finddlvsep(val, ISC_FALSE); - if (tresult != ISC_R_NOTFOUND && tresult != ISC_R_SUCCESS) { - validator_log(val, ISC_LOG_DEBUG(3), - "finddlvsep returned: %s", - dns_result_totext(tresult)); - return (tresult); - } - } + dns_fixedname_init(&fixedsecroot); + secroot = dns_fixedname_name(&fixedsecroot); + if (val->havedlvsep) + dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL); + else { + result = dns_keytable_finddeepestmatch(val->keytable, + val->event->name, + secroot); - if (result == ISC_R_NOTFOUND) { - if (!val->havedlvsep) { + if (result == ISC_R_NOTFOUND) { validator_log(val, ISC_LOG_DEBUG(3), - "not beneath secure root / DLV"); + "not beneath secure root"); if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, "must be secure failure"); result = DNS_R_MUSTBESECURE; goto out; } - val->event->rdataset->trust = dns_trust_answer; - return (ISC_R_SUCCESS); - } - dns_name_copy(dns_fixedname_name(&val->dlvsep), - dns_fixedname_name(&secroot), NULL); - } else if (result != ISC_R_SUCCESS) - return (result); - else if (val->havedlvsep && - dns_name_issubdomain(dns_fixedname_name(&val->dlvsep), - dns_fixedname_name(&secroot))) { - dns_name_copy(dns_fixedname_name(&val->dlvsep), - dns_fixedname_name(&secroot), NULL); + if (val->view->dlv == NULL || DLVTRIED(val)) { + markanswer(val); + return (ISC_R_SUCCESS); + } + return (startfinddlvsep(val, dns_rootname)); + } else if (result != ISC_R_SUCCESS) + return (result); } if (!resume) { - val->labels = - dns_name_countlabels(dns_fixedname_name(&secroot)) + 1; + /* + * We are looking for breaks below the SEP so add a label. + */ + val->labels = dns_name_countlabels(secroot) + 1; } else { validator_log(val, ISC_LOG_DEBUG(3), "resuming proveunsecure"); if (val->frdataset.trust >= dns_trust_secure && - !check_ds_algorithm(val, dns_fixedname_name(&val->fname), - &val->frdataset)) { + !check_ds(val, dns_fixedname_name(&val->fname), + &val->frdataset)) { + dns_name_format(dns_fixedname_name(&val->fname), + namebuf, sizeof(namebuf)); if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, - "must be secure failure"); + "must be secure failure at '%s'", + namebuf); result = DNS_R_MUSTBESECURE; goto out; } validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); - val->event->rdataset->trust = dns_trust_answer; - result = ISC_R_SUCCESS; + "no supported algorithm/digest (%s/DS)", + namebuf); + if (val->view->dlv == NULL || DLVTRIED(val)) { + markanswer(val); + result = ISC_R_SUCCESS; + goto out; + } + result = startfinddlvsep(val, + dns_fixedname_name(&val->fname)); goto out; } val->labels++; @@ -2406,7 +2310,6 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { val->labels <= dns_name_countlabels(val->event->name); val->labels++) { - char namebuf[DNS_NAME_FORMATSIZE]; dns_fixedname_init(&val->fname); tname = dns_fixedname_name(&val->fname); @@ -2425,7 +2328,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { if (result == DNS_R_NXRRSET || result == DNS_R_NCACHENXRRSET) { /* * There is no DS. If this is a delegation, - * we're done. + * we maybe done. */ if (val->frdataset.trust < dns_trust_secure) { /* @@ -2443,8 +2346,11 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { "must be secure failure"); return (DNS_R_MUSTBESECURE); } - val->event->rdataset->trust = dns_trust_answer; - return (ISC_R_SUCCESS); + if (val->view->dlv == NULL || DLVTRIED(val)) { + markanswer(val); + return (ISC_R_SUCCESS); + } + return (startfinddlvsep(val, tname)); } continue; } else if (result == ISC_R_SUCCESS) { @@ -2453,10 +2359,10 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { * continue. */ if (val->frdataset.trust >= dns_trust_secure) { - if (!check_ds_algorithm(val, tname, - &val->frdataset)) { + if (!check_ds(val, tname, &val->frdataset)) { validator_log(val, ISC_LOG_DEBUG(3), - "no supported algorithm (ds)"); + "no supported algorithm/" + "digest (%s/DS)", namebuf); if (val->mustbesecure) { validator_log(val, ISC_LOG_WARNING, @@ -2464,9 +2370,13 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { result = DNS_R_MUSTBESECURE; goto out; } - val->event->rdataset->trust = - dns_trust_answer; - result = ISC_R_SUCCESS; + if (val->view->dlv == NULL || + DLVTRIED(val)) { + markanswer(val); + result = ISC_R_SUCCESS; + goto out; + } + result = startfinddlvsep(val, tname); goto out; } continue; @@ -2531,6 +2441,23 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) { return (result); } +static isc_result_t +dlv_validator_start(dns_validator_t *val) { + isc_event_t *event; + + validator_log(val, ISC_LOG_DEBUG(3), "dlv_validator_start"); + + /* + * Reset state and try again. + */ + val->attributes &= VALATTR_DLVTRIED; + val->options &= ~DNS_VALIDATOR_DLV; + + event = (isc_event_t *)val->event; + isc_task_send(val->task, &event); + return (DNS_R_WAIT); +} + static void validator_start(isc_task_t *task, isc_event_t *event) { dns_validator_t *val; @@ -2547,11 +2474,18 @@ validator_start(isc_task_t *task, isc_event_t *event) { if (val->event == NULL) return; - validator_log(val, ISC_LOG_DEBUG(3), "starting"); + if (DLVTRIED(val)) + validator_log(val, ISC_LOG_DEBUG(3), "restarting using DLV"); + else + validator_log(val, ISC_LOG_DEBUG(3), "starting"); LOCK(&val->lock); - if (val->event->rdataset != NULL && val->event->sigrdataset != NULL) { + if ((val->options & DNS_VALIDATOR_DLV) != 0) { + validator_log(val, ISC_LOG_DEBUG(3), "looking for DLV"); + result = startfinddlvsep(val, dns_rootname); + } else if (val->event->rdataset != NULL && + val->event->sigrdataset != NULL) { isc_result_t saved_result; /* @@ -2635,7 +2569,6 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type, REQUIRE(type != 0); REQUIRE(rdataset != NULL || (rdataset == NULL && sigrdataset == NULL && message != NULL)); - REQUIRE(options == 0); REQUIRE(validatorp != NULL && *validatorp == NULL); tclone = NULL; @@ -2685,12 +2618,13 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type, val->currentset = NULL; val->keyset = NULL; val->dsset = NULL; - val->dlv = NULL; + dns_rdataset_init(&val->dlv); val->soaset = NULL; val->nsecset = NULL; val->soaname = NULL; val->seensig = ISC_FALSE; val->havedlvsep = ISC_FALSE; + val->depth = 0; val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name); dns_rdataset_init(&val->frdataset); dns_rdataset_init(&val->fsigrdataset); @@ -2749,6 +2683,12 @@ destroy(dns_validator_t *val) { dns_keytable_detach(&val->keytable); if (val->subvalidator != NULL) dns_validator_destroy(&val->subvalidator); + if (val->havedlvsep) + dns_rdataset_disassociate(&val->dlv); + if (dns_rdataset_isassociated(&val->frdataset)) + dns_rdataset_disassociate(&val->frdataset); + if (dns_rdataset_isassociated(&val->fsigrdataset)) + dns_rdataset_disassociate(&val->fsigrdataset); mctx = val->view->mctx; if (val->siginfo != NULL) isc_mem_put(mctx, val->siginfo, sizeof(*val->siginfo)); @@ -2787,9 +2727,14 @@ validator_logv(dns_validator_t *val, isc_logcategory_t *category, isc_logmodule_t *module, int level, const char *fmt, va_list ap) { char msgbuf[2048]; + static const char spaces[] = " *"; + int depth = val->depth * 2; vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap); + if ((unsigned int) depth >= sizeof spaces) + depth = sizeof spaces - 1; + if (val->event != NULL && val->event->name != NULL) { char namebuf[DNS_NAME_FORMATSIZE]; char typebuf[DNS_RDATATYPE_FORMATSIZE]; @@ -2798,11 +2743,12 @@ validator_logv(dns_validator_t *val, isc_logcategory_t *category, dns_rdatatype_format(val->event->type, typebuf, sizeof(typebuf)); isc_log_write(dns_lctx, category, module, level, - "validating %s %s: %s", namebuf, typebuf, - msgbuf); + "%.*svalidating @%p: %s %s: %s", depth, spaces, + val, namebuf, typebuf, msgbuf); } else { isc_log_write(dns_lctx, category, module, level, - "validator @%p: %s", val, msgbuf); + "%.*svalidator @%p: %s", depth, spaces, + val, msgbuf); } } diff --git a/contrib/bind9/lib/dns/xfrin.c b/contrib/bind9/lib/dns/xfrin.c index aa4d054ca33..8a824a73ef5 100644 --- a/contrib/bind9/lib/dns/xfrin.c +++ b/contrib/bind9/lib/dns/xfrin.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: xfrin.c,v 1.124.2.4.2.9 2004/10/13 22:28:42 marka Exp $ */ +/* $Id: xfrin.c,v 1.124.2.4.2.12 2005/11/03 23:08:41 marka Exp $ */ #include @@ -232,7 +232,7 @@ xfrin_log1(int level, dns_name_t *zonename, dns_rdataclass_t rdclass, ISC_FORMAT_PRINTF(5, 6); static void -xfrin_log(dns_xfrin_ctx_t *xfr, unsigned int level, const char *fmt, ...) +xfrin_log(dns_xfrin_ctx_t *xfr, int level, const char *fmt, ...) ISC_FORMAT_PRINTF(3, 4); /**************************************************************************/ @@ -581,7 +581,7 @@ dns_xfrin_create2(dns_zone_t *zone, dns_rdatatype_t xfrtype, isc_task_t *task, dns_xfrindone_t done, dns_xfrin_ctx_t **xfrp) { dns_name_t *zonename = dns_zone_getorigin(zone); - dns_xfrin_ctx_t *xfr; + dns_xfrin_ctx_t *xfr = NULL; isc_result_t result; dns_db_t *db = NULL; @@ -1391,7 +1391,7 @@ xfrin_log1(int level, dns_name_t *zonename, dns_rdataclass_t rdclass, */ static void -xfrin_log(dns_xfrin_ctx_t *xfr, unsigned int level, const char *fmt, ...) +xfrin_log(dns_xfrin_ctx_t *xfr, int level, const char *fmt, ...) { va_list ap; diff --git a/contrib/bind9/lib/dns/zone.c b/contrib/bind9/lib/dns/zone.c index 29f99cb1d68..a993877e91a 100644 --- a/contrib/bind9/lib/dns/zone.c +++ b/contrib/bind9/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.333.2.23.2.55 2005/02/03 23:50:45 marka Exp $ */ +/* $Id: zone.c,v 1.333.2.23.2.59 2005/07/29 00:38:33 marka Exp $ */ #include @@ -167,6 +167,7 @@ struct dns_zone { isc_sockaddr_t *masters; dns_name_t **masterkeynames; + isc_boolean_t *mastersok; unsigned int masterscnt; unsigned int curmaster; isc_sockaddr_t masteraddr; @@ -536,6 +537,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { zone->minretry = DNS_ZONE_MINRETRY; zone->masters = NULL; zone->masterkeynames = NULL; + zone->mastersok = NULL; zone->masterscnt = 0; zone->curmaster = 0; zone->notify = NULL; @@ -590,7 +592,8 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) { free_mutex: DESTROYLOCK(&zone->lock); - return (ISC_R_NOMEMORY); + isc_mem_putanddetach(&zone->mctx, zone, sizeof(*zone)); + return (result); } /* @@ -1250,6 +1253,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime, isc_uint32_t serial, refresh, retry, expire, minimum; isc_time_t now; isc_boolean_t needdump = ISC_FALSE; + isc_boolean_t hasinclude = DNS_ZONE_FLAG(zone, DNS_ZONEFLG_HASINCLUDE); TIME_NOW(&now); @@ -1355,10 +1359,32 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime, if (result != ISC_R_SUCCESS) goto cleanup; if (zone->db != NULL) { - if (!isc_serial_ge(serial, zone->serial)) { + /* + * This is checked in zone_replacedb() for slave zones + * as they don't reload from disk. + */ + if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS) && + !isc_serial_gt(serial, zone->serial)) { + isc_uint32_t serialmin, serialmax; + + INSIST(zone->type == dns_zone_master); + + serialmin = (zone->serial + 1) & 0xffffffffU; + serialmax = (zone->serial + 0x7fffffffU) & + 0xffffffffU; + dns_zone_log(zone, ISC_LOG_ERROR, + "ixfr-from-differences: " + "new serial (%u) out of range " + "[%u - %u]", serial, serialmin, + serialmax); + result = DNS_R_BADZONE; + goto cleanup; + } else if (!isc_serial_ge(serial, zone->serial)) dns_zone_log(zone, ISC_LOG_ERROR, "zone serial has gone backwards"); - } + else if (serial == zone->serial && !hasinclude) + dns_zone_log(zone, ISC_LOG_ERROR, + "zone serial unchanged"); } zone->serial = serial; zone->refresh = RANGE(refresh, @@ -1943,6 +1969,7 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters, isc_sockaddr_t *new; isc_result_t result = ISC_R_SUCCESS; dns_name_t **newname; + isc_boolean_t *newok; unsigned int i; REQUIRE(DNS_ZONE_VALID(zone)); @@ -1972,10 +1999,15 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters, zone->masterscnt * sizeof(dns_name_t *)); zone->masterkeynames = NULL; } + if (zone->mastersok != NULL) { + isc_mem_put(zone->mctx, zone->mastersok, + zone->masterscnt * sizeof(isc_boolean_t)); + zone->mastersok = NULL; + } zone->masterscnt = 0; /* - * If count == 0, don't allocate any space for masters or keynames - * so internally, those pointers are NULL if count == 0 + * If count == 0, don't allocate any space for masters, mastersok or + * keynames so internally, those pointers are NULL if count == 0 */ if (count == 0) goto unlock; @@ -1983,27 +2015,35 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters, /* * masters must countain count elements! */ - new = isc_mem_get(zone->mctx, - count * sizeof(isc_sockaddr_t)); + new = isc_mem_get(zone->mctx, count * sizeof(*new)); if (new == NULL) { result = ISC_R_NOMEMORY; goto unlock; } memcpy(new, masters, count * sizeof(*new)); - zone->masters = new; - zone->masterscnt = count; - DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOMASTERS); + + /* + * Similarly for mastersok. + */ + newok = isc_mem_get(zone->mctx, count * sizeof(*newok)); + if (newok == NULL) { + result = ISC_R_NOMEMORY; + isc_mem_put(zone->mctx, new, count * sizeof(*new)); + goto unlock; + }; + for (i = 0; i < count; i++) + newok[i] = ISC_FALSE; /* * if keynames is non-NULL, it must contain count elements! */ + newname = NULL; if (keynames != NULL) { - newname = isc_mem_get(zone->mctx, - count * sizeof(dns_name_t *)); + newname = isc_mem_get(zone->mctx, count * sizeof(*newname)); if (newname == NULL) { result = ISC_R_NOMEMORY; - isc_mem_put(zone->mctx, zone->masters, - count * sizeof(*new)); + isc_mem_put(zone->mctx, new, count * sizeof(*new)); + isc_mem_put(zone->mctx, newok, count * sizeof(*newok)); goto unlock; } for (i = 0; i < count; i++) @@ -2024,16 +2064,27 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters, dns_name_free( newname[i], zone->mctx); - isc_mem_put(zone->mctx, zone->masters, + isc_mem_put(zone->mctx, new, count * sizeof(*new)); + isc_mem_put(zone->mctx, newok, + count * sizeof(*newok)); isc_mem_put(zone->mctx, newname, count * sizeof(*newname)); goto unlock; } } } - zone->masterkeynames = newname; } + + /* + * Everything is ok so attach to the zone. + */ + zone->masters = new; + zone->mastersok = newok; + zone->masterkeynames = newname; + zone->masterscnt = count; + DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOMASTERS); + unlock: UNLOCK_ZONE(zone); return (result); @@ -2222,6 +2273,7 @@ void dns_zone_refresh(dns_zone_t *zone) { isc_interval_t i; isc_uint32_t oldflags; + unsigned int j; REQUIRE(DNS_ZONE_VALID(zone)); @@ -2266,6 +2318,8 @@ dns_zone_refresh(dns_zone_t *zone) { zone->retry = ISC_MIN(zone->retry * 2, 6 * 3600); zone->curmaster = 0; + for (j = 0; j < zone->masterscnt; j++) + zone->mastersok[j] = ISC_FALSE; /* initiate soa query */ queue_soa_query(zone); unlock: @@ -3186,6 +3240,7 @@ stub_callback(isc_task_t *task, isc_event_t *event) { isc_time_t now; isc_boolean_t exiting = ISC_FALSE; isc_interval_t i; + unsigned int j; stub = revent->ev_arg; INSIST(DNS_STUB_VALID(stub)); @@ -3360,13 +3415,37 @@ stub_callback(isc_task_t *task, isc_event_t *event) { isc_event_free(&event); LOCK_ZONE(zone); dns_request_destroy(&zone->request); - zone->curmaster++; + /* + * Skip to next failed / untried master. + */ + do { + zone->curmaster++; + } while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]); DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOEDNS); if (exiting || zone->curmaster >= zone->masterscnt) { + isc_boolean_t done = ISC_TRUE; if (!exiting && DNS_ZONE_OPTION(zone, DNS_ZONEOPT_USEALTXFRSRC) && !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) { + /* + * Did we get a good answer from all the masters? + */ + for (j = 0; j < zone->masterscnt; j++) + if (zone->mastersok[j] == ISC_FALSE) { + done = ISC_FALSE; + break; + } + } else + done = ISC_TRUE; + if (!done) { zone->curmaster = 0; + /* + * Find the next failed master. + */ + while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]) + zone->curmaster++; DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC); } else { DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_REFRESH); @@ -3420,6 +3499,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { dns_rdata_soa_t soa; isc_result_t result; isc_uint32_t serial; + unsigned int j; zone = revent->ev_arg; INSIST(DNS_ZONE_VALID(zone)); @@ -3668,6 +3748,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { } DNS_ZONE_JITTER_ADD(&now, zone->refresh, &zone->refreshtime); DNS_ZONE_TIME_ADD(&now, zone->expire, &zone->expiretime); + zone->mastersok[zone->curmaster] = ISC_TRUE; goto next_master; } else { if (!DNS_ZONE_OPTION(zone, DNS_ZONEOPT_MULTIMASTER)) @@ -3676,6 +3757,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { soa.serial, master, zone->serial); else zone_debuglog(zone, me, 1, "ahead"); + zone->mastersok[zone->curmaster] = ISC_TRUE; goto next_master; } if (msg != NULL) @@ -3688,13 +3770,37 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { isc_event_free(&event); LOCK_ZONE(zone); dns_request_destroy(&zone->request); - zone->curmaster++; + /* + * Skip to next failed / untried master. + */ + do { + zone->curmaster++; + } while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]); DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOEDNS); if (zone->curmaster >= zone->masterscnt) { + isc_boolean_t done = ISC_TRUE; if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_USEALTXFRSRC) && !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) { + /* + * Did we get a good answer from all the masters? + */ + for (j = 0; j < zone->masterscnt; j++) + if (zone->mastersok[j] == ISC_FALSE) { + done = ISC_FALSE; + break; + } + } else + done = ISC_TRUE; + if (!done) { DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC); zone->curmaster = 0; + /* + * Find the next failed master. + */ + while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]) + zone->curmaster++; goto requeue; } DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_REFRESH); @@ -4023,7 +4129,13 @@ soa_query(isc_task_t *task, isc_event_t *event) { skip_master: if (key != NULL) dns_tsigkey_detach(&key); - zone->curmaster++; + /* + * Skip to next failed / untried master. + */ + do { + zone->curmaster++; + } while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]); if (zone->curmaster < zone->masterscnt) goto again; zone->curmaster = 0; @@ -5275,40 +5387,58 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) { * is enabled in the configuration. */ if (zone->db != NULL && zone->journal != NULL && - DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) { - isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, - DNS_LOGMODULE_ZONE, ISC_LOG_DEBUG(3), - "generating diffs"); - result = dns_db_diff(zone->mctx, db, ver, - zone->db, NULL /* XXX */, + DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS) && + !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) { + isc_uint32_t serial; + + dns_zone_log(zone, ISC_LOG_DEBUG(3), "generating diffs"); + + result = dns_db_getsoaserial(db, ver, &serial); + if (result != ISC_R_SUCCESS) { + dns_zone_log(zone, ISC_LOG_ERROR, + "ixfr-from-differences: unable to get " + "new serial"); + goto fail; + } + + /* + * This is checked in zone_postload() for master zones. + */ + if (zone->type == dns_zone_slave && + !isc_serial_gt(serial, zone->serial)) { + isc_uint32_t serialmin, serialmax; + serialmin = (zone->serial + 1) & 0xffffffffU; + serialmax = (zone->serial + 0x7fffffffU) & 0xffffffffU; + dns_zone_log(zone, ISC_LOG_ERROR, + "ixfr-from-differences: failed: " + "new serial (%u) out of range [%u - %u]", + serial, serialmin, serialmax); + result = ISC_R_RANGE; + goto fail; + } + + result = dns_db_diff(zone->mctx, db, ver, zone->db, NULL, zone->journal); if (result != ISC_R_SUCCESS) goto fail; if (dump) zone_needdump(zone, DNS_DUMP_DELAY); else if (zone->journalsize != -1) { - isc_uint32_t serial; - - result = dns_db_getsoaserial(db, ver, &serial); - if (result == ISC_R_SUCCESS) { - result = dns_journal_compact(zone->mctx, - zone->journal, - serial, - zone->journalsize); - switch (result) { - case ISC_R_SUCCESS: - case ISC_R_NOSPACE: - case ISC_R_NOTFOUND: - dns_zone_log(zone, ISC_LOG_DEBUG(3), - "dns_journal_compact: %s", - dns_result_totext(result)); - break; - default: - dns_zone_log(zone, ISC_LOG_ERROR, + result = dns_journal_compact(zone->mctx, zone->journal, + serial, zone->journalsize); + switch (result) { + case ISC_R_SUCCESS: + case ISC_R_NOSPACE: + case ISC_R_NOTFOUND: + dns_zone_log(zone, ISC_LOG_DEBUG(3), + "dns_journal_compact: %s", + dns_result_totext(result)); + break; + default: + dns_zone_log(zone, ISC_LOG_ERROR, "dns_journal_compact failed: %s", - dns_result_totext(result)); - break; - } + dns_result_totext(result)); + break; } } } else { @@ -5503,7 +5633,14 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) { default: next_master: - zone->curmaster++; + /* + * Skip to next failed / untried master. + */ + do { + zone->curmaster++; + } while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]); + /* FALLTHROUGH */ same_master: if (zone->curmaster >= zone->masterscnt) { zone->curmaster = 0; @@ -5511,6 +5648,9 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) { !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) { DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_REFRESH); DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC); + while (zone->curmaster < zone->masterscnt && + zone->mastersok[zone->curmaster]) + zone->curmaster++; again = ISC_TRUE; } else DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC); @@ -5697,7 +5837,11 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) { "requesting AXFR of " "initial version from %s", mastertext); xfrtype = dns_rdatatype_axfr; - } else if (dns_zone_isforced(zone)) { + } else if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) { + dns_zone_log(zone, ISC_LOG_DEBUG(1), "ixfr-from-differences " + "set, requesting AXFR from %s", mastertext); + xfrtype = dns_rdatatype_axfr; + } else if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) { dns_zone_log(zone, ISC_LOG_DEBUG(1), "forced reload, requesting AXFR of " "initial version from %s", mastertext); @@ -6663,6 +6807,9 @@ void dns_zone_forcereload(dns_zone_t *zone) { REQUIRE(DNS_ZONE_VALID(zone)); + if (zone->type == dns_zone_master) + return; + LOCK_ZONE(zone); DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_FORCEXFER); UNLOCK_ZONE(zone); diff --git a/contrib/bind9/lib/isc/api b/contrib/bind9/lib/isc/api index 63704dd62ad..ddeff334f03 100644 --- a/contrib/bind9/lib/isc/api +++ b/contrib/bind9/lib/isc/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 10 -LIBREVISION = 5 -LIBAGE = 1 +LIBINTERFACE = 11 +LIBREVISION = 1 +LIBAGE = 0 diff --git a/contrib/bind9/lib/isc/include/isc/Makefile.in b/contrib/bind9/lib/isc/include/isc/Makefile.in index 10cad7e052d..f484c0bd4a7 100644 --- a/contrib/bind9/lib/isc/include/isc/Makefile.in +++ b/contrib/bind9/lib/isc/include/isc/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2001, 2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.50.12.4 2004/03/06 08:14:38 marka Exp $ +# $Id: Makefile.in,v 1.50.12.6 2005/03/22 02:32:07 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -28,8 +28,8 @@ top_srcdir = @top_srcdir@ # HEADERS = app.h assertions.h base64.h bitstring.h boolean.h buffer.h \ bufferlist.h commandline.h entropy.h error.h event.h \ - eventclass.h \ - file.h formatcheck.h fsaccess.h heap.h hex.h hmacmd5.h \ + eventclass.h file.h formatcheck.h fsaccess.h \ + hash.h heap.h hex.h hmacmd5.h \ interfaceiter.h @ISC_IPV6_H@ lang.h lex.h \ lfsr.h lib.h list.h log.h magic.h md5.h mem.h msgcat.h msgs.h \ mutexblock.h netaddr.h ondestroy.h os.h parseint.h \ diff --git a/contrib/bind9/lib/isc/include/isc/netaddr.h b/contrib/bind9/lib/isc/include/isc/netaddr.h index e209a9fa774..ad3328c47cd 100644 --- a/contrib/bind9/lib/isc/include/isc/netaddr.h +++ b/contrib/bind9/lib/isc/include/isc/netaddr.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: netaddr.h,v 1.18.12.7 2004/03/08 09:04:52 marka Exp $ */ +/* $Id: netaddr.h,v 1.18.12.9 2005/07/29 00:13:10 marka Exp $ */ #ifndef ISC_NETADDR_H #define ISC_NETADDR_H 1 @@ -81,7 +81,7 @@ isc_netaddr_format(const isc_netaddr_t *na, char *array, unsigned int size); */ #define ISC_NETADDR_FORMATSIZE \ - sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX") + sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX%SSSSSSSSSS") /* * Minimum size of array to pass to isc_netaddr_format(). */ diff --git a/contrib/bind9/lib/isc/include/isc/print.h b/contrib/bind9/lib/isc/include/isc/print.h index 19da6b0915b..1bf3704a26f 100644 --- a/contrib/bind9/lib/isc/include/isc/print.h +++ b/contrib/bind9/lib/isc/include/isc/print.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: print.h,v 1.17.188.2 2004/03/06 08:14:46 marka Exp $ */ +/* $Id: print.h,v 1.17.188.4 2005/06/09 23:54:30 marka Exp $ */ #ifndef ISC_PRINT_H #define ISC_PRINT_H 1 @@ -55,6 +55,10 @@ #include #include #endif +#ifdef ISC_PLATFORM_NEEDSPRINTF +#include +#endif + ISC_LANG_BEGINDECLS diff --git a/contrib/bind9/lib/isc/include/isc/quota.h b/contrib/bind9/lib/isc/include/isc/quota.h index 86478761332..4044118747b 100644 --- a/contrib/bind9/lib/isc/include/isc/quota.h +++ b/contrib/bind9/lib/isc/include/isc/quota.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: quota.h,v 1.8.12.3 2004/03/08 09:04:52 marka Exp $ */ +/* $Id: quota.h,v 1.8.12.6 2005/08/11 15:00:08 marka Exp $ */ #ifndef ISC_QUOTA_H #define ISC_QUOTA_H 1 @@ -53,7 +53,7 @@ struct isc_quota { /* Locked by lock. */ int max; int used; - isc_boolean_t soft; + int soft; }; isc_result_t @@ -73,11 +73,17 @@ isc_quota_destroy(isc_quota_t *quota); */ void -isc_quota_soft(isc_quota_t *quota, isc_boolean_t soft); +isc_quota_soft(isc_quota_t *quota, int soft); /* * Turn on/off soft quotas. */ +void +isc_quota_max(isc_quota_t *quota, int max); +/* + * Re-set a maximum quota. + */ + isc_result_t isc_quota_reserve(isc_quota_t *quota); /* diff --git a/contrib/bind9/lib/isc/include/isc/sockaddr.h b/contrib/bind9/lib/isc/include/isc/sockaddr.h index ffe4105deaa..1ffbca640fc 100644 --- a/contrib/bind9/lib/isc/include/isc/sockaddr.h +++ b/contrib/bind9/lib/isc/include/isc/sockaddr.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: sockaddr.h,v 1.35.12.6 2004/03/08 09:04:53 marka Exp $ */ +/* $Id: sockaddr.h,v 1.35.12.8 2005/07/29 00:13:10 marka Exp $ */ #ifndef ISC_SOCKADDR_H #define ISC_SOCKADDR_H 1 @@ -192,7 +192,7 @@ isc_sockaddr_issitelocal(isc_sockaddr_t *sa); */ #define ISC_SOCKADDR_FORMATSIZE \ - sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX#YYYYY") + sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX#YYYYY%SSSSSSSSSS") /* * Minimum size of array to pass to isc_sockaddr_format(). */ diff --git a/contrib/bind9/lib/isc/include/isc/timer.h b/contrib/bind9/lib/isc/include/isc/timer.h index be32911a29c..439c943dad5 100644 --- a/contrib/bind9/lib/isc/include/isc/timer.h +++ b/contrib/bind9/lib/isc/include/isc/timer.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: timer.h,v 1.28.12.4 2004/03/08 09:04:53 marka Exp $ */ +/* $Id: timer.h,v 1.28.12.6 2005/10/27 00:27:30 marka Exp $ */ #ifndef ISC_TIMER_H #define ISC_TIMER_H 1 @@ -277,8 +277,15 @@ isc_timer_detach(isc_timer_t **timerp); * timer event callbacks will run after the call. */ -isc_result_t +isc_timertype_t isc_timer_gettype(isc_timer_t *timer); +/*%< + * Return the timer type. + * + * Requires: + * + *\li 'timer' to be a valid timer. + */ isc_result_t isc_timermgr_create(isc_mem_t *mctx, isc_timermgr_t **managerp); diff --git a/contrib/bind9/lib/isc/inet_pton.c b/contrib/bind9/lib/isc/inet_pton.c index b253069e0d3..026fedf23c7 100644 --- a/contrib/bind9/lib/isc/inet_pton.c +++ b/contrib/bind9/lib/isc/inet_pton.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1996-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -17,7 +17,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = - "$Id: inet_pton.c,v 1.10.2.4.2.1 2004/03/06 08:14:31 marka Exp $"; + "$Id: inet_pton.c,v 1.10.2.4.2.3 2005/03/31 23:56:14 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -132,7 +132,7 @@ inet_pton6(const char *src, unsigned char *dst) { xdigits_u[] = "0123456789ABCDEF"; unsigned char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp; const char *xdigits, *curtok; - int ch, saw_xdigit; + int ch, seen_xdigits; unsigned int val; memset((tp = tmp), '\0', NS_IN6ADDRSZ); @@ -143,7 +143,7 @@ inet_pton6(const char *src, unsigned char *dst) { if (*++src != ':') return (0); curtok = src; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; while ((ch = *src++) != '\0') { const char *pch; @@ -153,14 +153,13 @@ inet_pton6(const char *src, unsigned char *dst) { if (pch != NULL) { val <<= 4; val |= (pch - xdigits); - if (val > 0xffff) + if (++seen_xdigits > 4) return (0); - saw_xdigit = 1; continue; } if (ch == ':') { curtok = src; - if (!saw_xdigit) { + if (!seen_xdigits) { if (colonp) return (0); colonp = tp; @@ -170,19 +169,19 @@ inet_pton6(const char *src, unsigned char *dst) { return (0); *tp++ = (unsigned char) (val >> 8) & 0xff; *tp++ = (unsigned char) val & 0xff; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; continue; } if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) && inet_pton4(curtok, tp) > 0) { tp += NS_INADDRSZ; - saw_xdigit = 0; + seen_xdigits = 0; break; /* '\0' was seen by inet_pton4(). */ } return (0); } - if (saw_xdigit) { + if (seen_xdigits) { if (tp + NS_INT16SZ > endp) return (0); *tp++ = (unsigned char) (val >> 8) & 0xff; diff --git a/contrib/bind9/lib/isc/lfsr.c b/contrib/bind9/lib/isc/lfsr.c index e1de6aa23eb..6d5b7ff8238 100644 --- a/contrib/bind9/lib/isc/lfsr.c +++ b/contrib/bind9/lib/isc/lfsr.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,10 +15,11 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: lfsr.c,v 1.11.2.2.2.3 2004/03/08 09:04:49 marka Exp $ */ +/* $Id: lfsr.c,v 1.11.2.2.2.6 2005/10/14 01:38:50 marka Exp $ */ #include +#include #include #include @@ -55,9 +56,6 @@ isc_lfsr_init(isc_lfsr_t *lfsr, isc_uint32_t state, unsigned int bits, static inline isc_uint32_t lfsr_generate(isc_lfsr_t *lfsr) { - unsigned int highbit; - - highbit = 1 << (lfsr->bits - 1); /* * If the previous state is zero, we must fill it with something diff --git a/contrib/bind9/lib/isc/mem.c b/contrib/bind9/lib/isc/mem.c index 762aa177070..f5069fb7dc1 100644 --- a/contrib/bind9/lib/isc/mem.c +++ b/contrib/bind9/lib/isc/mem.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1997-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: mem.c,v 1.98.2.7.2.5 2004/03/16 05:50:24 marka Exp $ */ +/* $Id: mem.c,v 1.98.2.7.2.7 2005/03/17 03:58:32 marka Exp $ */ #include @@ -717,6 +717,15 @@ isc_mem_createx(size_t init_max_size, size_t target_size, if (ctx == NULL) return (ISC_R_NOMEMORY); + if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) { + UNEXPECTED_ERROR(__FILE__, __LINE__, + "isc_mutex_init() %s", + isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, + ISC_MSG_FAILED, "failed")); + (memfree)(arg, ctx); + return (ISC_R_UNEXPECTED); + } + if (init_max_size == 0U) ctx->max_size = DEF_MAX_SIZE; else @@ -775,15 +784,6 @@ isc_mem_createx(size_t init_max_size, size_t target_size, ctx->highest = NULL; #endif /* ISC_MEM_USE_INTERNAL_MALLOC */ - if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) { - UNEXPECTED_ERROR(__FILE__, __LINE__, - "isc_mutex_init() %s", - isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, - ISC_MSG_FAILED, "failed")); - result = ISC_R_UNEXPECTED; - goto error; - } - #if ISC_MEM_TRACKLINES if ((isc_mem_debugging & ISC_MEM_DEBUGRECORD) != 0) { unsigned int i; @@ -805,17 +805,18 @@ isc_mem_createx(size_t init_max_size, size_t target_size, return (ISC_R_SUCCESS); error: - if (ctx) { - if (ctx->stats) + if (ctx != NULL) { + if (ctx->stats != NULL) (memfree)(arg, ctx->stats); #if ISC_MEM_USE_INTERNAL_MALLOC - if (ctx->freelists) + if (ctx->freelists != NULL) (memfree)(arg, ctx->freelists); #endif /* ISC_MEM_USE_INTERNAL_MALLOC */ #if ISC_MEM_TRACKLINES - if (ctx->debuglist) + if (ctx->debuglist != NULL) (ctx->memfree)(ctx->arg, ctx->debuglist); #endif /* ISC_MEM_TRACKLINES */ + DESTROYLOCK(&ctx->lock); (memfree)(arg, ctx); } diff --git a/contrib/bind9/lib/isc/nls/msgcat.c b/contrib/bind9/lib/isc/nls/msgcat.c index 484ab514a24..906e26e9070 100644 --- a/contrib/bind9/lib/isc/nls/msgcat.c +++ b/contrib/bind9/lib/isc/nls/msgcat.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: msgcat.c,v 1.10.12.4 2004/03/08 09:04:54 marka Exp $ */ +/* $Id: msgcat.c,v 1.10.12.6 2005/06/09 23:54:31 marka Exp $ */ /* * Principal Author: Bob Halley @@ -23,6 +23,7 @@ #include +#include #include #include diff --git a/contrib/bind9/lib/isc/pthreads/mutex.c b/contrib/bind9/lib/isc/pthreads/mutex.c index e29e92bd022..71db6696610 100644 --- a/contrib/bind9/lib/isc/pthreads/mutex.c +++ b/contrib/bind9/lib/isc/pthreads/mutex.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: mutex.c,v 1.6.26.3 2004/03/08 09:04:55 marka Exp $ */ +/* $Id: mutex.c,v 1.6.26.5 2005/03/17 03:58:32 marka Exp $ */ #include @@ -126,19 +126,6 @@ isc_mutex_lock_profile(isc_mutex_t *mp, const char *file, int line) { isc_mutexlocker_t *locker = NULL; int i; - for (i = 0; i < ISC_MUTEX_MAX_LOCKERS; i++) { - if (mp->stats->lockers[i].file == NULL) { - locker = &mp->stats->lockers[i]; - locker->file = file; - locker->line = line; - break; - } else if (mp->stats->lockers[i].file == file && - mp->stats->lockers[i].line == line) { - locker = &mp->stats->lockers[i]; - break; - } - } - gettimeofday(&prelock_t, NULL); if (pthread_mutex_lock(&mp->mutex) != 0) @@ -152,6 +139,19 @@ isc_mutex_lock_profile(isc_mutex_t *mp, const char *file, int line) { mp->stats->count++; timevaladd(&mp->stats->wait_total, &postlock_t); + for (i = 0; i < ISC_MUTEX_MAX_LOCKERS; i++) { + if (mp->stats->lockers[i].file == NULL) { + locker = &mp->stats->lockers[i]; + locker->file = file; + locker->line = line; + break; + } else if (mp->stats->lockers[i].file == file && + mp->stats->lockers[i].line == line) { + locker = &mp->stats->lockers[i]; + break; + } + } + if (locker != NULL) { locker->count++; timevaladd(&locker->wait_total, &postlock_t); diff --git a/contrib/bind9/lib/isc/quota.c b/contrib/bind9/lib/isc/quota.c index 012bfbb38dd..273a1b2ac6d 100644 --- a/contrib/bind9/lib/isc/quota.c +++ b/contrib/bind9/lib/isc/quota.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: quota.c,v 1.11.12.3 2004/03/08 09:04:49 marka Exp $ */ +/* $Id: quota.c,v 1.11.12.5 2005/07/29 00:13:09 marka Exp $ */ #include @@ -28,38 +28,45 @@ isc_result_t isc_quota_init(isc_quota_t *quota, int max) { quota->max = max; quota->used = 0; - quota->soft = ISC_FALSE; + quota->soft = 0; return (isc_mutex_init("a->lock)); } void isc_quota_destroy(isc_quota_t *quota) { INSIST(quota->used == 0); - quota->max = -1; - quota->used = -1; - quota->soft = ISC_FALSE; + quota->max = 0; + quota->used = 0; + quota->soft = 0; DESTROYLOCK("a->lock); } void -isc_quota_soft(isc_quota_t *quota, isc_boolean_t soft) { +isc_quota_soft(isc_quota_t *quota, int soft) { + LOCK("a->lock); quota->soft = soft; + UNLOCK("a->lock); +} + +void +isc_quota_max(isc_quota_t *quota, int max) { + LOCK("a->lock); + quota->max = max; + UNLOCK("a->lock); } isc_result_t isc_quota_reserve(isc_quota_t *quota) { isc_result_t result; LOCK("a->lock); - if (quota->used < quota->max) { - quota->used++; - result = ISC_R_SUCCESS; - } else { - if (quota->soft) { - quota->used++; + if (quota->max == 0 || quota->used < quota->max) { + if (quota->soft == 0 || quota->used < quota->soft) + result = ISC_R_SUCCESS; + else result = ISC_R_SOFTQUOTA; - } else - result = ISC_R_QUOTA; - } + quota->used++; + } else + result = ISC_R_QUOTA; UNLOCK("a->lock); return (result); } diff --git a/contrib/bind9/lib/isc/result.c b/contrib/bind9/lib/isc/result.c index 5b0ddd3fe14..fd4e5c6cb98 100644 --- a/contrib/bind9/lib/isc/result.c +++ b/contrib/bind9/lib/isc/result.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,10 +15,11 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: result.c,v 1.56.2.2.8.7 2004/06/11 00:31:01 marka Exp $ */ +/* $Id: result.c,v 1.56.2.2.8.9 2005/06/09 23:54:30 marka Exp $ */ #include +#include #include #include diff --git a/contrib/bind9/lib/isc/rwlock.c b/contrib/bind9/lib/isc/rwlock.c index 63f0c68de5c..3e444d8a112 100644 --- a/contrib/bind9/lib/isc/rwlock.c +++ b/contrib/bind9/lib/isc/rwlock.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rwlock.c,v 1.33.2.4.2.1 2004/03/06 08:14:35 marka Exp $ */ +/* $Id: rwlock.c,v 1.33.2.4.2.3 2005/03/17 03:58:32 marka Exp $ */ #include @@ -109,7 +109,9 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, "failed"), isc_result_totext(result)); - return (ISC_R_UNEXPECTED); + result = ISC_R_UNEXPECTED; + goto destroy_lock; + } result = isc_condition_init(&rwl->writeable); if (result != ISC_R_SUCCESS) { @@ -118,12 +120,20 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, "failed"), isc_result_totext(result)); - return (ISC_R_UNEXPECTED); + result = ISC_R_UNEXPECTED; + goto destroy_rcond; } rwl->magic = RWLOCK_MAGIC; return (ISC_R_SUCCESS); + + destroy_rcond: + (void)isc_condition_destroy(&rwl->readable); + destroy_lock: + DESTROYLOCK(&rwl->lock); + + return (result); } static isc_result_t diff --git a/contrib/bind9/lib/isc/timer.c b/contrib/bind9/lib/isc/timer.c index f3cdd916f9c..5426079397e 100644 --- a/contrib/bind9/lib/isc/timer.c +++ b/contrib/bind9/lib/isc/timer.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2002 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: timer.c,v 1.64.12.9 2004/03/08 09:04:50 marka Exp $ */ +/* $Id: timer.c,v 1.64.12.11 2005/10/27 00:27:29 marka Exp $ */ #include @@ -487,7 +487,7 @@ isc_timer_reset(isc_timer_t *timer, isc_timertype_t type, return (result); } -isc_result_t +isc_timertype_t isc_timer_gettype(isc_timer_t *timer) { isc_timertype_t t; diff --git a/contrib/bind9/lib/isc/unix/entropy.c b/contrib/bind9/lib/isc/unix/entropy.c index a2cbb3c6e98..50506634e4c 100644 --- a/contrib/bind9/lib/isc/unix/entropy.c +++ b/contrib/bind9/lib/isc/unix/entropy.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: entropy.c,v 1.60.2.3.8.9 2004/03/16 05:02:31 marka Exp $ */ +/* $Id: entropy.c,v 1.60.2.3.8.11 2005/07/12 05:47:43 marka Exp $ */ /* * This is the system depenedent part of the ISC entropy API. @@ -446,16 +446,25 @@ make_nonblock(int fd) { int ret; int flags; char strbuf[ISC_STRERRORSIZE]; +#ifdef USE_FIONBIO_IOCTL + int on = 1; + ret = ioctl(fd, FIONBIO, (char *)&on); +#else flags = fcntl(fd, F_GETFL, 0); - flags |= O_NONBLOCK; + flags |= PORT_NONBLOCK; ret = fcntl(fd, F_SETFL, flags); +#endif if (ret == -1) { isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "fcntl(%d, F_SETFL, %d): %s", - fd, flags, strbuf); +#ifdef USE_FIONBIO_IOCTL + "ioctl(%d, FIONBIO, &on): %s", fd, +#else + "fcntl(%d, F_SETFL, %d): %s", fd, flags, +#endif + strbuf); return (ISC_R_UNEXPECTED); } @@ -501,7 +510,7 @@ isc_entropy_createfilesource(isc_entropy_t *ent, const char *fname) { if (is_usocket) fd = socket(PF_UNIX, SOCK_STREAM, 0); else - fd = open(fname, O_RDONLY | O_NONBLOCK, 0); + fd = open(fname, O_RDONLY | PORT_NONBLOCK, 0); if (fd < 0) { ret = isc__errno2result(errno); diff --git a/contrib/bind9/lib/isc/unix/ifiter_ioctl.c b/contrib/bind9/lib/isc/unix/ifiter_ioctl.c index 6842c1f3525..0b01b96f942 100644 --- a/contrib/bind9/lib/isc/unix/ifiter_ioctl.c +++ b/contrib/bind9/lib/isc/unix/ifiter_ioctl.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ifiter_ioctl.c,v 1.19.2.5.2.15 2004/11/10 22:22:49 marka Exp $ */ +/* $Id: ifiter_ioctl.c,v 1.19.2.5.2.17 2005/10/14 02:13:07 marka Exp $ */ /* * Obtain the list of network interfaces using the SIOCGLIFCONF ioctl. @@ -896,7 +896,9 @@ internal_current(isc_interfaceiter_t *iter) { */ static isc_result_t internal_next4(isc_interfaceiter_t *iter) { +#ifdef ISC_PLATFORM_HAVESALEN struct ifreq *ifrp; +#endif REQUIRE (iter->pos < (unsigned int) iter->ifc.ifc_len); @@ -906,14 +908,14 @@ internal_next4(isc_interfaceiter_t *iter) { if (!iter->first) return (ISC_R_SUCCESS); #endif +#ifdef ISC_PLATFORM_HAVESALEN ifrp = (struct ifreq *)((char *) iter->ifc.ifc_req + iter->pos); -#ifdef ISC_PLATFORM_HAVESALEN if (ifrp->ifr_addr.sa_len > sizeof(struct sockaddr)) iter->pos += sizeof(ifrp->ifr_name) + ifrp->ifr_addr.sa_len; else #endif - iter->pos += sizeof(*ifrp); + iter->pos += sizeof(struct ifreq); if (iter->pos >= (unsigned int) iter->ifc.ifc_len) return (ISC_R_NOMORE); @@ -924,21 +926,23 @@ internal_next4(isc_interfaceiter_t *iter) { #if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR) static isc_result_t internal_next6(isc_interfaceiter_t *iter) { +#ifdef ISC_PLATFORM_HAVESALEN struct LIFREQ *ifrp; +#endif if (iter->result6 != ISC_R_SUCCESS && iter->result6 != ISC_R_IGNORE) return (iter->result6); REQUIRE(iter->pos6 < (unsigned int) iter->lifc.lifc_len); +#ifdef ISC_PLATFORM_HAVESALEN ifrp = (struct LIFREQ *)((char *) iter->lifc.lifc_req + iter->pos6); -#ifdef ISC_PLATFORM_HAVESALEN if (ifrp->lifr_addr.sa_len > sizeof(struct sockaddr)) iter->pos6 += sizeof(ifrp->lifr_name) + ifrp->lifr_addr.sa_len; else #endif - iter->pos6 += sizeof(*ifrp); + iter->pos6 += sizeof(struct LIFREQ); if (iter->pos6 >= (unsigned int) iter->lifc.lifc_len) return (ISC_R_NOMORE); diff --git a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c index c0f678b9cf0..b10a2d2090f 100644 --- a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c +++ b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: ifiter_sysctl.c,v 1.14.12.7 2004/03/08 09:04:56 marka Exp $ */ +/* $Id: ifiter_sysctl.c,v 1.14.12.9 2005/03/17 03:58:33 marka Exp $ */ /* * Obtain the list of network interfaces using sysctl. @@ -251,7 +251,7 @@ internal_current(isc_interfaceiter_t *iter) { iter->current.name); if (dst_sa != NULL && - (iter->current.flags & IFF_POINTOPOINT) != 0) + (iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) get_addr(family, &iter->current.dstaddress, dst_sa, iter->current.name); diff --git a/contrib/bind9/lib/isc/unix/net.c b/contrib/bind9/lib/isc/unix/net.c index 05f412153ce..e0aeccbbbf4 100644 --- a/contrib/bind9/lib/isc/unix/net.c +++ b/contrib/bind9/lib/isc/unix/net.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: net.c,v 1.22.2.2.10.7 2004/04/29 01:31:22 marka Exp $ */ +/* $Id: net.c,v 1.22.2.2.10.9 2005/03/17 03:58:33 marka Exp $ */ #include @@ -237,6 +237,7 @@ initialize_ipv6only(void) { } #endif /* IPV6_V6ONLY */ +#ifdef ISC_PLATFORM_HAVEIN6PKTINFO static void try_ipv6pktinfo(void) { int s, on; @@ -289,6 +290,7 @@ initialize_ipv6pktinfo(void) { RUNTIME_CHECK(isc_once_do(&once_ipv6pktinfo, try_ipv6pktinfo) == ISC_R_SUCCESS); } +#endif /* ISC_PLATFORM_HAVEIN6PKTINFO */ #endif /* WANT_IPV6 */ isc_result_t @@ -306,11 +308,13 @@ isc_net_probe_ipv6only(void) { isc_result_t isc_net_probe_ipv6pktinfo(void) { #ifdef ISC_PLATFORM_HAVEIPV6 +#ifdef ISC_PLATFORM_HAVEIN6PKTINFO #ifdef WANT_IPV6 initialize_ipv6pktinfo(); #else ipv6pktinfo_result = ISC_R_NOTFOUND; #endif +#endif #endif return (ipv6pktinfo_result); } diff --git a/contrib/bind9/lib/isc/unix/os.c b/contrib/bind9/lib/isc/unix/os.c index 0838e12770a..4d34d8ce6f4 100644 --- a/contrib/bind9/lib/isc/unix/os.c +++ b/contrib/bind9/lib/isc/unix/os.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: os.c,v 1.11.12.4 2004/05/18 01:39:20 marka Exp $ */ +/* $Id: os.c,v 1.11.12.6 2005/10/14 02:13:07 marka Exp $ */ #include @@ -26,6 +26,7 @@ #include +#ifndef __hpux static inline long sysconf_ncpus(void) { #if defined(_SC_NPROCESSORS_ONLN) @@ -36,6 +37,7 @@ sysconf_ncpus(void) { return (0); #endif } +#endif #endif /* HAVE_SYSCONF */ diff --git a/contrib/bind9/lib/isc/unix/socket.c b/contrib/bind9/lib/isc/unix/socket.c index f23b72b0f87..595990f995c 100644 --- a/contrib/bind9/lib/isc/unix/socket.c +++ b/contrib/bind9/lib/isc/unix/socket.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1998-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.207.2.19.2.15 2004/11/18 21:31:16 marka Exp $ */ +/* $Id: socket.c,v 1.207.2.19.2.22 2005/11/03 23:08:42 marka Exp $ */ #include @@ -280,7 +280,7 @@ socket_log(isc_socket_t *sock, isc_sockaddr_t *address, const char *fmt, ...) { char msgbuf[2048]; - char peerbuf[256]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; va_list ap; if (! isc_log_wouldlog(isc_lctx, level)) @@ -363,7 +363,7 @@ select_poke(isc_socketmgr_t *mgr, int fd, int msg) { } #endif } while (cc < 0 && SOFT_ERROR(errno)); - + if (cc < 0) { isc__strerror(errno, strbuf, sizeof(strbuf)); FATAL_ERROR(__FILE__, __LINE__, @@ -389,6 +389,7 @@ select_readmsg(isc_socketmgr_t *mgr, int *fd, int *msg) { cc = read(mgr->pipe_fds[0], buf, sizeof(buf)); if (cc < 0) { *msg = SELECT_POKE_NOTHING; + *fd = -1; /* Silence compiler. */ if (SOFT_ERROR(errno)) return; @@ -429,16 +430,25 @@ make_nonblock(int fd) { int ret; int flags; char strbuf[ISC_STRERRORSIZE]; +#ifdef USE_FIONBIO_IOCTL + int on = 1; + ret = ioctl(fd, FIONBIO, (char *)&on); +#else flags = fcntl(fd, F_GETFL, 0); - flags |= O_NONBLOCK; + flags |= PORT_NONBLOCK; ret = fcntl(fd, F_SETFL, flags); +#endif if (ret == -1) { isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "fcntl(%d, F_SETFL, %d): %s", - fd, flags, strbuf); +#ifdef USE_FIONBIO_IOCTL + "ioctl(%d, FIONBIO, &on): %s", fd, +#else + "fcntl(%d, F_SETFL, %d): %s", fd, flags, +#endif + strbuf); return (ISC_R_UNEXPECTED); } @@ -461,7 +471,11 @@ cmsg_len(ISC_SOCKADDR_LEN_T len) { #else ISC_SOCKADDR_LEN_T hdrlen; - hdrlen = (ISC_SOCKADDR_LEN_T)CMSG_DATA(NULL); /* XXX */ + /* + * Cast NULL so that any pointer arithmetic performed by CMSG_DATA + * is correct. + */ + hdrlen = (ISC_SOCKADDR_LEN_T)CMSG_DATA(((struct cmsghdr *)NULL)); return (hdrlen + len); #endif } @@ -1222,7 +1236,7 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type, cmsgbuflen += cmsg_space(sizeof(struct timeval)); #endif sock->recvcmsgbuflen = cmsgbuflen; - if (sock->recvcmsgbuflen != 0) { + if (sock->recvcmsgbuflen != 0U) { sock->recvcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen); if (sock->recvcmsgbuf == NULL) goto error; @@ -1233,7 +1247,7 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type, cmsgbuflen = cmsg_space(sizeof(struct in6_pktinfo)); #endif sock->sendcmsgbuflen = cmsgbuflen; - if (sock->sendcmsgbuflen != 0) { + if (sock->sendcmsgbuflen != 0U) { sock->sendcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen); if (sock->sendcmsgbuf == NULL) goto error; @@ -1348,6 +1362,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, int on = 1; #endif char strbuf[ISC_STRERRORSIZE]; + const char *err = "socket"; REQUIRE(VALID_MANAGER(manager)); REQUIRE(socketp != NULL && *socketp == NULL); @@ -1367,23 +1382,24 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, } #ifdef F_DUPFD - /* - * Leave a space for stdio to work in. - */ - if (sock->fd >= 0 && sock->fd < 20) { - int new, tmp; - new = fcntl(sock->fd, F_DUPFD, 20); - tmp = errno; - (void)close(sock->fd); - errno = tmp; - sock->fd = new; - } + /* + * Leave a space for stdio to work in. + */ + if (sock->fd >= 0 && sock->fd < 20) { + int new, tmp; + new = fcntl(sock->fd, F_DUPFD, 20); + tmp = errno; + (void)close(sock->fd); + errno = tmp; + sock->fd = new; + err = "isc_socket_create: fcntl"; + } #endif if (sock->fd >= (int)FD_SETSIZE) { (void)close(sock->fd); isc_log_iwrite(isc_lctx, ISC_LOGCATEGORY_GENERAL, - ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, + ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR, isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_TOOMANYFDS, "%s: too many open file descriptors", "socket"); @@ -1413,7 +1429,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, default: isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "socket() %s: %s", + "%s() %s: %s", err, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, @@ -1464,7 +1480,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type, #endif /* SO_TIMESTAMP */ #if defined(ISC_PLATFORM_HAVEIPV6) - if (pf == AF_INET6 && sock->recvcmsgbuflen == 0) { + if (pf == AF_INET6 && sock->recvcmsgbuflen == 0U) { /* * Warn explicitly because this anomaly can be hidden * in usual operation (and unexpectedly appear later). @@ -1764,6 +1780,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) { int fd; isc_result_t result = ISC_R_SUCCESS; char strbuf[ISC_STRERRORSIZE]; + const char *err = "accept"; UNUSED(me); @@ -1817,17 +1834,18 @@ internal_accept(isc_task_t *me, isc_event_t *ev) { (void *)&addrlen); #ifdef F_DUPFD - /* - * Leave a space for stdio to work in. - */ - if (fd >= 0 && fd < 20) { - int new, tmp; - new = fcntl(fd, F_DUPFD, 20); - tmp = errno; - (void)close(fd); - errno = tmp; - fd = new; - } + /* + * Leave a space for stdio to work in. + */ + if (fd >= 0 && fd < 20) { + int new, tmp; + new = fcntl(fd, F_DUPFD, 20); + tmp = errno; + (void)close(fd); + errno = tmp; + fd = new; + err = "fcntl"; + } #endif if (fd < 0) { @@ -1856,7 +1874,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) { } isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "internal_accept: accept() %s: %s", + "internal_accept: %s() %s: %s", err, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, ISC_MSG_FAILED, @@ -1865,7 +1883,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) { fd = -1; result = ISC_R_UNEXPECTED; } else { - if (addrlen == 0) { + if (addrlen == 0U) { UNEXPECTED_ERROR(__FILE__, __LINE__, "internal_accept(): " "accept() failed to return " @@ -2197,7 +2215,7 @@ watcher(void *uap) { cc = select(maxfd, &readfds, &writefds, NULL, NULL); if (cc < 0) { if (!SOFT_ERROR(errno)) { - isc__strerror(errno, strbuf, + isc__strerror(errno, strbuf, sizeof(strbuf)); FATAL_ERROR(__FILE__, __LINE__, "select() %s: %s", @@ -3094,6 +3112,7 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr, ERROR_MATCH(ENOBUFS, ISC_R_NORESOURCES); ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH); ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED); + ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET); #undef ERROR_MATCH } @@ -3163,6 +3182,7 @@ internal_connect(isc_task_t *me, isc_event_t *ev) { int cc; ISC_SOCKADDR_LEN_T optlen; char strbuf[ISC_STRERRORSIZE]; + char peerbuf[ISC_SOCKADDR_FORMATSIZE]; UNUSED(me); INSIST(ev->ev_type == ISC_SOCKEVENT_INTW); @@ -3239,13 +3259,16 @@ internal_connect(isc_task_t *me, isc_event_t *ev) { ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH); ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED); ERROR_MATCH(ETIMEDOUT, ISC_R_TIMEDOUT); + ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET); #undef ERROR_MATCH default: dev->result = ISC_R_UNEXPECTED; + isc_sockaddr_format(&sock->address, peerbuf, + sizeof(peerbuf)); isc__strerror(errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, - "internal_connect: connect() %s", - strbuf); + "internal_connect: connect(%s) %s", + peerbuf, strbuf); } } else { dev->result = ISC_R_SUCCESS; @@ -3407,7 +3430,7 @@ isc_socket_cancel(isc_socket_t *sock, isc_task_t *task, unsigned int how) { dev->result = ISC_R_CANCELED; dev->ev_sender = sock; isc_task_sendanddetach(¤t_task, - ISC_EVENT_PTR(&dev)); + ISC_EVENT_PTR(&dev)); } dev = next; diff --git a/contrib/bind9/lib/isc/unix/stdtime.c b/contrib/bind9/lib/isc/unix/stdtime.c index 8946a605ca7..b8d818dcfd7 100644 --- a/contrib/bind9/lib/isc/unix/stdtime.c +++ b/contrib/bind9/lib/isc/unix/stdtime.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,10 +15,11 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: stdtime.c,v 1.11.2.1.10.3 2004/03/08 09:04:57 marka Exp $ */ +/* $Id: stdtime.c,v 1.11.2.1.10.5 2005/06/09 23:54:31 marka Exp $ */ #include +#include /* NULL */ #include /* NULL */ #include diff --git a/contrib/bind9/lib/isccfg/api b/contrib/bind9/lib/isccfg/api index 7e9f0b651e2..59ed93b0110 100644 --- a/contrib/bind9/lib/isccfg/api +++ b/contrib/bind9/lib/isccfg/api @@ -1,3 +1,3 @@ LIBINTERFACE = 1 -LIBREVISION = 5 +LIBREVISION = 6 LIBAGE = 0 diff --git a/contrib/bind9/lib/isccfg/namedconf.c b/contrib/bind9/lib/isccfg/namedconf.c index 3321bd6d118..bfc5dda425e 100644 --- a/contrib/bind9/lib/isccfg/namedconf.c +++ b/contrib/bind9/lib/isccfg/namedconf.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2002, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.21.44.29 2004/10/17 23:19:51 marka Exp $ */ +/* $Id: namedconf.c,v 1.21.44.32 2005/10/26 05:06:40 marka Exp $ */ #include @@ -479,7 +479,7 @@ static cfg_type_t cfg_type_hostname = { }; /* - * "server-id" arguement. + * "server-id" argument. */ static isc_result_t @@ -619,6 +619,7 @@ options_clauses[] = { { "use-id-pool", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE }, { "use-ixfr", &cfg_type_boolean, 0 }, { "version", &cfg_type_qstringornone, 0 }, + { "flush-zones-on-shutdown", &cfg_type_boolean, 0 }, { NULL, NULL, 0 } }; diff --git a/contrib/bind9/lib/lwres/Makefile.in b/contrib/bind9/lib/lwres/Makefile.in index 548c5d5129a..024b988492a 100644 --- a/contrib/bind9/lib/lwres/Makefile.in +++ b/contrib/bind9/lib/lwres/Makefile.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 2000, 2001 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: Makefile.in,v 1.25.12.6 2004/08/28 06:25:23 marka Exp $ +# $Id: Makefile.in,v 1.25.12.8 2005/06/09 23:54:32 marka Exp $ srcdir = @srcdir@ VPATH = @srcdir@ @@ -35,14 +35,16 @@ OBJS = context.@O@ gai_strerror.@O@ getaddrinfo.@O@ gethost.@O@ \ getipnode.@O@ getnameinfo.@O@ getrrset.@O@ herror.@O@ \ lwbuffer.@O@ lwconfig.@O@ lwpacket.@O@ lwresutil.@O@ \ lwres_gabn.@O@ lwres_gnba.@O@ lwres_grbn.@O@ lwres_noop.@O@ \ - lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ print.@O@ + lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ print.@O@ \ + strtoul.@O@ # Alphabetically SRCS = context.c gai_strerror.c getaddrinfo.c gethost.c \ getipnode.c getnameinfo.c getrrset.c herror.c \ lwbuffer.c lwconfig.c lwpacket.c lwresutil.c \ lwres_gabn.c lwres_gnba.c lwres_grbn.c lwres_noop.c \ - lwinetaton.c lwinetpton.c lwinetntop.c print.c + lwinetaton.c lwinetpton.c lwinetntop.c print.c \ + strtoul.c LIBS = @LIBS@ diff --git a/contrib/bind9/lib/lwres/api b/contrib/bind9/lib/lwres/api index 01be87336cb..0ab1e92dc29 100644 --- a/contrib/bind9/lib/lwres/api +++ b/contrib/bind9/lib/lwres/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 3 -LIBREVISION = 2 -LIBAGE = 2 +LIBINTERFACE = 10 +LIBREVISION = 1 +LIBAGE = 1 diff --git a/contrib/bind9/lib/lwres/getaddrinfo.c b/contrib/bind9/lib/lwres/getaddrinfo.c index 86f48aa9ffd..c06327446b3 100644 --- a/contrib/bind9/lib/lwres/getaddrinfo.c +++ b/contrib/bind9/lib/lwres/getaddrinfo.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001 Internet Software Consortium. * * This code is derived from software contributed to ISC by @@ -18,17 +18,17 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: getaddrinfo.c,v 1.41.206.1 2004/03/06 08:15:30 marka Exp $ */ +/* $Id: getaddrinfo.c,v 1.41.206.3 2005/06/09 23:54:33 marka Exp $ */ #include #include #include -#include #include #include #include +#include #define SA(addr) ((struct sockaddr *)(addr)) #define SIN(addr) ((struct sockaddr_in *)(addr)) diff --git a/contrib/bind9/lib/lwres/getipnode.c b/contrib/bind9/lib/lwres/getipnode.c index 5bda15e6e04..9b1a07bdda7 100644 --- a/contrib/bind9/lib/lwres/getipnode.c +++ b/contrib/bind9/lib/lwres/getipnode.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: getipnode.c,v 1.30.2.4.2.4 2004/03/06 08:15:31 marka Exp $ */ +/* $Id: getipnode.c,v 1.30.2.4.2.6 2005/04/29 00:03:32 marka Exp $ */ #include @@ -331,6 +331,8 @@ lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num) { n = lwres_getnamebyaddr(lwrctx, LWRES_ADDRTYPE_V6, IN6ADDRSZ, src, &by); if (n != 0) { + lwres_conf_clear(lwrctx); + lwres_context_destroy(&lwrctx); *error_num = HOST_NOT_FOUND; return (NULL); } @@ -338,6 +340,7 @@ lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num) { lwres_gnbaresponse_free(lwrctx, &by); if (he1 == NULL) *error_num = NO_RECOVERY; + lwres_conf_clear(lwrctx); lwres_context_destroy(&lwrctx); return (he1); } diff --git a/contrib/bind9/lib/lwres/include/lwres/platform.h.in b/contrib/bind9/lib/lwres/include/lwres/platform.h.in index 9c6502b5ae6..e995aa46c0e 100644 --- a/contrib/bind9/lib/lwres/include/lwres/platform.h.in +++ b/contrib/bind9/lib/lwres/include/lwres/platform.h.in @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: platform.h.in,v 1.12.2.1.10.2 2004/08/28 06:25:26 marka Exp $ */ +/* $Id: platform.h.in,v 1.12.2.1.10.5 2005/06/08 02:08:32 marka Exp $ */ #ifndef LWRES_PLATFORM_H #define LWRES_PLATFORM_H 1 @@ -88,6 +88,16 @@ */ @LWRES_PLATFORM_NEEDSPRINTF@ +/* + * The printf format string modifier to use with lwres_uint64_t values. + */ +@LWRES_PLATFORM_QUADFORMAT@ + +/*! \brief + * Define if this system needs strtoul. + */ +@LWRES_PLATFORM_NEEDSTRTOUL@ + #ifndef LWRES_PLATFORM_USEDECLSPEC #define LIBLWRES_EXTERNAL_DATA #else 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 00000000000..f5d4db28187 --- /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 + +#include +#include + +#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/lwconfig.c b/contrib/bind9/lib/lwres/lwconfig.c index 9fc7825060e..7fc2c5d0efd 100644 --- a/contrib/bind9/lib/lwres/lwconfig.c +++ b/contrib/bind9/lib/lwres/lwconfig.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * 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 @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: lwconfig.c,v 1.33.2.1.2.5 2004/03/08 09:05:10 marka Exp $ */ +/* $Id: lwconfig.c,v 1.33.2.1.2.8 2005/06/08 02:35:21 marka Exp $ */ /*** *** Module for parsing resolv.conf files. @@ -277,6 +277,7 @@ lwres_conf_parsenameserver(lwres_context_t *ctx, FILE *fp) { char word[LWRES_CONFMAXLINELEN]; int res; lwres_conf_t *confdata; + lwres_addr_t address; confdata = &ctx->confdata; @@ -292,10 +293,9 @@ lwres_conf_parsenameserver(lwres_context_t *ctx, FILE *fp) { if (res != EOF && res != '\n') return (LWRES_R_FAILURE); /* Extra junk on line. */ - res = lwres_create_addr(word, - &confdata->nameservers[confdata->nsnext++], 1); - if (res != LWRES_R_SUCCESS) - return (res); + res = lwres_create_addr(word, &address, 1); + if (res == LWRES_R_SUCCESS) + confdata->nameservers[confdata->nsnext++] = address; return (LWRES_R_SUCCESS); } diff --git a/contrib/bind9/lib/lwres/lwinetntop.c b/contrib/bind9/lib/lwres/lwinetntop.c index f4af00d102e..78cd0b033e3 100644 --- a/contrib/bind9/lib/lwres/lwinetntop.c +++ b/contrib/bind9/lib/lwres/lwinetntop.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1996-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -17,7 +17,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = - "$Id: lwinetntop.c,v 1.9.12.3 2004/08/28 06:25:24 marka Exp $"; + "$Id: lwinetntop.c,v 1.9.12.5 2005/11/04 00:16:34 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -126,7 +126,9 @@ inet_ntop6(const unsigned char *src, char *dst, size_t size) { for (i = 0; i < NS_IN6ADDRSZ; i++) words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3)); best.base = -1; + best.len = 0; cur.base = -1; + cur.len = 0; for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) { if (words[i] == 0) { if (cur.base == -1) diff --git a/contrib/bind9/lib/lwres/lwinetpton.c b/contrib/bind9/lib/lwres/lwinetpton.c index 280b077cefc..e24334b1c82 100644 --- a/contrib/bind9/lib/lwres/lwinetpton.c +++ b/contrib/bind9/lib/lwres/lwinetpton.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1996-2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static char rcsid[] = "$Id: lwinetpton.c,v 1.6.206.1 2004/03/06 08:15:32 marka Exp $"; +static char rcsid[] = "$Id: lwinetpton.c,v 1.6.206.3 2005/03/31 23:56:15 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include @@ -129,7 +129,7 @@ inet_pton6(const char *src, unsigned char *dst) { xdigits_u[] = "0123456789ABCDEF"; unsigned char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp; const char *xdigits, *curtok; - int ch, saw_xdigit; + int ch, seen_xdigits; unsigned int val; memset((tp = tmp), '\0', NS_IN6ADDRSZ); @@ -140,7 +140,7 @@ inet_pton6(const char *src, unsigned char *dst) { if (*++src != ':') return (0); curtok = src; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; while ((ch = *src++) != '\0') { const char *pch; @@ -150,14 +150,13 @@ inet_pton6(const char *src, unsigned char *dst) { if (pch != NULL) { val <<= 4; val |= (pch - xdigits); - if (val > 0xffff) + if (++seen_xdigits > 4) return (0); - saw_xdigit = 1; continue; } if (ch == ':') { curtok = src; - if (!saw_xdigit) { + if (!seen_xdigits) { if (colonp) return (0); colonp = tp; @@ -167,19 +166,19 @@ inet_pton6(const char *src, unsigned char *dst) { return (0); *tp++ = (unsigned char) (val >> 8) & 0xff; *tp++ = (unsigned char) val & 0xff; - saw_xdigit = 0; + seen_xdigits = 0; val = 0; continue; } if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) && inet_pton4(curtok, tp) > 0) { tp += NS_INADDRSZ; - saw_xdigit = 0; + seen_xdigits = 0; break; /* '\0' was seen by inet_pton4(). */ } return (0); } - if (saw_xdigit) { + if (seen_xdigits) { if (tp + NS_INT16SZ > endp) return (0); *tp++ = (unsigned char) (val >> 8) & 0xff; diff --git a/contrib/bind9/lib/lwres/man/lwres.3 b/contrib/bind9/lib/lwres/man/lwres.3 index ad125d26d01..3411eac92b8 100644 --- a/contrib/bind9/lib/lwres/man/lwres.3 +++ b/contrib/bind9/lib/lwres/man/lwres.3 @@ -1,144 +1,142 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres.3,v 1.15.206.1 2004/03/06 07:41:42 marka Exp $ +.\" $Id: lwres.3,v 1.15.206.5 2005/10/13 02:33:58 marka Exp $ .\" -.TH "LWRES" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres \- introduction to the lightweight resolver library -.SH SYNOPSIS -\fB#include \fR +.SH "SYNOPSIS" +.nf +#include +.fi .SH "DESCRIPTION" .PP -The BIND 9 lightweight resolver library is a simple, name service -independent stub resolver library. It provides hostname-to-address -and address-to-hostname lookup services to applications by -transmitting lookup requests to a resolver daemon +The BIND 9 lightweight resolver library is a simple, name service independent stub resolver library. It provides hostname\-to\-address and address\-to\-hostname lookup services to applications by transmitting lookup requests to a resolver daemon \fBlwresd\fR -running on the local host. The resover daemon performs the -lookup using the DNS or possibly other name service protocols, -and returns the results to the application through the library. -The library and resolver daemon communicate using a simple -UDP-based protocol. +running on the local host. The resover daemon performs the lookup using the DNS or possibly other name service protocols, and returns the results to the application through the library. The library and resolver daemon communicate using a simple UDP\-based protocol. .SH "OVERVIEW" .PP -The lwresd library implements multiple name service APIs. -The standard +The lwresd library implements multiple name service APIs. The standard \fBgethostbyname()\fR, \fBgethostbyaddr()\fR, \fBgethostbyname_r()\fR, \fBgethostbyaddr_r()\fR, \fBgetaddrinfo()\fR, -\fBgetipnodebyname()\fR, -and +\fBgetipnodebyname()\fR, and \fBgetipnodebyaddr()\fR -functions are all supported. To allow the lwres library to coexist -with system libraries that define functions of the same name, -the library defines these functions with names prefixed by -lwres_. -To define the standard names, applications must include the -header file +functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by +lwres_. To define the standard names, applications must include the header file \fI\fR -which contains macro definitions mapping the standard function names -into +which contains macro definitions mapping the standard function names into lwres_ -prefixed ones. Operating system vendors who integrate the lwres -library into their base distributions should rename the functions -in the library proper so that the renaming macros are not needed. +prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions in the library proper so that the renaming macros are not needed. .PP The library also provides a native API consisting of the functions \fBlwres_getaddrsbyname()\fR and -\fBlwres_getnamebyaddr()\fR. -These may be called by applications that require more detailed -control over the lookup process than the standard functions -provide. +\fBlwres_getnamebyaddr()\fR. These may be called by applications that require more detailed control over the lookup process than the standard functions provide. .PP -In addition to these name service independent address lookup -functions, the library implements a new, experimental API -for looking up arbitrary DNS resource records, using the +In addition to these name service independent address lookup functions, the library implements a new, experimental API for looking up arbitrary DNS resource records, using the \fBlwres_getaddrsbyname()\fR function. .PP -Finally, there is a low-level API for converting lookup -requests and responses to and from raw lwres protocol packets. -This API can be used by clients requiring nonblocking operation, -and is also used when implementing the server side of the lwres -protocol, for example in the +Finally, there is a low\-level API for converting lookup requests and responses to and from raw lwres protocol packets. This API can be used by clients requiring nonblocking operation, and is also used when implementing the server side of the lwres protocol, for example in the \fBlwresd\fR -resolver daemon. The use of this low-level API in clients -and servers is outlined in the following sections. -.SH "CLIENT-SIDE LOW-LEVEL API CALL FLOW" +resolver daemon. The use of this low\-level API in clients and servers is outlined in the following sections. +.SH "CLIENT\-SIDE LOW\-LEVEL API CALL FLOW" .PP -When a client program wishes to make an lwres request using the -native low-level API, it typically performs the following -sequence of actions. +When a client program wishes to make an lwres request using the native low\-level API, it typically performs the following sequence of actions. .PP -(1) Allocate or use an existing \fBlwres_packet_t\fR, -called pkt below. +(1) Allocate or use an existing +\fBlwres_packet_t\fR, called +\fIpkt\fR +below. .PP -(2) Set \fBpkt.recvlength\fR to the maximum length we will accept. -This is done so the receiver of our packets knows how large our receive -buffer is. The "default" is a constant in -\fIlwres.h\fR: LWRES_RECVLENGTH = 4096. +(2) Set +pkt.recvlength +to the maximum length we will accept. This is done so the receiver of our packets knows how large our receive buffer is. The "default" is a constant in +\fIlwres.h\fR: +\fBLWRES_RECVLENGTH = 4096\fR. .PP -(3) Set \fBpkt.serial\fR -to a unique serial number. This value is echoed -back to the application by the remote server. +(3) Set +pkt.serial +to a unique serial number. This value is echoed back to the application by the remote server. .PP -(4) Set \fBpkt.pktflags\fR. Usually this is set to 0. +(4) Set +pkt.pktflags. Usually this is set to 0. .PP -(5) Set \fBpkt.result\fR to 0. +(5) Set +pkt.result +to 0. .PP -(6) Call \fBlwres_*request_render()\fR, -or marshall in the data using the primitives -such as \fBlwres_packet_render()\fR +(6) Call +\fBlwres_*request_render()\fR, or marshall in the data using the primitives such as +\fBlwres_packet_render()\fR and storing the packet data. .PP (7) Transmit the resulting buffer. .PP -(8) Call \fBlwres_*response_parse()\fR +(8) Call +\fBlwres_*response_parse()\fR to parse any packets received. .PP -(9) Verify that the opcode and serial match a request, and process the -packet specific information contained in the body. -.SH "SERVER-SIDE LOW-LEVEL API CALL FLOW" +(9) Verify that the opcode and serial match a request, and process the packet specific information contained in the body. +.SH "SERVER\-SIDE LOW\-LEVEL API CALL FLOW" .PP -When implementing the server side of the lightweight resolver -protocol using the lwres library, a sequence of actions like the -following is typically involved in processing each request packet. +When implementing the server side of the lightweight resolver protocol using the lwres library, a sequence of actions like the following is typically involved in processing each request packet. .PP -Note that the same \fBlwres_packet_t\fR is used -in both the \fB_parse()\fR and \fB_render()\fR calls, -with only a few modifications made -to the packet header's contents between uses. This method is recommended -as it keeps the serial, opcode, and other fields correct. +Note that the same +\fBlwres_packet_t\fR +is used in both the +\fB_parse()\fR +and +\fB_render()\fR +calls, with only a few modifications made to the packet header's contents between uses. This method is recommended as it keeps the serial, opcode, and other fields correct. .PP -(1) When a packet is received, call \fBlwres_*request_parse()\fR to -unmarshall it. This returns a \fBlwres_packet_t\fR (also called pkt, below) -as well as a data specific type, such as \fBlwres_gabnrequest_t\fR. +(1) When a packet is received, call +\fBlwres_*request_parse()\fR +to unmarshall it. This returns a +\fBlwres_packet_t\fR +(also called +\fIpkt\fR, below) as well as a data specific type, such as +\fBlwres_gabnrequest_t\fR. .PP (2) Process the request in the data specific type. .PP -(3) Set the \fBpkt.result\fR, -\fBpkt.recvlength\fR as above. All other fields can -be left untouched since they were filled in by the \fB*_parse()\fR call -above. If using \fBlwres_*response_render()\fR, -\fBpkt.pktflags\fR will be set up -properly. Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be -set. +(3) Set the +pkt.result, +pkt.recvlength +as above. All other fields can be left untouched since they were filled in by the +\fB*_parse()\fR +call above. If using +\fBlwres_*response_render()\fR, +pkt.pktflags +will be set up properly. Otherwise, the +\fBLWRES_LWPACKETFLAG_RESPONSE\fR +bit should be set. .PP (4) Call the data specific rendering function, such as \fBlwres_gabnresponse_render()\fR. diff --git a/contrib/bind9/lib/lwres/man/lwres.docbook b/contrib/bind9/lib/lwres/man/lwres.docbook index 511d82e91ea..83258a9dd74 100644 --- a/contrib/bind9/lib/lwres/man/lwres.docbook +++ b/contrib/bind9/lib/lwres/man/lwres.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -28,6 +30,20 @@ 3 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres introduction to the lightweight resolver library diff --git a/contrib/bind9/lib/lwres/man/lwres.html b/contrib/bind9/lib/lwres/man/lwres.html index 793ab72a526..1d5e57bfd24 100644 --- a/contrib/bind9/lib/lwres/man/lwres.html +++ b/contrib/bind9/lib/lwres/man/lwres.html @@ -1,433 +1,216 @@ - - - - -lwres

lwres

Name

lwres -- introduction to the lightweight resolver library

Synopsis

#include <lwres/lwres.h>

DESCRIPTION

The BIND 9 lightweight resolver library is a simple, name service + + + + +lwres + + +

+
+
+

Name

+

lwres — introduction to the lightweight resolver library

+
+
+

Synopsis

+
#include <lwres/lwres.h>
+
+
+

DESCRIPTION

+

+The BIND 9 lightweight resolver library is a simple, name service independent stub resolver library. It provides hostname-to-address and address-to-hostname lookup services to applications by transmitting lookup requests to a resolver daemon -lwresd +lwresd running on the local host. The resover daemon performs the lookup using the DNS or possibly other name service protocols, and returns the results to the application through the library. The library and resolver daemon communicate using a simple -UDP-based protocol.

OVERVIEW

The lwresd library implements multiple name service APIs. +UDP-based protocol. +

+
+
+

OVERVIEW

+

+The lwresd library implements multiple name service APIs. The standard -gethostbyname(), -gethostbyaddr(), -gethostbyname_r(), -gethostbyaddr_r(), -getaddrinfo(), -getipnodebyname(), +gethostbyname(), +gethostbyaddr(), +gethostbyname_r(), +gethostbyaddr_r(), +getaddrinfo(), +getipnodebyname(), and -getipnodebyaddr() +getipnodebyaddr() functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by -lwres_. +lwres_. To define the standard names, applications must include the header file -<lwres/netdb.h> +<lwres/netdb.h> which contains macro definitions mapping the standard function names into -lwres_ +lwres_ prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions -in the library proper so that the renaming macros are not needed.

The library also provides a native API consisting of the functions -lwres_getaddrsbyname() +in the library proper so that the renaming macros are not needed. +

+

+The library also provides a native API consisting of the functions +lwres_getaddrsbyname() and -lwres_getnamebyaddr(). +lwres_getnamebyaddr(). These may be called by applications that require more detailed control over the lookup process than the standard functions -provide.

In addition to these name service independent address lookup +provide. +

+

+In addition to these name service independent address lookup functions, the library implements a new, experimental API for looking up arbitrary DNS resource records, using the -lwres_getaddrsbyname() -function.

Finally, there is a low-level API for converting lookup +lwres_getaddrsbyname() +function. +

+

+Finally, there is a low-level API for converting lookup requests and responses to and from raw lwres protocol packets. This API can be used by clients requiring nonblocking operation, and is also used when implementing the server side of the lwres protocol, for example in the -lwresd +lwresd resolver daemon. The use of this low-level API in clients -and servers is outlined in the following sections.

CLIENT-SIDE LOW-LEVEL API CALL FLOW

When a client program wishes to make an lwres request using the +and servers is outlined in the following sections. +

+
+
+

CLIENT-SIDE LOW-LEVEL API CALL FLOW

+

+When a client program wishes to make an lwres request using the native low-level API, it typically performs the following -sequence of actions.

(1) Allocate or use an existing lwres_packet_t, -called pkt below.

(2) Set pkt.recvlength to the maximum length we will accept. +sequence of actions. +

+

+(1) Allocate or use an existing lwres_packet_t, +called pkt below. +

+

+(2) Set pkt.recvlength to the maximum length we will accept. This is done so the receiver of our packets knows how large our receive buffer is. The "default" is a constant in -lwres.h: LWRES_RECVLENGTH = 4096.

(3) Set pkt.serial +lwres.h: LWRES_RECVLENGTH = 4096. +

+

+(3) Set pkt.serial to a unique serial number. This value is echoed -back to the application by the remote server.

(4) Set pkt.pktflags. Usually this is set to 0.

(5) Set pkt.result to 0.

(6) Call lwres_*request_render(), +back to the application by the remote server. +

+

+(4) Set pkt.pktflags. Usually this is set to 0. +

+

+(5) Set pkt.result to 0. +

+

+(6) Call lwres_*request_render(), or marshall in the data using the primitives -such as lwres_packet_render() -and storing the packet data.

(7) Transmit the resulting buffer.

(8) Call lwres_*response_parse() -to parse any packets received.

(9) Verify that the opcode and serial match a request, and process the -packet specific information contained in the body.

SERVER-SIDE LOW-LEVEL API CALL FLOW

When implementing the server side of the lightweight resolver +such as lwres_packet_render() +and storing the packet data. +

+

+(7) Transmit the resulting buffer. +

+

+(8) Call lwres_*response_parse() +to parse any packets received. +

+

+(9) Verify that the opcode and serial match a request, and process the +packet specific information contained in the body. +

+
+
+

SERVER-SIDE LOW-LEVEL API CALL FLOW

+

+When implementing the server side of the lightweight resolver protocol using the lwres library, a sequence of actions like the -following is typically involved in processing each request packet.

Note that the same lwres_packet_t is used -in both the _parse() and _render() calls, +following is typically involved in processing each request packet. +

+

+Note that the same lwres_packet_t is used +in both the _parse() and _render() calls, with only a few modifications made to the packet header's contents between uses. This method is recommended -as it keeps the serial, opcode, and other fields correct.

(1) When a packet is received, call lwres_*request_parse() to -unmarshall it. This returns a lwres_packet_t (also called pkt, below) -as well as a data specific type, such as lwres_gabnrequest_t.

(2) Process the request in the data specific type.

(3) Set the pkt.result, -pkt.recvlength as above. All other fields can -be left untouched since they were filled in by the *_parse() call -above. If using lwres_*response_render(), -pkt.pktflags will be set up -properly. Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be -set.

(4) Call the data specific rendering function, such as -lwres_gabnresponse_render().

(5) Send the resulting packet to the client.

SEE ALSO

lwres_gethostent(3), +as it keeps the serial, opcode, and other fields correct. +

+

+(1) When a packet is received, call lwres_*request_parse() to +unmarshall it. This returns a lwres_packet_t (also called pkt, below) +as well as a data specific type, such as lwres_gabnrequest_t. +

+

+(2) Process the request in the data specific type. +

+

+(3) Set the pkt.result, +pkt.recvlength as above. All other fields can +be left untouched since they were filled in by the *_parse() call +above. If using lwres_*response_render(), +pkt.pktflags will be set up +properly. Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be +set. +

+

+(4) Call the data specific rendering function, such as +lwres_gabnresponse_render(). +

+

+(5) Send the resulting packet to the client. +

+

+

+
+
+

SEE ALSO

+

+lwres_gethostent(3), -lwres_getipnode(3), +lwres_getipnode(3), -lwres_getnameinfo(3), +lwres_getnameinfo(3), -lwres_noop(3), +lwres_noop(3), -lwres_gabn(3), +lwres_gabn(3), -lwres_gnba(3), +lwres_gnba(3), -lwres_context(3), +lwres_context(3), -lwres_config(3), +lwres_config(3), -resolver(5), +resolver(5), -lwresd(8).

+lwresd(8). + +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.3 b/contrib/bind9/lib/lwres/man/lwres_buffer.3 index 232742aa070..93e888b0c38 100644 --- a/contrib/bind9/lib/lwres/man/lwres_buffer.3 +++ b/contrib/bind9/lib/lwres/man/lwres_buffer.3 @@ -1,174 +1,117 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_buffer.3,v 1.12.2.1.8.1 2004/03/06 07:41:42 marka Exp $ +.\" $Id: lwres_buffer.3,v 1.12.2.1.8.5 2005/10/13 02:33:58 marka Exp $ .\" -.TH "LWRES_BUFFER" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_BUFFER" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem \- lightweight resolver buffer management -.SH SYNOPSIS -\fB#include -.sp -.na -void -lwres_buffer_init(lwres_buffer_t *b, void *base, unsigned int length); -.ad -.sp -.na -void -lwres_buffer_invalidate(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_add(lwres_buffer_t *b, unsigned int n); -.ad -.sp -.na -void -lwres_buffer_subtract(lwres_buffer_t *b, unsigned int n); -.ad -.sp -.na -void -lwres_buffer_clear(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_first(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_forward(lwres_buffer_t *b, unsigned int n); -.ad -.sp -.na -void -lwres_buffer_back(lwres_buffer_t *b, unsigned int n); -.ad -.sp -.na -lwres_uint8_t -lwres_buffer_getuint8(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_putuint8(lwres_buffer_t *b, lwres_uint8_t val); -.ad -.sp -.na -lwres_uint16_t -lwres_buffer_getuint16(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_putuint16(lwres_buffer_t *b, lwres_uint16_t val); -.ad -.sp -.na -lwres_uint32_t -lwres_buffer_getuint32(lwres_buffer_t *b); -.ad -.sp -.na -void -lwres_buffer_putuint32(lwres_buffer_t *b, lwres_uint32_t val); -.ad -.sp -.na -void -lwres_buffer_putmem(lwres_buffer_t *b, const unsigned char *base, unsigned int length); -.ad -.sp -.na -void -lwres_buffer_getmem(lwres_buffer_t *b, unsigned char *base, unsigned int length); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 23 +\fBvoid\ \fBlwres_buffer_init\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBvoid\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR +.HP 29 +\fBvoid\ \fBlwres_buffer_invalidate\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 22 +\fBvoid\ \fBlwres_buffer_add\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR +.HP 27 +\fBvoid\ \fBlwres_buffer_subtract\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR +.HP 24 +\fBvoid\ \fBlwres_buffer_clear\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 24 +\fBvoid\ \fBlwres_buffer_first\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 26 +\fBvoid\ \fBlwres_buffer_forward\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR +.HP 23 +\fBvoid\ \fBlwres_buffer_back\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR +.HP 36 +\fBlwres_uint8_t\ \fBlwres_buffer_getuint8\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 27 +\fBvoid\ \fBlwres_buffer_putuint8\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint8_t\ val\fR\fB);\fR +.HP 38 +\fBlwres_uint16_t\ \fBlwres_buffer_getuint16\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_buffer_putuint16\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint16_t\ val\fR\fB);\fR +.HP 38 +\fBlwres_uint32_t\ \fBlwres_buffer_getuint32\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_buffer_putuint32\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint32_t\ val\fR\fB);\fR +.HP 25 +\fBvoid\ \fBlwres_buffer_putmem\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBconst\ unsigned\ char\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR +.HP 25 +\fBvoid\ \fBlwres_buffer_getmem\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ char\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR .SH "DESCRIPTION" .PP -These functions provide bounds checked access to a region of memory -where data is being read or written. -They are based on, and similar to, the +These functions provide bounds checked access to a region of memory where data is being read or written. They are based on, and similar to, the isc_buffer_ functions in the ISC library. .PP -A buffer is a region of memory, together with a set of related -subregions. -The \fBused region\fR and the -\fBavailable\fR region are disjoint, and -their union is the buffer's region. -The used region extends from the beginning of the buffer region to the -last used byte. -The available region extends from one byte greater than the last used -byte to the end of the buffer's region. -The size of the used region can be changed using various -buffer commands. -Initially, the used region is empty. +A buffer is a region of memory, together with a set of related subregions. The +\fIused region\fR +and the +\fIavailable\fR +region are disjoint, and their union is the buffer's region. The used region extends from the beginning of the buffer region to the last used byte. The available region extends from one byte greater than the last used byte to the end of the buffer's region. The size of the used region can be changed using various buffer commands. Initially, the used region is empty. .PP The used region is further subdivided into two disjoint regions: the -\fBconsumed region\fR and the \fBremaining region\fR. -The union of these two regions is the used region. -The consumed region extends from the beginning of the used region to -the byte before the \fBcurrent\fR offset (if any). -The \fBremaining\fR region the current pointer to the end of the used -region. -The size of the consumed region can be changed using various -buffer commands. -Initially, the consumed region is empty. +\fIconsumed region\fR +and the +\fIremaining region\fR. The union of these two regions is the used region. The consumed region extends from the beginning of the used region to the byte before the +\fIcurrent\fR +offset (if any). The +\fIremaining\fR +region the current pointer to the end of the used region. The size of the consumed region can be changed using various buffer commands. Initially, the consumed region is empty. .PP -The \fBactive region\fR is an (optional) subregion of the remaining -region. -It extends from the current offset to an offset in the -remaining region. -Initially, the active region is empty. -If the current offset advances beyond the chosen offset, -the active region will also be empty. +The +\fIactive region\fR +is an (optional) subregion of the remaining region. It extends from the current offset to an offset in the remaining region. Initially, the active region is empty. If the current offset advances beyond the chosen offset, the active region will also be empty. .PP -.sp .nf - - /------------entire length---------------\\\\ - /----- used region -----\\\\/-- available --\\\\ - +----------------------------------------+ + /\-\-\-\-\-\-\-\-\-\-\-\-entire length\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\\\\ + /\-\-\-\-\- used region \-\-\-\-\-\\\\/\-\- available \-\-\\\\ + +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | consumed | remaining | | - +----------------------------------------+ + +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ a b c d e - a == base of buffer. b == current pointer. Can be anywhere between a and d. c == active pointer. Meaningful between b and d. d == used pointer. e == length of buffer. - - a-e == entire length of buffer. - a-d == used region. - a-b == consumed region. - b-d == remaining region. - b-c == optional active region. -.sp + a\-e == entire length of buffer. + a\-d == used region. + a\-b == consumed region. + b\-d == remaining region. + b\-c == optional active region. .fi +.sp .PP \fBlwres_buffer_init()\fR initializes the -\fBlwres_buffer_t\fR -\fI*b\fR +\fBlwres_buffer_t\fR\fI*b\fR and assocates it with the memory region of size \fIlength\fR bytes starting at location @@ -177,15 +120,13 @@ bytes starting at location \fBlwres_buffer_invalidate()\fR marks the buffer \fI*b\fR -as invalid. Invalidating a buffer after use is not required, -but makes it possible to catch its possible accidental use. +as invalid. Invalidating a buffer after use is not required, but makes it possible to catch its possible accidental use. .PP The functions \fBlwres_buffer_add()\fR and \fBlwres_buffer_subtract()\fR -respectively increase and decrease the used space in -buffer +respectively increase and decrease the used space in buffer \fI*b\fR by \fIn\fR @@ -193,25 +134,23 @@ bytes. \fBlwres_buffer_add()\fR checks for buffer overflow and \fBlwres_buffer_subtract()\fR -checks for underflow. -These functions do not allocate or deallocate memory. -They just change the value of -\fBused\fR. +checks for underflow. These functions do not allocate or deallocate memory. They just change the value of +used. .PP -A buffer is re-initialised by -\fBlwres_buffer_clear()\fR. -The function sets -\fBused\fR , -\fBcurrent\fR +A buffer is re\-initialised by +\fBlwres_buffer_clear()\fR. The function sets +used +, +current and -\fBactive\fR +active to zero. .PP \fBlwres_buffer_first\fR makes the consumed region of buffer \fI*p\fR empty by setting -\fBcurrent\fR +current to zero (the start of the buffer). .PP \fBlwres_buffer_forward()\fR @@ -219,21 +158,19 @@ increases the consumed region of buffer \fI*b\fR by \fIn\fR -bytes, checking for overflow. -Similarly, +bytes, checking for overflow. Similarly, \fBlwres_buffer_back()\fR decreases buffer -\fIb\fR's -consumed region by +\fIb\fR's consumed region by \fIn\fR bytes and checks for underflow. .PP \fBlwres_buffer_getuint8()\fR -reads an unsigned 8-bit integer from +reads an unsigned 8\-bit integer from \fI*b\fR and returns it. \fBlwres_buffer_putuint8()\fR -writes the unsigned 8-bit integer +writes the unsigned 8\-bit integer \fIval\fR to buffer \fI*b\fR. @@ -243,21 +180,17 @@ and \fBlwres_buffer_getuint32()\fR are identical to \fBlwres_buffer_putuint8()\fR -except that they respectively read an unsigned 16-bit or 32-bit integer -in network byte order from -\fIb\fR. -Similarly, +except that they respectively read an unsigned 16\-bit or 32\-bit integer in network byte order from +\fIb\fR. Similarly, \fBlwres_buffer_putuint16()\fR and \fBlwres_buffer_putuint32()\fR -writes the unsigned 16-bit or 32-bit integer +writes the unsigned 16\-bit or 32\-bit integer \fIval\fR to buffer -\fIb\fR, -in network byte order. +\fIb\fR, in network byte order. .PP -Arbitrary amounts of data are read or written from a lightweight -resolver buffer with +Arbitrary amounts of data are read or written from a lightweight resolver buffer with \fBlwres_buffer_getmem()\fR and \fBlwres_buffer_putmem()\fR @@ -268,8 +201,7 @@ copies bytes of memory at \fIbase\fR to -\fIb\fR. -Conversely, +\fIb\fR. Conversely, \fBlwres_buffer_getmem()\fR copies \fIlength\fR diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook index 4db9fd3acdb..c70aee508e7 100644 --- a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_buffer_init lwres_buffer_invalidate diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.html b/contrib/bind9/lib/lwres/man/lwres_buffer.html index 79354fc0559..5a203f1a15a 100644 --- a/contrib/bind9/lib/lwres/man/lwres_buffer.html +++ b/contrib/bind9/lib/lwres/man/lwres_buffer.html @@ -1,232 +1,267 @@ - - - - -lwres_buffer

lwres_buffer

Name

lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem -- lightweight resolver buffer management

Synopsis

#include <lwres/lwbuffer.h>

void -lwres_buffer_init(lwres_buffer_t *b, void *base, unsigned int length);

void -lwres_buffer_invalidate(lwres_buffer_t *b);

void -lwres_buffer_add(lwres_buffer_t *b, unsigned int n);

void -lwres_buffer_subtract(lwres_buffer_t *b, unsigned int n);

void -lwres_buffer_clear(lwres_buffer_t *b);

void -lwres_buffer_first(lwres_buffer_t *b);

void -lwres_buffer_forward(lwres_buffer_t *b, unsigned int n);

void -lwres_buffer_back(lwres_buffer_t *b, unsigned int n);

lwres_uint8_t -lwres_buffer_getuint8(lwres_buffer_t *b);

void -lwres_buffer_putuint8(lwres_buffer_t *b, lwres_uint8_t val);

lwres_uint16_t -lwres_buffer_getuint16(lwres_buffer_t *b);

void -lwres_buffer_putuint16(lwres_buffer_t *b, lwres_uint16_t val);

lwres_uint32_t -lwres_buffer_getuint32(lwres_buffer_t *b);

void -lwres_buffer_putuint32(lwres_buffer_t *b, lwres_uint32_t val);

void -lwres_buffer_putmem(lwres_buffer_t *b, const unsigned char *base, unsigned int length);

void -lwres_buffer_getmem(lwres_buffer_t *b, unsigned char *base, unsigned int length);

DESCRIPTION

These functions provide bounds checked access to a region of memory + + + + +lwres_buffer + + +

+
+
+

Name

+

lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem — lightweight resolver buffer management

+
+
+

Synopsis

+
+
+#include <lwres/lwbuffer.h>
+
+ + + + + + + + + + + + + + + + +
+void +lwres_buffer_init( ,
  ,
   +);
+ + + + +
+void +lwres_buffer_invalidate(  +);
+ + + + + + + + + + + +
+void +lwres_buffer_add( ,
   +);
+ + + + + + + + + + + +
+void +lwres_buffer_subtract( ,
   +);
+ + + + +
+void +lwres_buffer_clear(  +);
+ + + + +
+void +lwres_buffer_first(  +);
+ + + + + + + + + + + +
+void +lwres_buffer_forward( ,
   +);
+ + + + + + + + + + + +
+void +lwres_buffer_back( ,
   +);
+ + + + +
+lwres_uint8_t +lwres_buffer_getuint8(  +);
+ + + + + + + + + + + +
+void +lwres_buffer_putuint8( ,
   +);
+ + + + +
+lwres_uint16_t +lwres_buffer_getuint16(  +);
+ + + + + + + + + + + +
+void +lwres_buffer_putuint16( ,
   +);
+ + + + +
+lwres_uint32_t +lwres_buffer_getuint32(  +);
+ + + + + + + + + + + +
+void +lwres_buffer_putuint32( ,
   +);
+ + + + + + + + + + + + + + + + +
+void +lwres_buffer_putmem( ,
  ,
   +);
+ + + + + + + + + + + + + + + + +
+void +lwres_buffer_getmem( ,
  ,
   +);
+
+
+
+

DESCRIPTION

+

+These functions provide bounds checked access to a region of memory where data is being read or written. They are based on, and similar to, the -isc_buffer_ -functions in the ISC library.

A buffer is a region of memory, together with a set of related +isc_buffer_ +functions in the ISC library. +

+

+A buffer is a region of memory, together with a set of related subregions. -The used region and the -available region are disjoint, and +The used region and the +available region are disjoint, and their union is the buffer's region. The used region extends from the beginning of the buffer region to the last used byte. @@ -234,60 +269,33 @@ The available region extends from one byte greater than the last used byte to the end of the buffer's region. The size of the used region can be changed using various buffer commands. -Initially, the used region is empty.

The used region is further subdivided into two disjoint regions: the -consumed region and the remaining region. +Initially, the used region is empty. +

+

+The used region is further subdivided into two disjoint regions: the +consumed region and the remaining region. The union of these two regions is the used region. The consumed region extends from the beginning of the used region to -the byte before the current offset (if any). -The remaining region the current pointer to the end of the used +the byte before the current offset (if any). +The remaining region the current pointer to the end of the used region. The size of the consumed region can be changed using various buffer commands. -Initially, the consumed region is empty.

The active region is an (optional) subregion of the remaining +Initially, the consumed region is empty. +

+

+The active region is an (optional) subregion of the remaining region. It extends from the current offset to an offset in the remaining region. Initially, the active region is empty. If the current offset advances beyond the chosen offset, -the active region will also be empty.

 
+the active region will also be empty.
+

+

+

+
+ 
    /------------entire length---------------\\
    /----- used region -----\\/-- available --\\
    +----------------------------------------+
@@ -305,272 +313,132 @@ CLASS="PROGRAMLISTING"
   a-d == used region.
   a-b == consumed region.
   b-d == remaining region.
-  b-c == optional active region.
lwres_buffer_init()
+  b-c == optional active region.
+
+

+

+

+lwres_buffer_init() initializes the -lwres_buffer_t -*b +lwres_buffer_t +*b and assocates it with the memory region of size -length +length bytes starting at location -base.

lwres_buffer_invalidate() +base. +

+

+lwres_buffer_invalidate() marks the buffer -*b +*b as invalid. Invalidating a buffer after use is not required, -but makes it possible to catch its possible accidental use.

The functions -lwres_buffer_add() +but makes it possible to catch its possible accidental use. +

+

+The functions +lwres_buffer_add() and -lwres_buffer_subtract() +lwres_buffer_subtract() respectively increase and decrease the used space in buffer -*b +*b by -n +n bytes. -lwres_buffer_add() +lwres_buffer_add() checks for buffer overflow and -lwres_buffer_subtract() +lwres_buffer_subtract() checks for underflow. These functions do not allocate or deallocate memory. They just change the value of -used.

A buffer is re-initialised by -lwres_buffer_clear(). +used. +

+

+A buffer is re-initialised by +lwres_buffer_clear(). The function sets -used , -current +used , +current and -active -to zero.

lwres_buffer_first +active +to zero. +

+

+lwres_buffer_first makes the consumed region of buffer -*p +*p empty by setting -current -to zero (the start of the buffer).

lwres_buffer_forward() +current +to zero (the start of the buffer). +

+

+lwres_buffer_forward() increases the consumed region of buffer -*b +*b by -n +n bytes, checking for overflow. Similarly, -lwres_buffer_back() +lwres_buffer_back() decreases buffer -b's +b's consumed region by -n -bytes and checks for underflow.

lwres_buffer_getuint8() +n +bytes and checks for underflow. +

+

+lwres_buffer_getuint8() reads an unsigned 8-bit integer from -*b +*b and returns it. -lwres_buffer_putuint8() +lwres_buffer_putuint8() writes the unsigned 8-bit integer -val +val to buffer -*b.

lwres_buffer_getuint16() +*b. +

+

+lwres_buffer_getuint16() and -lwres_buffer_getuint32() +lwres_buffer_getuint32() are identical to -lwres_buffer_putuint8() +lwres_buffer_putuint8() except that they respectively read an unsigned 16-bit or 32-bit integer in network byte order from -b. +b. Similarly, -lwres_buffer_putuint16() +lwres_buffer_putuint16() and -lwres_buffer_putuint32() +lwres_buffer_putuint32() writes the unsigned 16-bit or 32-bit integer -val +val to buffer -b, -in network byte order.

Arbitrary amounts of data are read or written from a lightweight +b, +in network byte order. +

+

+Arbitrary amounts of data are read or written from a lightweight resolver buffer with -lwres_buffer_getmem() +lwres_buffer_getmem() and -lwres_buffer_putmem() +lwres_buffer_putmem() respectively. -lwres_buffer_putmem() +lwres_buffer_putmem() copies -length +length bytes of memory at -base +base to -b. +b. Conversely, -lwres_buffer_getmem() +lwres_buffer_getmem() copies -length +length bytes of memory from -b +b to -base.

+base. +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_config.3 b/contrib/bind9/lib/lwres/man/lwres_config.3 index 0c345efa979..94302837518 100644 --- a/contrib/bind9/lib/lwres/man/lwres_config.3 +++ b/contrib/bind9/lib/lwres/man/lwres_config.3 @@ -1,51 +1,47 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_config.3,v 1.12.2.1.8.1 2004/03/06 07:41:42 marka Exp $ +.\" $Id: lwres_config.3,v 1.12.2.1.8.5 2005/10/13 02:33:58 marka Exp $ .\" -.TH "LWRES_CONFIG" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_CONFIG" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get \- lightweight resolver configuration -.SH SYNOPSIS -\fB#include -.sp -.na -void -lwres_conf_init(lwres_context_t *ctx); -.ad -.sp -.na -void -lwres_conf_clear(lwres_context_t *ctx); -.ad -.sp -.na -lwres_result_t -lwres_conf_parse(lwres_context_t *ctx, const char *filename); -.ad -.sp -.na -lwres_result_t -lwres_conf_print(lwres_context_t *ctx, FILE *fp); -.ad -.sp -.na -lwres_conf_t * -lwres_conf_get(lwres_context_t *ctx); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 21 +\fBvoid\ \fBlwres_conf_init\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR +.HP 22 +\fBvoid\ \fBlwres_conf_clear\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR +.HP 32 +\fBlwres_result_t\ \fBlwres_conf_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBconst\ char\ *filename\fR\fB);\fR +.HP 32 +\fBlwres_result_t\ \fBlwres_conf_print\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBFILE\ *fp\fR\fB);\fR +.HP 30 +\fBlwres_conf_t\ *\ \fBlwres_conf_get\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR .SH "DESCRIPTION" .PP \fBlwres_conf_init()\fR @@ -55,8 +51,7 @@ structure for lightweight resolver context \fIctx\fR. .PP \fBlwres_conf_clear()\fR -frees up all the internal memory used by -that +frees up all the internal memory used by that \fBlwres_conf_t\fR structure in resolver context \fIctx\fR. @@ -75,29 +70,24 @@ prints the structure for resolver context \fIctx\fR to the -\fBFILE\fR -\fIfp\fR. +\fBFILE\fR\fIfp\fR. .SH "RETURN VALUES" .PP \fBlwres_conf_parse()\fR returns -LWRES_R_SUCCESS +\fBLWRES_R_SUCCESS\fR if it successfully read and parsed -\fIfilename\fR. -It returns -LWRES_R_FAILURE +\fIfilename\fR. It returns +\fBLWRES_R_FAILURE\fR if \fIfilename\fR -could not be opened or contained incorrect -resolver statements. +could not be opened or contained incorrect resolver statements. .PP \fBlwres_conf_print()\fR returns -LWRES_R_SUCCESS -unless an error occurred when converting the network addresses to a -numeric host address string. -If this happens, the function returns -LWRES_R_FAILURE. +\fBLWRES_R_SUCCESS\fR +unless an error occurred when converting the network addresses to a numeric host address string. If this happens, the function returns +\fBLWRES_R_FAILURE\fR. .SH "SEE ALSO" .PP \fBstdio\fR(3), diff --git a/contrib/bind9/lib/lwres/man/lwres_config.docbook b/contrib/bind9/lib/lwres/man/lwres_config.docbook index eeb244ed40d..03426beb327 100644 --- a/contrib/bind9/lib/lwres/man/lwres_config.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_config.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_conf_init lwres_conf_clear @@ -149,6 +164,7 @@ If this happens, the function returns resolver5 . + FILES diff --git a/contrib/bind9/lib/lwres/man/lwres_config.html b/contrib/bind9/lib/lwres/man/lwres_config.html index cd7c63bee8a..7ea416b62b6 100644 --- a/contrib/bind9/lib/lwres/man/lwres_config.html +++ b/contrib/bind9/lib/lwres/man/lwres_config.html @@ -1,282 +1,166 @@ - - - - -lwres_config

lwres_config

Name

lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get -- lightweight resolver configuration

Synopsis

#include <lwres/lwres.h>

void -lwres_conf_init(lwres_context_t *ctx);

void -lwres_conf_clear(lwres_context_t *ctx);

lwres_result_t -lwres_conf_parse(lwres_context_t *ctx, const char *filename);

lwres_result_t -lwres_conf_print(lwres_context_t *ctx, FILE *fp);

lwres_conf_t * -lwres_conf_get(lwres_context_t *ctx);

DESCRIPTION

lwres_conf_init() + + + + +lwres_config + + +

+
+
+

Name

+

lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get — lightweight resolver configuration

+
+
+

Synopsis

+
+
#include <lwres/lwres.h>
+ + + + +
+void +lwres_conf_init(  +);
+ + + + +
+void +lwres_conf_clear(  +);
+ + + + + + + + + + + +
+lwres_result_t +lwres_conf_parse( ,
   +);
+ + + + + + + + + + + +
+lwres_result_t +lwres_conf_print( ,
   +);
+ + + + +
+lwres_conf_t * +lwres_conf_get(  +);
+
+
+
+

DESCRIPTION

+

+lwres_conf_init() creates an empty -lwres_conf_t +lwres_conf_t structure for lightweight resolver context -ctx.

lwres_conf_clear() +ctx. +

+

+lwres_conf_clear() frees up all the internal memory used by that -lwres_conf_t +lwres_conf_t structure in resolver context -ctx.

lwres_conf_parse() +ctx. +

+

+lwres_conf_parse() opens the file -filename +filename and parses it to initialise the resolver context -ctx's -lwres_conf_t -structure.

lwres_conf_print() +ctx's +lwres_conf_t +structure. +

+

+lwres_conf_print() prints the -lwres_conf_t +lwres_conf_t structure for resolver context -ctx +ctx to the -FILE -fp.

RETURN VALUES

lwres_conf_parse() +FILE +fp. +

+
+
+

RETURN VALUES

+

+lwres_conf_parse() returns -LWRES_R_SUCCESS +LWRES_R_SUCCESS if it successfully read and parsed -filename. +filename. It returns -LWRES_R_FAILURE +LWRES_R_FAILURE if -filename +filename could not be opened or contained incorrect -resolver statements.

lwres_conf_print() +resolver statements. +

+

+lwres_conf_print() returns -LWRES_R_SUCCESS +LWRES_R_SUCCESS unless an error occurred when converting the network addresses to a numeric host address string. If this happens, the function returns -LWRES_R_FAILURE.

SEE ALSO

stdio(3), -resolver(5).

FILES

/etc/resolv.conf

+LWRES_R_FAILURE. +

+
+
+

SEE ALSO

+

+stdio(3), +resolver(5). +

+
+
+

FILES

+

+/etc/resolv.conf +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_context.3 b/contrib/bind9/lib/lwres/man/lwres_context.3 index d19b18a21a0..be8cd387089 100644 --- a/contrib/bind9/lib/lwres/man/lwres_context.3 +++ b/contrib/bind9/lib/lwres/man/lwres_context.3 @@ -1,103 +1,82 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 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, +.\" 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: lwres_context.3,v 1.13.2.2.2.2 2004/03/08 09:05:12 marka Exp $ +.\" $Id: lwres_context.3,v 1.13.2.2.2.6 2005/10/13 02:33:52 marka Exp $ .\" -.TH "LWRES_CONTEXT" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_CONTEXT" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv \- lightweight resolver context management -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_context_create(lwres_context_t **contextp, void *arg, lwres_malloc_t malloc_function, lwres_free_t free_function); -.ad -.sp -.na -lwres_result_t -lwres_context_destroy(lwres_context_t **contextp); -.ad -.sp -.na -void -lwres_context_initserial(lwres_context_t *ctx, lwres_uint32_t serial); -.ad -.sp -.na -lwres_uint32_t -lwres_context_nextserial(lwres_context_t *ctx); -.ad -.sp -.na -void -lwres_context_freemem(lwres_context_t *ctx, void *mem, size_t len); -.ad -.sp -.na -void -lwres_context_allocmem(lwres_context_t *ctx, size_t len); -.ad -.sp -.na -void * -lwres_context_sendrecv(lwres_context_t *ctx, void *sendbase, int sendlen, void *recvbase, int recvlen, int *recvd_len); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 36 +\fBlwres_result_t\ \fBlwres_context_create\fR\fR\fB(\fR\fBlwres_context_t\ **contextp\fR\fB, \fR\fBvoid\ *arg\fR\fB, \fR\fBlwres_malloc_t\ malloc_function\fR\fB, \fR\fBlwres_free_t\ free_function\fR\fB);\fR +.HP 37 +\fBlwres_result_t\ \fBlwres_context_destroy\fR\fR\fB(\fR\fBlwres_context_t\ **contextp\fR\fB);\fR +.HP 30 +\fBvoid\ \fBlwres_context_initserial\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_uint32_t\ serial\fR\fB);\fR +.HP 40 +\fBlwres_uint32_t\ \fBlwres_context_nextserial\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR +.HP 27 +\fBvoid\ \fBlwres_context_freemem\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBvoid\ *mem\fR\fB, \fR\fBsize_t\ len\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_context_allocmem\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBsize_t\ len\fR\fB);\fR +.HP 30 +\fBvoid\ *\ \fBlwres_context_sendrecv\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBvoid\ *sendbase\fR\fB, \fR\fBint\ sendlen\fR\fB, \fR\fBvoid\ *recvbase\fR\fB, \fR\fBint\ recvlen\fR\fB, \fR\fBint\ *recvd_len\fR\fB);\fR .SH "DESCRIPTION" .PP \fBlwres_context_create()\fR creates a \fBlwres_context_t\fR -structure for use in lightweight resolver operations. -It holds a socket and other data needed for communicating -with a resolver daemon. -The new +structure for use in lightweight resolver operations. It holds a socket and other data needed for communicating with a resolver daemon. The new \fBlwres_context_t\fR is returned through -\fIcontextp\fR, -a pointer to a +\fIcontextp\fR, a pointer to a \fBlwres_context_t\fR -pointer. This +pointer. This \fBlwres_context_t\fR -pointer must initially be NULL, and is modified -to point to the newly created +pointer must initially be NULL, and is modified to point to the newly created \fBlwres_context_t\fR. .PP -When the lightweight resolver needs to perform dynamic memory -allocation, it will call +When the lightweight resolver needs to perform dynamic memory allocation, it will call \fImalloc_function\fR to allocate memory and \fIfree_function\fR -to free it. If +to free it. If \fImalloc_function\fR and \fIfree_function\fR -are NULL, memory is allocated using -\&.Xr malloc 3 -and -\fBfree\fR(3). -It is not permitted to have a NULL +are NULL, memory is allocated using .Xr malloc 3 and +\fBfree\fR(3). It is not permitted to have a NULL \fImalloc_function\fR -and a non-NULL +and a non\-NULL \fIfree_function\fR or vice versa. \fIarg\fR -is passed as the first parameter to the memory -allocation functions. -If +is passed as the first parameter to the memory allocation functions. If \fImalloc_function\fR and \fIfree_function\fR @@ -105,23 +84,18 @@ are NULL, \fIarg\fR is unused and should be passed as NULL. .PP -Once memory for the structure has been allocated, -it is initialized using +Once memory for the structure has been allocated, it is initialized using \fBlwres_conf_init\fR(3) and returned via \fI*contextp\fR. .PP \fBlwres_context_destroy()\fR -destroys a -\fBlwres_context_t\fR, -closing its socket. +destroys a +\fBlwres_context_t\fR, closing its socket. \fIcontextp\fR -is a pointer to a pointer to the context that is to be destroyed. -The pointer will be set to NULL when the context has been destroyed. +is a pointer to a pointer to the context that is to be destroyed. The pointer will be set to NULL when the context has been destroyed. .PP -The context holds a serial number that is used to identify resolver -request packets and associate responses with the corresponding requests. -This serial number is controlled using +The context holds a serial number that is used to identify resolver request packets and associate responses with the corresponding requests. This serial number is controlled using \fBlwres_context_initserial()\fR and \fBlwres_context_nextserial()\fR. @@ -136,15 +110,12 @@ increments the serial number and returns the previous value. Memory for a lightweight resolver context is allocated and freed using \fBlwres_context_allocmem()\fR and -\fBlwres_context_freemem()\fR. -These use whatever allocations were defined when the context was -created with +\fBlwres_context_freemem()\fR. These use whatever allocations were defined when the context was created with \fBlwres_context_create()\fR. \fBlwres_context_allocmem()\fR allocates \fIlen\fR -bytes of memory and if successful returns a pointer to the allocated -storage. +bytes of memory and if successful returns a pointer to the allocated storage. \fBlwres_context_freemem()\fR frees \fIlen\fR @@ -153,39 +124,33 @@ bytes of space starting at location .PP \fBlwres_context_sendrecv()\fR performs I/O for the context -\fIctx\fR. -Data are read and written from the context's socket. -It writes data from +\fIctx\fR. Data are read and written from the context's socket. It writes data from \fIsendbase\fR -\(em typically a lightweight resolver query packet \(em -and waits for a reply which is copied to the receive buffer at -\fIrecvbase\fR. -The number of bytes that were written to this receive buffer is -returned in +\(em typically a lightweight resolver query packet \(em and waits for a reply which is copied to the receive buffer at +\fIrecvbase\fR. The number of bytes that were written to this receive buffer is returned in \fI*recvd_len\fR. .SH "RETURN VALUES" .PP \fBlwres_context_create()\fR returns -LWRES_R_NOMEMORY +\fBLWRES_R_NOMEMORY\fR if memory for the \fBstruct lwres_context\fR -could not be allocated, -LWRES_R_SUCCESS +could not be allocated, +\fBLWRES_R_SUCCESS\fR otherwise. .PP Successful calls to the memory allocator \fBlwres_context_allocmem()\fR -return a pointer to the start of the allocated space. -It returns NULL if memory could not be allocated. +return a pointer to the start of the allocated space. It returns NULL if memory could not be allocated. .PP -LWRES_R_SUCCESS +\fBLWRES_R_SUCCESS\fR is returned when \fBlwres_context_sendrecv()\fR completes successfully. -LWRES_R_IOERROR +\fBLWRES_R_IOERROR\fR is returned if an I/O error occurs and -LWRES_R_TIMEOUT +\fBLWRES_R_TIMEOUT\fR is returned if \fBlwres_context_sendrecv()\fR times out waiting for a response. @@ -193,4 +158,4 @@ times out waiting for a response. .PP \fBlwres_conf_init\fR(3), \fBmalloc\fR(3), -\fBfree\fR(3). +\fBfree\fR(3 ). diff --git a/contrib/bind9/lib/lwres/man/lwres_context.docbook b/contrib/bind9/lib/lwres/man/lwres_context.docbook index 137e4bc209b..48d43362e1e 100644 --- a/contrib/bind9/lib/lwres/man/lwres_context.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_context.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,21 @@ 3 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2003 + Internet Software Consortium. + + + lwres_context_create lwres_context_destroy diff --git a/contrib/bind9/lib/lwres/man/lwres_context.html b/contrib/bind9/lib/lwres/man/lwres_context.html index cca12d7d31e..8988c5dc102 100644 --- a/contrib/bind9/lib/lwres/man/lwres_context.html +++ b/contrib/bind9/lib/lwres/man/lwres_context.html @@ -1,478 +1,335 @@ - - - - -lwres_context

lwres_context

Name

lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv -- lightweight resolver context management

Synopsis

#include <lwres/lwres.h>

lwres_result_t -lwres_context_create(lwres_context_t **contextp, void *arg, lwres_malloc_t malloc_function, lwres_free_t free_function);

lwres_result_t -lwres_context_destroy(lwres_context_t **contextp);

void -lwres_context_initserial(lwres_context_t *ctx, lwres_uint32_t serial);

lwres_uint32_t -lwres_context_nextserial(lwres_context_t *ctx);

void -lwres_context_freemem(lwres_context_t *ctx, void *mem, size_t len);

void -lwres_context_allocmem(lwres_context_t *ctx, size_t len);

void * -lwres_context_sendrecv(lwres_context_t *ctx, void *sendbase, int sendlen, void *recvbase, int recvlen, int *recvd_len);

DESCRIPTION

lwres_context_create() + + + + +lwres_context + + +

+
+
+

Name

+

lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv — lightweight resolver context management

+
+
+

Synopsis

+
+
#include <lwres/lwres.h>
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_context_create( ,
  ,
  ,
   +);
+ + + + +
+lwres_result_t +lwres_context_destroy(  +);
+ + + + + + + + + + + +
+void +lwres_context_initserial( ,
   +);
+ + + + +
+lwres_uint32_t +lwres_context_nextserial(  +);
+ + + + + + + + + + + + + + + + +
+void +lwres_context_freemem( ,
  ,
   +);
+ + + + + + + + + + + +
+void +lwres_context_allocmem( ,
   +);
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+void * +lwres_context_sendrecv( ,
  ,
  ,
  ,
  ,
   +);
+
+
+
+

DESCRIPTION

+

+lwres_context_create() creates a -lwres_context_t +lwres_context_t structure for use in lightweight resolver operations. It holds a socket and other data needed for communicating with a resolver daemon. The new -lwres_context_t +lwres_context_t is returned through -contextp, +contextp, a pointer to a -lwres_context_t +lwres_context_t pointer. This -lwres_context_t +lwres_context_t pointer must initially be NULL, and is modified to point to the newly created -lwres_context_t.

When the lightweight resolver needs to perform dynamic memory +lwres_context_t. + +

+

+When the lightweight resolver needs to perform dynamic memory allocation, it will call -malloc_function +malloc_function to allocate memory and -free_function +free_function to free it. If -malloc_function +malloc_function and -free_function +free_function are NULL, memory is allocated using .Xr malloc 3 and -free(3). +free(3). It is not permitted to have a NULL -malloc_function +malloc_function and a non-NULL -free_function +free_function or vice versa. -arg +arg is passed as the first parameter to the memory allocation functions. If -malloc_function +malloc_function and -free_function +free_function are NULL, -arg +arg -is unused and should be passed as NULL.

Once memory for the structure has been allocated, +is unused and should be passed as NULL. +

+

+Once memory for the structure has been allocated, it is initialized using -lwres_conf_init(3) +lwres_conf_init(3) and returned via -*contextp.

lwres_context_destroy() +*contextp. + +

+

+lwres_context_destroy() destroys a -lwres_context_t, +lwres_context_t, closing its socket. -contextp +contextp is a pointer to a pointer to the context that is to be destroyed. -The pointer will be set to NULL when the context has been destroyed.

The context holds a serial number that is used to identify resolver +The pointer will be set to NULL when the context has been destroyed. +

+

+The context holds a serial number that is used to identify resolver request packets and associate responses with the corresponding requests. This serial number is controlled using -lwres_context_initserial() +lwres_context_initserial() and -lwres_context_nextserial(). -lwres_context_initserial() +lwres_context_nextserial(). +lwres_context_initserial() sets the serial number for context -*ctx +*ctx to -serial. +serial. -lwres_context_nextserial() -increments the serial number and returns the previous value.

Memory for a lightweight resolver context is allocated and freed using -lwres_context_allocmem() +lwres_context_nextserial() +increments the serial number and returns the previous value. +

+

+Memory for a lightweight resolver context is allocated and freed using +lwres_context_allocmem() and -lwres_context_freemem(). +lwres_context_freemem(). These use whatever allocations were defined when the context was created with -lwres_context_create(). -lwres_context_allocmem() +lwres_context_create(). +lwres_context_allocmem() allocates -len +len bytes of memory and if successful returns a pointer to the allocated storage. -lwres_context_freemem() +lwres_context_freemem() frees -len +len bytes of space starting at location -mem.

lwres_context_sendrecv() +mem. + +

+

+lwres_context_sendrecv() performs I/O for the context -ctx. +ctx. Data are read and written from the context's socket. It writes data from -sendbase -— typically a lightweight resolver query packet — +sendbase +— typically a lightweight resolver query packet — and waits for a reply which is copied to the receive buffer at -recvbase. +recvbase. The number of bytes that were written to this receive buffer is returned in -*recvd_len.

RETURN VALUES

lwres_context_create() +*recvd_len. + +

+
+
+

RETURN VALUES

+

+lwres_context_create() returns -LWRES_R_NOMEMORY +LWRES_R_NOMEMORY if memory for the -struct lwres_context +struct lwres_context could not be allocated, -LWRES_R_SUCCESS -otherwise.

Successful calls to the memory allocator -lwres_context_allocmem() +LWRES_R_SUCCESS +otherwise. +

+

+Successful calls to the memory allocator +lwres_context_allocmem() return a pointer to the start of the allocated space. -It returns NULL if memory could not be allocated.

LWRES_R_SUCCESS +It returns NULL if memory could not be allocated. +

+

+LWRES_R_SUCCESS is returned when -lwres_context_sendrecv() +lwres_context_sendrecv() completes successfully. -LWRES_R_IOERROR +LWRES_R_IOERROR is returned if an I/O error occurs and -LWRES_R_TIMEOUT +LWRES_R_TIMEOUT is returned if -lwres_context_sendrecv() -times out waiting for a response.

SEE ALSO

lwres_conf_init(3), +lwres_context_sendrecv() +times out waiting for a response. +

+
+
+

SEE ALSO

+

+lwres_conf_init(3), -malloc(3), +malloc(3), -free(3).

+free(3 +). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.3 b/contrib/bind9/lib/lwres/man/lwres_gabn.3 index a309f3e6239..60a56fe46b3 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gabn.3 +++ b/contrib/bind9/lib/lwres/man/lwres_gabn.3 @@ -1,91 +1,72 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_gabn.3,v 1.13.2.1.8.1 2004/03/06 07:41:42 marka Exp $ +.\" $Id: lwres_gabn.3,v 1.13.2.1.8.5 2005/10/13 02:33:52 marka Exp $ .\" -.TH "LWRES_GABN" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GABN" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free \- lightweight resolver getaddrbyname message handling -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_gabnrequest_render(lwres_context_t *ctx, lwres_gabnrequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b); -.ad -.sp -.na -lwres_result_t -lwres_gabnresponse_render(lwres_context_t *ctx, lwres_gabnresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b); -.ad -.sp -.na -lwres_result_t -lwres_gabnrequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnrequest_t **structp); -.ad -.sp -.na -lwres_result_t -lwres_gabnresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnresponse_t **structp); -.ad -.sp -.na -void -lwres_gabnresponse_free(lwres_context_t *ctx, lwres_gabnresponse_t **structp); -.ad -.sp -.na -void -lwres_gabnrequest_free(lwres_context_t *ctx, lwres_gabnrequest_t **structp); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 40 +\fBlwres_result_t\ \fBlwres_gabnrequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnrequest_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 41 +\fBlwres_result_t\ \fBlwres_gabnresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 39 +\fBlwres_result_t\ \fBlwres_gabnrequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gabnrequest_t\ **structp\fR\fB);\fR +.HP 40 +\fBlwres_result_t\ \fBlwres_gabnresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR +.HP 29 +\fBvoid\ \fBlwres_gabnresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_gabnrequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnrequest_t\ **structp\fR\fB);\fR .SH "DESCRIPTION" .PP -These are low-level routines for creating and parsing -lightweight resolver name-to-address lookup request and -response messages. +These are low\-level routines for creating and parsing lightweight resolver name\-to\-address lookup request and response messages. .PP -There are four main functions for the getaddrbyname opcode. -One render function converts a getaddrbyname request structure \(em -\fBlwres_gabnrequest_t\fR \(em -to the lighweight resolver's canonical format. -It is complemented by a parse function that converts a packet in this -canonical format to a getaddrbyname request structure. -Another render function converts the getaddrbyname response structure \(em -\fBlwres_gabnresponse_t\fR \(em -to the canonical format. -This is complemented by a parse function which converts a packet in -canonical format to a getaddrbyname response structure. +There are four main functions for the getaddrbyname opcode. One render function converts a getaddrbyname request structure \(em +\fBlwres_gabnrequest_t\fR +\(em to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getaddrbyname request structure. Another render function converts the getaddrbyname response structure \(em +\fBlwres_gabnresponse_t\fR +\(em to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a getaddrbyname response structure. .PP These structures are defined in -\fI\fR. -They are shown below. +\fI\fR. They are shown below. .sp .nf #define LWRES_OPCODE_GETADDRSBYNAME 0x00010001U - typedef struct lwres_addr lwres_addr_t; typedef LWRES_LIST(lwres_addr_t) lwres_addrlist_t; - typedef struct { lwres_uint32_t flags; lwres_uint32_t addrtypes; lwres_uint16_t namelen; char *name; } lwres_gabnrequest_t; - typedef struct { lwres_uint32_t flags; lwres_uint16_t naliases; @@ -98,21 +79,18 @@ typedef struct { void *base; size_t baselen; } lwres_gabnresponse_t; -.sp .fi +.sp .PP \fBlwres_gabnrequest_render()\fR uses resolver context \fIctx\fR to convert getaddrbyname request structure \fIreq\fR -to canonical format. -The packet header structure +to canonical format. The packet header structure \fIpkt\fR -is initialised and transferred to -buffer -\fIb\fR. -The contents of +is initialised and transferred to buffer +\fIb\fR. The contents of \fI*req\fR are then appended to the buffer in canonical format. \fBlwres_gabnresponse_render()\fR @@ -127,11 +105,9 @@ to convert the contents of packet \fIpkt\fR to a \fBlwres_gabnrequest_t\fR -structure. -Buffer +structure. Buffer \fIb\fR -provides space to be used for storing this structure. -When the function succeeds, the resulting +provides space to be used for storing this structure. When the function succeeds, the resulting \fBlwres_gabnrequest_t\fR is made available through \fI*structp\fR. @@ -152,24 +128,20 @@ that was allocated to the or \fBlwres_gabnrequest_t\fR structures referenced via -\fIstructp\fR. -Any memory associated with ancillary buffers and strings for those -structures is also discarded. +\fIstructp\fR. Any memory associated with ancillary buffers and strings for those structures is also discarded. .SH "RETURN VALUES" .PP The getaddrbyname opcode functions -\fBlwres_gabnrequest_render()\fR, -\fBlwres_gabnresponse_render()\fR -\fBlwres_gabnrequest_parse()\fR +\fBlwres_gabnrequest_render()\fR, +\fBlwres_gabnresponse_render()\fR\fBlwres_gabnrequest_parse()\fR and \fBlwres_gabnresponse_parse()\fR all return -LWRES_R_SUCCESS -on success. -They return -LWRES_R_NOMEMORY +\fBLWRES_R_SUCCESS\fR +on success. They return +\fBLWRES_R_NOMEMORY\fR if memory allocation fails. -LWRES_R_UNEXPECTEDEND +\fBLWRES_R_UNEXPECTEDEND\fR is returned if the available space in the buffer \fIb\fR is too small to accommodate the packet header or the @@ -181,15 +153,14 @@ structures. and \fBlwres_gabnresponse_parse()\fR will return -LWRES_R_UNEXPECTEDEND -if the buffer is not empty after decoding the received packet. -These functions will return -LWRES_R_FAILURE +\fBLWRES_R_UNEXPECTEDEND\fR +if the buffer is not empty after decoding the received packet. These functions will return +\fBLWRES_R_FAILURE\fR if -\fBpktflags\fR +pktflags in the packet header structure \fBlwres_lwpacket_t\fR indicate that the packet is not a response to an earlier query. .SH "SEE ALSO" .PP -\fBlwres_packet\fR(3) +\fBlwres_packet\fR(3 ) diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook index cb9481f4aa8..6e90ea3905b 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,20 @@ 3 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_gabnrequest_render lwres_gabnresponse_render diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.html b/contrib/bind9/lib/lwres/man/lwres_gabn.html index 6cb6614cbd5..771394508a2 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gabn.html +++ b/contrib/bind9/lib/lwres/man/lwres_gabn.html @@ -1,158 +1,195 @@ - - - - -lwres_gabn

lwres_gabn

Name

lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free -- lightweight resolver getaddrbyname message handling

Synopsis

#include <lwres/lwres.h>

lwres_result_t -lwres_gabnrequest_render(lwres_context_t *ctx, lwres_gabnrequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_gabnresponse_render(lwres_context_t *ctx, lwres_gabnresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_gabnrequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnrequest_t **structp);

lwres_result_t -lwres_gabnresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnresponse_t **structp);

void -lwres_gabnresponse_free(lwres_context_t *ctx, lwres_gabnresponse_t **structp);

void -lwres_gabnrequest_free(lwres_context_t *ctx, lwres_gabnrequest_t **structp);

DESCRIPTION

These are low-level routines for creating and parsing + + + + +lwres_gabn + + +

+
+
+

Name

+

lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free — lightweight resolver getaddrbyname message handling

+
+
+

Synopsis

+
+
#include <lwres/lwres.h>
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gabnrequest_render( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gabnresponse_render( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gabnrequest_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gabnresponse_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + +
+void +lwres_gabnresponse_free( ,
   +);
+ + + + + + + + + + + +
+void +lwres_gabnrequest_free( ,
   +);
+
+
+
+

DESCRIPTION

+

+These are low-level routines for creating and parsing lightweight resolver name-to-address lookup request and -response messages.

There are four main functions for the getaddrbyname opcode. -One render function converts a getaddrbyname request structure — -lwres_gabnrequest_t — +response messages. +

+

+There are four main functions for the getaddrbyname opcode. +One render function converts a getaddrbyname request structure — +lwres_gabnrequest_t — to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getaddrbyname request structure. -Another render function converts the getaddrbyname response structure — -lwres_gabnresponse_t — +Another render function converts the getaddrbyname response structure — +lwres_gabnresponse_t — to the canonical format. This is complemented by a parse function which converts a packet in -canonical format to a getaddrbyname response structure.

These structures are defined in -<lwres/lwres.h>. +canonical format to a getaddrbyname response structure. +

+

+These structures are defined in +<lwres/lwres.h>. They are shown below. -

#define LWRES_OPCODE_GETADDRSBYNAME     0x00010001U
+

+
+#define LWRES_OPCODE_GETADDRSBYNAME     0x00010001U
 
 typedef struct lwres_addr lwres_addr_t;
 typedef LWRES_LIST(lwres_addr_t) lwres_addrlist_t;
@@ -175,245 +212,116 @@ typedef struct {
         lwres_addrlist_t        addrs;
         void                   *base;
         size_t                  baselen;
-} lwres_gabnresponse_t;
lwres_gabnrequest_render()
+} lwres_gabnresponse_t;
+
+

+

+

+lwres_gabnrequest_render() uses resolver context -ctx +ctx to convert getaddrbyname request structure -req +req to canonical format. The packet header structure -pkt +pkt is initialised and transferred to buffer -b. +b. The contents of -*req +*req are then appended to the buffer in canonical format. -lwres_gabnresponse_render() +lwres_gabnresponse_render() performs the same task, except it converts a getaddrbyname response structure -lwres_gabnresponse_t -to the lightweight resolver's canonical format.

lwres_gabnrequest_parse() +lwres_gabnresponse_t +to the lightweight resolver's canonical format. +

+

+lwres_gabnrequest_parse() uses context -ctx +ctx to convert the contents of packet -pkt +pkt to a -lwres_gabnrequest_t +lwres_gabnrequest_t structure. Buffer -b +b provides space to be used for storing this structure. When the function succeeds, the resulting -lwres_gabnrequest_t +lwres_gabnrequest_t is made available through -*structp. +*structp. -lwres_gabnresponse_parse() +lwres_gabnresponse_parse() offers the same semantics as -lwres_gabnrequest_parse() +lwres_gabnrequest_parse() except it yields a -lwres_gabnresponse_t -structure.

lwres_gabnresponse_free() +lwres_gabnresponse_t +structure. +

+

+lwres_gabnresponse_free() and -lwres_gabnrequest_free() +lwres_gabnrequest_free() release the memory in resolver context -ctx +ctx that was allocated to the -lwres_gabnresponse_t +lwres_gabnresponse_t or -lwres_gabnrequest_t +lwres_gabnrequest_t structures referenced via -structp. +structp. Any memory associated with ancillary buffers and strings for those -structures is also discarded.

RETURN VALUES

The getaddrbyname opcode functions -lwres_gabnrequest_render(), -lwres_gabnresponse_render() -lwres_gabnrequest_parse() +structures is also discarded. +

+
+
+

RETURN VALUES

+

+The getaddrbyname opcode functions +lwres_gabnrequest_render(), +lwres_gabnresponse_render() +lwres_gabnrequest_parse() and -lwres_gabnresponse_parse() +lwres_gabnresponse_parse() all return -LWRES_R_SUCCESS +LWRES_R_SUCCESS on success. They return -LWRES_R_NOMEMORY +LWRES_R_NOMEMORY if memory allocation fails. -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND is returned if the available space in the buffer -b +b is too small to accommodate the packet header or the -lwres_gabnrequest_t +lwres_gabnrequest_t and -lwres_gabnresponse_t +lwres_gabnresponse_t structures. -lwres_gabnrequest_parse() +lwres_gabnrequest_parse() and -lwres_gabnresponse_parse() +lwres_gabnresponse_parse() will return -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND if the buffer is not empty after decoding the received packet. These functions will return -LWRES_R_FAILURE +LWRES_R_FAILURE if -pktflags +pktflags in the packet header structure -lwres_lwpacket_t -indicate that the packet is not a response to an earlier query.

SEE ALSO

lwres_packet(3)

+lwres_lwpacket_t +indicate that the packet is not a response to an earlier query. +

+
+
+

SEE ALSO

+

+lwres_packet(3 +) +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 index ea75066f8ae..388c59e0f1e 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 +++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 @@ -1,37 +1,44 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_gai_strerror.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_gai_strerror.3,v 1.13.2.1.8.5 2005/10/13 02:33:52 marka Exp $ .\" -.TH "LWRES_GAI_STRERROR" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GAI_STRERROR" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" gai_strerror \- print suitable error string -.SH SYNOPSIS -\fB#include -.sp -.na -char * -gai_strerror(int ecode); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 20 +\fBchar\ *\ \fBgai_strerror\fR\fR\fB(\fR\fBint\ ecode\fR\fB);\fR .SH "DESCRIPTION" .PP \fBlwres_gai_strerror()\fR returns an error message corresponding to an error code returned by -\fBgetaddrinfo()\fR. -The following error codes and their meaning are defined in +\fBgetaddrinfo()\fR. The following error codes and their meaning are defined in \fIinclude/lwres/netdb.h\fR. .TP \fBEAI_ADDRFAMILY\fR @@ -42,13 +49,14 @@ temporary failure in name resolution .TP \fBEAI_BADFLAGS\fR invalid value for -ai_flags +\fBai_flags\fR .TP \fBEAI_FAIL\fR -non-recoverable failure in name resolution +non\-recoverable failure in name resolution .TP \fBEAI_FAMILY\fR -ai_family not supported +\fBai_family\fR +not supported .TP \fBEAI_MEMORY\fR memory allocation failure @@ -60,22 +68,25 @@ no address associated with hostname hostname or servname not provided, or not known .TP \fBEAI_SERVICE\fR -servname not supported for ai_socktype +servname not supported for +\fBai_socktype\fR .TP \fBEAI_SOCKTYPE\fR -ai_socktype not supported +\fBai_socktype\fR +not supported .TP \fBEAI_SYSTEM\fR system error returned in errno -.PP -The message \fBinvalid error code\fR is returned if +The message +invalid error code +is returned if \fIecode\fR is out of range. .PP -ai_flags, -ai_family +\fBai_flags\fR, +\fBai_family\fR and -ai_socktype +\fBai_socktype\fR are elements of the \fBstruct addrinfo\fR used by @@ -85,4 +96,4 @@ used by \fBstrerror\fR(3), \fBlwres_getaddrinfo\fR(3), \fBgetaddrinfo\fR(3), -\fBRFC2133\fR. +\fBRFC2133\fR(). diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook index 475d4441d0c..f34836d2a2c 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,20 @@ 3 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + gai_strerror print suitable error string diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html index 45dc5cb3d02..5506564197e 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html +++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html @@ -1,295 +1,124 @@ - - - - -lwres_gai_strerror

lwres_gai_strerror

Name

gai_strerror -- print suitable error string

Synopsis

#include <lwres/netdb.h>

char * -gai_strerror(int ecode);

DESCRIPTION

lwres_gai_strerror() + + + + +lwres_gai_strerror + + +

+
+
+

Name

+

gai_strerror — print suitable error string

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+

+char * +gai_strerror(int ecode);

+
+
+
+

DESCRIPTION

+

+lwres_gai_strerror() returns an error message corresponding to an error code returned by -getaddrinfo(). +getaddrinfo(). The following error codes and their meaning are defined in -include/lwres/netdb.h. -

EAI_ADDRFAMILY

address family for hostname not supported

EAI_AGAIN

temporary failure in name resolution

EAI_BADFLAGS

invalid value for -ai_flags

EAI_FAIL

non-recoverable failure in name resolution

EAI_FAMILY

ai_family not supported

EAI_MEMORY

memory allocation failure

EAI_NODATA

no address associated with hostname

EAI_NONAME

hostname or servname not provided, or not known

EAI_SERVICE

servname not supported for ai_socktype

EAI_SOCKTYPE

ai_socktype not supported

EAI_SYSTEM

system error returned in errno

-The message invalid error code is returned if -ecode -is out of range.

ai_flags, -ai_family +include/lwres/netdb.h. +

+
+
EAI_ADDRFAMILY
+

+address family for hostname not supported +

+
EAI_AGAIN
+

+temporary failure in name resolution +

+
EAI_BADFLAGS
+

+invalid value for +ai_flags +

+
EAI_FAIL
+

+non-recoverable failure in name resolution +

+
EAI_FAMILY
+

+ai_family not supported +

+
EAI_MEMORY
+

+memory allocation failure +

+
EAI_NODATA
+

+no address associated with hostname +

+
EAI_NONAME
+

+hostname or servname not provided, or not known +

+
EAI_SERVICE
+

+servname not supported for ai_socktype +

+
EAI_SOCKTYPE
+

+ai_socktype not supported +

+
EAI_SYSTEM
+

+system error returned in errno +

+
+

+The message invalid error code is returned if +ecode +is out of range. +

+

+ai_flags, +ai_family and -ai_socktype +ai_socktype are elements of the -struct addrinfo +struct addrinfo used by -lwres_getaddrinfo().

SEE ALSO

strerror(3), +lwres_getaddrinfo(). +

+
+
+

SEE ALSO

+

+strerror(3), -lwres_getaddrinfo(3), +lwres_getaddrinfo(3), -getaddrinfo(3), +getaddrinfo(3), -RFC2133.

+RFC2133. +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 index d360b3e807a..df1390a95eb 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 +++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 @@ -1,40 +1,44 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 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, +.\" 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: lwres_getaddrinfo.3,v 1.16.2.1.8.2 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_getaddrinfo.3,v 1.16.2.1.8.6 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GETADDRINFO" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GETADDRINFO" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_getaddrinfo, lwres_freeaddrinfo \- socket address structure to host and service name -.SH SYNOPSIS -\fB#include -.sp -.na -int -lwres_getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); -.ad -.sp -.na -void -lwres_freeaddrinfo(struct addrinfo *ai); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 22 +\fBint\ \fBlwres_getaddrinfo\fR\fR\fB(\fR\fBconst\ char\ *hostname\fR\fB, \fR\fBconst\ char\ *servname\fR\fB, \fR\fBconst\ struct\ addrinfo\ *hints\fR\fB, \fR\fBstruct\ addrinfo\ **res\fR\fB);\fR +.HP 24 +\fBvoid\ \fBlwres_freeaddrinfo\fR\fR\fB(\fR\fBstruct\ addrinfo\ *ai\fR\fB);\fR .PP If the operating system does not provide a -\fBstruct addrinfo\fR, -the following structure is used: +\fBstruct addrinfo\fR, the following structure is used: .sp .nf struct addrinfo { @@ -47,47 +51,38 @@ struct addrinfo { struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ }; -.sp .fi +.sp .SH "DESCRIPTION" .PP \fBlwres_getaddrinfo()\fR is used to get a list of IP addresses and port numbers for host \fIhostname\fR and service -\fIservname\fR. -The function is the lightweight resolver's implementation of +\fIservname\fR. The function is the lightweight resolver's implementation of \fBgetaddrinfo()\fR as defined in RFC2133. \fIhostname\fR and \fIservname\fR -are pointers to null-terminated -strings or +are pointers to null\-terminated strings or \fBNULL\fR. \fIhostname\fR -is either a host name or a numeric host address string: a dotted decimal -IPv4 address or an IPv6 address. +is either a host name or a numeric host address string: a dotted decimal IPv4 address or an IPv6 address. \fIservname\fR is either a decimal port number or a service name as listed in \fI/etc/services\fR. .PP \fIhints\fR is an optional pointer to a -\fBstruct addrinfo\fR. -This structure can be used to provide hints concerning the type of socket -that the caller supports or wishes to use. -The caller can supply the following structure elements in +\fBstruct addrinfo\fR. This structure can be used to provide hints concerning the type of socket that the caller supports or wishes to use. The caller can supply the following structure elements in \fI*hints\fR: .TP \fBai_family\fR -The protocol family that should be used. -When -ai_family +The protocol family that should be used. When +\fBai_family\fR is set to -\fBPF_UNSPEC\fR, -it means the caller will accept any protocol family supported by the -operating system. +\fBPF_UNSPEC\fR, it means the caller will accept any protocol family supported by the operating system. .TP \fBai_socktype\fR denotes the type of socket \(em @@ -95,122 +90,107 @@ denotes the type of socket \(em \fBSOCK_DGRAM\fR or \fBSOCK_RAW\fR -\(em that is wanted. -When -ai_socktype +\(em that is wanted. When +\fBai_socktype\fR is zero the caller will accept any socket type. .TP \fBai_protocol\fR -indicates which transport protocol is wanted: IPPROTO_UDP or -IPPROTO_TCP. -If -ai_protocol +indicates which transport protocol is wanted: IPPROTO_UDP or IPPROTO_TCP. If +\fBai_protocol\fR is zero the caller will accept any protocol. .TP \fBai_flags\fR -Flag bits. -If the +Flag bits. If the \fBAI_CANONNAME\fR bit is set, a successful call to \fBlwres_getaddrinfo()\fR -will return a null-terminated string containing the canonical name -of the specified hostname in -ai_canonname +will return a null\-terminated string containing the canonical name of the specified hostname in +\fBai_canonname\fR of the first \fBaddrinfo\fR -structure returned. -Setting the +structure returned. Setting the \fBAI_PASSIVE\fR -bit indicates that the returned socket address structure is intended -for used in a call to -\fBbind\fR(2). -In this case, if the hostname argument is a +bit indicates that the returned socket address structure is intended for used in a call to +\fBbind\fR(2). In this case, if the hostname argument is a \fBNULL\fR -pointer, then the IP address portion of the socket -address structure will be set to +pointer, then the IP address portion of the socket address structure will be set to \fBINADDR_ANY\fR for an IPv4 address or \fBIN6ADDR_ANY_INIT\fR for an IPv6 address. - +.sp When -ai_flags +\fBai_flags\fR does not set the \fBAI_PASSIVE\fR -bit, the returned socket address structure will be ready -for use in a call to -\fBconnect\fR(2) -for a connection-oriented protocol or +bit, the returned socket address structure will be ready for use in a call to +\fBconnect\fR(2 ) +for a connection\-oriented protocol or \fBconnect\fR(2), -\fBsendto\fR(2), -or -\fBsendmsg\fR(2) -if a connectionless protocol was chosen. -The IP address portion of the socket address structure will be -set to the loopback address if +\fBsendto\fR(2), or +\fBsendmsg\fR(2 ) +if a connectionless protocol was chosen. The IP address portion of the socket address structure will be set to the loopback address if \fIhostname\fR is a \fBNULL\fR pointer and \fBAI_PASSIVE\fR is not set in -ai_flags. - +\fBai_flags\fR. +.sp If -ai_flags +\fBai_flags\fR is set to \fBAI_NUMERICHOST\fR it indicates that \fIhostname\fR -should be treated as a numeric string defining an IPv4 or IPv6 address -and no name resolution should be attempted. +should be treated as a numeric string defining an IPv4 or IPv6 address and no name resolution should be attempted. .PP -All other elements of the \fBstruct addrinfo\fR passed -via \fIhints\fR must be zero. +All other elements of the +\fBstruct addrinfo\fR +passed via +\fIhints\fR +must be zero. .PP -A \fIhints\fR of \fBNULL\fR is treated as if -the caller provided a \fBstruct addrinfo\fR initialized to zero -with ai_familyset to -PF_UNSPEC. +A +\fIhints\fR +of +\fBNULL\fR +is treated as if the caller provided a +\fBstruct addrinfo\fR +initialized to zero with +\fBai_family\fRset to +\fBPF_UNSPEC\fR. .PP After a successful call to \fBlwres_getaddrinfo()\fR, \fI*res\fR is a pointer to a linked list of one or more \fBaddrinfo\fR -structures. -Each +structures. Each \fBstruct addrinfo\fR -in this list cn be processed by following -the -ai_next +in this list cn be processed by following the +\fBai_next\fR pointer, until a \fBNULL\fR -pointer is encountered. -The three members -ai_family, -ai_socktype, -and -ai_protocol -in each -returned +pointer is encountered. The three members +\fBai_family\fR, +\fBai_socktype\fR, and +\fBai_protocol\fR +in each returned \fBaddrinfo\fR structure contain the corresponding arguments for a call to -\fBsocket\fR(2). -For each +\fBsocket\fR(2). For each \fBaddrinfo\fR structure in the list, the -ai_addr -member points to a filled-in socket address structure of length -ai_addrlen. +\fBai_addr\fR +member points to a filled\-in socket address structure of length +\fBai_addrlen\fR. .PP All of the information returned by \fBlwres_getaddrinfo()\fR -is dynamically allocated: the addrinfo structures, and the socket -address structures and canonical host name strings pointed to by the -addrinfostructures. -Memory allocated for the dynamically allocated structures created by -a successful call to +is dynamically allocated: the addrinfo structures, and the socket address structures and canonical host name strings pointed to by the +\fBaddrinfo\fRstructures. Memory allocated for the dynamically allocated structures created by a successful call to \fBlwres_getaddrinfo()\fR is released by \fBlwres_freeaddrinfo()\fR. @@ -223,24 +203,22 @@ created by a call to .PP \fBlwres_getaddrinfo()\fR returns zero on success or one of the error codes listed in -\fBgai_strerror\fR(3) -if an error occurs. -If both +\fBgai_strerror\fR(3 ) +if an error occurs. If both \fIhostname\fR and \fIservname\fR are -\fBNULL\fR -\fBlwres_getaddrinfo()\fR +\fBNULL\fR\fBlwres_getaddrinfo()\fR returns -EAI_NONAME. +\fBEAI_NONAME\fR. .SH "SEE ALSO" .PP \fBlwres\fR(3), \fBlwres_getaddrinfo\fR(3), \fBlwres_freeaddrinfo\fR(3), \fBlwres_gai_strerror\fR(3), -\fBRFC2133\fR, +\fBRFC2133\fR(), \fBgetservbyname\fR(3), \fBbind\fR(2), \fBconnect\fR(2), diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook index 2f2fc829f8f..190721923b1 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2003 + Internet Software Consortium. + + + lwres_getaddrinfo lwres_freeaddrinfo diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html index b568e5915ad..bc84e74f5c3 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html +++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html @@ -1,97 +1,78 @@ - - - - -lwres_getaddrinfo

lwres_getaddrinfo

Name

lwres_getaddrinfo, lwres_freeaddrinfo -- socket address structure to host and service name

Synopsis

#include <lwres/netdb.h>

int -lwres_getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res);

void -lwres_freeaddrinfo(struct addrinfo *ai);

If the operating system does not provide a -struct addrinfo, + + + + +lwres_getaddrinfo + + +

+
+
+

Name

+

lwres_getaddrinfo, lwres_freeaddrinfo — socket address structure to host and service name

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+ + + + + + + + + + + + + + + + + + + + + +
+int +lwres_getaddrinfo( ,
  ,
  ,
   +);
+ + + + +
+void +lwres_freeaddrinfo(  +);
+
+

+If the operating system does not provide a +struct addrinfo, the following structure is used: -

struct  addrinfo {
+

+
+struct  addrinfo {
         int             ai_flags;       /* AI_PASSIVE, AI_CANONNAME */
         int             ai_family;      /* PF_xxx */
         int             ai_socktype;    /* SOCK_xxx */
@@ -100,594 +81,253 @@ CLASS="PROGRAMLISTING"
         char            *ai_canonname;  /* canonical name for hostname */
         struct sockaddr *ai_addr;       /* binary address */
         struct addrinfo *ai_next;       /* next structure in linked list */
-};

DESCRIPTION

lwres_getaddrinfo() +}; + +

+

+
+
+

DESCRIPTION

+

+lwres_getaddrinfo() is used to get a list of IP addresses and port numbers for host -hostname +hostname and service -servname. +servname. The function is the lightweight resolver's implementation of -getaddrinfo() +getaddrinfo() as defined in RFC2133. -hostname +hostname and -servname +servname are pointers to null-terminated strings or -NULL. +NULL. -hostname +hostname is either a host name or a numeric host address string: a dotted decimal IPv4 address or an IPv6 address. -servname +servname is either a decimal port number or a service name as listed in -/etc/services.

hints +/etc/services. +

+

+hints is an optional pointer to a -struct addrinfo. +struct addrinfo. This structure can be used to provide hints concerning the type of socket that the caller supports or wishes to use. The caller can supply the following structure elements in -*hints: +*hints: -

ai_family

The protocol family that should be used. +

+
+
ai_family
+

The protocol family that should be used. When -ai_family +ai_family is set to -PF_UNSPEC, +PF_UNSPEC, it means the caller will accept any protocol family supported by the -operating system.

ai_socktype

denotes the type of socket — -SOCK_STREAM, -SOCK_DGRAM +operating system. +

+
ai_socktype
+

+denotes the type of socket — +SOCK_STREAM, +SOCK_DGRAM or -SOCK_RAW -— that is wanted. +SOCK_RAW +— that is wanted. When -ai_socktype -is zero the caller will accept any socket type.

ai_protocol

indicates which transport protocol is wanted: IPPROTO_UDP or +ai_socktype +is zero the caller will accept any socket type. +

+
ai_protocol
+

+indicates which transport protocol is wanted: IPPROTO_UDP or IPPROTO_TCP. If -ai_protocol -is zero the caller will accept any protocol.

ai_flags

Flag bits. +ai_protocol +is zero the caller will accept any protocol. +

+
ai_flags
+
+

+Flag bits. If the -AI_CANONNAME +AI_CANONNAME bit is set, a successful call to -lwres_getaddrinfo() +lwres_getaddrinfo() will return a null-terminated string containing the canonical name of the specified hostname in -ai_canonname +ai_canonname of the first -addrinfo +addrinfo structure returned. Setting the -AI_PASSIVE +AI_PASSIVE bit indicates that the returned socket address structure is intended for used in a call to -bind(2). +bind(2). In this case, if the hostname argument is a -NULL +NULL pointer, then the IP address portion of the socket address structure will be set to -INADDR_ANY +INADDR_ANY for an IPv4 address or -IN6ADDR_ANY_INIT -for an IPv6 address.

When -ai_flags +IN6ADDR_ANY_INIT +for an IPv6 address. +

+

+When +ai_flags does not set the -AI_PASSIVE +AI_PASSIVE bit, the returned socket address structure will be ready for use in a call to -connect(2) +connect(2 +) for a connection-oriented protocol or -connect(2), +connect(2), -sendto(2), +sendto(2), or -sendmsg(2) +sendmsg(2 +) if a connectionless protocol was chosen. The IP address portion of the socket address structure will be set to the loopback address if -hostname +hostname is a -NULL +NULL pointer and -AI_PASSIVE +AI_PASSIVE is not set in -ai_flags.

If -ai_flags +ai_flags. +

+

+If +ai_flags is set to -AI_NUMERICHOST +AI_NUMERICHOST it indicates that -hostname +hostname should be treated as a numeric string defining an IPv4 or IPv6 address -and no name resolution should be attempted.

All other elements of the struct addrinfo passed -via hints must be zero.

A hints of NULL is treated as if -the caller provided a struct addrinfo initialized to zero -with ai_familyset to -PF_UNSPEC.

After a successful call to -lwres_getaddrinfo(), -*res +and no name resolution should be attempted. +

+
+
+

+

+

+All other elements of the struct addrinfo passed +via hints must be zero. +

+

+A hints of NULL is treated as if +the caller provided a struct addrinfo initialized to zero +with ai_familyset to +PF_UNSPEC. +

+

+After a successful call to +lwres_getaddrinfo(), +*res is a pointer to a linked list of one or more -addrinfo +addrinfo structures. Each -struct addrinfo +struct addrinfo in this list cn be processed by following the -ai_next +ai_next pointer, until a -NULL +NULL pointer is encountered. The three members -ai_family, -ai_socktype, +ai_family, +ai_socktype, and -ai_protocol +ai_protocol in each returned -addrinfo +addrinfo structure contain the corresponding arguments for a call to -socket(2). +socket(2). For each -addrinfo +addrinfo structure in the list, the -ai_addr +ai_addr member points to a filled-in socket address structure of length -ai_addrlen.

All of the information returned by -lwres_getaddrinfo() +ai_addrlen. +

+

+All of the information returned by +lwres_getaddrinfo() is dynamically allocated: the addrinfo structures, and the socket address structures and canonical host name strings pointed to by the -addrinfostructures. +addrinfostructures. Memory allocated for the dynamically allocated structures created by a successful call to -lwres_getaddrinfo() +lwres_getaddrinfo() is released by -lwres_freeaddrinfo(). -ai +lwres_freeaddrinfo(). +ai is a pointer to a -struct addrinfo +struct addrinfo created by a call to -lwres_getaddrinfo().

RETURN VALUES

lwres_getaddrinfo() +lwres_getaddrinfo(). +

+
+
+

RETURN VALUES

+

+lwres_getaddrinfo() returns zero on success or one of the error codes listed in -gai_strerror(3) +gai_strerror(3 +) if an error occurs. If both -hostname +hostname and -servname +servname are -NULL -lwres_getaddrinfo() +NULL +lwres_getaddrinfo() returns -EAI_NONAME.

SEE ALSO

lwres(3), +EAI_NONAME. -lwres_getaddrinfo(3), +

+
+
+

SEE ALSO

+

+lwres(3), -lwres_freeaddrinfo(3), +lwres_getaddrinfo(3), -lwres_gai_strerror(3), +lwres_freeaddrinfo(3), -RFC2133, +lwres_gai_strerror(3), -getservbyname(3), +RFC2133, -bind(2), +getservbyname(3), -connect(2), +bind(2), -sendto(2), +connect(2), -sendmsg(2), +sendto(2), -socket(2).

+sendmsg(2), + +socket(2). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.3 b/contrib/bind9/lib/lwres/man/lwres_gethostent.3 index 5a4234797d0..99dc5338e58 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gethostent.3 +++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.3 @@ -1,89 +1,64 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2001 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, +.\" 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: lwres_gethostent.3,v 1.16.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_gethostent.3,v 1.16.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GETHOSTENT" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GETHOSTENT" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r \- lightweight resolver get network host entry -.SH SYNOPSIS -\fB#include -.sp -.na -struct hostent * -lwres_gethostbyname(const char *name); -.ad -.sp -.na -struct hostent * -lwres_gethostbyname2(const char *name, int af); -.ad -.sp -.na -struct hostent * -lwres_gethostbyaddr(const char *addr, int len, int type); -.ad -.sp -.na -struct hostent * -lwres_gethostent(void); -.ad -.sp -.na -void -lwres_sethostent(int stayopen); -.ad -.sp -.na -void -lwres_endhostent(void); -.ad -.sp -.na -struct hostent * -lwres_gethostbyname_r(const char *name, struct hostent *resbuf, char *buf, int buflen, int *error); -.ad -.sp -.na -struct hostent * -lwres_gethostbyaddr_r(const char *addr, int len, int type, struct hostent *resbuf, char *buf, int buflen, int *error); -.ad -.sp -.na -struct hostent * -lwres_gethostent_r(struct hostent *resbuf, char *buf, int buflen, int *error); -.ad -.sp -.na -void -lwres_sethostent_r(int stayopen); -.ad -.sp -.na -void -lwres_endhostent_r(void); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 37 +\fBstruct\ hostent\ *\ \fBlwres_gethostbyname\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB);\fR +.HP 38 +\fBstruct\ hostent\ *\ \fBlwres_gethostbyname2\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBint\ af\fR\fB);\fR +.HP 37 +\fBstruct\ hostent\ *\ \fBlwres_gethostbyaddr\fR\fR\fB(\fR\fBconst\ char\ *addr\fR\fB, \fR\fBint\ len\fR\fB, \fR\fBint\ type\fR\fB);\fR +.HP 34 +\fBstruct\ hostent\ *\ \fBlwres_gethostent\fR\fR\fB(\fR\fBvoid\fR\fB);\fR +.HP 22 +\fBvoid\ \fBlwres_sethostent\fR\fR\fB(\fR\fBint\ stayopen\fR\fB);\fR +.HP 22 +\fBvoid\ \fBlwres_endhostent\fR\fR\fB(\fR\fBvoid\fR\fB);\fR +.HP 39 +\fBstruct\ hostent\ *\ \fBlwres_gethostbyname_r\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR +.HP 39 +\fBstruct\ hostent\ *\ \fBlwres_gethostbyaddr_r\fR\fR\fB(\fR\fBconst\ char\ *addr\fR\fB, \fR\fBint\ len\fR\fB, \fR\fBint\ type\fR\fB, \fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR +.HP 36 +\fBstruct\ hostent\ *\ \fBlwres_gethostent_r\fR\fR\fB(\fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR +.HP 24 +\fBvoid\ \fBlwres_sethostent_r\fR\fR\fB(\fR\fBint\ stayopen\fR\fB);\fR +.HP 24 +\fBvoid\ \fBlwres_endhostent_r\fR\fR\fB(\fR\fBvoid\fR\fB);\fR .SH "DESCRIPTION" .PP -These functions provide hostname-to-address and -address-to-hostname lookups by means of the lightweight resolver. -They are similar to the standard -\fBgethostent\fR(3) -functions provided by most operating systems. -They use a +These functions provide hostname\-to\-address and address\-to\-hostname lookups by means of the lightweight resolver. They are similar to the standard +\fBgethostent\fR(3 ) +functions provided by most operating systems. They use a \fBstruct hostent\fR which is usually defined in \fI\fR. @@ -97,8 +72,8 @@ struct hostent { char **h_addr_list; /* list of addresses from name server */ }; #define h_addr h_addr_list[0] /* address, for backward compatibility */ -.sp .fi +.sp .PP The members of this structure are: .TP @@ -106,7 +81,7 @@ The members of this structure are: The official (canonical) name of the host. .TP \fBh_aliases\fR -A NULL-terminated array of alternate names (nicknames) for the host. +A NULL\-terminated array of alternate names (nicknames) for the host. .TP \fBh_addrtype\fR The type of address being returned \(em @@ -118,14 +93,14 @@ or The length of the address in bytes. .TP \fBh_addr_list\fR -A \fBNULL\fR -terminated array of network addresses for the host. -Host addresses are returned in network byte order. +A +\fBNULL\fR +terminated array of network addresses for the host. Host addresses are returned in network byte order. .PP For backward compatibility with very old software, -h_addr +\fBh_addr\fR is the first address in -h_addr_list. +\fBh_addr_list.\fR .PP \fBlwres_gethostent()\fR, \fBlwres_sethostent()\fR, @@ -134,72 +109,109 @@ h_addr_list. \fBlwres_sethostent_r()\fR and \fBlwres_endhostent_r()\fR -provide iteration over the known host entries on systems that -provide such functionality through facilities like +provide iteration over the known host entries on systems that provide such functionality through facilities like \fI/etc/hosts\fR -or NIS. The lightweight resolver does not currently implement -these functions; it only provides them as stub functions that always -return failure. +or NIS. The lightweight resolver does not currently implement these functions; it only provides them as stub functions that always return failure. .PP -\fBlwres_gethostbyname()\fR and -\fBlwres_gethostbyname2()\fR look up the hostname +\fBlwres_gethostbyname()\fR +and +\fBlwres_gethostbyname2()\fR +look up the hostname \fIname\fR. -\fBlwres_gethostbyname()\fR always looks for an IPv4 -address while \fBlwres_gethostbyname2()\fR looks for an -address of protocol family \fIaf\fR: either -\fBPF_INET\fR or \fBPF_INET6\fR \(em IPv4 or IPV6 -addresses respectively. Successful calls of the functions return a +\fBlwres_gethostbyname()\fR +always looks for an IPv4 address while +\fBlwres_gethostbyname2()\fR +looks for an address of protocol family +\fIaf\fR: either +\fBPF_INET\fR +or +\fBPF_INET6\fR +\(em IPv4 or IPV6 addresses respectively. Successful calls of the functions return a \fBstruct hostent\fRfor the name that was looked up. -\fBNULL\fR is returned if the lookups by -\fBlwres_gethostbyname()\fR or -\fBlwres_gethostbyname2()\fR fail. +\fBNULL\fR +is returned if the lookups by +\fBlwres_gethostbyname()\fR +or +\fBlwres_gethostbyname2()\fR +fail. .PP Reverse lookups of addresses are performed by \fBlwres_gethostbyaddr()\fR. -\fIaddr\fR is an address of length -\fIlen\fR bytes and protocol family -\fItype\fR \(em \fBPF_INET\fR or +\fIaddr\fR +is an address of length +\fIlen\fR +bytes and protocol family +\fItype\fR +\(em +\fBPF_INET\fR +or \fBPF_INET6\fR. -\fBlwres_gethostbyname_r()\fR is a thread-safe function -for forward lookups. If an error occurs, an error code is returned in +\fBlwres_gethostbyname_r()\fR +is a thread\-safe function for forward lookups. If an error occurs, an error code is returned in \fI*error\fR. -\fIresbuf\fR is a pointer to a \fBstruct -hostent\fR which is initialised by a successful call to -\fBlwres_gethostbyname_r()\fR . -\fIbuf\fR is a buffer of length -\fIlen\fR bytes which is used to store the -h_name, h_aliases, and -h_addr_list elements of the \fBstruct -hostent\fR returned in \fIresbuf\fR. -Successful calls to \fBlwres_gethostbyname_r()\fR -return \fIresbuf\fR, -which is a pointer to the \fBstruct hostent\fR it created. -.PP -\fBlwres_gethostbyaddr_r()\fR is a thread-safe function -that performs a reverse lookup of address \fIaddr\fR -which is \fIlen\fR bytes long and is of protocol -family \fItype\fR \(em \fBPF_INET\fR or -\fBPF_INET6\fR. If an error occurs, the error code is returned -in \fI*error\fR. The other function parameters are -identical to those in \fBlwres_gethostbyname_r()\fR. -\fIresbuf\fR is a pointer to a \fBstruct -hostent\fR which is initialised by a successful call to -\fBlwres_gethostbyaddr_r()\fR. -\fIbuf\fR is a buffer of length -\fIlen\fR bytes which is used to store the -h_name, h_aliases, and -h_addr_list elements of the \fBstruct -hostent\fR returned in \fIresbuf\fR. Successful -calls to \fBlwres_gethostbyaddr_r()\fR return +\fIresbuf\fR +is a pointer to a +\fBstruct hostent\fR +which is initialised by a successful call to +\fBlwres_gethostbyname_r()\fR +. +\fIbuf\fR +is a buffer of length +\fIlen\fR +bytes which is used to store the +\fBh_name\fR, +\fBh_aliases\fR, and +\fBh_addr_list\fR +elements of the +\fBstruct hostent\fR +returned in +\fIresbuf\fR. Successful calls to +\fBlwres_gethostbyname_r()\fR +return \fIresbuf\fR, which is a pointer to the -\fBstruct hostent()\fR it created. +\fBstruct hostent\fR +it created. +.PP +\fBlwres_gethostbyaddr_r()\fR +is a thread\-safe function that performs a reverse lookup of address +\fIaddr\fR +which is +\fIlen\fR +bytes long and is of protocol family +\fItype\fR +\(em +\fBPF_INET\fR +or +\fBPF_INET6\fR. If an error occurs, the error code is returned in +\fI*error\fR. The other function parameters are identical to those in +\fBlwres_gethostbyname_r()\fR. +\fIresbuf\fR +is a pointer to a +\fBstruct hostent\fR +which is initialised by a successful call to +\fBlwres_gethostbyaddr_r()\fR. +\fIbuf\fR +is a buffer of length +\fIlen\fR +bytes which is used to store the +\fBh_name\fR, +\fBh_aliases\fR, and +\fBh_addr_list\fR +elements of the +\fBstruct hostent\fR +returned in +\fIresbuf\fR. Successful calls to +\fBlwres_gethostbyaddr_r()\fR +return +\fIresbuf\fR, which is a pointer to the +\fBstruct hostent()\fR +it created. .SH "RETURN VALUES" .PP The functions \fBlwres_gethostbyname()\fR, \fBlwres_gethostbyname2()\fR, -\fBlwres_gethostbyaddr()\fR, -and +\fBlwres_gethostbyaddr()\fR, and \fBlwres_gethostent()\fR return NULL to indicate an error. In this case the global variable \fBlwres_h_errno\fR @@ -210,20 +222,15 @@ will contain one of the following error codes defined in The host or address was not found. .TP \fBTRY_AGAIN\fR -A recoverable error occurred, e.g., a timeout. -Retrying the lookup may succeed. +A recoverable error occurred, e.g., a timeout. Retrying the lookup may succeed. .TP \fBNO_RECOVERY\fR -A non-recoverable error occurred. +A non\-recoverable error occurred. .TP \fBNO_DATA\fR -The name exists, but has no address information -associated with it (or vice versa in the case -of a reverse lookup). The code NO_ADDRESS -is accepted as a synonym for NO_DATA for backwards -compatibility. +The name exists, but has no address information associated with it (or vice versa in the case of a reverse lookup). The code NO_ADDRESS is accepted as a synonym for NO_DATA for backwards compatibility. .PP -\fBlwres_hstrerror\fR(3) +\fBlwres_hstrerror\fR(3 ) translates these error codes to suitable error messages. .PP \fBlwres_gethostent()\fR @@ -232,23 +239,37 @@ and always return \fBNULL\fR. .PP -Successful calls to \fBlwres_gethostbyname_r()\fR and -\fBlwres_gethostbyaddr_r()\fR return -\fIresbuf\fR, a pointer to the \fBstruct -hostent\fR that was initialised by these functions. They return -\fBNULL\fR if the lookups fail or if \fIbuf\fR -was too small to hold the list of addresses and names referenced by -the h_name, h_aliases, and -h_addr_list elements of the \fBstruct -hostent\fR. If \fIbuf\fR was too small, both -\fBlwres_gethostbyname_r()\fR and -\fBlwres_gethostbyaddr_r()\fR set the global variable -\fBerrno\fR to ERANGE. +Successful calls to +\fBlwres_gethostbyname_r()\fR +and +\fBlwres_gethostbyaddr_r()\fR +return +\fIresbuf\fR, a pointer to the +\fBstruct hostent\fR +that was initialised by these functions. They return +\fBNULL\fR +if the lookups fail or if +\fIbuf\fR +was too small to hold the list of addresses and names referenced by the +\fBh_name\fR, +\fBh_aliases\fR, and +\fBh_addr_list\fR +elements of the +\fBstruct hostent\fR. If +\fIbuf\fR +was too small, both +\fBlwres_gethostbyname_r()\fR +and +\fBlwres_gethostbyaddr_r()\fR +set the global variable +\fBerrno\fR +to +\fBERANGE\fR. .SH "SEE ALSO" .PP \fBgethostent\fR(3), \fBlwres_getipnode\fR(3), -\fBlwres_hstrerror\fR(3) +\fBlwres_hstrerror\fR(3 ) .SH "BUGS" .PP \fBlwres_gethostbyname()\fR, @@ -256,17 +277,12 @@ hostent\fR. If \fIbuf\fR was too small, both \fBlwres_gethostbyaddr()\fR and \fBlwres_endhostent()\fR -are not thread safe; they return pointers to static data and -provide error codes through a global variable. -Thread-safe versions for name and address lookup are provided by -\fBlwres_gethostbyname_r()\fR, -and +are not thread safe; they return pointers to static data and provide error codes through a global variable. Thread\-safe versions for name and address lookup are provided by +\fBlwres_gethostbyname_r()\fR, and \fBlwres_gethostbyaddr_r()\fR respectively. .PP -The resolver daemon does not currently support any non-DNS -name services such as +The resolver daemon does not currently support any non\-DNS name services such as \fI/etc/hosts\fR or -\fBNIS\fR, -consequently the above functions don't, either. +\fBNIS\fR, consequently the above functions don't, either. diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook index 10324c31b94..9f92d3b3134 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook @@ -1,6 +1,8 @@ - +]> - + @@ -30,6 +32,18 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2001 + Internet Software Consortium. + + + lwres_gethostbyname lwres_gethostbyname2 diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.html b/contrib/bind9/lib/lwres/man/lwres_gethostent.html index 00b285db206..263f9932362 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gethostent.html +++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.html @@ -1,784 +1,430 @@ - - - - -lwres_gethostent

lwres_gethostent

Name

lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r -- lightweight resolver get network host entry

Synopsis

#include <lwres/netdb.h>

struct hostent * -lwres_gethostbyname(const char *name);

struct hostent * -lwres_gethostbyname2(const char *name, int af);

struct hostent * -lwres_gethostbyaddr(const char *addr, int len, int type);

struct hostent * -lwres_gethostent(void);

void -lwres_sethostent(int stayopen);

void -lwres_endhostent(void);

struct hostent * -lwres_gethostbyname_r(const char *name, struct hostent *resbuf, char *buf, int buflen, int *error);

struct hostent * -lwres_gethostbyaddr_r(const char *addr, int len, int type, struct hostent *resbuf, char *buf, int buflen, int *error);

struct hostent * -lwres_gethostent_r(struct hostent *resbuf, char *buf, int buflen, int *error);

void -lwres_sethostent_r(int stayopen);

void -lwres_endhostent_r(void);

DESCRIPTION

These functions provide hostname-to-address and + + + + +lwres_gethostent + + +

+
+
+

Name

+

lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r — lightweight resolver get network host entry

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+ + + + +
+struct hostent * +lwres_gethostbyname(  +);
+ + + + + + + + + + + +
+struct hostent * +lwres_gethostbyname2( ,
   +);
+ + + + + + + + + + + + + + + + +
+struct hostent * +lwres_gethostbyaddr( ,
  ,
   +);
+

+struct hostent * +lwres_gethostent(void);

+

+void +lwres_sethostent(int stayopen);

+

+void +lwres_endhostent(void);

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+struct hostent * +lwres_gethostbyname_r( ,
  ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+struct hostent * +lwres_gethostbyaddr_r( ,
  ,
  ,
  ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+struct hostent * +lwres_gethostent_r( ,
  ,
  ,
   +);
+

+void +lwres_sethostent_r(int stayopen);

+

+void +lwres_endhostent_r(void);

+
+
+
+

DESCRIPTION

+

+These functions provide hostname-to-address and address-to-hostname lookups by means of the lightweight resolver. They are similar to the standard -gethostent(3) +gethostent(3 +) functions provided by most operating systems. They use a -struct hostent +struct hostent which is usually defined in -<namedb.h>. +<namedb.h>. -

struct  hostent {
+

+
+struct  hostent {
         char    *h_name;        /* official name of host */
         char    **h_aliases;    /* alias list */
         int     h_addrtype;     /* host address type */
         int     h_length;       /* length of address */
         char    **h_addr_list;  /* list of addresses from name server */
 };
-#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
The members of this structure are:
-
h_name
The official (canonical) name of the host.
h_aliases
A NULL-terminated array of alternate names (nicknames) for the host.
h_addrtype
The type of address being returned —
-PF_INET
+#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
+
+

+

+

+The members of this structure are: +

+
+
h_name
+

+The official (canonical) name of the host. +

+
h_aliases
+

+A NULL-terminated array of alternate names (nicknames) for the host. +

+
h_addrtype
+

+The type of address being returned — +PF_INET or -PF_INET6.

h_length

The length of the address in bytes.

h_addr_list

A NULL +PF_INET6. +

+
h_length
+

+The length of the address in bytes. +

+
h_addr_list
+

+A NULL terminated array of network addresses for the host. -Host addresses are returned in network byte order.

For backward compatibility with very old software, -h_addr +Host addresses are returned in network byte order. +

+
+

+

+

+For backward compatibility with very old software, +h_addr is the first address in -h_addr_list.

lwres_gethostent(), -lwres_sethostent(), -lwres_endhostent(), -lwres_gethostent_r(), -lwres_sethostent_r() +h_addr_list. +

+

+lwres_gethostent(), +lwres_sethostent(), +lwres_endhostent(), +lwres_gethostent_r(), +lwres_sethostent_r() and -lwres_endhostent_r() +lwres_endhostent_r() provide iteration over the known host entries on systems that provide such functionality through facilities like -/etc/hosts +/etc/hosts or NIS. The lightweight resolver does not currently implement these functions; it only provides them as stub functions that always -return failure.

lwres_gethostbyname() and -lwres_gethostbyname2() look up the hostname -name. -lwres_gethostbyname() always looks for an IPv4 -address while lwres_gethostbyname2() looks for an -address of protocol family af: either -PF_INET or PF_INET6 — IPv4 or IPV6 +return failure. +

+

+lwres_gethostbyname() and +lwres_gethostbyname2() look up the hostname +name. +lwres_gethostbyname() always looks for an IPv4 +address while lwres_gethostbyname2() looks for an +address of protocol family af: either +PF_INET or PF_INET6 — IPv4 or IPV6 addresses respectively. Successful calls of the functions return a -struct hostentfor the name that was looked up. -NULL is returned if the lookups by -lwres_gethostbyname() or -lwres_gethostbyname2() fail.

Reverse lookups of addresses are performed by -lwres_gethostbyaddr(). -addr is an address of length -len bytes and protocol family -type — PF_INET or -PF_INET6. -lwres_gethostbyname_r() is a thread-safe function +struct hostentfor the name that was looked up. +NULL is returned if the lookups by +lwres_gethostbyname() or +lwres_gethostbyname2() fail. +

+

+Reverse lookups of addresses are performed by +lwres_gethostbyaddr(). +addr is an address of length +len bytes and protocol family +type — PF_INET or +PF_INET6. +lwres_gethostbyname_r() is a thread-safe function for forward lookups. If an error occurs, an error code is returned in -*error. -resbuf is a pointer to a struct -hostent which is initialised by a successful call to -lwres_gethostbyname_r() . -buf is a buffer of length -len bytes which is used to store the -h_name, h_aliases, and -h_addr_list elements of the struct -hostent returned in resbuf. -Successful calls to lwres_gethostbyname_r() -return resbuf, -which is a pointer to the struct hostent it created.

lwres_gethostbyaddr_r() is a thread-safe function -that performs a reverse lookup of address addr -which is len bytes long and is of protocol -family type — PF_INET or -PF_INET6. If an error occurs, the error code is returned -in *error. The other function parameters are -identical to those in lwres_gethostbyname_r(). -resbuf is a pointer to a struct -hostent which is initialised by a successful call to -lwres_gethostbyaddr_r(). -buf is a buffer of length -len bytes which is used to store the -h_name, h_aliases, and -h_addr_list elements of the struct -hostent returned in resbuf. Successful -calls to lwres_gethostbyaddr_r() return -resbuf, which is a pointer to the -struct hostent() it created.

RETURN VALUES

The functions -lwres_gethostbyname(), -lwres_gethostbyname2(), -lwres_gethostbyaddr(), +*error. +resbuf is a pointer to a struct +hostent which is initialised by a successful call to +lwres_gethostbyname_r() . +buf is a buffer of length +len bytes which is used to store the +h_name, h_aliases, and +h_addr_list elements of the struct +hostent returned in resbuf. +Successful calls to lwres_gethostbyname_r() +return resbuf, +which is a pointer to the struct hostent it created. +

+

+lwres_gethostbyaddr_r() is a thread-safe function +that performs a reverse lookup of address addr +which is len bytes long and is of protocol +family type — PF_INET or +PF_INET6. If an error occurs, the error code is returned +in *error. The other function parameters are +identical to those in lwres_gethostbyname_r(). +resbuf is a pointer to a struct +hostent which is initialised by a successful call to +lwres_gethostbyaddr_r(). +buf is a buffer of length +len bytes which is used to store the +h_name, h_aliases, and +h_addr_list elements of the struct +hostent returned in resbuf. Successful +calls to lwres_gethostbyaddr_r() return +resbuf, which is a pointer to the +struct hostent() it created. +

+
+
+

RETURN VALUES

+

+The functions +lwres_gethostbyname(), +lwres_gethostbyname2(), +lwres_gethostbyaddr(), and -lwres_gethostent() +lwres_gethostent() return NULL to indicate an error. In this case the global variable -lwres_h_errno +lwres_h_errno will contain one of the following error codes defined in -<lwres/netdb.h>: +<lwres/netdb.h>: -

HOST_NOT_FOUND

The host or address was not found.

TRY_AGAIN

A recoverable error occurred, e.g., a timeout. -Retrying the lookup may succeed.

NO_RECOVERY

A non-recoverable error occurred.

NO_DATA

The name exists, but has no address information +

+
+
HOST_NOT_FOUND
+

+The host or address was not found. +

+
TRY_AGAIN
+

+A recoverable error occurred, e.g., a timeout. +Retrying the lookup may succeed. +

+
NO_RECOVERY
+

+A non-recoverable error occurred. +

+
NO_DATA
+

+The name exists, but has no address information associated with it (or vice versa in the case of a reverse lookup). The code NO_ADDRESS is accepted as a synonym for NO_DATA for backwards -compatibility.

lwres_hstrerror(3) -translates these error codes to suitable error messages.

lwres_gethostent() +compatibility. +

+
+

+

+

+lwres_hstrerror(3 +) +translates these error codes to suitable error messages. +

+

+lwres_gethostent() and -lwres_gethostent_r() +lwres_gethostent_r() always return -NULL.

Successful calls to lwres_gethostbyname_r() and -lwres_gethostbyaddr_r() return -resbuf, a pointer to the struct -hostent that was initialised by these functions. They return -NULL if the lookups fail or if buf +NULL. +

+

+Successful calls to lwres_gethostbyname_r() and +lwres_gethostbyaddr_r() return +resbuf, a pointer to the struct +hostent that was initialised by these functions. They return +NULL if the lookups fail or if buf was too small to hold the list of addresses and names referenced by -the h_name, h_aliases, and -h_addr_list elements of the struct -hostent. If buf was too small, both -lwres_gethostbyname_r() and -lwres_gethostbyaddr_r() set the global variable -errno to ERANGE.

SEE ALSO

gethostent(3), +the h_name, h_aliases, and +h_addr_list elements of the struct +hostent. If buf was too small, both +lwres_gethostbyname_r() and +lwres_gethostbyaddr_r() set the global variable +errno to ERANGE. +

+
+
+

SEE ALSO

+

+gethostent(3), -lwres_getipnode(3), +lwres_getipnode(3), -lwres_hstrerror(3)

BUGS

lwres_gethostbyname(), -lwres_gethostbyname2(), -lwres_gethostbyaddr() +lwres_hstrerror(3 +) +

+
+
+

BUGS

+

+lwres_gethostbyname(), +lwres_gethostbyname2(), +lwres_gethostbyaddr() and -lwres_endhostent() +lwres_endhostent() are not thread safe; they return pointers to static data and provide error codes through a global variable. Thread-safe versions for name and address lookup are provided by -lwres_gethostbyname_r(), +lwres_gethostbyname_r(), and -lwres_gethostbyaddr_r() -respectively.

The resolver daemon does not currently support any non-DNS +lwres_gethostbyaddr_r() +respectively. +

+

+The resolver daemon does not currently support any non-DNS name services such as -/etc/hosts +/etc/hosts or -NIS, -consequently the above functions don't, either.

+NIS, +consequently the above functions don't, either. +

+
+ + diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.3 b/contrib/bind9/lib/lwres/man/lwres_getipnode.3 index 815a841512c..d83758c5acf 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getipnode.3 +++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.3 @@ -1,46 +1,46 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001, 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, +.\" 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: lwres_getipnode.3,v 1.13.2.2.4.2 2004/03/09 05:21:10 marka Exp $ +.\" $Id: lwres_getipnode.3,v 1.13.2.2.4.6 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GETIPNODE" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GETIPNODE" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent \- lightweight resolver nodename / address translation API -.SH SYNOPSIS -\fB#include -.sp -.na -struct hostent * -lwres_getipnodebyname(const char *name, int af, int flags, int *error_num); -.ad -.sp -.na -struct hostent * -lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num); -.ad -.sp -.na -void -lwres_freehostent(struct hostent *he); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 39 +\fBstruct\ hostent\ *\ \fBlwres_getipnodebyname\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBint\ af\fR\fB, \fR\fBint\ flags\fR\fB, \fR\fBint\ *error_num\fR\fB);\fR +.HP 39 +\fBstruct\ hostent\ *\ \fBlwres_getipnodebyaddr\fR\fR\fB(\fR\fBconst\ void\ *src\fR\fB, \fR\fBsize_t\ len\fR\fB, \fR\fBint\ af\fR\fB, \fR\fBint\ *error_num\fR\fB);\fR +.HP 23 +\fBvoid\ \fBlwres_freehostent\fR\fR\fB(\fR\fBstruct\ hostent\ *he\fR\fB);\fR .SH "DESCRIPTION" .PP -These functions perform thread safe, protocol independent -nodename-to-address and address-to-nodename -translation as defined in RFC2553. +These functions perform thread safe, protocol independent nodename\-to\-address and address\-to\-nodename translation as defined in RFC2553. .PP They use a \fBstruct hostent\fR @@ -56,8 +56,8 @@ struct hostent { char **h_addr_list; /* list of addresses from name server */ }; #define h_addr h_addr_list[0] /* address, for backward compatibility */ -.sp .fi +.sp .PP The members of this structure are: .TP @@ -65,10 +65,10 @@ The members of this structure are: The official (canonical) name of the host. .TP \fBh_aliases\fR -A NULL-terminated array of alternate names (nicknames) for the host. +A NULL\-terminated array of alternate names (nicknames) for the host. .TP \fBh_addrtype\fR -The type of address being returned - usually +The type of address being returned \- usually \fBPF_INET\fR or \fBPF_INET6\fR. @@ -79,49 +79,38 @@ The length of the address in bytes. \fBh_addr_list\fR A \fBNULL\fR -terminated array of network addresses for the host. -Host addresses are returned in network byte order. +terminated array of network addresses for the host. Host addresses are returned in network byte order. .PP \fBlwres_getipnodebyname()\fR looks up addresses of protocol family \fIaf\fR for the hostname -\fIname\fR. -The +\fIname\fR. The \fIflags\fR -parameter contains ORed flag bits to -specify the types of addresses that are searched -for, and the types of addresses that are returned. -The flag bits are: +parameter contains ORed flag bits to specify the types of addresses that are searched for, and the types of addresses that are returned. The flag bits are: .TP \fBAI_V4MAPPED\fR This is used with an \fIaf\fR -of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped -IPv6 addresses. +of AF_INET6, and causes IPv4 addresses to be returned as IPv4\-mapped IPv6 addresses. .TP \fBAI_ALL\fR This is used with an \fIaf\fR -of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned. -If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped -IPv6 addresses. +of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned. If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped IPv6 addresses. .TP \fBAI_ADDRCONFIG\fR -Only return an IPv6 or IPv4 address if here is an active network -interface of that type. This is not currently implemented -in the BIND 9 lightweight resolver, and the flag is ignored. +Only return an IPv6 or IPv4 address if here is an active network interface of that type. This is not currently implemented in the BIND 9 lightweight resolver, and the flag is ignored. .TP \fBAI_DEFAULT\fR This default sets the -AI_V4MAPPED +\fBAI_V4MAPPED\fR and -AI_ADDRCONFIG +\fBAI_ADDRCONFIG\fR flag bits. .PP \fBlwres_getipnodebyaddr()\fR -performs a reverse lookup -of address +performs a reverse lookup of address \fIsrc\fR which is \fIlen\fR @@ -133,16 +122,14 @@ or \fBPF_INET6\fR. .PP \fBlwres_freehostent()\fR -releases all the memory associated with -the +releases all the memory associated with the \fBstruct hostent\fR pointer -\fIhe\fR. -Any memory allocated for the -h_name, -h_addr_list +\fIhe\fR. Any memory allocated for the +\fBh_name\fR, +\fBh_addr_list\fR and -h_aliases +\fBh_aliases\fR is freed, as is the memory for the \fBhostent\fR structure itself. @@ -156,32 +143,26 @@ set \fI*error_num\fR to an appropriate error code and the function returns a \fBNULL\fR -pointer. -The error codes and their meanings are defined in +pointer. The error codes and their meanings are defined in \fI\fR: .TP \fBHOST_NOT_FOUND\fR No such host is known. .TP \fBNO_ADDRESS\fR -The server recognised the request and the name but no address is -available. Another type of request to the name server for the -domain might return an answer. +The server recognised the request and the name but no address is available. Another type of request to the name server for the domain might return an answer. .TP \fBTRY_AGAIN\fR -A temporary and possibly transient error occurred, such as a -failure of a server to respond. The request may succeed if -retried. +A temporary and possibly transient error occurred, such as a failure of a server to respond. The request may succeed if retried. .TP \fBNO_RECOVERY\fR -An unexpected failure occurred, and retrying the request -is pointless. +An unexpected failure occurred, and retrying the request is pointless. .PP -\fBlwres_hstrerror\fR(3) +\fBlwres_hstrerror\fR(3 ) translates these error codes to suitable error messages. .SH "SEE ALSO" .PP -\fBRFC2553\fR, +\fBRFC2553\fR(), \fBlwres\fR(3), \fBlwres_gethostent\fR(3), \fBlwres_getaddrinfo\fR(3), diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook index 30c04a35550..94de72c0fe7 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,20 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2003 + Internet Software Consortium. + + + lwres_getipnodebyname lwres_getipnodebyaddr diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.html b/contrib/bind9/lib/lwres/man/lwres_getipnode.html index 3063d440582..c5038b4f5a5 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getipnode.html +++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.html @@ -1,512 +1,298 @@ - - - - -lwres_getipnode

lwres_getipnode

Name

lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent -- lightweight resolver nodename / address translation API

Synopsis

#include <lwres/netdb.h>

struct hostent * -lwres_getipnodebyname(const char *name, int af, int flags, int *error_num);

struct hostent * -lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num);

void -lwres_freehostent(struct hostent *he);

DESCRIPTION

These functions perform thread safe, protocol independent + + + + +lwres_getipnode + + +

+
+
+

Name

+

lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent — lightweight resolver nodename / address translation API

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+ + + + + + + + + + + + + + + + + + + + + +
+struct hostent * +lwres_getipnodebyname( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+struct hostent * +lwres_getipnodebyaddr( ,
  ,
  ,
   +);
+ + + + +
+void +lwres_freehostent(  +);
+
+
+
+

DESCRIPTION

+

+These functions perform thread safe, protocol independent nodename-to-address and address-to-nodename -translation as defined in RFC2553.

They use a -struct hostent +translation as defined in RFC2553. +

+

+They use a +struct hostent which is defined in -namedb.h: -

struct  hostent {
+namedb.h:
+

+
+struct  hostent {
         char    *h_name;        /* official name of host */
         char    **h_aliases;    /* alias list */
         int     h_addrtype;     /* host address type */
         int     h_length;       /* length of address */
         char    **h_addr_list;  /* list of addresses from name server */
 };
-#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
The members of this structure are:
-
h_name
The official (canonical) name of the host.
h_aliases
A NULL-terminated array of alternate names (nicknames) for the host.
h_addrtype
The type of address being returned - usually
-PF_INET
+#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
+
+

+

+

+The members of this structure are: +

+
+
h_name
+

+The official (canonical) name of the host. +

+
h_aliases
+

+A NULL-terminated array of alternate names (nicknames) for the host. +

+
h_addrtype
+

+The type of address being returned - usually +PF_INET or -PF_INET6.

h_length

The length of the address in bytes.

h_addr_list

A -NULL +PF_INET6. + +

+
h_length
+

+The length of the address in bytes. +

+
h_addr_list
+

+A +NULL terminated array of network addresses for the host. -Host addresses are returned in network byte order.

lwres_getipnodebyname() +Host addresses are returned in network byte order. +

+
+

+

+

+lwres_getipnodebyname() looks up addresses of protocol family -af +af for the hostname -name. +name. The -flags +flags parameter contains ORed flag bits to specify the types of addresses that are searched for, and the types of addresses that are returned. The flag bits are: -

AI_V4MAPPED

This is used with an -af +

+
+
AI_V4MAPPED
+

+This is used with an +af of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped -IPv6 addresses.

AI_ALL

This is used with an -af +IPv6 addresses. +

+
AI_ALL
+

+This is used with an +af of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned. If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped -IPv6 addresses.

AI_ADDRCONFIG

Only return an IPv6 or IPv4 address if here is an active network +IPv6 addresses. +

+
AI_ADDRCONFIG
+

+Only return an IPv6 or IPv4 address if here is an active network interface of that type. This is not currently implemented -in the BIND 9 lightweight resolver, and the flag is ignored.

AI_DEFAULT

This default sets the -AI_V4MAPPED +in the BIND 9 lightweight resolver, and the flag is ignored. +

+
AI_DEFAULT
+

+This default sets the +AI_V4MAPPED and -AI_ADDRCONFIG -flag bits.

lwres_getipnodebyaddr() +AI_ADDRCONFIG +flag bits. +

+
+

+

+

+lwres_getipnodebyaddr() performs a reverse lookup of address -src +src which is -len +len bytes long. -af +af denotes the protocol family, typically -PF_INET +PF_INET or -PF_INET6.

lwres_freehostent() +PF_INET6. + +

+

+lwres_freehostent() releases all the memory associated with the -struct hostent +struct hostent pointer -he. +he. Any memory allocated for the -h_name, +h_name, -h_addr_list +h_addr_list and -h_aliases +h_aliases is freed, as is the memory for the -hostent -structure itself.

RETURN VALUES

If an error occurs, -lwres_getipnodebyname() +hostent +structure itself. +

+
+
+

RETURN VALUES

+

+If an error occurs, +lwres_getipnodebyname() and -lwres_getipnodebyaddr() +lwres_getipnodebyaddr() set -*error_num +*error_num to an appropriate error code and the function returns a -NULL +NULL pointer. The error codes and their meanings are defined in -<lwres/netdb.h>: -

HOST_NOT_FOUND

No such host is known.

NO_ADDRESS

The server recognised the request and the name but no address is +<lwres/netdb.h>: +

+
+
HOST_NOT_FOUND
+

+No such host is known. +

+
NO_ADDRESS
+

+The server recognised the request and the name but no address is available. Another type of request to the name server for the -domain might return an answer.

TRY_AGAIN

A temporary and possibly transient error occurred, such as a +domain might return an answer. +

+
TRY_AGAIN
+

+A temporary and possibly transient error occurred, such as a failure of a server to respond. The request may succeed if -retried.

NO_RECOVERY

An unexpected failure occurred, and retrying the request -is pointless.

lwres_hstrerror(3) -translates these error codes to suitable error messages.

SEE ALSO

RFC2553, +retried. +

+
NO_RECOVERY
+

+An unexpected failure occurred, and retrying the request +is pointless. +

+
+

+

+

+lwres_hstrerror(3 +) +translates these error codes to suitable error messages. +

+
+
+

SEE ALSO

+

+RFC2553, -lwres(3), +lwres(3), -lwres_gethostent(3), +lwres_gethostent(3), -lwres_getaddrinfo(3), +lwres_getaddrinfo(3), -lwres_getnameinfo(3), +lwres_getnameinfo(3), -lwres_hstrerror(3).

+lwres_hstrerror(3). +

+
+ + diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 index a512270673b..853c2b9bb94 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 +++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 @@ -1,79 +1,91 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_getnameinfo.3,v 1.15.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_getnameinfo.3,v 1.15.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GETNAMEINFO" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GETNAMEINFO" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_getnameinfo \- lightweight resolver socket address structure to hostname and service name -.SH SYNOPSIS -\fB#include -.sp -.na -int -lwres_getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 22 +\fBint\ \fBlwres_getnameinfo\fR\fR\fB(\fR\fBconst\ struct\ sockaddr\ *sa\fR\fB, \fR\fBsize_t\ salen\fR\fB, \fR\fBchar\ *host\fR\fB, \fR\fBsize_t\ hostlen\fR\fB, \fR\fBchar\ *serv\fR\fB, \fR\fBsize_t\ servlen\fR\fB, \fR\fBint\ flags\fR\fB);\fR .SH "DESCRIPTION" .PP -This function is equivalent to the \fBgetnameinfo\fR(3) function defined in RFC2133. -\fBlwres_getnameinfo()\fR returns the hostname for the -\fBstruct sockaddr\fR \fIsa\fR which is -\fIsalen\fR bytes long. The hostname is of length -\fIhostlen\fR and is returned via -\fI*host.\fR The maximum length of the hostname is -1025 bytes: NI_MAXHOST. +This function is equivalent to the +\fBgetnameinfo\fR(3) +function defined in RFC2133. +\fBlwres_getnameinfo()\fR +returns the hostname for the +\fBstruct sockaddr\fR\fIsa\fR +which is +\fIsalen\fR +bytes long. The hostname is of length +\fIhostlen\fR +and is returned via +\fI*host.\fR +The maximum length of the hostname is 1025 bytes: +\fBNI_MAXHOST\fR. .PP The name of the service associated with the port number in -\fIsa\fR is returned in \fI*serv.\fR -It is \fIservlen\fR bytes long. The maximum length -of the service name is NI_MAXSERV - 32 bytes. +\fIsa\fR +is returned in +\fI*serv.\fR +It is +\fIservlen\fR +bytes long. The maximum length of the service name is +\fBNI_MAXSERV\fR +\- 32 bytes. .PP -The \fIflags\fR argument sets the following -bits: +The +\fIflags\fR +argument sets the following bits: .TP \fBNI_NOFQDN\fR -A fully qualified domain name is not required for local hosts. -The local part of the fully qualified domain name is returned instead. +A fully qualified domain name is not required for local hosts. The local part of the fully qualified domain name is returned instead. .TP \fBNI_NUMERICHOST\fR -Return the address in numeric form, as if calling inet_ntop(), -instead of a host name. +Return the address in numeric form, as if calling inet_ntop(), instead of a host name. .TP \fBNI_NAMEREQD\fR -A name is required. If the hostname cannot be found in the DNS and -this flag is set, a non-zero error code is returned. -If the hostname is not found and the flag is not set, the -address is returned in numeric form. +A name is required. If the hostname cannot be found in the DNS and this flag is set, a non\-zero error code is returned. If the hostname is not found and the flag is not set, the address is returned in numeric form. .TP \fBNI_NUMERICSERV\fR The service name is returned as a digit string representing the port number. .TP \fBNI_DGRAM\fR -Specifies that the service being looked up is a datagram -service, and causes getservbyport() to be called with a second -argument of "udp" instead of its default of "tcp". This is required -for the few ports (512-514) that have different services for UDP and -TCP. +Specifies that the service being looked up is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (512\-514) that have different services for UDP and TCP. .SH "RETURN VALUES" .PP \fBlwres_getnameinfo()\fR -returns 0 on success or a non-zero error code if an error occurs. +returns 0 on success or a non\-zero error code if an error occurs. .SH "SEE ALSO" .PP -\fBRFC2133\fR, +\fBRFC2133\fR(), \fBgetservbyport\fR(3), \fBlwres\fR(3), \fBlwres_getnameinfo\fR(3), diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook index ff2eaad0e96..b6e10ac3ab0 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_getnameinfo lightweight resolver socket address structure to hostname and service name @@ -140,6 +155,7 @@ returns 0 on success or a non-zero error code if an error occurs. lwres_net_ntop3 . + BUGS diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html index 8130fe83211..6e7a7b16658 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html +++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html @@ -1,290 +1,154 @@ - - - - -lwres_getnameinfo

lwres_getnameinfo

Name

lwres_getnameinfo -- lightweight resolver socket address structure to hostname and service name

Synopsis

#include <lwres/netdb.h>

int -lwres_getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags);

DESCRIPTION

This function is equivalent to the getnameinfo(3) function defined in RFC2133. -lwres_getnameinfo() returns the hostname for the -struct sockaddr sa which is -salen bytes long. The hostname is of length -hostlen and is returned via -*host. The maximum length of the hostname is -1025 bytes: NI_MAXHOST.

The name of the service associated with the port number in -sa is returned in *serv. -It is servlen bytes long. The maximum length -of the service name is NI_MAXSERV - 32 bytes.

The flags argument sets the following + + + + +lwres_getnameinfo + + +

+
+
+

Name

+

lwres_getnameinfo — lightweight resolver socket address structure to hostname and service name

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+int +lwres_getnameinfo( ,
  ,
  ,
  ,
  ,
  ,
   +);
+
+
+
+

DESCRIPTION

+

This function is equivalent to the getnameinfo(3) function defined in RFC2133. +lwres_getnameinfo() returns the hostname for the +struct sockaddr sa which is +salen bytes long. The hostname is of length +hostlen and is returned via +*host. The maximum length of the hostname is +1025 bytes: NI_MAXHOST.

+

The name of the service associated with the port number in +sa is returned in *serv. +It is servlen bytes long. The maximum length +of the service name is NI_MAXSERV - 32 bytes. +

+

The flags argument sets the following bits: -

NI_NOFQDN

A fully qualified domain name is not required for local hosts. -The local part of the fully qualified domain name is returned instead.

NI_NUMERICHOST

Return the address in numeric form, as if calling inet_ntop(), -instead of a host name.

NI_NAMEREQD

A name is required. If the hostname cannot be found in the DNS and +

+
+
NI_NOFQDN
+

+A fully qualified domain name is not required for local hosts. +The local part of the fully qualified domain name is returned instead. +

+
NI_NUMERICHOST
+

+Return the address in numeric form, as if calling inet_ntop(), +instead of a host name. +

+
NI_NAMEREQD
+

+A name is required. If the hostname cannot be found in the DNS and this flag is set, a non-zero error code is returned. If the hostname is not found and the flag is not set, the -address is returned in numeric form.

NI_NUMERICSERV

The service name is returned as a digit string representing the port number.

NI_DGRAM

Specifies that the service being looked up is a datagram +address is returned in numeric form. +

+
NI_NUMERICSERV
+

+The service name is returned as a digit string representing the port number. +

+
NI_DGRAM
+

+Specifies that the service being looked up is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (512-514) that have different services for UDP and -TCP.

RETURN VALUES

lwres_getnameinfo() -returns 0 on success or a non-zero error code if an error occurs.

SEE ALSO

RFC2133, -getservbyport(3), -lwres(3), -lwres_getnameinfo(3), -lwres_getnamebyaddr(3). -lwres_net_ntop(3).

BUGS

RFC2133 fails to define what the nonzero return values of -getnameinfo(3) -are.

+TCP. +

+
+

+

+
+
+

RETURN VALUES

+

+lwres_getnameinfo() +returns 0 on success or a non-zero error code if an error occurs. +

+
+
+

SEE ALSO

+

+RFC2133, +getservbyport(3), +lwres(3), +lwres_getnameinfo(3), +lwres_getnamebyaddr(3). +lwres_net_ntop(3). +

+
+
+

BUGS

+

+RFC2133 fails to define what the nonzero return values of +getnameinfo(3) +are. +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 index 1558f6d5b08..6d900f864ff 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 +++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 @@ -1,36 +1,41 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_getrrsetbyname.3,v 1.11.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_getrrsetbyname.3,v 1.11.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GETRRSETBYNAME" "3" "Oct 18, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GETRRSETBYNAME" "3" "Oct 18, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_getrrsetbyname, lwres_freerrset \- retrieve DNS records -.SH SYNOPSIS -\fB#include -.sp -.na -int -lwres_getrrsetbyname(const char *hostname, unsigned int rdclass, unsigned int rdtype, unsigned int flags, struct rrsetinfo **res); -.ad -.sp -.na -void -lwres_freerrset(struct rrsetinfo *rrset); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 25 +\fBint\ \fBlwres_getrrsetbyname\fR\fR\fB(\fR\fBconst\ char\ *hostname\fR\fB, \fR\fBunsigned\ int\ rdclass\fR\fB, \fR\fBunsigned\ int\ rdtype\fR\fB, \fR\fBunsigned\ int\ flags\fR\fB, \fR\fBstruct\ rrsetinfo\ **res\fR\fB);\fR +.HP 21 +\fBvoid\ \fBlwres_freerrset\fR\fR\fB(\fR\fBstruct\ rrsetinfo\ *rrset\fR\fB);\fR .PP The following structures are used: .sp @@ -39,7 +44,6 @@ struct rdatainfo { unsigned int rdi_length; /* length of data */ unsigned char *rdi_data; /* record data */ }; - struct rrsetinfo { unsigned int rri_flags; /* RRSET_VALIDATED... */ unsigned int rri_rdclass; /* class number */ @@ -51,19 +55,17 @@ struct rrsetinfo { struct rdatainfo *rri_rdatas; /* individual records */ struct rdatainfo *rri_sigs; /* individual signatures */ }; -.sp .fi +.sp .SH "DESCRIPTION" .PP \fBlwres_getrrsetbyname()\fR gets a set of resource records associated with a \fIhostname\fR, -\fIclass\fR, -and +\fIclass\fR, and \fItype\fR. \fIhostname\fR -is -a pointer a to null-terminated string. The +is a pointer a to null\-terminated string. The \fIflags\fR field is currently unused and must be zero. .PP @@ -76,38 +78,30 @@ structure, containing a list of one or more \fBrdatainfo\fR structures containing resource records and potentially another list of \fBrdatainfo\fR -structures containing SIG resource records -associated with those records. -The members -rri_rdclass +structures containing SIG resource records associated with those records. The members +\fBrri_rdclass\fR and -rri_rdtype +\fBrri_rdtype\fR are copied from the parameters. -rri_ttl +\fBrri_ttl\fR and -rri_name -are properties of the obtained rrset. -The resource records contained in -rri_rdatas +\fBrri_name\fR +are properties of the obtained rrset. The resource records contained in +\fBrri_rdatas\fR and -rri_sigs -are in uncompressed DNS wire format. -Properties of the rdataset are represented in the -rri_flags -bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC -validated and the signatures verified. +\fBrri_sigs\fR +are in uncompressed DNS wire format. Properties of the rdataset are represented in the +\fBrri_flags\fR +bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC validated and the signatures verified. .PP All of the information returned by \fBlwres_getrrsetbyname()\fR is dynamically allocated: the -rrsetinfo +\fBrrsetinfo\fR and -rdatainfo -structures, -and the canonical host name strings pointed to by the -rrsetinfostructure. -Memory allocated for the dynamically allocated structures created by -a successful call to +\fBrdatainfo\fR +structures, and the canonical host name strings pointed to by the +\fBrrsetinfo\fRstructure. Memory allocated for the dynamically allocated structures created by a successful call to \fBlwres_getrrsetbyname()\fR is released by \fBlwres_freerrset()\fR. @@ -120,8 +114,7 @@ created by a call to .SH "RETURN VALUES" .PP \fBlwres_getrrsetbyname()\fR -returns zero on success, and one of the following error -codes if an error occurred: +returns zero on success, and one of the following error codes if an error occurred: .TP \fBERRSET_NONAME\fR the name does not exist @@ -138,7 +131,6 @@ a parameter is invalid \fBERRSET_FAIL\fR other failure .TP -\fB\fR .SH "SEE ALSO" .PP \fBlwres\fR(3). diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook index 5ec7884b360..53c33bef7b3 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -29,6 +31,20 @@ 3 BIND9 + + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_getrrsetbyname lwres_freerrset diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html index 8a688e9b2b4..f36a1d21d99 100644 --- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html +++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html @@ -1,91 +1,80 @@ - - - - -lwres_getrrsetbyname

lwres_getrrsetbyname

Name

lwres_getrrsetbyname, lwres_freerrset -- retrieve DNS records

Synopsis

#include <lwres/netdb.h>

int -lwres_getrrsetbyname(const char *hostname, unsigned int rdclass, unsigned int rdtype, unsigned int flags, struct rrsetinfo **res);

void -lwres_freerrset(struct rrsetinfo *rrset);

The following structures are used: -

struct  rdatainfo {
+
+
+
+
+lwres_getrrsetbyname
+
+
+

+

+

+
Name

+
lwres_getrrsetbyname, lwres_freerrset — retrieve DNS records

+

+

+
Synopsis

+

+
#include <lwres/netdb.h>

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

+int
+lwres_getrrsetbyname( , 
  , 
  , 
  , 
  
+);

+
+
+
+
+

+void
+lwres_freerrset( 
+);

+

+

+The following structures are used:
+

+
+struct  rdatainfo {
         unsigned int            rdi_length;     /* length of data */
         unsigned char           *rdi_data;      /* record data */
 };
@@ -100,261 +89,129 @@ struct  rrsetinfo {
         char                    *rri_name;      /* canonical name */
         struct rdatainfo        *rri_rdatas;    /* individual records */
         struct rdatainfo        *rri_sigs;      /* individual signatures */
-};
DESCRIPTION
lwres_getrrsetbyname()
+};
+
+

+

+
+
+

DESCRIPTION

+

+lwres_getrrsetbyname() gets a set of resource records associated with a -hostname, +hostname, -class, +class, and -type. +type. -hostname +hostname is a pointer a to null-terminated string. The -flags -field is currently unused and must be zero.

After a successful call to -lwres_getrrsetbyname(), +flags +field is currently unused and must be zero. +

+

+After a successful call to +lwres_getrrsetbyname(), -*res +*res is a pointer to an -rrsetinfo +rrsetinfo structure, containing a list of one or more -rdatainfo +rdatainfo structures containing resource records and potentially another list of -rdatainfo +rdatainfo structures containing SIG resource records associated with those records. The members -rri_rdclass +rri_rdclass and -rri_rdtype +rri_rdtype are copied from the parameters. -rri_ttl +rri_ttl and -rri_name +rri_name are properties of the obtained rrset. The resource records contained in -rri_rdatas +rri_rdatas and -rri_sigs +rri_sigs are in uncompressed DNS wire format. Properties of the rdataset are represented in the -rri_flags +rri_flags bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC -validated and the signatures verified.

All of the information returned by -lwres_getrrsetbyname() +validated and the signatures verified. +

+

+All of the information returned by +lwres_getrrsetbyname() is dynamically allocated: the -rrsetinfo +rrsetinfo and -rdatainfo +rdatainfo structures, and the canonical host name strings pointed to by the -rrsetinfostructure. +rrsetinfostructure. Memory allocated for the dynamically allocated structures created by a successful call to -lwres_getrrsetbyname() +lwres_getrrsetbyname() is released by -lwres_freerrset(). +lwres_freerrset(). -rrset +rrset is a pointer to a -struct rrset +struct rrset created by a call to -lwres_getrrsetbyname().

RETURN VALUES

lwres_getrrsetbyname() +lwres_getrrsetbyname(). + +

+

+

+
+
+

RETURN VALUES

+

+lwres_getrrsetbyname() returns zero on success, and one of the following error codes if an error occurred: -

ERRSET_NONAME

the name does not exist

ERRSET_NODATA

the name exists, but does not have data of the desired type

ERRSET_NOMEMORY

memory could not be allocated

ERRSET_INVAL

a parameter is invalid

ERRSET_FAIL

other failure

SEE ALSO

lwres(3).

+

+
+
ERRSET_NONAME
+

+the name does not exist +

+
ERRSET_NODATA
+

+the name exists, but does not have data of the desired type +

+
ERRSET_NOMEMORY
+

+memory could not be allocated +

+
ERRSET_INVAL
+

+a parameter is invalid +

+
ERRSET_FAIL
+

+other failure +

+
+

+

+
+

+ +

+ +
+

SEE ALSO

+

+lwres(3). +

+
+ + diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.3 b/contrib/bind9/lib/lwres/man/lwres_gnba.3 index 404ae4141b0..58047ce6b5d 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gnba.3 +++ b/contrib/bind9/lib/lwres/man/lwres_gnba.3 @@ -1,86 +1,68 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_gnba.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_gnba.3,v 1.13.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_GNBA" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_GNBA" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free \- lightweight resolver getnamebyaddress message handling -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_gnbarequest_render(lwres_context_t *\fIctx\fB, lwres_gnbarequest_t *\fIreq\fB, lwres_lwpacket_t *\fIpkt\fB, lwres_buffer_t *\fIb\fB); -.ad -.sp -.na -lwres_result_t -lwres_gnbaresponse_render(lwres_context_t *ctx, lwres_gnbaresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b); -.ad -.sp -.na -lwres_result_t -lwres_gnbarequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbarequest_t **structp); -.ad -.sp -.na -lwres_result_t -lwres_gnbaresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbaresponse_t **structp); -.ad -.sp -.na -void -lwres_gnbaresponse_free(lwres_context_t *ctx, lwres_gnbaresponse_t **structp); -.ad -.sp -.na -void -lwres_gnbarequest_free(lwres_context_t *ctx, lwres_gnbarequest_t **structp); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 40 +\fBlwres_result_t\ \fBlwres_gnbarequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *\fR\fB\fIctx\fR\fR\fB, \fR\fBlwres_gnbarequest_t\ *\fR\fB\fIreq\fR\fR\fB, \fR\fBlwres_lwpacket_t\ *\fR\fB\fIpkt\fR\fR\fB, \fR\fBlwres_buffer_t\ *\fR\fB\fIb\fR\fR\fB);\fR +.HP 41 +\fBlwres_result_t\ \fBlwres_gnbaresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbaresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 39 +\fBlwres_result_t\ \fBlwres_gnbarequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gnbarequest_t\ **structp\fR\fB);\fR +.HP 40 +\fBlwres_result_t\ \fBlwres_gnbaresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR +.HP 29 +\fBvoid\ \fBlwres_gnbaresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_gnbarequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbarequest_t\ **structp\fR\fB);\fR .SH "DESCRIPTION" .PP -These are low-level routines for creating and parsing -lightweight resolver address-to-name lookup request and -response messages. +These are low\-level routines for creating and parsing lightweight resolver address\-to\-name lookup request and response messages. .PP -There are four main functions for the getnamebyaddr opcode. -One render function converts a getnamebyaddr request structure \(em -\fBlwres_gnbarequest_t\fR \(em -to the lightweight resolver's canonical format. -It is complemented by a parse function that converts a packet in this -canonical format to a getnamebyaddr request structure. -Another render function converts the getnamebyaddr response structure \(em +There are four main functions for the getnamebyaddr opcode. One render function converts a getnamebyaddr request structure \(em +\fBlwres_gnbarequest_t\fR +\(em to the lightweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getnamebyaddr request structure. Another render function converts the getnamebyaddr response structure \(em \fBlwres_gnbaresponse_t\fR -to the canonical format. -This is complemented by a parse function which converts a packet in -canonical format to a getnamebyaddr response structure. +to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a getnamebyaddr response structure. .PP These structures are defined in -\fIlwres/lwres.h\fR. -They are shown below. +\fIlwres/lwres.h\fR. They are shown below. .sp .nf #define LWRES_OPCODE_GETNAMEBYADDR 0x00010002U - typedef struct { lwres_uint32_t flags; lwres_addr_t addr; } lwres_gnbarequest_t; - typedef struct { lwres_uint32_t flags; lwres_uint16_t naliases; @@ -91,22 +73,19 @@ typedef struct { void *base; size_t baselen; } lwres_gnbaresponse_t; -.sp .fi +.sp .PP \fBlwres_gnbarequest_render()\fR uses resolver context -ctx +\fIctx\fR to convert getnamebyaddr request structure -req -to canonical format. -The packet header structure -pkt -is initialised and transferred to -buffer -b. -The contents of -*req +\fIreq\fR +to canonical format. The packet header structure +\fIpkt\fR +is initialised and transferred to buffer +\fIb\fR. The contents of +\fI*req\fR are then appended to the buffer in canonical format. \fBlwres_gnbaresponse_render()\fR performs the same task, except it converts a getnamebyaddr response structure @@ -115,19 +94,17 @@ to the lightweight resolver's canonical format. .PP \fBlwres_gnbarequest_parse()\fR uses context -ctx +\fIctx\fR to convert the contents of packet -pkt +\fIpkt\fR to a \fBlwres_gnbarequest_t\fR -structure. -Buffer -b -provides space to be used for storing this structure. -When the function succeeds, the resulting +structure. Buffer +\fIb\fR +provides space to be used for storing this structure. When the function succeeds, the resulting \fBlwres_gnbarequest_t\fR is made available through -*structp. +\fI*structp\fR. \fBlwres_gnbaresponse_parse()\fR offers the same semantics as \fBlwres_gnbarequest_parse()\fR @@ -139,32 +116,28 @@ structure. and \fBlwres_gnbarequest_free()\fR release the memory in resolver context -ctx +\fIctx\fR that was allocated to the \fBlwres_gnbaresponse_t\fR or \fBlwres_gnbarequest_t\fR structures referenced via -structp. -Any memory associated with ancillary buffers and strings for those -structures is also discarded. +\fIstructp\fR. Any memory associated with ancillary buffers and strings for those structures is also discarded. .SH "RETURN VALUES" .PP The getnamebyaddr opcode functions \fBlwres_gnbarequest_render()\fR, -\fBlwres_gnbaresponse_render()\fR -\fBlwres_gnbarequest_parse()\fR +\fBlwres_gnbaresponse_render()\fR\fBlwres_gnbarequest_parse()\fR and \fBlwres_gnbaresponse_parse()\fR all return -LWRES_R_SUCCESS -on success. -They return -LWRES_R_NOMEMORY +\fBLWRES_R_SUCCESS\fR +on success. They return +\fBLWRES_R_NOMEMORY\fR if memory allocation fails. -LWRES_R_UNEXPECTEDEND +\fBLWRES_R_UNEXPECTEDEND\fR is returned if the available space in the buffer -b +\fIb\fR is too small to accommodate the packet header or the \fBlwres_gnbarequest_t\fR and @@ -174,12 +147,11 @@ structures. and \fBlwres_gnbaresponse_parse()\fR will return -LWRES_R_UNEXPECTEDEND -if the buffer is not empty after decoding the received packet. -These functions will return -LWRES_R_FAILURE +\fBLWRES_R_UNEXPECTEDEND\fR +if the buffer is not empty after decoding the received packet. These functions will return +\fBLWRES_R_FAILURE\fR if -\fBpktflags\fR +pktflags in the packet header structure \fBlwres_lwpacket_t\fR indicate that the packet is not a response to an earlier query. diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook index 5bd4172495a..753148642ef 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_gnbarequest_render lwres_gnbaresponse_render diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.html b/contrib/bind9/lib/lwres/man/lwres_gnba.html index 537b259377d..89cf35e02c3 100644 --- a/contrib/bind9/lib/lwres/man/lwres_gnba.html +++ b/contrib/bind9/lib/lwres/man/lwres_gnba.html @@ -1,158 +1,203 @@ - - - - -lwres_gnba

lwres_gnba

Name

lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free -- lightweight resolver getnamebyaddress message handling

Synopsis

#include <lwres/lwres.h>

lwres_result_t -lwres_gnbarequest_render(lwres_context_t *ctx, lwres_gnbarequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_gnbaresponse_render(lwres_context_t *ctx, lwres_gnbaresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_gnbarequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbarequest_t **structp);

lwres_result_t -lwres_gnbaresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbaresponse_t **structp);

void -lwres_gnbaresponse_free(lwres_context_t *ctx, lwres_gnbaresponse_t **structp);

void -lwres_gnbarequest_free(lwres_context_t *ctx, lwres_gnbarequest_t **structp);

DESCRIPTION

These are low-level routines for creating and parsing + + + + +lwres_gnba + + +

+
+
+

Name

+

lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free — lightweight resolver getnamebyaddress message handling

+
+
+

Synopsis

+
+
+#include <lwres/lwres.h>
+
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gnbarequest_render +(lwres_context_t *  +ctx,
 lwres_gnbarequest_t *  +req,
 lwres_lwpacket_t *  +pkt,
 lwres_buffer_t *  +b);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gnbaresponse_render +( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gnbarequest_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_gnbaresponse_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + +
+void +lwres_gnbaresponse_free +( ,
   +);
+ + + + + + + + + + + +
+void +lwres_gnbarequest_free( ,
   +);
+
+
+
+

DESCRIPTION

+

+These are low-level routines for creating and parsing lightweight resolver address-to-name lookup request and -response messages.

There are four main functions for the getnamebyaddr opcode. -One render function converts a getnamebyaddr request structure — -lwres_gnbarequest_t — +response messages. +

+

+There are four main functions for the getnamebyaddr opcode. +One render function converts a getnamebyaddr request structure — +lwres_gnbarequest_t — to the lightweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getnamebyaddr request structure. -Another render function converts the getnamebyaddr response structure — -lwres_gnbaresponse_t +Another render function converts the getnamebyaddr response structure — +lwres_gnbaresponse_t to the canonical format. This is complemented by a parse function which converts a packet in -canonical format to a getnamebyaddr response structure.

These structures are defined in -lwres/lwres.h. +canonical format to a getnamebyaddr response structure. +

+

+These structures are defined in +lwres/lwres.h. They are shown below. -

#define LWRES_OPCODE_GETNAMEBYADDR      0x00010002U
+

+
+#define LWRES_OPCODE_GETNAMEBYADDR      0x00010002U
 
 typedef struct {
         lwres_uint32_t  flags;
@@ -168,242 +213,112 @@ typedef struct {
         lwres_uint16_t *aliaslen;
         void           *base;
         size_t          baselen;
-} lwres_gnbaresponse_t;
lwres_gnbarequest_render()
+} lwres_gnbaresponse_t;
+
+

+

+

+lwres_gnbarequest_render() uses resolver context -ctx +ctx to convert getnamebyaddr request structure -req +req to canonical format. The packet header structure -pkt +pkt is initialised and transferred to buffer -b. +b. The contents of -*req +*req are then appended to the buffer in canonical format. -lwres_gnbaresponse_render() +lwres_gnbaresponse_render() performs the same task, except it converts a getnamebyaddr response structure -lwres_gnbaresponse_t -to the lightweight resolver's canonical format.

lwres_gnbarequest_parse() +lwres_gnbaresponse_t +to the lightweight resolver's canonical format. +

+

+lwres_gnbarequest_parse() uses context -ctx +ctx to convert the contents of packet -pkt +pkt to a -lwres_gnbarequest_t +lwres_gnbarequest_t structure. Buffer -b +b provides space to be used for storing this structure. When the function succeeds, the resulting -lwres_gnbarequest_t +lwres_gnbarequest_t is made available through -*structp. -lwres_gnbaresponse_parse() +*structp. +lwres_gnbaresponse_parse() offers the same semantics as -lwres_gnbarequest_parse() +lwres_gnbarequest_parse() except it yields a -lwres_gnbaresponse_t -structure.

lwres_gnbaresponse_free() +lwres_gnbaresponse_t +structure. +

+

+lwres_gnbaresponse_free() and -lwres_gnbarequest_free() +lwres_gnbarequest_free() release the memory in resolver context -ctx +ctx that was allocated to the -lwres_gnbaresponse_t +lwres_gnbaresponse_t or -lwres_gnbarequest_t +lwres_gnbarequest_t structures referenced via -structp. +structp. Any memory associated with ancillary buffers and strings for those -structures is also discarded.

RETURN VALUES

The getnamebyaddr opcode functions -lwres_gnbarequest_render(), -lwres_gnbaresponse_render() -lwres_gnbarequest_parse() +structures is also discarded. +

+
+
+

RETURN VALUES

+

+The getnamebyaddr opcode functions +lwres_gnbarequest_render(), +lwres_gnbaresponse_render() +lwres_gnbarequest_parse() and -lwres_gnbaresponse_parse() +lwres_gnbaresponse_parse() all return -LWRES_R_SUCCESS +LWRES_R_SUCCESS on success. They return -LWRES_R_NOMEMORY +LWRES_R_NOMEMORY if memory allocation fails. -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND is returned if the available space in the buffer -b +b is too small to accommodate the packet header or the -lwres_gnbarequest_t +lwres_gnbarequest_t and -lwres_gnbaresponse_t +lwres_gnbaresponse_t structures. -lwres_gnbarequest_parse() +lwres_gnbarequest_parse() and -lwres_gnbaresponse_parse() +lwres_gnbaresponse_parse() will return -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND if the buffer is not empty after decoding the received packet. These functions will return -LWRES_R_FAILURE +LWRES_R_FAILURE if -pktflags +pktflags in the packet header structure -lwres_lwpacket_t -indicate that the packet is not a response to an earlier query.

SEE ALSO

lwres_packet(3).

+lwres_lwpacket_t +indicate that the packet is not a response to an earlier query. +

+
+
+

SEE ALSO

+

+lwres_packet(3). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 index 2260088e775..a1ecf7c2071 100644 --- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 +++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 @@ -1,67 +1,79 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_hstrerror.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $ +.\" $Id: lwres_hstrerror.3,v 1.13.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_HSTRERROR" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_HSTRERROR" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_herror, lwres_hstrerror \- lightweight resolver error message generation -.SH SYNOPSIS -\fB#include -.sp -.na -void -lwres_herror(const char *s); -.ad -.sp -.na -const char * -lwres_hstrerror(int err); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 18 +\fBvoid\ \fBlwres_herror\fR\fR\fB(\fR\fBconst\ char\ *s\fR\fB);\fR +.HP 29 +\fBconst\ char\ *\ \fBlwres_hstrerror\fR\fR\fB(\fR\fBint\ err\fR\fB);\fR .SH "DESCRIPTION" .PP -\fBlwres_herror()\fR prints the string -\fIs\fR on \fBstderr\fR followed by the string -generated by \fBlwres_hstrerror()\fR for the error code -stored in the global variable lwres_h_errno. +\fBlwres_herror()\fR +prints the string +\fIs\fR +on +\fBstderr\fR +followed by the string generated by +\fBlwres_hstrerror()\fR +for the error code stored in the global variable +\fBlwres_h_errno\fR. .PP -\fBlwres_hstrerror()\fR returns an appropriate string -for the error code gievn by \fIerr\fR. The values of -the error codes and messages are as follows: +\fBlwres_hstrerror()\fR +returns an appropriate string for the error code gievn by +\fIerr\fR. The values of the error codes and messages are as follows: .TP \fBNETDB_SUCCESS\fR -\fBResolver Error 0 (no error)\fR +Resolver Error 0 (no error) .TP \fBHOST_NOT_FOUND\fR -\fBUnknown host\fR +Unknown host .TP \fBTRY_AGAIN\fR -\fBHost name lookup failure\fR +Host name lookup failure .TP \fBNO_RECOVERY\fR -\fBUnknown server error\fR +Unknown server error .TP \fBNO_DATA\fR -\fBNo address associated with name\fR +No address associated with name .SH "RETURN VALUES" .PP -The string \fBUnknown resolver error\fR is returned by +The string +Unknown resolver error +is returned by \fBlwres_hstrerror()\fR when the value of -lwres_h_errno +\fBlwres_h_errno\fR is not a valid error code. .SH "SEE ALSO" .PP diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook index 2ad4c498e7e..a36c072ef39 100644 --- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_herror lwres_hstrerror diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html index 0c264af1ca0..4204a3365bd 100644 --- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html +++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html @@ -1,241 +1,100 @@ - - - - -lwres_hstrerror

lwres_hstrerror

Name

lwres_herror, lwres_hstrerror -- lightweight resolver error message generation

Synopsis

#include <lwres/netdb.h>

void -lwres_herror(const char *s);

const char * -lwres_hstrerror(int err);

DESCRIPTION

lwres_herror() prints the string -s on stderr followed by the string -generated by lwres_hstrerror() for the error code -stored in the global variable lwres_h_errno.

lwres_hstrerror() returns an appropriate string -for the error code gievn by err. The values of + + + + +lwres_hstrerror + + +

+
+
+

Name

+

lwres_herror, lwres_hstrerror — lightweight resolver error message generation

+
+
+

Synopsis

+
+
#include <lwres/netdb.h>
+

+void +lwres_herror(const char *s);

+

+const char * +lwres_hstrerror(int err);

+
+
+
+

DESCRIPTION

+

+lwres_herror() prints the string +s on stderr followed by the string +generated by lwres_hstrerror() for the error code +stored in the global variable lwres_h_errno. +

+

+lwres_hstrerror() returns an appropriate string +for the error code gievn by err. The values of the error codes and messages are as follows: -

NETDB_SUCCESS

Resolver Error 0 (no error)

HOST_NOT_FOUND

Unknown host

TRY_AGAIN

Host name lookup failure

NO_RECOVERY

Unknown server error

NO_DATA

No address associated with name

RETURN VALUES

The string Unknown resolver error is returned by -lwres_hstrerror() +

+
+
NETDB_SUCCESS
+

+Resolver Error 0 (no error) +

+
HOST_NOT_FOUND
+

+Unknown host +

+
TRY_AGAIN
+

+Host name lookup failure +

+
NO_RECOVERY
+

+Unknown server error +

+
NO_DATA
+

+No address associated with name +

+
+

+

+
+
+

RETURN VALUES

+

+The string Unknown resolver error is returned by +lwres_hstrerror() when the value of -lwres_h_errno -is not a valid error code.

SEE ALSO

herror(3), +lwres_h_errno +is not a valid error code. +

+
+
+

SEE ALSO

+

+herror(3), -lwres_hstrerror(3).

+lwres_hstrerror(3). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.3 b/contrib/bind9/lib/lwres/man/lwres_inetntop.3 index a4603c604b4..782cbafd228 100644 --- a/contrib/bind9/lib/lwres/man/lwres_inetntop.3 +++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.3 @@ -1,54 +1,69 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_inetntop.3,v 1.12.2.1.8.1 2004/03/06 07:41:44 marka Exp $ +.\" $Id: lwres_inetntop.3,v 1.12.2.1.8.5 2005/10/13 02:33:53 marka Exp $ .\" -.TH "LWRES_INETNTOP" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_INETNTOP" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_net_ntop \- lightweight resolver IP address presentation -.SH SYNOPSIS -\fB#include -.sp -.na -const char * -lwres_net_ntop(int af, const void *src, char *dst, size_t size); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 28 +\fBconst\ char\ *\ \fBlwres_net_ntop\fR\fR\fB(\fR\fBint\ af\fR\fB, \fR\fBconst\ void\ *src\fR\fB, \fR\fBchar\ *dst\fR\fB, \fR\fBsize_t\ size\fR\fB);\fR .SH "DESCRIPTION" .PP -\fBlwres_net_ntop()\fR converts an IP address of -protocol family \fIaf\fR \(em IPv4 or IPv6 \(em -at location \fIsrc\fR from network format to its -conventional representation as a string. For IPv4 addresses, that -string would be a dotted-decimal. An IPv6 address would be -represented in colon notation as described in RFC1884. +\fBlwres_net_ntop()\fR +converts an IP address of protocol family +\fIaf\fR +\(em IPv4 or IPv6 \(em at location +\fIsrc\fR +from network format to its conventional representation as a string. For IPv4 addresses, that string would be a dotted\-decimal. An IPv6 address would be represented in colon notation as described in RFC1884. .PP -The generated string is copied to \fIdst\fR provided -\fIsize\fR indicates it is long enough to store the -ASCII representation of the address. +The generated string is copied to +\fIdst\fR +provided +\fIsize\fR +indicates it is long enough to store the ASCII representation of the address. .SH "RETURN VALUES" .PP -If successful, the function returns \fIdst\fR: -a pointer to a string containing the presentation format of the -address. \fBlwres_net_ntop()\fR returns -\fBNULL\fR and sets the global variable -errno to EAFNOSUPPORT if -the protocol family given in \fIaf\fR is not -supported. +If successful, the function returns +\fIdst\fR: a pointer to a string containing the presentation format of the address. +\fBlwres_net_ntop()\fR +returns +\fBNULL\fR +and sets the global variable +\fBerrno\fR +to +\fBEAFNOSUPPORT\fR +if the protocol family given in +\fIaf\fR +is not supported. .SH "SEE ALSO" .PP -\fBRFC1884\fR, +\fBRFC1884\fR(), \fBinet_ntop\fR(3), \fBerrno\fR(3). diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook index e771478bf5d..651ef04d91b 100644 --- a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_net_ntop lightweight resolver IP address presentation diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.html b/contrib/bind9/lib/lwres/man/lwres_inetntop.html index 34533454796..3c794a53b45 100644 --- a/contrib/bind9/lib/lwres/man/lwres_inetntop.html +++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.html @@ -1,177 +1,98 @@ - - - - -lwres_inetntop

lwres_inetntop

Name

lwres_net_ntop -- lightweight resolver IP address presentation

Synopsis

#include <lwres/net.h>

const char * -lwres_net_ntop(int af, const void *src, char *dst, size_t size);

DESCRIPTION

lwres_net_ntop() converts an IP address of -protocol family af — IPv4 or IPv6 — -at location src from network format to its + + + + +lwres_inetntop + + +

+
+
+

Name

+

lwres_net_ntop — lightweight resolver IP address presentation

+
+
+

Synopsis

+
+
#include <lwres/net.h>
+ + + + + + + + + + + + + + + + + + + + + +
+const char * +lwres_net_ntop( ,
  ,
  ,
   +);
+
+
+
+

DESCRIPTION

+

+lwres_net_ntop() converts an IP address of +protocol family af — IPv4 or IPv6 — +at location src from network format to its conventional representation as a string. For IPv4 addresses, that string would be a dotted-decimal. An IPv6 address would be -represented in colon notation as described in RFC1884.

The generated string is copied to dst provided -size indicates it is long enough to store the -ASCII representation of the address.

RETURN VALUES

If successful, the function returns dst: +represented in colon notation as described in RFC1884. +

+

+The generated string is copied to dst provided +size indicates it is long enough to store the +ASCII representation of the address. +

+
+
+

RETURN VALUES

+

+If successful, the function returns dst: a pointer to a string containing the presentation format of the -address. lwres_net_ntop() returns -NULL and sets the global variable -errno to EAFNOSUPPORT if -the protocol family given in af is not -supported.

SEE ALSO

RFC1884, -inet_ntop(3), -errno(3).

+address. lwres_net_ntop() returns +NULL and sets the global variable +errno to EAFNOSUPPORT if +the protocol family given in af is not +supported. +

+
+
+

SEE ALSO

+

+RFC1884, +inet_ntop(3), +errno(3). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.3 b/contrib/bind9/lib/lwres/man/lwres_noop.3 index 36bb90423d7..d2eba576591 100644 --- a/contrib/bind9/lib/lwres/man/lwres_noop.3 +++ b/contrib/bind9/lib/lwres/man/lwres_noop.3 @@ -1,142 +1,140 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_noop.3,v 1.14.2.1.8.1 2004/03/06 07:41:44 marka Exp $ +.\" $Id: lwres_noop.3,v 1.14.2.1.8.5 2005/10/13 02:33:54 marka Exp $ .\" -.TH "LWRES_NOOP" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME -lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free \- lightweight resolver no-op message handling -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_nooprequest_render(lwres_context_t *ctx, lwres_nooprequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b); -.ad -.sp -.na -lwres_result_t -lwres_noopresponse_render(lwres_context_t *ctx, lwres_noopresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b); -.ad -.sp -.na -lwres_result_t -lwres_nooprequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_nooprequest_t **structp); -.ad -.sp -.na -lwres_result_t -lwres_noopresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_noopresponse_t **structp); -.ad -.sp -.na -void -lwres_noopresponse_free(lwres_context_t *ctx, lwres_noopresponse_t **structp); -.ad -.sp -.na -void -lwres_nooprequest_free(lwres_context_t *ctx, lwres_nooprequest_t **structp); -.ad -\fR +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_NOOP" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" +lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free \- lightweight resolver no\-op message handling +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 40 +\fBlwres_result_t\ \fBlwres_nooprequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_nooprequest_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 41 +\fBlwres_result_t\ \fBlwres_noopresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_noopresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR +.HP 39 +\fBlwres_result_t\ \fBlwres_nooprequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_nooprequest_t\ **structp\fR\fB);\fR +.HP 40 +\fBlwres_result_t\ \fBlwres_noopresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_noopresponse_t\ **structp\fR\fB);\fR +.HP 29 +\fBvoid\ \fBlwres_noopresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_noopresponse_t\ **structp\fR\fB);\fR +.HP 28 +\fBvoid\ \fBlwres_nooprequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_nooprequest_t\ **structp\fR\fB);\fR .SH "DESCRIPTION" .PP -These are low-level routines for creating and parsing -lightweight resolver no-op request and response messages. +These are low\-level routines for creating and parsing lightweight resolver no\-op request and response messages. .PP -The no-op message is analogous to a \fBping\fR packet: -a packet is sent to the resolver daemon and is simply echoed back. -The opcode is intended to allow a client to determine if the server is -operational or not. +The no\-op message is analogous to a +\fBping\fR +packet: a packet is sent to the resolver daemon and is simply echoed back. The opcode is intended to allow a client to determine if the server is operational or not. .PP -There are four main functions for the no-op opcode. -One render function converts a no-op request structure \(em -\fBlwres_nooprequest_t\fR \(em -to the lighweight resolver's canonical format. -It is complemented by a parse function that converts a packet in this -canonical format to a no-op request structure. -Another render function converts the no-op response structure \(em +There are four main functions for the no\-op opcode. One render function converts a no\-op request structure \(em +\fBlwres_nooprequest_t\fR +\(em to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a no\-op request structure. Another render function converts the no\-op response structure \(em \fBlwres_noopresponse_t\fR -to the canonical format. -This is complemented by a parse function which converts a packet in -canonical format to a no-op response structure. +to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a no\-op response structure. .PP These structures are defined in -\fIlwres/lwres.h\fR. -They are shown below. +\fIlwres/lwres.h\fR. They are shown below. .sp .nf #define LWRES_OPCODE_NOOP 0x00000000U - typedef struct { lwres_uint16_t datalength; unsigned char *data; } lwres_nooprequest_t; - typedef struct { lwres_uint16_t datalength; unsigned char *data; } lwres_noopresponse_t; -.sp .fi -Although the structures have different types, they are identical. -This is because the no-op opcode simply echos whatever data was sent: -the response is therefore identical to the request. +.sp +Although the structures have different types, they are identical. This is because the no\-op opcode simply echos whatever data was sent: the response is therefore identical to the request. .PP -\fBlwres_nooprequest_render()\fR uses resolver -context \fIctx\fR to convert no-op request structure -\fIreq\fR to canonical format. The packet header -structure \fIpkt\fR is initialised and transferred to -buffer \fIb\fR. The contents of -\fI*req\fR are then appended to the buffer in -canonical format. \fBlwres_noopresponse_render()\fR -performs the same task, except it converts a no-op response structure -\fBlwres_noopresponse_t\fR to the lightweight resolver's -canonical format. +\fBlwres_nooprequest_render()\fR +uses resolver context +\fIctx\fR +to convert no\-op request structure +\fIreq\fR +to canonical format. The packet header structure +\fIpkt\fR +is initialised and transferred to buffer +\fIb\fR. The contents of +\fI*req\fR +are then appended to the buffer in canonical format. +\fBlwres_noopresponse_render()\fR +performs the same task, except it converts a no\-op response structure +\fBlwres_noopresponse_t\fR +to the lightweight resolver's canonical format. .PP -\fBlwres_nooprequest_parse()\fR uses context -\fIctx\fR to convert the contents of packet -\fIpkt\fR to a \fBlwres_nooprequest_t\fR -structure. Buffer \fIb\fR provides space to be used -for storing this structure. When the function succeeds, the resulting -\fBlwres_nooprequest_t\fR is made available through +\fBlwres_nooprequest_parse()\fR +uses context +\fIctx\fR +to convert the contents of packet +\fIpkt\fR +to a +\fBlwres_nooprequest_t\fR +structure. Buffer +\fIb\fR +provides space to be used for storing this structure. When the function succeeds, the resulting +\fBlwres_nooprequest_t\fR +is made available through \fI*structp\fR. -\fBlwres_noopresponse_parse()\fR offers the same -semantics as \fBlwres_nooprequest_parse()\fR except it -yields a \fBlwres_noopresponse_t\fR structure. +\fBlwres_noopresponse_parse()\fR +offers the same semantics as +\fBlwres_nooprequest_parse()\fR +except it yields a +\fBlwres_noopresponse_t\fR +structure. .PP -\fBlwres_noopresponse_free()\fR and -\fBlwres_nooprequest_free()\fR release the memory in -resolver context \fIctx\fR that was allocated to the -\fBlwres_noopresponse_t\fR or \fBlwres_nooprequest_t\fR -structures referenced via \fIstructp\fR. +\fBlwres_noopresponse_free()\fR +and +\fBlwres_nooprequest_free()\fR +release the memory in resolver context +\fIctx\fR +that was allocated to the +\fBlwres_noopresponse_t\fR +or +\fBlwres_nooprequest_t\fR +structures referenced via +\fIstructp\fR. .SH "RETURN VALUES" .PP -The no-op opcode functions +The no\-op opcode functions \fBlwres_nooprequest_render()\fR, -\fBlwres_noopresponse_render()\fR -\fBlwres_nooprequest_parse()\fR +\fBlwres_noopresponse_render()\fR\fBlwres_nooprequest_parse()\fR and \fBlwres_noopresponse_parse()\fR all return -LWRES_R_SUCCESS -on success. -They return -LWRES_R_NOMEMORY +\fBLWRES_R_SUCCESS\fR +on success. They return +\fBLWRES_R_NOMEMORY\fR if memory allocation fails. -LWRES_R_UNEXPECTEDEND +\fBLWRES_R_UNEXPECTEDEND\fR is returned if the available space in the buffer \fIb\fR is too small to accommodate the packet header or the @@ -148,15 +146,14 @@ structures. and \fBlwres_noopresponse_parse()\fR will return -LWRES_R_UNEXPECTEDEND -if the buffer is not empty after decoding the received packet. -These functions will return -LWRES_R_FAILURE +\fBLWRES_R_UNEXPECTEDEND\fR +if the buffer is not empty after decoding the received packet. These functions will return +\fBLWRES_R_FAILURE\fR if -pktflags +\fBpktflags\fR in the packet header structure \fBlwres_lwpacket_t\fR indicate that the packet is not a response to an earlier query. .SH "SEE ALSO" .PP -\fBlwres_packet\fR(3) +\fBlwres_packet\fR(3 ) diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.docbook b/contrib/bind9/lib/lwres/man/lwres_noop.docbook index dde2795c82d..fcb3c5933ab 100644 --- a/contrib/bind9/lib/lwres/man/lwres_noop.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_noop.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_nooprequest_render lwres_noopresponse_render diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.html b/contrib/bind9/lib/lwres/man/lwres_noop.html index 0962883d043..261bac802f6 100644 --- a/contrib/bind9/lib/lwres/man/lwres_noop.html +++ b/contrib/bind9/lib/lwres/man/lwres_noop.html @@ -1,166 +1,202 @@ - - - - -lwres_noop

lwres_noop

Name

lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free -- lightweight resolver no-op message handling

Synopsis

#include <lwres/lwres.h>

lwres_result_t -lwres_nooprequest_render(lwres_context_t *ctx, lwres_nooprequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_noopresponse_render(lwres_context_t *ctx, lwres_noopresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);

lwres_result_t -lwres_nooprequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_nooprequest_t **structp);

lwres_result_t -lwres_noopresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_noopresponse_t **structp);

void -lwres_noopresponse_free(lwres_context_t *ctx, lwres_noopresponse_t **structp);

void -lwres_nooprequest_free(lwres_context_t *ctx, lwres_nooprequest_t **structp);

DESCRIPTION

These are low-level routines for creating and parsing -lightweight resolver no-op request and response messages.

The no-op message is analogous to a ping packet: + + + + +lwres_noop + + +

+
+
+

Name

+

lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free — lightweight resolver no-op message handling

+
+
+

Synopsis

+
+
+#include <lwres/lwres.h>
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_nooprequest_render( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_noopresponse_render( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_nooprequest_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_noopresponse_parse( ,
  ,
  ,
   +);
+ + + + + + + + + + + +
+void +lwres_noopresponse_free( ,
   +);
+ + + + + + + + + + + +
+void +lwres_nooprequest_free( ,
   +);
+
+
+
+

DESCRIPTION

+

+These are low-level routines for creating and parsing +lightweight resolver no-op request and response messages. +

+

+The no-op message is analogous to a ping packet: a packet is sent to the resolver daemon and is simply echoed back. The opcode is intended to allow a client to determine if the server is -operational or not.

There are four main functions for the no-op opcode. -One render function converts a no-op request structure — -lwres_nooprequest_t — +operational or not. +

+

+There are four main functions for the no-op opcode. +One render function converts a no-op request structure — +lwres_nooprequest_t — to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a no-op request structure. -Another render function converts the no-op response structure — -lwres_noopresponse_t +Another render function converts the no-op response structure — +lwres_noopresponse_t to the canonical format. This is complemented by a parse function which converts a packet in -canonical format to a no-op response structure.

These structures are defined in -lwres/lwres.h. +canonical format to a no-op response structure. +

+

+These structures are defined in +lwres/lwres.h. They are shown below. -

#define LWRES_OPCODE_NOOP       0x00000000U
+

+
+#define LWRES_OPCODE_NOOP       0x00000000U
 
 typedef struct {
         lwres_uint16_t  datalength;
@@ -170,219 +206,90 @@ typedef struct {
 typedef struct {
         lwres_uint16_t  datalength;
         unsigned char   *data;
-} lwres_noopresponse_t;

+} lwres_noopresponse_t;
+
+

Although the structures have different types, they are identical. This is because the no-op opcode simply echos whatever data was sent: -the response is therefore identical to the request.

lwres_nooprequest_render() uses resolver -context ctx to convert no-op request structure -req to canonical format. The packet header -structure pkt is initialised and transferred to -buffer b. The contents of -*req are then appended to the buffer in -canonical format. lwres_noopresponse_render() +the response is therefore identical to the request. +

+

+lwres_nooprequest_render() uses resolver +context ctx to convert no-op request structure +req to canonical format. The packet header +structure pkt is initialised and transferred to +buffer b. The contents of +*req are then appended to the buffer in +canonical format. lwres_noopresponse_render() performs the same task, except it converts a no-op response structure -lwres_noopresponse_t to the lightweight resolver's -canonical format.

lwres_nooprequest_parse() uses context -ctx to convert the contents of packet -pkt to a lwres_nooprequest_t -structure. Buffer b provides space to be used +lwres_noopresponse_t to the lightweight resolver's +canonical format. +

+

+lwres_nooprequest_parse() uses context +ctx to convert the contents of packet +pkt to a lwres_nooprequest_t +structure. Buffer b provides space to be used for storing this structure. When the function succeeds, the resulting -lwres_nooprequest_t is made available through -*structp. -lwres_noopresponse_parse() offers the same -semantics as lwres_nooprequest_parse() except it -yields a lwres_noopresponse_t structure.

lwres_noopresponse_free() and -lwres_nooprequest_free() release the memory in -resolver context ctx that was allocated to the -lwres_noopresponse_t or lwres_nooprequest_t -structures referenced via structp.

RETURN VALUES

The no-op opcode functions -lwres_nooprequest_render(), +lwres_nooprequest_t is made available through +*structp. +lwres_noopresponse_parse() offers the same +semantics as lwres_nooprequest_parse() except it +yields a lwres_noopresponse_t structure. +

+

+lwres_noopresponse_free() and +lwres_nooprequest_free() release the memory in +resolver context ctx that was allocated to the +lwres_noopresponse_t or lwres_nooprequest_t +structures referenced via structp. +

+
+
+

RETURN VALUES

+

+The no-op opcode functions +lwres_nooprequest_render(), -lwres_noopresponse_render() -lwres_nooprequest_parse() +lwres_noopresponse_render() +lwres_nooprequest_parse() and -lwres_noopresponse_parse() +lwres_noopresponse_parse() all return -LWRES_R_SUCCESS +LWRES_R_SUCCESS on success. They return -LWRES_R_NOMEMORY +LWRES_R_NOMEMORY if memory allocation fails. -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND is returned if the available space in the buffer -b +b is too small to accommodate the packet header or the -lwres_nooprequest_t +lwres_nooprequest_t and -lwres_noopresponse_t +lwres_noopresponse_t structures. -lwres_nooprequest_parse() +lwres_nooprequest_parse() and -lwres_noopresponse_parse() +lwres_noopresponse_parse() will return -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND if the buffer is not empty after decoding the received packet. These functions will return -LWRES_R_FAILURE +LWRES_R_FAILURE if -pktflags +pktflags in the packet header structure -lwres_lwpacket_t -indicate that the packet is not a response to an earlier query.

SEE ALSO

lwres_packet(3)

+lwres_lwpacket_t +indicate that the packet is not a response to an earlier query. +

+
+
+

SEE ALSO

+

+lwres_packet(3 +) +

+
+
+ diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.3 b/contrib/bind9/lib/lwres/man/lwres_packet.3 index 1fbc417e45e..777e0c76eed 100644 --- a/contrib/bind9/lib/lwres/man/lwres_packet.3 +++ b/contrib/bind9/lib/lwres/man/lwres_packet.3 @@ -1,36 +1,41 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_packet.3,v 1.15.2.1.8.1 2004/03/06 07:41:44 marka Exp $ +.\" $Id: lwres_packet.3,v 1.15.2.1.8.5 2005/10/13 02:33:54 marka Exp $ .\" -.TH "LWRES_PACKET" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_PACKET" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_lwpacket_renderheader, lwres_lwpacket_parseheader \- lightweight resolver packet handling functions -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_lwpacket_renderheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt); -.ad -.sp -.na -lwres_result_t -lwres_lwpacket_parseheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 43 +\fBlwres_result_t\ \fBlwres_lwpacket_renderheader\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB);\fR +.HP 42 +\fBlwres_result_t\ \fBlwres_lwpacket_parseheader\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB);\fR .SH "DESCRIPTION" .PP These functions rely on a @@ -40,7 +45,6 @@ which is defined in .sp .nf typedef struct lwres_lwpacket lwres_lwpacket_t; - struct lwres_lwpacket { lwres_uint32_t length; lwres_uint16_t version; @@ -52,100 +56,74 @@ struct lwres_lwpacket { lwres_uint16_t authtype; lwres_uint16_t authlength; }; -.sp .fi +.sp .PP The elements of this structure are: .TP \fBlength\fR -the overall packet length, including the entire packet header. -This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls. +the overall packet length, including the entire packet header. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls. .TP \fBversion\fR the header format. There is currently only one format, -\fBLWRES_LWPACKETVERSION_0\fR. -This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls. +\fBLWRES_LWPACKETVERSION_0\fR. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls. .TP \fBpktflags\fR -library-defined flags for this packet: for instance whether the packet -is a request or a reply. Flag values can be set, but not defined by -the caller. -This field is filled in by the application wit the exception of the -LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the -lwres_gabn_*() and lwres_gnba_*() calls. +library\-defined flags for this packet: for instance whether the packet is a request or a reply. Flag values can be set, but not defined by the caller. This field is filled in by the application wit the exception of the LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the lwres_gabn_*() and lwres_gnba_*() calls. .TP \fBserial\fR -is set by the requestor and is returned in all replies. If two or more -packets from the same source have the same serial number and are from -the same source, they are assumed to be duplicates and the latter ones -may be dropped. -This field must be set by the application. +is set by the requestor and is returned in all replies. If two or more packets from the same source have the same serial number and are from the same source, they are assumed to be duplicates and the latter ones may be dropped. This field must be set by the application. .TP \fBopcode\fR -indicates the operation. -Opcodes between 0x00000000 and 0x03ffffff are -reserved for use by the lightweight resolver library. Opcodes between -0x04000000 and 0xffffffff are application defined. -This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls. +indicates the operation. Opcodes between 0x00000000 and 0x03ffffff are reserved for use by the lightweight resolver library. Opcodes between 0x04000000 and 0xffffffff are application defined. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls. .TP \fBresult\fR -is only valid for replies. -Results between 0x04000000 and 0xffffffff are application defined. -Results between 0x00000000 and 0x03ffffff are reserved for library use. -This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls. +is only valid for replies. Results between 0x04000000 and 0xffffffff are application defined. Results between 0x00000000 and 0x03ffffff are reserved for library use. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls. .TP \fBrecvlength\fR -is the maximum buffer size that the receiver can handle on requests -and the size of the buffer needed to satisfy a request when the buffer -is too large for replies. -This field is supplied by the application. +is the maximum buffer size that the receiver can handle on requests and the size of the buffer needed to satisfy a request when the buffer is too large for replies. This field is supplied by the application. .TP \fBauthtype\fR -defines the packet level authentication that is used. -Authorisation types between 0x1000 and 0xffff are application defined -and types between 0x0000 and 0x0fff are reserved for library use. -Currently these are not used and must be zero. +defines the packet level authentication that is used. Authorisation types between 0x1000 and 0xffff are application defined and types between 0x0000 and 0x0fff are reserved for library use. Currently these are not used and must be zero. .TP \fBauthlen\fR -gives the length of the authentication data. -Since packet authentication is currently not used, this must be zero. +gives the length of the authentication data. Since packet authentication is currently not used, this must be zero. .PP The following opcodes are currently defined: .TP \fBNOOP\fR -Success is always returned and the packet contents are echoed. -The lwres_noop_*() functions should be used for this type. +Success is always returned and the packet contents are echoed. The lwres_noop_*() functions should be used for this type. .TP \fBGETADDRSBYNAME\fR -returns all known addresses for a given name. -The lwres_gabn_*() functions should be used for this type. +returns all known addresses for a given name. The lwres_gabn_*() functions should be used for this type. .TP \fBGETNAMEBYADDR\fR -return the hostname for the given address. -The lwres_gnba_*() functions should be used for this type. +return the hostname for the given address. The lwres_gnba_*() functions should be used for this type. .PP -\fBlwres_lwpacket_renderheader()\fR transfers the -contents of lightweight resolver packet structure -\fBlwres_lwpacket_t\fR \fI*pkt\fR in network -byte order to the lightweight resolver buffer, +\fBlwres_lwpacket_renderheader()\fR +transfers the contents of lightweight resolver packet structure +\fBlwres_lwpacket_t\fR\fI*pkt\fR +in network byte order to the lightweight resolver buffer, \fI*b\fR. .PP -\fBlwres_lwpacket_parseheader()\fR performs the -converse operation. It transfers data in network byte order from -buffer \fI*b\fR to resolver packet +\fBlwres_lwpacket_parseheader()\fR +performs the converse operation. It transfers data in network byte order from buffer +\fI*b\fR +to resolver packet \fI*pkt\fR. The contents of the buffer -\fIb\fR should correspond to a +\fIb\fR +should correspond to a \fBlwres_lwpacket_t\fR. .SH "RETURN VALUES" .PP Successful calls to -\fBlwres_lwpacket_renderheader()\fR and -\fBlwres_lwpacket_parseheader()\fR return -LWRES_R_SUCCESS. If there is insufficient -space to copy data between the buffer \fI*b\fR and -lightweight resolver packet \fI*pkt\fR both functions -return LWRES_R_UNEXPECTEDEND. +\fBlwres_lwpacket_renderheader()\fR +and +\fBlwres_lwpacket_parseheader()\fR +return +\fBLWRES_R_SUCCESS\fR. If there is insufficient space to copy data between the buffer +\fI*b\fR +and lightweight resolver packet +\fI*pkt\fR +both functions return +\fBLWRES_R_UNEXPECTEDEND\fR. diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.docbook b/contrib/bind9/lib/lwres/man/lwres_packet.docbook index 7795ebc7551..226f9942c9a 100644 --- a/contrib/bind9/lib/lwres/man/lwres_packet.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_packet.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_lwpacket_renderheader lwres_lwpacket_parseheader diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.html b/contrib/bind9/lib/lwres/man/lwres_packet.html index cb61e0a4831..b83fbcbf1b5 100644 --- a/contrib/bind9/lib/lwres/man/lwres_packet.html +++ b/contrib/bind9/lib/lwres/man/lwres_packet.html @@ -1,109 +1,79 @@ - - - - -lwres_packet

lwres_packet

Name

lwres_lwpacket_renderheader, lwres_lwpacket_parseheader -- lightweight resolver packet handling functions

Synopsis

#include <lwres/lwpacket.h>

lwres_result_t -lwres_lwpacket_renderheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt);

lwres_result_t -lwres_lwpacket_parseheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt);

DESCRIPTION

These functions rely on a -struct lwres_lwpacket + + + + +lwres_packet + + +

+
+
+

Name

+

lwres_lwpacket_renderheader, lwres_lwpacket_parseheader — lightweight resolver packet handling functions

+
+
+

Synopsis

+
+
#include <lwres/lwpacket.h>
+ + + + + + + + + + + +
+lwres_result_t +lwres_lwpacket_renderheader( ,
   +);
+ + + + + + + + + + + +
+lwres_result_t +lwres_lwpacket_parseheader( ,
   +);
+
+
+
+

DESCRIPTION

+

+These functions rely on a +struct lwres_lwpacket which is defined in -lwres/lwpacket.h. +lwres/lwpacket.h. -

typedef struct lwres_lwpacket lwres_lwpacket_t;
+

+
+typedef struct lwres_lwpacket lwres_lwpacket_t;
 
 struct lwres_lwpacket {
         lwres_uint32_t          length;
@@ -115,248 +85,132 @@ struct lwres_lwpacket {
         lwres_uint32_t          recvlength;
         lwres_uint16_t          authtype;
         lwres_uint16_t          authlength;
-};
The elements of this structure are:
-
length
the overall packet length, including the entire packet header.
+};
+
+

+

+

+The elements of this structure are: +

+
+
length
+

+the overall packet length, including the entire packet header. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls.

version

the header format. There is currently only one format, -LWRES_LWPACKETVERSION_0. +calls. +

+
version
+

+the header format. There is currently only one format, +LWRES_LWPACKETVERSION_0. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls.

pktflags

library-defined flags for this packet: for instance whether the packet +calls. +

+
pktflags
+

+library-defined flags for this packet: for instance whether the packet is a request or a reply. Flag values can be set, but not defined by the caller. This field is filled in by the application wit the exception of the LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the -lwres_gabn_*() and lwres_gnba_*() calls.

serial

is set by the requestor and is returned in all replies. If two or more +lwres_gabn_*() and lwres_gnba_*() calls. +

+
serial
+

+is set by the requestor and is returned in all replies. If two or more packets from the same source have the same serial number and are from the same source, they are assumed to be duplicates and the latter ones may be dropped. -This field must be set by the application.

opcode

indicates the operation. +This field must be set by the application. +

+
opcode
+

+indicates the operation. Opcodes between 0x00000000 and 0x03ffffff are reserved for use by the lightweight resolver library. Opcodes between 0x04000000 and 0xffffffff are application defined. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls.

result

is only valid for replies. +calls. +

+
result
+

+is only valid for replies. Results between 0x04000000 and 0xffffffff are application defined. Results between 0x00000000 and 0x03ffffff are reserved for library use. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() -calls.

recvlength

is the maximum buffer size that the receiver can handle on requests +calls. +

+
recvlength
+

+is the maximum buffer size that the receiver can handle on requests and the size of the buffer needed to satisfy a request when the buffer is too large for replies. -This field is supplied by the application.

authtype

defines the packet level authentication that is used. +This field is supplied by the application. +

+
authtype
+

+defines the packet level authentication that is used. Authorisation types between 0x1000 and 0xffff are application defined and types between 0x0000 and 0x0fff are reserved for library use. -Currently these are not used and must be zero.

authlen

gives the length of the authentication data. -Since packet authentication is currently not used, this must be zero.

The following opcodes are currently defined: -

NOOP

Success is always returned and the packet contents are echoed. -The lwres_noop_*() functions should be used for this type.

GETADDRSBYNAME

returns all known addresses for a given name. -The lwres_gabn_*() functions should be used for this type.

GETNAMEBYADDR

return the hostname for the given address. -The lwres_gnba_*() functions should be used for this type.

lwres_lwpacket_renderheader() transfers the +Currently these are not used and must be zero. +

+
authlen
+

+gives the length of the authentication data. +Since packet authentication is currently not used, this must be zero. +

+
+

+

+

+The following opcodes are currently defined: +

+
+
NOOP
+

+Success is always returned and the packet contents are echoed. +The lwres_noop_*() functions should be used for this type. +

+
GETADDRSBYNAME
+

+returns all known addresses for a given name. +The lwres_gabn_*() functions should be used for this type. +

+
GETNAMEBYADDR
+

+return the hostname for the given address. +The lwres_gnba_*() functions should be used for this type. +

+
+

+

+

+lwres_lwpacket_renderheader() transfers the contents of lightweight resolver packet structure -lwres_lwpacket_t *pkt in network +lwres_lwpacket_t *pkt in network byte order to the lightweight resolver buffer, -*b.

lwres_lwpacket_parseheader() performs the +*b. +

+

+lwres_lwpacket_parseheader() performs the converse operation. It transfers data in network byte order from -buffer *b to resolver packet -*pkt. The contents of the buffer -b should correspond to a -lwres_lwpacket_t.

RETURN VALUES

Successful calls to -lwres_lwpacket_renderheader() and -lwres_lwpacket_parseheader() return -LWRES_R_SUCCESS. If there is insufficient -space to copy data between the buffer *b and -lightweight resolver packet *pkt both functions -return LWRES_R_UNEXPECTEDEND.

+buffer *b to resolver packet +*pkt. The contents of the buffer +b should correspond to a +lwres_lwpacket_t. +

+
+
+

RETURN VALUES

+

Successful calls to +lwres_lwpacket_renderheader() and +lwres_lwpacket_parseheader() return +LWRES_R_SUCCESS. If there is insufficient +space to copy data between the buffer *b and +lightweight resolver packet *pkt both functions +return LWRES_R_UNEXPECTEDEND. +

+
+ + diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.3 b/contrib/bind9/lib/lwres/man/lwres_resutil.3 index d73122d338c..5d4cfc050c9 100644 --- a/contrib/bind9/lib/lwres/man/lwres_resutil.3 +++ b/contrib/bind9/lib/lwres/man/lwres_resutil.3 @@ -1,68 +1,68 @@ -.\" Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -.\" Copyright (C) 2000, 2001 Internet Software Consortium. -.\" +.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (C) 2000, 2001 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, +.\" 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: lwres_resutil.3,v 1.14.2.1.8.1 2004/03/06 07:41:44 marka Exp $ +.\" $Id: lwres_resutil.3,v 1.14.2.1.8.5 2005/10/13 02:33:54 marka Exp $ .\" -.TH "LWRES_RESUTIL" "3" "Jun 30, 2000" "BIND9" "" -.SH NAME +.hy 0 +.ad l +.\" ** You probably do not want to edit this file directly ** +.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1). +.\" Instead of manually editing it, you probably should edit the DocBook XML +.\" source for it and then use the DocBook XSL Stylesheets to regenerate it. +.TH "LWRES_RESUTIL" "3" "Jun 30, 2000" "BIND9" "BIND9" +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.SH "NAME" lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr \- lightweight resolver utility functions -.SH SYNOPSIS -\fB#include -.sp -.na -lwres_result_t -lwres_string_parse(lwres_buffer_t *b, char **c, lwres_uint16_t *len); -.ad -.sp -.na -lwres_result_t -lwres_addr_parse(lwres_buffer_t *b, lwres_addr_t *addr); -.ad -.sp -.na -lwres_result_t -lwres_getaddrsbyname(lwres_context_t *ctx, const char *name, lwres_uint32_t addrtypes, lwres_gabnresponse_t **structp); -.ad -.sp -.na -lwres_result_t -lwres_getnamebyaddr(lwres_context_t *ctx, lwres_uint32_t addrtype, lwres_uint16_t addrlen, const unsigned char *addr, lwres_gnbaresponse_t **structp); -.ad -\fR +.SH "SYNOPSIS" +.nf +#include +.fi +.HP 34 +\fBlwres_result_t\ \fBlwres_string_parse\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBchar\ **c\fR\fB, \fR\fBlwres_uint16_t\ *len\fR\fB);\fR +.HP 32 +\fBlwres_result_t\ \fBlwres_addr_parse\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_addr_t\ *addr\fR\fB);\fR +.HP 36 +\fBlwres_result_t\ \fBlwres_getaddrsbyname\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBconst\ char\ *name\fR\fB, \fR\fBlwres_uint32_t\ addrtypes\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR +.HP 35 +\fBlwres_result_t\ \fBlwres_getnamebyaddr\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_uint32_t\ addrtype\fR\fB, \fR\fBlwres_uint16_t\ addrlen\fR\fB, \fR\fBconst\ unsigned\ char\ *addr\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR .SH "DESCRIPTION" .PP -\fBlwres_string_parse()\fR retrieves a DNS-encoded -string starting the current pointer of lightweight resolver buffer -\fIb\fR: i.e. b->current. -When the function returns, the address of the first byte of the -encoded string is returned via \fI*c\fR and the -length of that string is given by \fI*len\fR. The -buffer's current pointer is advanced to point at the character -following the string length, the encoded string, and the trailing -\fBNULL\fR character. +\fBlwres_string_parse()\fR +retrieves a DNS\-encoded string starting the current pointer of lightweight resolver buffer +\fIb\fR: i.e. +\fBb\->current\fR. When the function returns, the address of the first byte of the encoded string is returned via +\fI*c\fR +and the length of that string is given by +\fI*len\fR. The buffer's current pointer is advanced to point at the character following the string length, the encoded string, and the trailing +\fBNULL\fR +character. .PP -\fBlwres_addr_parse()\fR extracts an address from the -buffer \fIb\fR. The buffer's current pointer -b->current is presumed to point at an encoded -address: the address preceded by a 32-bit protocol family identifier -and a 16-bit length field. The encoded address is copied to -addr->address and -addr->length indicates the size in bytes of -the address that was copied. b->current is -advanced to point at the next byte of available data in the buffer -following the encoded address. +\fBlwres_addr_parse()\fR +extracts an address from the buffer +\fIb\fR. The buffer's current pointer +\fBb\->current\fR +is presumed to point at an encoded address: the address preceded by a 32\-bit protocol family identifier and a 16\-bit length field. The encoded address is copied to +\fBaddr\->address\fR +and +\fBaddr\->length\fR +indicates the size in bytes of the address that was copied. +\fBb\->current\fR +is advanced to point at the next byte of available data in the buffer following the encoded address. .PP \fBlwres_getaddrsbyname()\fR and @@ -84,31 +84,40 @@ typedef struct { void *base; size_t baselen; } lwres_gabnresponse_t; -.sp .fi -The contents of this structure are not manipulated directly but -they are controlled through the -\fBlwres_gabn\fR(3) +.sp +The contents of this structure are not manipulated directly but they are controlled through the +\fBlwres_gabn\fR(3 ) functions. .PP The lightweight resolver uses -\fBlwres_getaddrsbyname()\fR to perform foward lookups. -Hostname \fIname\fR is looked up using the resolver -context \fIctx\fR for memory allocation. -\fIaddrtypes\fR is a bitmask indicating which type of -addresses are to be looked up. Current values for this bitmask are -\fBLWRES_ADDRTYPE_V4\fR for IPv4 addresses and -\fBLWRES_ADDRTYPE_V6\fR for IPv6 addresses. Results of the -lookup are returned in \fI*structp\fR. +\fBlwres_getaddrsbyname()\fR +to perform foward lookups. Hostname +\fIname\fR +is looked up using the resolver context +\fIctx\fR +for memory allocation. +\fIaddrtypes\fR +is a bitmask indicating which type of addresses are to be looked up. Current values for this bitmask are +\fBLWRES_ADDRTYPE_V4\fR +for IPv4 addresses and +\fBLWRES_ADDRTYPE_V6\fR +for IPv6 addresses. Results of the lookup are returned in +\fI*structp\fR. .PP -\fBlwres_getnamebyaddr()\fR performs reverse lookups. -Resolver context \fIctx\fR is used for memory -allocation. The address type is indicated by -\fIaddrtype\fR: \fBLWRES_ADDRTYPE_V4\fR or -\fBLWRES_ADDRTYPE_V6\fR. The address to be looked up is given -by \fIaddr\fR and its length is -\fIaddrlen\fR bytes. The result of the function call -is made available through \fI*structp\fR. +\fBlwres_getnamebyaddr()\fR +performs reverse lookups. Resolver context +\fIctx\fR +is used for memory allocation. The address type is indicated by +\fIaddrtype\fR: +\fBLWRES_ADDRTYPE_V4\fR +or +\fBLWRES_ADDRTYPE_V6\fR. The address to be looked up is given by +\fIaddr\fR +and its length is +\fIaddrlen\fR +bytes. The result of the function call is made available through +\fI*structp\fR. .SH "RETURN VALUES" .PP Successful calls to @@ -116,24 +125,23 @@ Successful calls to and \fBlwres_addr_parse()\fR return -LWRES_R_SUCCESS. +\fBLWRES_R_SUCCESS.\fR Both functions return -LWRES_R_FAILURE +\fBLWRES_R_FAILURE\fR if the buffer is corrupt or -LWRES_R_UNEXPECTEDEND -if the buffer has less space than expected for the components of the -encoded string or address. +\fBLWRES_R_UNEXPECTEDEND\fR +if the buffer has less space than expected for the components of the encoded string or address. .PP \fBlwres_getaddrsbyname()\fR returns -LWRES_R_SUCCESS +\fBLWRES_R_SUCCESS\fR on success and it returns -LWRES_R_NOTFOUND +\fBLWRES_R_NOTFOUND\fR if the hostname \fIname\fR could not be found. .PP -LWRES_R_SUCCESS +\fBLWRES_R_SUCCESS\fR is returned by a successful call to \fBlwres_getnamebyaddr()\fR. .PP @@ -142,11 +150,10 @@ Both and \fBlwres_getnamebyaddr()\fR return -LWRES_R_NOMEMORY +\fBLWRES_R_NOMEMORY\fR when memory allocation requests fail and -LWRES_R_UNEXPECTEDEND -if the buffers used for sending queries and receiving replies are too -small. +\fBLWRES_R_UNEXPECTEDEND\fR +if the buffers used for sending queries and receiving replies are too small. .SH "SEE ALSO" .PP \fBlwres_buffer\fR(3), diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook index e5f891fa75f..7ab2146b40b 100644 --- a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook +++ b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook @@ -1,7 +1,9 @@ - +]> - + @@ -30,6 +32,19 @@ BIND9 + + + 2004 + 2005 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + Internet Software Consortium. + + + lwres_string_parse lwres_addr_parse diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.html b/contrib/bind9/lib/lwres/man/lwres_resutil.html index cc45556adc4..4cee0c7804d 100644 --- a/contrib/bind9/lib/lwres/man/lwres_resutil.html +++ b/contrib/bind9/lib/lwres/man/lwres_resutil.html @@ -1,186 +1,163 @@ - - - - -lwres_resutil

lwres_resutil

Name

lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr -- lightweight resolver utility functions

Synopsis

#include <lwres/lwres.h>

lwres_result_t -lwres_string_parse(lwres_buffer_t *b, char **c, lwres_uint16_t *len);

lwres_result_t -lwres_addr_parse(lwres_buffer_t *b, lwres_addr_t *addr);

lwres_result_t -lwres_getaddrsbyname(lwres_context_t *ctx, const char *name, lwres_uint32_t addrtypes, lwres_gabnresponse_t **structp);

lwres_result_t -lwres_getnamebyaddr(lwres_context_t *ctx, lwres_uint32_t addrtype, lwres_uint16_t addrlen, const unsigned char *addr, lwres_gnbaresponse_t **structp);

DESCRIPTION

lwres_string_parse() retrieves a DNS-encoded + + + + +lwres_resutil + + +

+
+
+

Name

+

lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr — lightweight resolver utility functions

+
+
+

Synopsis

+
+
#include <lwres/lwres.h>
+ + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_string_parse( ,
  ,
   +);
+ + + + + + + + + + + +
+lwres_result_t +lwres_addr_parse( ,
   +);
+ + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_getaddrsbyname( ,
  ,
  ,
   +);
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+lwres_result_t +lwres_getnamebyaddr( ,
  ,
  ,
  ,
   +);
+
+
+
+

DESCRIPTION

+

+lwres_string_parse() retrieves a DNS-encoded string starting the current pointer of lightweight resolver buffer -b: i.e. b->current. +b: i.e. b->current. When the function returns, the address of the first byte of the -encoded string is returned via *c and the -length of that string is given by *len. The +encoded string is returned via *c and the +length of that string is given by *len. The buffer's current pointer is advanced to point at the character following the string length, the encoded string, and the trailing -NULL character.

lwres_addr_parse() extracts an address from the -buffer b. The buffer's current pointer -b->current is presumed to point at an encoded +NULL character. +

+

+lwres_addr_parse() extracts an address from the +buffer b. The buffer's current pointer +b->current is presumed to point at an encoded address: the address preceded by a 32-bit protocol family identifier and a 16-bit length field. The encoded address is copied to -addr->address and -addr->length indicates the size in bytes of -the address that was copied. b->current is +addr->address and +addr->length indicates the size in bytes of +the address that was copied. b->current is advanced to point at the next byte of available data in the buffer -following the encoded address.

lwres_getaddrsbyname() +following the encoded address. +

+

+lwres_getaddrsbyname() and -lwres_getnamebyaddr() +lwres_getnamebyaddr() use the -lwres_gnbaresponse_t +lwres_gnbaresponse_t structure defined below: -

typedef struct {
+

+
+typedef struct {
         lwres_uint32_t          flags;
         lwres_uint16_t          naliases;
         lwres_uint16_t          naddrs;
@@ -191,197 +168,88 @@ CLASS="PROGRAMLISTING"
         lwres_addrlist_t        addrs;
         void                   *base;
         size_t                  baselen;
-} lwres_gabnresponse_t;

+} lwres_gabnresponse_t;
+
+

The contents of this structure are not manipulated directly but they are controlled through the -lwres_gabn(3) -functions.

The lightweight resolver uses -lwres_getaddrsbyname() to perform foward lookups. -Hostname name is looked up using the resolver -context ctx for memory allocation. -addrtypes is a bitmask indicating which type of +lwres_gabn(3 +) +functions. +

+

+The lightweight resolver uses +lwres_getaddrsbyname() to perform foward lookups. +Hostname name is looked up using the resolver +context ctx for memory allocation. +addrtypes is a bitmask indicating which type of addresses are to be looked up. Current values for this bitmask are -LWRES_ADDRTYPE_V4 for IPv4 addresses and -LWRES_ADDRTYPE_V6 for IPv6 addresses. Results of the -lookup are returned in *structp.

lwres_getnamebyaddr() performs reverse lookups. -Resolver context ctx is used for memory +LWRES_ADDRTYPE_V4 for IPv4 addresses and +LWRES_ADDRTYPE_V6 for IPv6 addresses. Results of the +lookup are returned in *structp. +

+

+lwres_getnamebyaddr() performs reverse lookups. +Resolver context ctx is used for memory allocation. The address type is indicated by -addrtype: LWRES_ADDRTYPE_V4 or -LWRES_ADDRTYPE_V6. The address to be looked up is given -by addr and its length is -addrlen bytes. The result of the function call -is made available through *structp.

RETURN VALUES

Successful calls to -lwres_string_parse() +addrtype: LWRES_ADDRTYPE_V4 or +LWRES_ADDRTYPE_V6. The address to be looked up is given +by addr and its length is +addrlen bytes. The result of the function call +is made available through *structp. +

+
+
+

RETURN VALUES

+

+Successful calls to +lwres_string_parse() and -lwres_addr_parse() +lwres_addr_parse() return -LWRES_R_SUCCESS. +LWRES_R_SUCCESS. Both functions return -LWRES_R_FAILURE +LWRES_R_FAILURE if the buffer is corrupt or -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND if the buffer has less space than expected for the components of the -encoded string or address.

lwres_getaddrsbyname() +encoded string or address. +

+

+lwres_getaddrsbyname() returns -LWRES_R_SUCCESS +LWRES_R_SUCCESS on success and it returns -LWRES_R_NOTFOUND +LWRES_R_NOTFOUND if the hostname -name -could not be found.

LWRES_R_SUCCESS +name +could not be found. +

+

+LWRES_R_SUCCESS is returned by a successful call to -lwres_getnamebyaddr().

Both -lwres_getaddrsbyname() +lwres_getnamebyaddr(). +

+

+Both +lwres_getaddrsbyname() and -lwres_getnamebyaddr() +lwres_getnamebyaddr() return -LWRES_R_NOMEMORY +LWRES_R_NOMEMORY when memory allocation requests fail and -LWRES_R_UNEXPECTEDEND +LWRES_R_UNEXPECTEDEND if the buffers used for sending queries and receiving replies are too -small.

SEE ALSO

lwres_buffer(3), +small. +

+
+
+

SEE ALSO

+

+lwres_buffer(3), -lwres_gabn(3).

+lwres_gabn(3). +

+
+
+ diff --git a/contrib/bind9/lib/lwres/print.c b/contrib/bind9/lib/lwres/print.c index e8dd37a7349..15522284e5d 100644 --- a/contrib/bind9/lib/lwres/print.c +++ b/contrib/bind9/lib/lwres/print.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2001, 2003 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: print.c,v 1.2.4.3 2004/09/16 07:01:13 marka Exp $ */ +/* $Id: print.c,v 1.2.4.7 2005/10/14 01:38:51 marka Exp $ */ #include @@ -25,11 +25,13 @@ #define LWRES__PRINT_SOURCE /* Used to get the lwres_print_* prototypes. */ -#include +#include #include "assert_p.h" #include "print_p.h" +#define LWRES_PRINT_QUADFORMAT LWRES_PLATFORM_QUADFORMAT + int lwres__print_sprintf(char *str, const char *format, ...) { va_list ap; @@ -70,7 +72,6 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { int left; int plus; int space; - int neg; long long tmpi; unsigned long long tmpui; unsigned long width; @@ -110,7 +111,7 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { /* * Reset flags. */ - dot = neg = space = plus = left = zero = alt = h = l = q = 0; + dot = space = plus = left = zero = alt = h = l = q = 0; width = precision = 0; head = ""; length = pad = zeropad = 0; @@ -242,7 +243,7 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { head = ""; tmpui = tmpi; } - sprintf(buf, "%llu", + sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "u", tmpui); goto printint; case 'o': @@ -254,7 +255,9 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { else tmpui = va_arg(ap, int); sprintf(buf, - alt ? "%#llo" : "%llo", tmpui); + alt ? "%#" LWRES_PRINT_QUADFORMAT "o" + : "%" LWRES_PRINT_QUADFORMAT "o", + tmpui); goto printint; case 'u': if (q) @@ -264,7 +267,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { tmpui = va_arg(ap, unsigned long int); else tmpui = va_arg(ap, unsigned int); - sprintf(buf, "%llu", tmpui); + sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "u", + tmpui); goto printint; case 'x': if (q) @@ -279,7 +283,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { if (precision > 2U) precision -= 2; } - sprintf(buf, "%llx", tmpui); + sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "x", + tmpui); goto printint; case 'X': if (q) @@ -294,7 +299,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) { if (precision > 2U) precision -= 2; } - sprintf(buf, "%llX", tmpui); + sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "X", + tmpui); goto printint; printint: if (precision != 0U || width != 0U) { diff --git a/contrib/bind9/lib/lwres/strtoul.c b/contrib/bind9/lib/lwres/strtoul.c new file mode 100644 index 00000000000..9cda1947724 --- /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 + +#include +#include +#include + +#include + +#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); +} diff --git a/contrib/bind9/make/rules.in b/contrib/bind9/make/rules.in index 45bca273240..6b83bce434e 100644 --- a/contrib/bind9/make/rules.in +++ b/contrib/bind9/make/rules.in @@ -1,4 +1,4 @@ -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") # Copyright (C) 1998-2003 Internet Software Consortium. # # Permission to use, copy, modify, and distribute this software for any @@ -13,7 +13,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: rules.in,v 1.40.2.5.4.4 2004/07/20 07:02:00 marka Exp $ +# $Id: rules.in,v 1.40.2.5.4.8 2005/10/28 01:53:44 marka Exp $ ### ### Common Makefile rules for BIND 9. @@ -112,8 +112,7 @@ ALL_CPPFLAGS = \ ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \ ${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES} -ALL_CFLAGS = ${EXT_CFLAGS} ${CFLAGS} \ - ${ALL_CPPFLAGS} \ +ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \ ${ALWAYS_WARNINGS} ${STD_CWARNINGS} ${CWARNINGS} .c.@O@: @@ -132,7 +131,7 @@ cleandir: distclean superclean: maintainer-clean clean distclean maintainer-clean:: - rm -f *.@O@ *.lo *.la core *.core .depend + rm -f *.@O@ *.o *.lo *.la core *.core .depend rm -rf .libs distclean maintainer-clean:: @@ -180,6 +179,16 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_DATA = @INSTALL_DATA@ +### +### Programs used when generating documentation. It's ok for these +### not to exist when not generating documentation. +### + +XSLTPROC = @XSLTPROC@ --novalid +PERL = @PERL@ +LATEX = @LATEX@ +PDFLATEX = @PDFLATEX@ + ### ### DocBook -> HTML ### DocBook -> man page @@ -187,42 +196,29 @@ INSTALL_DATA = @INSTALL_DATA@ .SUFFIXES: .docbook .html .1 .2 .3 .4 .5 .6 .7 .8 -OPENJADE = @OPENJADE@ -SGMLCATALOG = @SGMLCATALOG@ -HTMLSTYLE = @HTMLSTYLE@ -XMLDCL = @XMLDCL@ -DOCBOOK2MANSPEC = @DOCBOOK2MANSPEC@ -JADETEX = @JADETEX@ -PDFJADETEX = @PDFJADETEX@ - -ONSGMLS = onsgmls -SGMLSPL = sgmlspl - -# -# Note: this rule assumes the docbook.dsl stylesheet -# is being used. If another stylesheet is used, the -# filename 'r1.htm' in the rule might have to be -# be changed. -# .docbook.html: - ${OPENJADE} -c ${SGMLCATALOG} -t sgml -d ${HTMLSTYLE} $< - echo "" >> r1.htm - cat ${top_srcdir}/docutil/HTML_COPYRIGHT r1.htm > $@ - rm -f r1.htm + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-docbook-html.xsl $< .docbook.1: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.2: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.3: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.4: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.5: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.6: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.7: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< + .docbook.8: - sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@ + ${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $< diff --git a/contrib/bind9/version b/contrib/bind9/version index 48786a62326..5c9032a3ed0 100644 --- a/contrib/bind9/version +++ b/contrib/bind9/version @@ -1,10 +1,10 @@ -# $Id: version,v 1.26.2.17.2.17 2005/03/03 04:51:08 marka Exp $ +# $Id: version,v 1.26.2.17.2.21 2005/12/14 00:43:14 marka Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # MAJORVER=9 MINORVER=3 -PATCHVER=1 +PATCHVER=2 RELEASETYPE= RELEASEVER=